när jag förberedde en testmiljö (virtuella maskiner) för migrering från Lotus Notes till Exchange Server 2007 kom jag över en intressant fråga: alla meddelanden som skickades till mottagare internt (inom Exchange) eller externt (Lotus Notes eller Internet) skulle hamna i mappen Utkast.

inga varningar, felmeddelanden eller NDR genererades i användargränssnittet. Detta var ganska förbryllande minst sagt. Så jag bestämde mig för att göra vad de flesta av er erfarna IT-proffs skulle betrakta som nästa logiska steg: gräva djupare.

jag började med att titta igenom händelseloggar på Exchange brevlåda och nav Transportservrar. I applikationsloggen på Postlådeservern märkte jag Händelse-ID 1009-en varningshändelse med källan och kategorin märkt som ”MSExchangeMailSubmission”. Beskrivningen av händelsen var på plats: ”Microsoft Exchange Mail Submission service kan för närvarande inte kontakta några Navtransportservrar på den lokala Active Directory-webbplatsen. Servrarna kan vara för upptagna för att acceptera nya anslutningar just nu.”

jag antar att jag är skyldig ett stort ”tack” till personen på Microsoft som kom med meningsfulla etiketter för Händelsekälla och kategori – bara den typ av saker vi tar för givet.

hur som helst, eftersom det fanns en stark indikation på att problemet fanns på Navtransportservern, började jag undersöka applikationsloggen på Navtransportservern. Det fanns inga fel loggade, men det fanns en varning: Händelse-ID: 15002, källa: MSExchangeTransport, Kategori: ResourceManager. I min brådska att lösa problemet ignorerade jag varningshändelsen och antog att servern bara klagade över systemresurser på den virtuella maskinen – inte långt ifrån sanningen verkligen.

under tiden använde jag Telnet för att ansluta till port 25 på navtransportservern och fick omedelbart ett svar som anger:

452 4.3.1 otillräckliga systemresurser

anslutning till värd förlorad

detta fick mig att titta närmare på Varningshändelsens ID: 15002 i programloggen på navtransportservern. Jag läste beskrivningen noggrant:

”resurstrycket är konstant vid högt. Statistik:

Microsoft-den väsentliga guiden till Microsoft Teams Slutanvändarengagemang
den väsentliga guiden till Microsoft Teams Slutanvändarengagemang

vi tar dig igenom 10 bästa metoder, överväganden och förslag som kan berika din Microsoft Teams-distribution och säkerställa både slutanvändarens adoption och engagemang.

hämta guiden

Ködatabas och diskutrymme (”C:Program FilesMicrosoftExchange ServerTransportRolesdataQueuemail.que”) = 63%

kö databas loggning diskutrymme (”C: Program FilesMicrosoftExchange ServerTransportRolesdataQueue”) = 63%

version hinkar = 1

privata byte = 16%

fysiskt minne belastning = 53%

inkommande e-post från andra nav transportservrar, Internet, Pickup katalogen, Replay katalogen, och brevlådan servern, om det är på ett nav Transportserver, har slutat.

inläsning av e-post från ködatabasen, om tillgänglig, fortsätter.”

rulla ner på beskrivningen och faktiskt läsa detaljerna hjälpte J men vänta, jag hade 2.94 GB ledigt utrymme på min virtuella maskin som kör navet transport server Roll. Så varför klagade Exchange på diskutrymme?

efter lite forskning kom jag över den här artikeln om Technet som introducerade mig till ett inte så välkänt men nytt koncept som introducerades i Exchange Server 2007 – Back Pressure. Medan du kan läsa mer information om ämnet på refererade sidor är i huvudsak back pressure en systemresursövervakningsfunktion inbyggd i Exchange Server 2007 Hub Transport och Edge Server roller och påverkar meddelandeleverans beroende på systemresursernas tillstånd.

efter att ha använt formeln Exchange använder för att beräkna tröskelvärdena för transporttjänsten (100 * (hårddiskstorlek – 4 GB) / hårddiskstorlek) insåg jag att det resulterande höga värdet för Ködatabas och diskutrymme i min miljö (50%) var högre än den höga tröskeln beräknad av Exchange (49%).

tips: om tillgängligt ledigt utrymme är mindre än 4 GB anses hårddiskens användningsnivå vara hög.

så mina val för att få e-postflöde var:

  • öka Tillgängligt diskutrymme (rekommenderas för produktionsmiljöer) eller
  • öka lämplig tröskel (rekommenderas inte för produktionsmiljöer)

eftersom jag använde en testmiljö bestämde jag mig för att ta den enkla vägen och åsidosätta standardberäkningarna för den höga hårddiskutnyttjandet genom att ange ett nytt värde i EdgeTransport.exe.konfigurationsfil som finns i C: Program FilesMicrosoftExchange ServerBin katalog. Jag ändrade standardvärdet för PercentageDatabaseDiskSpaceUsedHighthreshold från ”0” till ”80” och startade om Microsoft Exchange transporttjänst.

jag verifierade att varningsmeddelandet inte visades igen efter omstart av tjänsten och försökte skicka ett meddelande till mig själv igen med OWA – SUCCESSFUL!! Jag märkte också att meddelandet som tidigare placerades i utkastmappen (under problemet) också levererades framgångsrikt utan manuell ingripande.

medan mottryck är en snygg funktion i utbyte och är avsedd att ta itu med systemresursfrågor mer graciöst, hoppas jag att företag kommer att fortsätta att investera i effektiva övervakningslösningar för utbyte som System Center Operations Manager för att undvika problem som den som beskrivs ovan. Undantaget för-kursen är ett scenario där du testar en Exchange-lösning i en testmiljö där du kanske inte har lyxen att ha produktionsklassens systemresurser.