Nog een reden waarom Public folders mogen verdwijnen.....

Naast het feit dat ik een mailsysteem geen plek vind om informatie met elkaar te delen, ben ik deze week achter nog een reden gekomen waarom public folders uit Exchange 2007 moeten verdwijnen. Dit heeft alles te maken met een probleem waar ik een maand mee bezig ben geweest...

Vorige maand is de klant waar ik momenteel voor werk een Exchange 2007 pilot gestart in een redelijk grote bestaande Exchange 2003 organisatie. Deze omgeving telt 100+ servers verspreid over 4 continenten. Daarbinnen hebben ze 52 Public Folder stores.

De initiele pilot groep telde +- 30 gebruikers, welke in UAT uitgebreid zou gaan worden naar +- 250 gebruikers. Vanaf het begin af aan kreeg ik klachten dat geheel willekeurig een Outlook client ineens bleef hangen voor 1 a 2 minuten, waarbij "retrieving data" popups verschenen, welke verwezen naar de 2007 public folder server die opgetuigd was voor de pilot users. Na verschillende perfmon sessies te hebben gedraaid op deze server, kon ik geen performance issues vinden. De hardware functioneerde prima, en ook de lokale GC's lieten geen problemen zien. Wel zagen we om het half uur hoge "RPC average latency" pieken. Na ook met network monitor aan de slag te zijn gegaan konden we zien dat de server elk half uur een waslijst aan Exchange servers verspreid over het hele forest aan het benaderen waren. We konden alleen zien dat het NetLogon verkeer was, aangezien de content encrypted is.

Microsoft werd erbij gehaald, maar na een week ploeteren hadden we nog geen inzicht in wat het probleem nou precies was. We hadden in de tussentijd al van alles gedaan. IsInteg gedraaid, andere public folder stores geprobeert. Aangezien de problemen zo willekeurig optraden konden we niet goed zien wat er nu precies gaande was. Het leek erop dat het probleem vaak optrad bij het opstarten van Outlook. Echter waren er ook berichten dat het ook gebeurde als iemand andere zaken aan het doen was of zelfs helemaal niets aan het doen was. In een poging het probleem in de kraag te vatten had ik Netmon op mijn werkstation weten te krijgen (is gesloten omgeving dus was een hele klus om toestemming te krijgen). Door via script Outlook om de 7 seconden te openen en te sluiten, hoopte ik te kunnen tracen wat Outlook nou precies vraagt, waar Exchange nu zo'n moeite mee heeft. na 3 uur had ik beet. Na de capture opgestuurt te hebben naar Microsoft (zij kunnen namelijk delen van RPC pakketjes decrypten), bleek dat het om een request te gaan waarbij Outlook vroeg op content van de "Outlook Security Forms". Om er zeker van te zijn moesten we proberen nog een packet te capturen, maar tegelijkertijd ook een perfmon en netmon sessie op de server te starten.

Dit bleek lastig aangezien we al moeite hadden het te triggeren met script. Op mijn werkstation was het al meer dan een week niet "zomaar" voorgekomen. Na intern overleg had ik toestemming op nog een aantal werkstations netmon te installeren. Echter bleek dit niet nodig te zijn, want na ik wat beter naar de netmon capture van de server te kijken en naar de perfmon sessie, kon ik een patroon vinden waarbij er telkens om het half uur een RPC request gedaan werd, waarna Exchange al die PF servers afging. Nadat dat klaar was, kwam er een RPC response, en precies op dat moment schoot de RPC average latency omhoog. Microsoft vroeg mij verschillende malen memorydumps te maken van store.exe. Tijdens de rpc peak, vlak voor de rpc peak etc etc. In totaal hebben we 15 GB aan dumps op moeten sturen. In de tussentijd was er een CPR engineer onsite geweest omdat MS zelf ook niet wist wat er nu precies gaande was. Veel meer dan meekijken kon hij niet. Kreeg meer de indruk dat hij kwam kijken of we de boel niet voor de gek aan het houden waren.
Enfin, Na een paar dagen was Microsoft klaar met het analyseren van de memory dumps en wat bleek. Het probleem werd veroorzaakt doordat Outlook de Public Folder hierarchy wilde laten reloaden. Dit kwam doordat er public folder stores in de hierarchy zaten die niet meer bestonden. Dit kan komen doordat public folder stores voor Exchange 2003 sp2 gewoon verwijdert konden worden, zonder de replicas te verplaatsen naar andere servers. Nu had ik in die omgeving al een keer een schoningsactie gehouden waarbij System folders van oude stores verwijdert waren en de replicalijst aardig schoon was (replstate test van ISINTEG schoont deze op). Echter het blijkt dat de replicalijst ook nog op andere plaatsen in de PF store opgeslagen wordt. Deze "orphaned" entries op die plek kunnen dus niet verwijdert worden en zorgen ervoor dat ze blijven voorkomen in de hierarchie. Outlook ziet de guids van deze nietbestaande PF stores en zal elke keer wanneer het de hierachie opvraagt vragen om een reload. Nu doet Exchange dit standaard 1 keer per uur, maar op aanvraag doet Exchange dat dus sneller, als er maar minimaal een half uur tussen zit.... Laat dat nu net de interval zijn dat we die high latency pieken zien.

Wat blijkt nu? In Exchange 2003 hadden we dat probleem dus ook, maar hadden we geen Outlook clients die hingen. Dat komt omdat de reload van Exchange 2003 veel sneller ging. In Exchange 2003 gebruiken we routinggroup connectoren met costs. Door een paar snelle AD queries kan Exchange dus heel snel de hierarchie opbouwen.
In Exchange 2007 gebruiken we echter AD sites met costs. Echter op een serverobject in AD staat niet in welke AD-site deze zit. Exchange moet dat dus zien te bepalen. En waar hebben de programmeurs voor gekozen??? ...Precies... Een sessie opzetten met de server om zo de site te achterhalen. Vandaar dat we de Netlogons zagen. En servers in Azie en Australie reageren nu eenmaal niet zo snel als ze achter high latency lijntjes zitten. Dus om het half uur wachtte een client totdat Exchange sessies had opgezet naar 52 PF server in de organisatie.

Hoe nu verder? Nou... Niet met Exchange 2007 public folders dus voorlopig. Als het aantal is teruggebracht van 53 naar 8, dan kunnen we erover denken, maar nu niet.
Er is wel de mogelijkheid om het interval van reloaden aan te passen. Dit doe je door een DWORD aan te maken in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MsExchangeIS\\Public-(guid)

Dit DWORD moet heten "Replication Reload TLH Min" en de waarde is het aantal seconden die minimaal moeten zijn verstreken sinds de laatste reload. De maximale waarde is 43200 decimaal (12 uur). Zo kan je ervoor zorgen dat het probleem slechts 1 keer per 12 uur optreed. De enige echte structurele oplossing is om de hele PF tree opnieuw op te bouwen. Dat is echt heel erg lastig in grote omgevingen.

Omdat de programmeurs niet echt handig zijn omgesprongen met het reloaden van de hierarchie in Exchange 2007 is dit probleem nog in onderzoek bij de productgroep. Hopelijk wordt er een aanpassing gemaakt. Misschien wordt dit zelfs als bug aangeduid. Hoe het ook wil, op dit moment zijn public folders in grote omgevingen dus RUK...

Van mij mogen ze verdwijnen.