tesztkörnyezet (virtuális gépek) előkészítése során a Lotus Notes-ról Az Exchange Server 2007-re való áttéréshez érdekes problémát találtam: minden üzenet, amelyet a címzetteknek belsőleg (az Exchange-en belül) vagy külsőleg (Lotus Notes vagy Internet) küldtek, a Piszkozatok mappába kerül.

nem jött létre figyelmeztetés, hibaüzenet vagy NDR a felhasználói felületen. Ez enyhén szólva meglehetősen rejtélyes volt. Ezért úgy döntöttem, hogy azt teszem, amit a legtöbb tapasztalt informatikai szakember a következő logikus lépésnek tart: mélyebbre ásni.

azzal kezdtem, hogy átnéztem az Exchange postaláda és a Hub Transport szerverek eseménynaplóit. A postaláda-kiszolgáló alkalmazásnaplójában észrevettem az 1009 eseményazonosítót – egy figyelmeztető eseményt, amelynek forrása és kategóriája “MSExchangeMailSubmission”. Az esemény leírása a következő volt:” a Microsoft Exchange Mail Submission service jelenleg nem tud kapcsolatba lépni a helyi Active Directory webhelyen található Hub-átviteli kiszolgálókkal. Lehet, hogy a szerverek túl elfoglaltak ahhoz, hogy új kapcsolatokat fogadjanak el.”

azt hiszem, tartozom egy nagy “köszönöm”, hogy a személy a Microsoft, aki jött az értelmes címkék Esemény forrása és kategória – csak az a fajta dolog, amit magától értetődőnek.

mindenesetre, mivel erős jelek voltak arra, hogy a probléma a Hub Transport szerveren létezik, elkezdtem megvizsgálni a Hub Transport szerver alkalmazásnaplóját. Nem voltak hibák naplózva, de volt egy figyelmeztetés: Eseményazonosító: 15002, forrás: MSExchangeTransport, Kategória: ResourceManager. A probléma megoldásának rohanásában figyelmen kívül hagytam a figyelmeztető eseményt, és feltételeztem, hogy a szerver csak a virtuális gép rendszer erőforrásaira panaszkodik – nem messze az igazságtól.

közben a telnet-et használtam a hub transport server 25-ös portjához való csatlakozáshoz, és azonnal kaptam egy választ, amely szerint:

452 4.3.1 nem elegendő rendszererőforrás

a host-kapcsolat megszakadt

ez arra késztetett, hogy közelebbről megvizsgáljam a Hub transport server alkalmazásnaplójában található figyelmeztető eseményazonosítót: 15002. Figyelmesen elolvastam a leírást:

“az erőforrás nyomás állandó magas. Statisztika:

Microsoft-Alapvető útmutató a Microsoft Teams Végfelhasználói elkötelezettségéhez
Alapvető útmutató a Microsoft Teams Végfelhasználói elkötelezettségéhez

10 bevált gyakorlatot, megfontolást és javaslatot mutatunk be Önnek, amelyek gazdagíthatják a Microsoft Teams telepítését, és biztosíthatják a végfelhasználók elfogadását és elkötelezettségét.

Szerezd meg az útmutatót

várólista adatbázis és lemezterület (“C: Program FilesMicrosoftExchange ServerTransportRolesdataQueuemail.que”) = 63%

sor adatbázis naplózása lemezterület (“C: Program FilesMicrosoftExchange ServerTransportRolesdataQueue”) = 63%

Version buckets = 1

privát bájtok = 16%

fizikai memória terhelés = 53%

a bejövő levelek elküldése más Hub átviteli kiszolgálókról, az internetről, a felvételi könyvtárból, a Replay könyvtárból és a postafiók-kiszolgálóból, ha egy Hub szállítási kiszolgálón van, leállt.

az e-mailek betöltése a queuing adatbázisból, ha rendelkezésre áll, folytatódik.”

a leírás lefelé görgetése és a részletek elolvasása segített J de várj, 2,94 GB szabad hely volt a virtuális gépemen, amely a hub transport server szerepet futtatta. Akkor miért panaszkodott az Exchange a lemezterületről?

miután néhány kutatás, rábukkantam ezt a cikket Technet amely bemutatta nekem, hogy egy nem olyan jól ismert, de új koncepció bevezetett Exchange Server 2007 – ellennyomás. Míg a hivatkozott oldalakon további részleteket olvashat a témáról, lényegében az ellennyomás az Exchange Server 2007 Hub átviteli és Edge Server szerepkörökbe épített rendszererőforrás-figyelő szolgáltatás, amely a rendszererőforrások állapotától függően befolyásolja az üzenetek kézbesítését.

miután alkalmaztam az Exchange által a szállítási szolgáltatás küszöbértékeinek kiszámításához használt képletet(100 * (merevlemez – meghajtó mérete-4 GB) / merevlemez-meghajtó mérete), rájöttem, hogy az eredményül kapott magas érték a várólista-adatbázis és a lemezterület számára a környezetemben (50%) magasabb volt, mint az Exchange által kiszámított magas küszöbérték (49%).

Tipp: Ha a rendelkezésre álló szabad terület kevesebb, mint 4 GB, akkor a merevlemez-meghajtó kihasználtsági szintje magasnak tekinthető.

tehát a választásom, hogy a levelek áramlanak:

  • növelje a rendelkezésre álló lemezterületet (termelési környezetekhez ajánlott) vagy
  • növelje a megfelelő küszöbértéket (termelési környezetekhez nem ajánlott)

mivel tesztkörnyezetet használtam, úgy döntöttem, hogy a könnyű utat választom, és felülbírálom a merevlemez-meghajtó magas szintű kihasználtságának alapértelmezett számításait egy új érték megadásával az EdgeTransport-ban.exe.konfigurációs fájl, amely megtalálható a C: Program FilesMicrosoftExchange ServerBin könyvtárban. Megváltoztattam a PercentageDatabaseDiskSpaceUsedHighthreshold alapértelmezett értékét “0” – ról “80” – ra, majd újraindítottam a Microsoft Exchange Transport szolgáltatást.

ellenőriztem, hogy a figyelmeztető üzenet nem jelenik meg újra a szolgáltatás újraindítása után, és megpróbáltam újra üzenetet küldeni magamnak az OWA használatával-sikeres!! Azt is észrevettem, hogy a korábban a piszkozat mappába helyezett üzenetet (a probléma során) kézi beavatkozás nélkül is sikeresen kézbesítették.

míg ellennyomás egy ügyes funkció cserébe, és célja, hogy foglalkozzon a rendszer erőforrás kérdések kecsesen, remélem, hogy a vállalatok továbbra is befektetni hatékony felügyeleti megoldások csere, mint a System Center Operations Manager, hogy elkerüljék a kérdéseket, mint a fent leírt. A-course kivétel egy olyan eset, amikor egy Cseremegoldást tesztel egy tesztkörnyezetben, ahol előfordulhat, hogy nem engedheti meg magának, hogy termelési osztályú rendszererőforrásokkal rendelkezzen.