Exchange tip: Vergroot het Application log met PowerShell

Het is een best practice om het Application Log op een server met Exchange wat groter te maken. Standaard op een server met Windows Server 2008 of hoger is deze 20 megabyte groot. Wanneer er nu een issue optreedt waarbij een grote hoeveelheid events wordt weggeschreven, dan kan het voorkomen dat de events die informatie geven over de oorzaak van het probleem als overschreven zijn. Bijvoorbeeld als je na het weekend een issue blijkt te hebben wat vrijdagavond al voor het eerst opgetreden is.

Anno 2012/2013 doen we dat uiteraard met PowerShell. Geef in een elevated (Run as administrator) PowerShell window het volgende commando:

Limit-EventLog -LogName Application -MaximumSize 50MB

Mijn tip aan Exchange-beheerders en -specialisten is om deze aanpassing in de standaard procedure voor uitrol van een nieuwe server op te nemen.

Exchange 2010: Unhandled Exception “User setting 'PreferredSite' is not available.”

Beheerders die recent een upgrade van Exchange 2003 naar Exchange 2010 hebben uitgevoerd, of voor langere tijd een omgeving beheren met beide versies naast elkaar, kunnen de volgende melding in grote hoeveelheid aantreffen in het Application Log van de Client Access servers:

Het gaat om Event ID 1 van de source MSExchange Autodiscover. De foutmelding luidt Description: Unhandled Exception "User setting 'PreferredSite' is not available.". Deze melding wil zeggen dat Autodiscover voor een bepaalde gebruiker niet in staat was om de juiste gegevens te bepalen. De oorzaak is dat er een Autodiscover request werd gedaan door een gebruiker waarvan de mailbox nog op Exchange 2003 staat, het is dus logisch dat Autodiscover voor deze gebruikers geen informatie samen kan stellen.

Een fix voor dit issue is opgenomen in Update Rollup 5 (versie 2) voor Exchange 2010 SP2. Deze kun je hier downloaden, een lijst met alle opgeloste issues vind je hier. Overigens bevat Update Rollup 5-v2 ook een security fix wat inhoudt dat hij ook via Microsoft/Windows Update wordt aangeboden.

Belangrijk: Installeer KB2506143 en KB2506146 niet op Exchange 2007/2010

De afgelopen dagen melden verschillende mensen issues met Exchange 2007 en 2010 servers. Na onderzoek blijkt dat de installatie van twee updates de oorzaak hiervan is:

• KB2506143 Description of Windows Management Framework 3.0 for Windows 7 SP1 and Windows Server 2008 R2 SP1
• KB2506146 Description of Windows Management Framework 3.0 for Windows Server 2008 SP2

Deze updates bevatten Windows Management Framework 3.0. WMF is de managementlaag van Windows servers en bestaat uit onder andere WinRM, WMI en PowerShell. Exchange is sterk afhankelijk van dit framework, WMF wordt volop gebruikt om de lokale server te beheren maar ook voor communicatie tussen verschillende Exchange servers zoals DAG members.

Op dit moment ondersteunt Exchange 2007 versie 1.0 en 2.0 van WMF, Exchange 2010 ondersteunt alleen versie 2.0. Wanneer je nu met bovenstaande updates versie 3.0 van deze componenten installeert dan gaan er onherroepelijk problemen optreden, het is bijvoorbeeld niet meer mogelijk om Update Rollups te installeren.

Voor Exchange 2010 betekent dit dat je WMF 3.0 pas kunt installeren nadat Service Pack 3 geïnstalleerd is, deze wordt verwacht in het eerste kwartaal van 2013. Voor Exchange 2007 is het onwaarschijnlijk dat er ondersteuning voor WMF 3.0 gaat komen. Overigens zorgt de installatie van WMF 3.0 ook voor problemen met SharePoint en waarschijnlijk een grote hoeveelheid andere software. Ook hier is het devies dus: niet installeren voor je zeker weet dat het ondersteund wordt.

Voor Exchange 2013 is bovenstaande niet van toepassing, wanneer je Exchange 2013 draait is WMF 3.0 een vereiste namelijk en is deze dus al op je server geïnstalleerd.

Exchange en de taal van NDR’s aanpassen

In Exchange 2007 en 2010 probeert de Hub Transport rol te bepalen in welke taal een non-delivery report (NDR) verstuurt moet worden. Het zelfde geldt trouwens voor de Mailbox rol van Exchange 2013. In bepaalde gevallen geeft dit een ongewenst resultaat en dan is het goed om te weten dat je deze functionaliteit kunt configureren.

Exchange bepaalt de taal

Standaard probeert Exchange een NDR te sturen in de zelfde taal als het bericht waar het om gaat, dit doet Exchange met zowel interne als externe berichten. En voor intern en extern kunnen we dit uitschakelen met de ExternalDsnLanguageDetectionEnabled en InternalDsnLanguageDetectionEnabled parameters van Set-TransportConfig. Uit- en inschakelen doen we door deze op $false of $true te zetten:

Set-TransportConfig –ExternalDsnLanguageDetectionEnabled:$false -InternalDsnLanguageDetectionEnabled:$false

Standaardtaal

Maar dan gebruikt Exchange standaard de taal waarin de server geconfigureerd is, dus de taal van Windows Server. We kunnen deze ook zelf kiezen met de ExternalDsnDefaultLanguage en InternalDsnDefaultLanguage parameters van Set-TransportConfig. Bijvoorbeeld:

Set-TransportConfig -ExternalDsnDefaultLanguage en-us -InternalDsnDefaultLanguage en-us

Nu zal Exchange de NDR in het Engels verzenden als de taal van het oorspronkelijke bericht niet bepaald kan worden, of altijd in het Engels als we Language Detection uitgeschakeld hadden.

Let wel op, deze instellingen hebben alleen effect op NDR’s die door de Hub Transport rol gegenereerd worden en dus niet op NDR’s die door Outlook aangemaakt worden.