při přípravě testovací prostředí (virtuální stroje) pro migraci z Lotus Notes Exchange Server 2007, jsem narazil na zajímavý problém: Všechny zprávy odeslané příjemcům interně (v rámci Exchange) nebo externě (Lotus Notes nebo Internet), skončí ve složce Koncepty.

v uživatelském rozhraní nebyla generována žádná varování, chybové zprávy nebo NDR. To bylo přinejmenším záhadné. Rozhodl jsem se tedy udělat to, co by většina z vás ostřílených IT profesionálů považovala za další logický krok: kopat hlouběji.

začal jsem prohlížením protokolů událostí na serverech Exchange Mailbox a Hub Transport. V aplikačním protokolu serveru poštovní schránky jsem si všiml události ID 1009-varovné události se zdrojem a kategorií označenou jako „MSExchangeMailSubmission“. Popis události byl na místě: „služba Microsoft Exchange Mail Submission v současné době není schopna kontaktovat žádné servery pro přepravu rozbočovačů na místním webu služby Active Directory. Servery mohou být v tuto chvíli příliš zaneprázdněny na to, aby přijaly nová připojení.“

předpokládám, že dlužím velké „děkuji“ osobě v Microsoftu, která přišla se smysluplnými štítky pro zdroj a kategorii událostí-právě takové věci považujeme za samozřejmost.

každopádně, protože existovaly silné náznaky, že problém existuje na serveru Hub Transport, začal jsem zkoumat protokol aplikací serveru Hub Transport. Nebyly zaznamenány žádné chyby, ale bylo zde jedno varování: ID události: 15002, zdroj: MSExchangeTransport, Kategorie: ResourceManager. Ve svém spěchu k vyřešení problému jsem ignoroval varovnou událost a předpokládal jsem, že server si jen stěžuje na systémové prostředky na virtuálním stroji-ne daleko od pravdy.

mezitím jsem použil Telnet k připojení k portu 25 dopravního serveru rozbočovače a okamžitě jsem dostal odpověď, že:

452 4.3.1 nedostatečné systémové prostředky

spojení s hostitelem ztraceno

to mě přimělo blíže se podívat na ID události varování: 15002 v protokolu aplikace Dopravního serveru rozbočovače. Pečlivě jsem si přečetl popis:

“ tlak zdroje je konstantní na vysoké úrovni. Statistiky:

Microsoft-Základní průvodce zapojením koncových uživatelů Microsoft Teams
Základní průvodce pro zapojení koncových uživatelů Microsoft Teams

provedeme vás 10 osvědčenými postupy, úvahami a návrhy, které mohou obohatit nasazení týmů Microsoft a zajistit přijetí i zapojení koncových uživatelů.

získejte průvodce

fronta databáze a místo na disku („C: Program FilesMicrosoftExchange ServerTransportRolesdataQueuemail.que“) = 63%

fronta databáze protokolování místa na disku („C: Program FilesMicrosoftExchange ServerTransportRolesdataQueue“) = 63%

verze kbelíky = 1

Private bytes = 16%

fyzické zatížení paměti = 53%

příchozí odeslání pošty z jiných serverů pro přepravu náboje, internetu, adresáře vyzvednutí, adresáře pro přehrávání a serveru poštovní schránky, pokud je na Serveru pro přepravu náboje, se zastavilo.

načítání e-mailů z databáze ve frontě, pokud je k dispozici, pokračuje.“

rolování dolů na popis a vlastně čtení detailů pomohlo J ale počkejte, měl jsem 2.94 GB volného místa na mém virtuálním počítači se systémem role serveru hub transport server. Tak proč si Exchange stěžoval na místo na disku?

po nějakém výzkumu jsem narazil na tento článek na Technetu, který mě seznámil s ne tak známým, ale neotřelým konceptem zavedeným v Exchange Server 2007 – Back Pressure. I když si můžete přečíst další podrobnosti o tématu na odkazovaných stránkách, v podstatě back pressure je funkce monitorování systémových prostředků zabudovaná do rolí Exchange Server 2007 Hub Transport a Edge Server a ovlivňuje doručování zpráv v závislosti na stavu systémových prostředků.

po použití vzorce Exchange používá k výpočtu prahových hodnot pro přepravní službu (100*(velikost pevného disku – 4 GB) / velikost pevného disku) jsem si uvědomil, že výsledná vysoká hodnota pro databázi fronty a místo na disku v mém prostředí (50%) byla vyšší než vysoká prahová hodnota vypočtená společností Exchange (49%).

Tip: Pokud je volné místo menší než 4 GB, je úroveň využití pevného disku považována za vysokou.

takže moje volby, jak dostat poštu tekoucí byly:

  • Zvyšte dostupné místo na disku (doporučeno pro produkční prostředí) nebo
  • Zvyšte příslušnou prahovou hodnotu (nedoporučuje se pro produkční prostředí)

protože jsem používal testovací prostředí, rozhodl jsem se jít snadnou cestou a přepsat výchozí výpočty pro vysokou úroveň využití pevného disku zadáním nové hodnoty v EdgeTransport.exe.konfigurační soubor, který lze nalézt v adresáři C: Program FilesMicrosoftExchange ServerBin. Změnil jsem výchozí hodnotu pro PercentageDatabaseDiskSpaceUsedHighthreshold z „0“ na “ 80 “ a restartoval službu Microsoft Exchange Transport.

Ověřil jsem, že se varovná zpráva neobjevila znovu po restartu služby a pokusil jsem se znovu odeslat zprávu pomocí OWA-SUCCESSFUL!! Také jsem si všiml, že zpráva, která byla dříve umístěna do složky návrhu (během vydání), byla také úspěšně doručena bez jakéhokoli ručního zásahu.

zatímco zpětný tlak je úhlednou funkcí výměny a je určen k elegantnějšímu řešení problémů se systémovými zdroji, doufám, že společnosti budou i nadále investovat do účinných monitorovacích řešení pro výměnu, jako je správce operací System Center, aby se předešlo problémům, jako je ten popsaný výše. Výjimkou kurzu je scénář, kdy testujete výměnné řešení v testovacím prostředí, kde možná nebudete mít luxus mít systémové prostředky výrobní třídy.