• Standard, deze ondersteund maximaal 5 databases
• Enterprise, deze heeft een maximum 100 databases

In veel gevallen wordt direct de correcte licentie geïnstalleerd maar het soms nodig zijn om bijvoorbeeld over te schakelen naar Enterprise. Denk hierbij bijvoorbeeld aan een bedrijf wat een ander bedrijf overneemt waardoor er een grote hoeveelheid mailboxen bij moeten komen maar die niet meer in de huidige database erbij passen. In het geval van Exchange 2010 Server Standard Edition kan je dan tegen de limiet van 5 aanlopen. Maar is het mogelijk om dan zomaar je licentie om te zetten naar Enterprise?

Dat is iets wat ik mezelf ook afvroeg en daarom ben ik gaan testen in mijn lab. We hebben dus een Exchange 2010 Server Standard Edition en hebben 5 databases. Nu willen we graag een 6de database aanmaken wat dus betekent dat we naar de Enterprise Edition zouden moeten upgraden. In de Exchange Management Console zul je de optie niet meer vinden om een licentiesleutel in te voeren dus blijft de Exchange Management Shell over.

Middels het commando:

set-exchangeserver -productkey 123445-14553-53363-453463

Kunnen we eenvoudig een nieuwe sleutel invoeren, in dit geval dus een productkey voor de Enterprise Edition. Net als wanneer de trail productkey vervangen wordt door een officiele key zul je na het invoeren van de productkey de Information Store service moeten herstarten.

Nadat dit is gebeurd en je het commando get-exchangeserver uitvoerd zul je zien dat je nu ineens een Enterprise edition hebt. Maar is er ook een weg terug ? Nee je kunt alleen maar upgraden en niet meer downgraden. Wanneer je dit zal proberen zul je de volgende foutmelding krijgen:

Denk dus goed na voordat je de key aanpast voordat je dit daadwerkelijk uitvoerd.

In dit geval was er dus meer aan de hand. Middels de logging welke wordt gegenereerd tijdens het migreren kwam onderstaande foutmelding naar boven:

Warning: Unable to update AD information for the source mailbox at the end of the move.  Error details: An error occurred while updating a user object after the move operation. –> The LdapRecipientFilter “(&(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=contact))(objectCategory=group)(objectCategory=publicFolder)(objectCategory=msExchDynamicDistributionList) )))(objectCategory=user)(vasco-Locked<=sdfasdfsdfasdfasdfasdf)))” on Address List or Email Address Policy “domain.com” is invalid. Additional information: The decimal number ‘sdfasdfsdfasdfasdfasdf’ is invalid or out-of-range. –> The decimal number ‘sdfasdfsdfasdfasdfasdf’ is invalid or out-of-range.
Failed to cleanup the source mailbox after the move.
Error details: MapiExceptionNotFound: Unable to delete mailbox. (hr=0x8004010f, ec=-2147221233)

Zoals te zien is zijn er problemen met het update van de AD informatie van de betreffende gebruiker en om nog specifieker te zijn met een Email Address Policy met de naam domain.com. Zoals de melding al aangeeft bevat deze Email Address Policy een ongeldigde waarde. Deze policy was snel aangemaakt door een beheerder het weekend voor de migratie en het was de bedoeling dat deze niet werd toegepast vandaar de vreemde waarde aangezien geen enkele match gevonden zou worden.

Zorg er dus voor dat de Email Address Policy welke aanwezig zijn in de oude omgeving correct zijn en ook goed functioneren en maak geen wijzigingen in de omgeving vlak voor een migratie. In dit geval moesten er twee acties uitgevoerd worden:

• mailbox van betreffende gebruiker verwijderen
• gebruiker mail enabled maken en correcte mail-adressen configureren t.b.v. co-existence met Exchange 2010

Daarnaast dient de policy hersteld te of verwijderd te worden indien deze niet meer nodig is.

• niet alle benodigde Windows componenten zijn geïnstalleerd
• er zijn instellingen middels IIS aangepast waardoor OWA niet meer werkt

Benodigde Windows componenten ontbreken

De eerste oorzaak is eigenlijk best vreemd omdat je zou verwachten dat de installatie controleert of alle componenten geïnstalleerd zijn voordat begonnen wordt met de daadwerkelijke installatie van Exchange.

Wanneer bijvoorbeeld de static content niet is geïnstalleerd kan dit voor dit issue zorgen. Om het e.e.a. te vergemakkelijken kun je gebruik maken van onderstaande script wat alle benodigde componenten op een Windows 2008 server zal installeren welke als CAS server gaat fungeren:

ServerManagerCmd -i Powershell
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Digest-Auth
ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Dyn-Compression

Indien je van plan bent om Outlook Anywhere te gaan gebruiken vergeet dan niet de RPC over HTTP feature te installeren:

ServerManagerCmd -i RPC-over-HTTP-proxy

Wanneer bovenstaande componenten eenmaal zijn geïnstalleerd kun je beginnen met de installatie van Exchange 2007.

OWA virtual directory configuratie is corrupt

De tweede oorzaak kan zijn dat er instellingen middels IIS zijn aangepast. Eén van de grootste fouten die je kunt maken is dit doen. Op e.o.a. manier vindt Exchange dit toch niet echt leuk, gebruik daarom de Exchange Management Shell of Exchange Management Console om wijzigingen door te voeren.

Mocht je toch dingen hebben gewijzigd middels IIS en werkt OWA hierna niet meer dan is er maar één oplossing. Verwijder de OWA virtual directory en maak heb opnieuw aan. Dit kan eenvoudig gedaan worden d.m.v. de commando’s remove-owavirtualdirectory en new-owavirtualdirectory te gebruiken.

Als eerste stap verwijderen we de oude OWA directory:

remove-owavirtualdirectory “owa (Default Web Site)”

Dit zorgt ervoor dat de OWA virtual directory wordt verwijderd in IIS:

Vervolgens maken we de nieuwe OWA directory:

new-owavirtualdirectory -OwaVersion “Exchange2007″ -Name “owa (Default Web Site)”

Dit zorgt ervoor dat de OWA virtual directory opnieuw wordt aangemaakt en als je geluk hebt werkt OWA nu weer. Dit zijn slechts 2 mogelijke oorzaken van het probleem, mocht je er meer tegenkomen laat het me dan weten zodat ik deze aan het artikel toe kan voegen johan (a)  johanveldhuis.nl

De pop3 connector heeft een aantal opties die je kunt configureren, één daarvan is bijvoorbeeld de banner die je te zien krijgt wanneer je connectie maakt met de server. Nou is dit waarschijnlijk niet één van de instellingen die je gaat wijzigen. Er is een grotere kans dat er wijzigingen zijn gemaakt aan de authenticatie methode of de manier waarop clients mail berichten op kunnen halen.

Nadat je wijzigingen hebt uitgevoerd dien je de pop3 service te herstarten, dit kan via de services MMC of middels het commando net stop MSExchangePop3 gevolgd door net start MSExchangePop3. In een omgeving met maar één domain controller zal dit wel werken. Maar wanneer je een omgeving hebt met meerdere domain controllers dan kan het wel eens even duren voordat de wijziging is doorgevoerd, ondanks dat je de pop3 service hebt herstart.

Instellingen van o.a. de pop3 connector worden namelijk opgeslagen in de Active Directory. Je kunt ze terugvinden in de configuration partitie van AD in de volgende map:

CN=Services, CN=Microsoft Exchange, CN=Administrative Groups,CN=Exchange Administrative Group  (FYDIBOHF23SPDLT),CN=Servers,CN=CASServer,CN=Protocols,CN=Pop3,CN=1

Wanneer je vervolgens de eigenschappen van dit object opvraagt zul je de diverse instellingen zien voor de pop3 connector:

Hou er dus rekening mee dat mocht je pop3 wijzigingen doorvoeren en je hebt meerdere DC’s dat het even kan duren voordat de wijziging is doorgevoerd.

Het schema versie van Exchange 2007 SP3 is dus hoger als die van de Exchange 2010 setup. Dit maakt het dus niet mogelijk om Exchange 2010 te installeren.

Wanneer Exchange 2007 SP3 dus is geïnstalleerd zul je moeten wachten tot er een service pack uitkomt waarin het schema wordt uitgebreid. Aangezien waarschijnlijk veel mensen Exchange 2007 SP3 installeren zal dit vermoedelijk in SP1 van Exchange 2010 verwerkt zijn.

Onderstaand een overzicht van Exchange versies met hierbij de versie van het schema wat gebruikt wordt:

Mocht je willen weten hoe je kunt achterhalen wat de huidige versie van je AD schema is kijk dan eens op onderstaande site:

open

Veel leesplezier:

open

(PID 5396, Thread 640) Task New-MoveRequest writing error when processing record of index 0. Error: Microsoft.Exchange.MailboxReplicationService.MailboxReplicationTransientException: Service ‘net.tcp://cas001.lab.local/Microsoft.Exchange.MailboxReplicationService’ encountered an exception. Error: MapiExceptionNetworkError: Unable to make connection to the server. (hr=0×80004005, ec=2423)

Diagnostic context:
……   
Lid: 12952   dwParam: 0x6BA      Msg: EEInfo: prm[3]: Long val: 1722
Lid: 16280   dwParam: 0x6BA      Msg: EEInfo: ComputerName: n/a
Lid: 8600    dwParam: 0x6BA      Msg: EEInfo: ProcessID: 2268
Lid: 12696   dwParam: 0x6BA      Msg: EEInfo: Generation Time: 2010-06-30 12:15:24:818
Lid: 10648   dwParam: 0x6BA      Msg: EEInfo: Generating component: 8
Lid: 14744   dwParam: 0x6BA      Msg: EEInfo: Status: 1722
Lid: 9624    dwParam: 0x6BA      Msg: EEInfo: Detection location: 1442
Lid: 13720   dwParam: 0x6BA      Msg: EEInfo: Flags: 0
Lid: 11672   dwParam: 0x6BA      Msg: EEInfo: NumberOfParameters: 1
Lid: 8856    dwParam: 0x6BA      Msg: EEInfo: prm[0]: Unicode string: EX02
Lid: 45169   StoreEc: 0×977    
Lid: 52465   StoreEc: 0×977    
Lid: 60065 
Lid: 33777   StoreEc: 0×977    
Lid: 59805 
Lid: 52209   StoreEc: 0×977    
Lid: 19778 
Lid: 27970   StoreEc: 0×977    
Lid: 17730 
Lid: 25922   StoreEc: 0×977      —> Microsoft.Exchange.MailboxReplicationService.MailboxReplicationTransientException: Exception details: MapiExceptionNetworkError (80004005): MapiExceptionNetworkError: Unable to make connection to the server. (hr=0×80004005, ec=2423)

Maar waar wordt deze foutmelding door veroorzaakt? Er kunnen meerdere oorzaken zijn die deze melding veroorzaken. De melding MapiExceptionNetworkError geeft aan dat er een probleem is met het maken van een connectie naar een server.  De volgende vraag is natuurlijk naar welke server dan? Dit is te zien op de regel welke begint met Lid 8856, wanneer je aan het einde van de regel kijkt zie je de naam van de server, in dit geval dus de EX02.

Wanneer je echter verder leest kom je de foutmelding 0×80004005 tegen welke kan duiden op een authenticatie probleem.

Dit laatste is natuurlijk het makkelijkst te controleren door nogmaals het new-moverequest commando uit te voeren, dit maal met de correcte gebruikersnaam en wachtwoord.

Wanneer dit niet werkt controleer dan onderstaande items:

• Is de server bereikbaar van het nieuwe forest
• Controleer eventuele firewall instellingen
• Kan de server op NETBIOS naam geresolved worden

Misschien heb je wat vraagtekens bij de laatste optie, echter in dit geval was dit het probleem. Op de NIC stond alleen de nieuwe suffix geconfigureerd en niet de oude. Toen de oude suffix was toegevoegd in de TCP/IP configuratie werkte het commando zonder problemen.

Maar hoe werkt dit principe nu precies? In de directory van OWA, te vinden onder Exchange\ClientAccess\Owa vind je de directory auth. Deze directory bevat enkele bestanden welke nodig zijn om een gebruiker in te laten loggen en uit te laten loggen. Maar naast deze bestanden staan er ook twee nieuwe bestanden expiredpassword.aspx en exppw.dll.

Voordat je gebruik kunt maken van de nieuwe functionaliteit zal je een aanpassing moeten maken in het register van de CAS server. Ga hiervoor naar onderstaande locatie in het register:

HLKM\SYSTEM\CurrentControlSet\Services\MSExchange OWA

Maak vervolgens een DWORD aan met de naam ChangeExpiredPasswordEnabled en geef de nieuwe key de waarde 1. Eenmaal toegevoegd zal dit er als volgt uitzien:

Wanneer tijdens het inloggen (logon.aspx) wordt gedetecteerd dat het wachtwoord is verlopen en de gebruiker het direct moet wijzigen zal de gebruiker omgeleid worden naar het bestand expiredpassword.aspx.

Voordat de gebruiker zijn/haar wachtwoord kan wijzigen dient hij als extra controle het oude wachtwoord op te geven. Eenmaal aangepast wordt de gebruiker direct naar zijn/haar mailbox omgeleid.

In eerste instantie maar eens in het event log gaan kijken aangezien hier standaard aardig wat informatie in wordt gelogd. Hierin was onderstaande melding zichtbaar:

Mailbox move for ‘xxxxxxxxxxxxxxxxxxxxxx’ (d126705e-af4d-4aca-83c6-0ea443a2ad60) has failed.
Error code: -2147024809
MapiExceptionInvalidParameter: Unable to set properties on object. (hr=0×80070057, ec=-2147024809)
Diagnostic context:
    Lid: 18969   EcDoRpcExt2 called [length=363]
    Lid: 27161   EcDoRpcExt2 returned [ec=0x0][length=108][latency=0]
    Lid: 23226   — ROP Parse Start —
    Lid: 27962   ROP: ropSetProps [10]
    Lid: 17082   ROP Error: 0×80070057
    Lid: 30561 
    Lid: 21921   StoreEc: 0×80070057
    Lid: 27962   ROP: ropExtendedError [250]
    Lid: 1494    —- Remote Context Beg —-
    Lid: 26426   ROP: ropSetProps [10]
    Lid: 47113 
    Lid: 7915    StoreEc: 0×80070057
    Lid: 5263    StoreEc: 0×80070057
    Lid: 19768 
    Lid: 4559    StoreEc: 0×80070057
    Lid: 1750    —- Remote Context End —-
    Lid: 26849 
    Lid: 21817   ROP Failure: 0×80070057
   Lid: 25761 
    Lid: 1940    StoreEc: 0×80070057
    Lid: 25297 
    Lid: 21201   StoreEc: 0×80070057
Context:
Mailbox: Primary (d126705e-af4d-4aca-83c6-0ea443a2ad60)
Folder: ‘/Top of Information Store/Taken/xxxxxx’, entryId [len=46, data=00000000109014FD0A523641A2C3C55606B5EA8201006E5BA8745959BC4C9F7B175EAE3144A80000378F00370000], parentId [len=46, data=00000000109014FD0A523641A2C3C55606B5EA820100C0260BEE56B49E4981448625D74A5AAB0000000400470000]
Operation: LocalDestinationFolder.SetSecurityDescriptor
SD: O:S-1-5-21-3869603026-3631219241-1903344517-3835G:S-1-5-21-3869603026-3631219241-1903344517-513D:AI(A;OIIO;0x1f0fbf;;;S-1-5-21-3869603026-3631219241-1903344517-3835)(A;CI;0x1fc9ff;;;S-1-5-21-3869603026-3631219241-1903344517-3835)(A;OIIO;0x1208a9;;;S-1-5-21-4230955503-526549450-3057572010-5377)(D;OIIOID;0x1f0716;;;S-1-5-21-3869603026-3631219241-1903344517-2781)(A;CI;0x1208a9;;;S-1-5-21-4230955503-526549450-3057572010-5377)(D;CIID;0xdc916;;;S-1-5-21-3869603026-3631219241-1903344517-2781)

Zoals te zien is in de melding zijn er problemen op de Taken map. Toen we hier samen met de gebruiker op gingen kijken stonden hier wat rechten op gedefinieerd maar niks bijzonders. Na overleg met de gebruiker heeft deze in eerste instantie geprobeerd op één van de mappen de specifieke rechten te verwijderen. Nadat dit was gebeurd kwamen we een map verder maar zoals verwacht liepen we vast op de volgende map waar rechten op stonden gedefinieerd.
Het is natuurlijk niet echt een optie om alle rechten te gaan verwijderen op een map om vervolgens de mailbox te gaan migreren. Dus maar even contact opgenomen met Microsoft om het e.e.a. uit te zoeken.

Na het gesprek werd een hoop duidelijk. Wat er gedaan wordt tijdens een mailbox move van Exchange 2003 naar Exchange 2010 wordt er geprobeerd de ACL’s opnieuw in te stellen. Dit omdat Exchange 2010 anders met ACL’s omgaat als Exchange 2003. Het kan echter voorkomen dat de ACL corrupt raakt waardoor deze niet kan worden omgezet. Wanneer dit het geval is zal het move request afgebroken worden.

De oplossing: definieer middels Outlook de rechten opnieuw, dit kan door deze te verwijderen of eventjes te wijzigen naar iets anders en daarna weer terug te zetten zoals deze stonden. Niet een hele mooie oplossing maar je kunt wel verder migreren.

Collega Michel de Rooij kwam nog met de tip om het eens te proberen via PFdavAdmin deze tool bied namelijk de mogelijkheid om ACL’s te repareren van mailboxen.

Warning: Unable to update AD information for the source mailbox at the end of the move.  Error details: An error occurred while updating a user object after the move operation. –> Failed to find the address type object in Active Directory for address type “SMTP:AMD64″.
Failed to cleanup the source mailbox after the move.
Error details: MapiExceptionNotFound: Unable to delete mailbox. (hr=0x8004010f, ec=-2147221233)

Toen we gingen kijken bestond de mailbox inderdaad zowel in het oude forest als in het nieuwe forest. In dat geval heb je een redelijke uitdaging zeker als de mail eerst binnenkomt op de Exchange 2003 server en het homeMDB attribuut daar nog niet is geupdate. Mail wordt dan namelijk alleen maar afgeleverd in de Exchange 2003 omgeving en niet in de nieuwe omgeving wat dus inhoudt dat er mail niet aanwezig is in de nieuwe mailbox in de Exchange 2010 omgeving.

Om dit probleem te voorkomen dien je een hotfix op de Exchange 2003 omgeving te installeren, de hotfix is te vinden op onderstaande site.

open