Exchange

Vanaf Exchange 2010 SP1 wordt op iedere mailbox server een scheduled task aangemaakt genaamd Database One Copy Alert. Dit script wordt elk uur uitgevoerd en controleert of er meerdere kopieën van een database binnen een DAG aanwezig zijn. Daarnaast wordt de status gecontroleerd van deze kopieën. Heb je namelijk een copy die niet goed is dan kan dit tot data verlies leiden tijdens een failover.

Het script wat daadwerkelijk wordt uitgevoerd is terug te vinden in de scripts directory van Exchange 2010 en heet CheckDatabaseRedundancy.ps1.  Maar wat als je geen DAG hebt binnen je Exchange omgeving? In dat geval zal het script geen alerts versturen.

Naast het automatisch draaien van het script kun je dit ook handmatig uitvoeren.

In bovenstaand geval is te zien dat de Exchange server geen lid is van een DAG. In dat geval zal er dus geen controle uitgevoerd worden. Wel is te zien dat het mogelijk is om een alert te versturen via mail.

Wanneer je wel in het bezit bent van een DAG zul je veel meer informatie terug vinden. Bijvoorbeeld zijn er meerdere databases maar ook wat is de laatst bekende status van deze database.

Binnen het script zijn twee niveau’s van events mogelijk:

  • rood, er zijn minder dan het benodigd aantal kopieën aanwezig, of de kopieën die aanwezig zijn hebben een status die anders is dan healthy. Wanneer dit het geval is wordt er een event weggeschreven in het event log met ID 4113
  • groen, er zijn additionele kopieën aanwezig van een database en deze databases hebben de status healthy. In dit geval wordt er een event met ID 4114 weggeschreven in het event log

In het eerste geval is het noodzakelijk om natuurlijk actie te nemen. Hierbij dient wel opgemerkt te worden dat het niveau pas naar rood wordt aangepast als het probleem zich langer dan 20 minuten voordoet. Wanneer dit namelijk het geval is zal het script een aantal maal een itteration uitvoeren. Een itteration wordt elke minuut uitgevoerd, na 20 minuten de status nogsteeds rood dan wordt een event weggeschreven in het log. Het event wordt zolang het niveau rood is elke 15 minuten weggeschreven in het event log. Dit wordt nadat het rode niveau actief is elke minuut herhaald tot het niveau weer groen is.  Van rood naar een groen niveau wordt echter niet zomaar gedaan. Er zijn 10 itterations (10 minuten) nodig voordat het niveau weer wordt verlaagd naar groen.  Wil je een melding ontvangen per mail wanneer de status van één of meerdere databases veranderd in rood dan dient de scheduled task aangepast te worden.

Standaard worden deze parameters gebruikt in de scheduled task:

-NonInteractive -WindowStyle Hidden -command “& ‘C:\Program Files\Microsoft\Exchange Server\V14\Scripts\CheckDatabaseRedundancy.ps1′ -MonitoringContext -ShowDetailedErrors -ErrorAction:Continue”

Wanneer je dit aanpast in het volgende:

-NonInteractive -WindowStyle Hidden -command “& ‘C:\Program Files\Microsoft\Exchange Server\V14\Scripts\CheckDatabaseRedundancy.ps1′ -MonitoringContext -ShowDetailedErrors -ErrorAction:Continue -SummaryMailFrom:’exchange02.corp.local’-SendSummaryMailTos:@(‘administrator@corp.local’)”

Zal het script, indien er problemen zijn een mail versturen met daarin gedetaileerde informatie.

In bovenstaande voorbeeld is te zien dat er een issue is met een database in de DAG. Deze database heeft slechts één copy wat betekend als de mailbox server weg zou vallen de database niet meer beschikbaar is.

Wanneer we nu een extra database copy toevoegen en het script nogmaals draaien is te zien dat de status nu van rood naar groen is veranderd. Mocht de copy met preference 1 nu uitvallen dan zal de database met preference 2 geactiveerd worden.

Het script kan naast de e-mail parameters uitgevoerd worden met nog enkele andere parameters. In onderstaande tabel is een overzicht te zien van de beschikbare parameters en wat het effekt is van deze parameters:

ParameterOmschrijving
-vVerbose mode, geeft gedetaileerde logging van wat er exact gebeurd
-SummaryMailFromHet afzender adres voor het versturen van de logging
-SendSummaryMailTosHet adres waar de logging naar verstuurd moet worden
-ShowDetailedErrorsGeeft extra details per database copy per server

Voor meer informatie kun je terecht op onderstaande pagina.  Hierbij dient wel opgemerkt te worden dat de pagina het script beschrijft zoals in Exchange 2010 RTM gebruikt kon worden. Vanaf Exchange 2010 SP1 bevat een Exchange installatie dit script al standaard:

The Exchange Team Blog: RELEASED: Exchange 2010 Database Redundancy Check Script: open

http://blogs.technet.com/b/exchange/archive/2010/05/20/3409984.aspx

ActiveSync werkt niet bij bepaalde devices

Onlangs heeft Microsoft het Exchange ActiveSync Logo programma aangekondigd. Middels dit programma wil Microsoft devices gaan testen op de compatibiliteit met ActiveSync.

Eén van de redenen hiervoor zijn de problemen die er vaak zijn met devices i.c.m. ActiveSync. Als beheerder/consultant is dit vaak lastig uit te leggen aan een eindgebruiker of klant.

Op dit moment zijn de volgende toestellen gecertificeerd:

  • Windows Phone 7
  • Windows Phone 6.5
  • Nokia’s met Mail for Exchange 3.0.50
  • Nokia E7
  • Apple devices met iOS 4

Wanneer een toestel hieraan niet voldoet kan dit tot problemen leiden. Eén van de dingen waar je tegenaan kunt lopen is dat het toestel compleet niet meer synchroniseerd. Dit kan bijvoorbeeld voorkomen wanneer een mailbox wordt verhuisd naar Exchange 2010 vanaf een Exchange 2003 omgeving. Dit laatste voorbeeld heb ik zelf ondervonden met Nokia devices.

Om dit probleem te onderzoeken kun je gebruik maken van de IIS logs. In het geval van de Nokia toestellen was in de logs het volgende terug te vinden:

2011-05-06 11:29:50 192.168.1.41 OPTIONS /Microsoft-Server-ActiveSync/default.eas User=XXXXXX&DeviceId=IMEIXXXXXXXXXXX&DeviceType=NokiaEmail&Log=V0_LdapC9_LdapL16_Mbx:
MB.DOMAIN.LOCAL_Dc:DC.DOMAIN.LOCAL_Throttle0_Budget:(A)Conn%3a0%2cHangingConn%3a0%2cAD%3a%24null%2f%24null%2f0%25%2cCAS%3a%24null%2f%24null%2f0%25%2cAB%3a%24null%2f%24null%2f0%25%2cRPC%3a%24null%2f%24null%2f0%25%2cFC%3a1000%2f0%2cPolicy%3aDefaultThrottlingPolicy%5F3006a3a1-0211-447a-99f5-6c0ab8e33c84%2cNorm_ 443 DOMAIN\Username 192.168.100.201 NokiaE721/2.02(0)MailforExchange+3gpp-gba 200 0 0 140

2011-05-06 11:30:11 192.168.1.41 POST /Microsoft-Server-ActiveSync/default.eas User=Username&DeviceId=IMEIXXXXXXXX&DeviceType=NokiaEmail&Cmd=Settings&Log=
V121_Ssnf:T_LdapC4_LdapL16_RpcC45_RpcL125_Ers1_Cpo19781_Fet19999_Pk0_Error:
DeviceNotProvisioned_As:BlockedP_Mbx:MB.DOMAIN.LOCAL_Dc:DC.DOMAIN.LOCAL_Throttle0_Budget:(D)Conn%3a1%2cHangingConn%3a0%2cAD%3a%24null%2f%24null%2f1%25%2cCAS%3a%24null%2f%24null%2f1%25%2cAB%3a%24null%2f%24null%2f0%25%2cRPC%3a%24null%2f%24null%2f1%25%2cFC%3a1000%2f0%2cPolicy%3aDefaultThrottlingPolicy%5F3006a3a1-0211-447a-99f5-6c0ab8e33c84%2cNorm%5bResources%3a(Mdb)MBDB01(Health%3a-1%25%2cHistLoad%3a0)%2c(DC.LOCAL(Health%3a-1%25%2cHistLoad%3a0)%2c(DC)DOMAIN.LOCAL(Health%3a-1%25%2cHistLoad%3a0)%2c%5d_ 443 DOMAIN\Username192.168.100.201 NokiaE721/2.02(0)MailforExchange+3gpp-gba 449 0 0 19999

Dit zijn de twee regels waar het om gaat in de logging. In de eerste regel zien we dat het gebruiker zich authentiseert en de webserver hierop ook antwoord met 200. In de volgende stap zien we echter dat het één en ander niet goed gaat met het provisionen van het toestel. Wanneer je gaat zoeken op internet zul je zien dat niet alleen Nokia devices hier problemen mee hebben maar ook de devices met Android als OS. Het probleem wordt veroorzaakt door de ActiveSync policy waarmee deze toestellen niet overweg kunnen. Middels deze policy kunnen beheerders o.a. beveiligings gerelateerde instellingen toepassen op devices.

Wanneer een gebruiker inlogt via het Exchange Control Panel en naar de pagina Phones gaat zal het toestel wel zichtbaar zijn. Vraagt men echter de eigenschappen op dan zal o.a. volgende zichtbaar zijn:

Access state: 
Access Denied
Access set by:  Security Policy Application

In sommige gevallen kan dit tot vervelende gevolgen leiden. Vaak zijn gebruikers niet echt blij als hun synchronisatie niet meer werkt, ook al zijn hier goede redenen voor.

Omdat het lastig is te controleren of alle apparaten wel de laatste software gebruiken kan het in sommige gevallen raadzaam zijn om een workaround te implementeren. Deze workaround is natuurlijk maar tijdelijk benodigd totdat alle devices zijn geupgrade naar de vereiste versie.

De workaround om dit probleem tijdens een migratie te voorkomen is het tijdelijk uitschakelen van de defaultActiveSync policy van Exchange 2010. Standaard staat deze policy als default ingesteld wat als gevolg heeft dat iedere gebruiker deze policy krijgt toegewezen.

Om deze policy tijdelijk niet toe te passen op een gebruiker dien je de default ActiveSync policy aan te passen. Dit dient gedaan te worden door gebruik te maken van de Exchange Management Shell (EMS):

Set-ActiveSyncMailboxPolicy -Identity:Default -IsDefaultPolicy:$false

Wanneer het device nu wordt ingesteld zul je zien dat synchronisatie weer correct werkt. Omdat dit een niet wenselijke situatie creëert is het verstandig om daarna het daadwerkelijke probleem aan te pakken.

Naast het up-to-date zijn van de client die gebruikt wordt om te synchroniseren met Exchange is het van belang ervoor te zorgen dat de firmware van het toestel ook up-to-date is. In het geval van de Nokia toestellen werkt ActiveSync namelijk nog steeds niet na de upgrade van Mail-for-Exchange naar versie 3.0.50.

Wanneer alle toestellen ge-upgrade zijn is het sterk aan te raden de default ActiveSync policy weer te activeren:

Set-ActiveSyncMailboxPolicy -Identity:Default -IsDefaultPolicy:$true

Voor meer informatie over ActiveSync policies kun je terecht op de volgende pagina:

Technet: Understanding Exchange ActiveSync Mailbox Policies open

Hoe kun je berichten opnieuw verwerken uit een queue

Deze week kreeg ik een vraag via de e-mail over een Exchange 2010 omgeving. In deze omgeving waren grote problemen geweest waardoor er ontzettend veel berichten terecht waren gekomen in de Unreachable queue. Berichten komen in deze queue terecht wanneer Exchange ze niet af kan leveren. Dit kunnen dus zowel berichten naar externe mailservers zijn als berichten naar de interne Exchange servers.

De queues kunnen via twee methodes bekeken worden:

  • via de queue viewer
  • via het Powershell cmdlet get-queue

Middels de eerste methode kunnen ook specifieke berichten bekeken worden in de queue. Standaard worden namelijk enkele attributen bewaard van berichten o.a.:

  • afzender
  • ontvanger
  • onderwerp
  • datum en tijdstip

Je kunt er natuurlijk voor kiezen om de berichten te exporteren en vervolgens weer opnieuw in de queue te plaatsen. Maar dit is niet de meest handige optie als het om een queue gaat met honderden of misschien wel duizenden berichten.

In dit soort gevallen kun je beter gebruik maken van het Retry-Queue cmdlet. Hierdoor worden opnieuw verstuurd naar de categorizer. Dit component van Exchange is verantwoordelijk voor o.a. het opzoeken vanhet  adres van de ontvanger en daarna routeren van het bericht. Om een bericht goed te routeren wordt het bericht geplaatst in de queue die gebruikt wordt voor de aflevering naar de afzender. Wanneer je in de queue viewer kijkt zal je o.a. queues zien voor elke mailbox database. Daarnaast zijn hier ook queues terug te vinden voor de berichten die naar buiten verstuurd moeten worden. Gebruik je een smarthost dan zal je hier slechts één queue zien staan die de berichten afleverd naar bij de smarthost.

Wanneer berichten echter niet afgeleverd kunnen worden binnen een bepaald tijdsbestek dan worden deze in de Unreachable queue geplaatst. Dit kan bijvoorbeeld voorkomen wanneer de mailbox server niet beschikbaar is.

Om deze berichten opnieuw te versturen kun je onderstaande cmdlet gebruiken:

Retry-Queue -Identity <servername>\Unreachable -Confirm -Resubmit $true

Bijvoorbeeld:

Retry-Queue -Identity HUB01\Unreachable -Confirm -Resubmit $true

In bovenstaand voorbeeld worden alle berichten uit de Unreachable queue op de server HUB01 opnieuw verstuurd.

Hierna zullen de berichten afgeleverd worden. Afhankelijk van de hoeveelheid berichten kan dit natuurlijk enige tijd in beslag nemen.

Voor meer informatie kun je terecht op onderstaande pagina:

Technet: Resubmit Messages in Queues open

Zowel de Exchange Management Console (EMC) als Exchange Management Shell (EMS) maken connectie naar de Powershell middels een remote sessie. Tijdens het opzetten van de sessie wordt connectie gemaakt naar de virtuele directory Powershell die terug te vinden is in de IIS Management Console. Deze virtual directory kan standaard alleen benaderd worden via poort 80.

Voor de authenticatie wordt gebruikt gemaakt van Kerberos. Hierbij wordt gebruik gemaakt van een aparte dll die tijdens de Exchange setup is geïnstalleerd.

In het geval van een de-installatie van Exchange en hierna een installatie op een ander volume kan dit tot problemen leiden. Natuurlijk komt dit voorbeeld weinig voor maar dit probleem kan mogelijk ook in andere scenario’s voorkomen.

Nadat Exchange echter is geïnstalleerd op de nieuwe locatie kan de EMC niet meer opgestart worden. In het event log zullen vele van bovenstaande meldingen zichtbaar zijn.

Omdat hierbij gebruik wordt gemaakt van de IIS worden voor sommige dingen de IIS configuratie bestanden gebruikt. Deze zijn standaard terug te vinden in c:\windows\system32\inetsrv\config\hier is onder andere het bestand applicationhost.config terug te vinden.

In de sectie globalmodules worden de diverse modules zoals de authenticatie methodes, redirection, en de overige modules geladen. Hierbij wordt een verwijzing gemaakt naar de benodigde dll.

Omdat de kerbauth.dll een native module is, is deze ook terug te vinden in de lijst maar verwijst naar de Exchange installatie directory. In sommige gevallen komt het voor dat deze regel niet wordt verwijderd of aangepast en dus naar de oude lokatie blijft verwijzen. Het resultaat: de DLL kan niet gevonden worden.

Het probleem is eenvoudig te verhelpen door ervoor te zorgen dat de correcte lokatie wordt opgegeven. Dit kan eventueel door gebruik te maken van de variabele ExchangeInstallPath (alleen Exchange 2007).

Voor meer troubleshooting tips kun je op onderstaande pagina terecht. Hierop vind je een aantal problemen met hierbij de oplossing.

Technet: Powershell Virtual Directory issue causes problems with EMS open

Update 1-5-2010: dit issue komt alleen voor wanneer één van de items in organizational management word geopend

Op diverse fora zijn berichten te vinden over problemen met het afsluiten van de Exchange Management Console (EMC). Deze zou na de installatie van Internet Explorer 9 niet meer af te sluiten zijn maar de volgende waarschuwing geven:

Het probleem zou zich voordoen bij zowel de EMC van Exchange 2007 als Exchange 2010 en zowel met Windows 7 als 2008 en 2008 R2.

De oplossing om dit probleem op te lossen is redelijk eenvoudig: de-installeer Internet Explorer 9.

Om toch eens te kijken of ik de foutmelding boven water kon krijgen heb ik een schone installatie van Windows 2008 R2 met hierop Exchange 2010 SP1 uitgevoerd.  Echter hierop was het probleem niet te reproduceren. Ook na het installeren van SP1 werkte alles nog correct.

Het is natuurlijk niet een helemaal eerlijke vergelijking omdat ik hier een schoon OS heb geïnstalleerd en daarop Exchange 2010 SP1. Mocht je toch problemen tegen komen dan hoor ik het graag.

Na de installatie van Exchange 2010 SP1 op een server die alleen functioneert als Mailbox Server kan het voorkomen dat je veel errors in het event log hebt.

Wanneer je specifiek naar deze meldingen gaat kijken zie je dat deze meldingen worden veroorzaakt door de Performance Counters. Hierbij wordt een verwijzing gemaakt naar de volgende registry key HKLM\Software\Microsoft\ExchangeServer\v14\Transport die niet geopend kan worden.

Wanneer je met behulp van regedit gaat kijken zal je zien dat de registry key niet bestaat. Eigenlijk best vreemd, omdat de RPC Client Access Service wel wordt geïnstalleerd op een Mailbox Server.

Wanneer je het volgende Knowledge Base artikel leest hoef je je geen zorgen te maken omdat dit geen negatief effekt heeft op de werking van de Mailbox Server. Echter vind ik het zelf meestal niet erg prettig als er errors in het event log staan, dus hoe kun je dit probleem oplossen?

Eigenlijk redelijk eenvoudig:

  • Open de Exchange Management Shell
  • Voer het volgende commando uit: add-pssnapin Microsoft.Exchange.Management.PowerShell.Setup
  • Voer het volgende commando uit: new-perfcounters –definitionfilename “C:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\RpcClientAccessPerformanceCounters.xml”

Hiermee zorgen we ervoor dat de Performance Counters m.b.t. de RPC Client Access Service worden geïnstalleerd. Eenmaal geïnstalleerd zal de melding niet meer voorkomen.

Wil je meer weten over het verwijderen of opnieuw laden van de Performance Counters neem dan eens een kijkje op onderstaande site:

open

De OAB Generator van Exchange is ervoor verantwoordelijk om het Offline Address Book (OAB) te genereren. Hiervoor maakt de service gebruik van de informatie welke is te vinden in de Active Directory. Wanneer je een eenvoudig forest hebt met één domein dan zal dit vaak weinig problemen geven. Maar wat gebeurd er als je Exchange omgeving is geïnstalleerd in het forest root domain en de gebruikers zijn geplaatst in een child domain? Exchange zal in dit geval de domain controllers van het child domain benaderen om de informatie te verzamelen.

Exchange zal dan op basis van de netbios naam connectie maken met de domain controller. Wanneer je dus in de TCP/IP configuratie de standaard waarde append primary and connection specific DNS suffixes hebt geselecteerd zal DNS resolving niet correct functioneren. Dit leid in dat geval tot bovenstaande foutmelding en heeft als resultaat dat het offline address book niet wordt gegenereerd.

Het probleem is eenvoudig op te lossen: zorg ervoor dat alle DNS suffixes in de TCP/IP configuratie zijn toegevoegd en in de goede volgorde: eerst het top domain en daarna de child domains. Door dit te doen zal de domain controller in het child domain wel te vinden zijn en kan het offline address book gegenereerd worden. Om dit te forceren kun je gebruik maken van het cmdlet update-offlineaddressbook.

OWA IM Integratie configuratie automatiseren – update 2

Het is weer tijd voor een update van het prepare_owa_im script, dit keer een redelijk grote vergeleken met de eerste update. Vanaf deze versie is het namelijk mogelijk om naast de OWA configuratie ook direct de Lync configuratie aan te passen. Het script bevat echter één beperking: het is niet mogelijk om de nieuwe topology direct te activeren.

De oorzaak hiervan is een beperking in de remote connectie naar de Lync Front End Server toe. De remote connectie laat veel toe behalve het uitvoeren van het enable-CsTopology commando. Dit commando is vereist om de topology aanpassing te activeren.

Vergeet dus niet na het uitvoeren van het script het enable-CsTopology commando handmatig uit te voeren op de Lync Front End Server.

Op dit moment dient het script nog uitgevoerd te worden op alle CAS servers waarop de IM integratie geconfigureerd dient te worden. In een toekomstige update zal dit veranderen.

Mocht je nog andere feature requests hebben laat het me dan weten zodat ik deze mee kan nemen in een nieuwe versie van het script.

Waarschuwing: het kan voorkomen dat het script de ExecutionPolicy tijdelijk moet aanpassen.

prepare_owa_im script versie 1.2 download

In Exchange 2010 worden bijna alle client connecties gemaakt via de CAS server, uitgezonderd de connectie naar de Public Folders. Op de CAS server draait de RPC Client Access Service die gebruikt wordt door Outlook om connectie te maken naar de mailbox. Valt deze service dus uit dan kunnen er geen MAPI connecties meer opgezet worden naar de server.

In de meeste gevallen zal of de service of zelfs de hele server herstart worden om te kijken of dit het probleem oplost. Maar stel dat dit niet helpt waar kun je dan verder gaan. Wanneer de service niet opstart zal er weinig te zien zijn in het event log, behalve onderstaande melding:

Helaas zijn de logging methoden van de RPC Client Access Service beperkt. Tijdens het opstarten van de service maakt deze gebruik van een config bestand. Dit bestand is te vinden in  de BIN directory van Exchange en heeft de naam Microsoft.Exchange.RpcClientAccess.Service.exe.config.

Dit bestand kan in sommige gevallen corrupt raken, bijvoorbeeld door een unexpected shutdown. Wanneer dit corrupt raakt heeft dit als gevolg dat de service niet meer opstart.

De makkelijkste manier om dit op te lossen is een nieuwe config aanmaken met daarin alleen de volgende vier regels:

<configuration>
 <runtime>         
           <generatePublisherEvidence enabled=”false” />
 </runtime>
</configuration>

Wanneer de service in dit geval weer opstart kan dus de conclusie getrokken worden dat het in de huidige config zit. Echter door gebruik te maken van bovenstaande config wordt er bijvoorbeeld geen logging meer aangemaakt, iets wat in veel gevallen wel wenselijk is. In dit geval zal dus onderzoek gedaan moeten worden naar de huidige config.

<configuration>
  <runtime>
    <gcServer enabled=”true” />
  </runtime>
<generatePublisherEvidence enabled=”false”/>
  <appSettings>

In bovenstaand voorbeeld is te zien dat de generatePublisherEvidence enabled regel op de verkeerde plek staat. Deze lijn dient tussen de runtime headers te staan, wanneer je deze regel weer verplaatst naar de correcte plaats en vervolgens de RPC Client Access Service opnieuw opstart, zul je zien dat deze weer normaal opstart.

Heb je dus problemen met het opstarten van de RPC Client Access Service vergeet dan vooral niet de config file.

OWA IM Integratie configuratie automatiseren – update

Eén van de mogelijkheden die nog in het script ontbrak was het controleren of het certificaat niet een self-signed certificaat is. Standaard wordt namelijk op de  Exchange CAS server een self-signed certificaat geïnstalleerd dat niet vertrouwd wordt door andere servers.

In zo’n geval kun je twee dingen doen:

  • het self-signed certificaat importeren op de overige servers, in dit geval de Lync Front End;
  • een geldig certificaat installeren;

Natuurlijk is de eerste methode niet de mooiste methode maar soms kun je niet anders.

Onderstaand de wijzigingen die zijn doorgevoerd in het script:

  • controle toegevoegd of een certificaat self-signed is;
  • export mogelijkheid van een self-signed certificaat;

Mocht je nog tips of suggesties hebben laat gerust een comment achter.

download prepare_owa_im.ps1 v1.1