Zoals je misschien weet zijn er twee verschillende versies van Exchange 2010:

• 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.

Gepost in Exchange 2010 ~ Geen Reactie

Op dit moment ben ik bezig met een Exchange 2003 omgeving naar Exchange 2010. Tijdens het migreren liep ik tegen een issue op wat als resultaat had dat de oude mailboxen niet netjes werden opgeruimd en de gebruiker dus ook niet converteerde naar een mail user. Nou komt het niet op kunnen ruimen van de oude mailbox wel vaker voor en de enige oplossing die er op dit moment is de cleanup agent draaien in de Exchange System Manager.

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.

Gepost in Exchange 2010 ~ Geen Reactie

Volgens de Technet documentatie zou je gewoon Exchange 2010 naast Exchange 2007 moeten kunnen draaien. Laatst kreeg ik een vraag van een klant die hiermee problemen had. De huidige Exchange 2007 omgeving was up-to-date en Service Pack 3 was dus geïnstalleerd. Tijdens het uitbreiden van het schema middels het setup.com /ps commando was de volgende foutmelding te zien:

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

Gepost in Exchange 2010 ~ 7 Reacties

Het is alweer een tijdje geleden sinds de laatste tutorial, daarom is het weer hoog tijd voor een nieuwe. Dit keer over de nieuwe functionaliteiten van Exchange 2010 SP1 beta en dan specifiek de Unified Messaging rol.

Veel leesplezier:

open

Gepost in Exchange 2010 ~ Geen Reactie

Tijdens het migreren van een mailbox uit een ander Exchange forest naar een nieuw Exchange forest liep ik tegen onderstaand probleem op:

(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.

Gepost in Exchange 2010 ~ Geen Reactie

Tijdens een cross-forest migratie van een Exchange 2003 naar een Exchange 2010 omgeving liep ik tegen een probleem aan tijdens het migreren van een mailbox.  De eerste 10% ging goed maar daarna klapte het move-request eruit met een foutmelding. In de eerste 10% worden de mailbox aangemaakt, wordt de mappenstuctuur aangemaakt en worden de rechten op de mappen gezet.

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.

Gepost in Exchange 2010 ~ Geen Reactie

Tijdens een cross-forest test-migratie van Exchange 2003 naar Exchange 2010 liep ik tegen onderstaande foutmelding aan:

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

Gepost in Exchange 2003, Exchange 2010 ~ Geen Reactie

Bij toeval tegen een bugje aangelopen in Exchange 2010. De issue doet zich alleen voor met Exchange 2010 en als de CAS servers zich in verschillende sites bevinden waartussen niet alle communicatie mogelijk is. Tot nu toe heb ik deze issue alleen gezien wanneer er in bijvoorbeeld het hoofdkantoor nog een CAS bijgezet wordt. Dit is dan in dit geval de 3rde CAS server in de Exchange 2010 omgeving.

Normaliter krijg je met get-owavirtualdirectory netjes een overzicht terug van alle CAS servers welke de OWA service aanbieden. Wanneer er echter geen RPC verkeer mogelijk is tussen de CAS servers in de diverse sites dan krijg je onderstaand resultaat:

Zoals je ziet geeft het commando netjes de eerste CAS server weer maar bij de tweede CAS gaat het verkeerd. Logisch want deze is niet te bereiken via RPC. Normaliter zou je verwachten dat de query wel op zoek gaat naar nog meer CAS servers, nou niet dus. Na contact met Microsoft werd bevestigd dat dit een bug is en dit in een toekomstige update wordt gefixt.

Workaround: zet RPC open

Gepost in Exchange 2010 ~ Geen Reactie

Tijdens het ombouwen van een pilot naar een produktie omgeving liep ik tegen een leuk issue’tje aan. De mailboxen moesten verplaatst worden van de oude mailbox server naar een nieuwe mailbox server. Normaliter niet een heel spannend proces wat zowel via de Exchange Management Console als Exchange Management Shell uitgevoerd kan worden. Toch lukte het niet om de mailboxen te verplaatsen van de ene Exchange 2010 mailbox server naar de nieuwe Exchange 2010 mailbox server. Als eerst maar even het event log onderzocht en daar kwam ik het volgende in tegen:

(PID 5988, Thread 954) Task New-MoveRequest writing error when processing record of index 0. Error: Microsoft.Exchange.MailboxReplicationService.MailboxReplicationTransientException: The call to ‘net.tcp://cas.domain.local/Microsoft.Exchange.MailboxReplicationService’ failed. Error details: The type initializer for ‘Microsoft.Exchange.MailboxReplicationService.LocalMailbox’ threw an exception.. —> System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: The type initializer for ‘Microsoft.Exchange.MailboxReplicationService.LocalMailbox’ threw an exception. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:

System.TypeInitializationException: The type initializer for ‘Microsoft.Exchange.MailboxReplicationService.LocalMailbox’ threw an exception. —-> System.IO.FileLoadException: The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0×80131040)

   at Microsoft.Exchange.MailboxReplicationService.LocalMailbox..cctor()

   — End of inner ExceptionDetail stack trace —

   at Microsoft.Exchange.MailboxReplicationService.LocalMailbox..ctor(LocalMailboxFlags flags)
   at Microsoft.Exchange.MailboxReplicationService.LocalSourceMailbox..ctor(LocalMailboxFlags flags)
   at Microsoft.Exchange.MailboxReplicationService.MailboxReplicationService.<>c__DisplayClass25.<GetMailboxInformation2>b__24()
   at Microsoft.Exchange.MailboxReplicationService.CommonUtils.CatchKnownExceptions(GenericCallDelegate del, FailureDelegate failureDelegate, MrsTracer tracer)
   at Microsoft.Excha…).

   — End of inner exception stack trace —

   at Microsoft.Exchange.MailboxReplicationService.CommonUtils.CallService(GenericCallDelegate del, String epAddress)
   at Microsoft.Exchange.MailboxReplicationService.MailboxReplicationServiceClient.GetMailboxInformation(Guid primaryMailboxGuid, Guid physicalMailboxGuid, Guid targetMdbGuid, String targetMdbName, String remoteHostName, String remoteOrgName, String remoteDCName, NetworkCredential cred)
   at Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest.InternalValidate()
   at Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()

Zoals in de foutmelding al wordt weergeven is er iets mis met de Exchange Mailbox Replication Service (MRS). Deze service bevind zich op de server(s) welke de Client Access Role hebben en zorgt ervoor dat de mailbox van de bron server naar de doel server wordt verplaatst.  Wanneer je meerdere CAS servers in één site hebt zullen de MRS services onderling informatie uitwisselen zodat het verplaatsen maar door één server wordt opgepakt en niet door meerdere.

Aangezien er in dit geval maar 1 CAS server was, de cas.domain.local, besloot ik op deze server eens wat nader onderzoek te doen. De service draaide echter netjes dus besloot ik de Mailbox Replication Service te herstarten. Nadat dit was gebeurd nogmaals geprobeerd de mailbox proberen te verplaatsen en dit keer verliep dit zonder problemen.

Oorzaak heb ik helaas niet kunnen achterhalen en mailbox moves op de nieuwe server verlopen ook zonder problemen. Eén van de oorzaken kan bijvoorbeeld zijn een mailbox database die niet helemaal lekker is. D.m.v. het gebruik van eseutil en isinteg zou je de database in dit geval kunnen repareren en hierna nogmaals de mailbox move kunnen uitvoeren.

Onderstaand nog wat handige sites die extra informatie  bevatten over het proces en de problemen die je kunt ondervinden:

Technet: Understanding Move Requests open
Technet: Troubleshooting Mailbox Moves open

Gepost in Exchange 2010 ~ 1 Reactie

Weer een leuk probleempje tegengekomen dit keer met de installatie van Forefront for Exchange 2010. Het begon met een pre-release die ervoor zorgde dat de Exchange Transport service niet meer gestart kon worden vanwege een mislukte update van Forefront. Dit veroorzaakte dat er diverse Forefront services niet meer startte. Aangezien de Exchange Transport service afhankelijk is van de Forefront service kon er geen mail meer verzonden en ontvangen worden.

Aangezien de RTM versie vrij is gegeven was dit natuurlijk een mooi moment om deze gelijk te installeren. Dus eerst de pre-release verwijderd zodat ik zeker wist dat dit geen problemen zou geven. Hierna begon de ellende, de eerste paar stappen gingen goed maar tijdens de prerequisite check ging het mis. Die kwam namelijk met de volgende melding: 

Eerst maar eens even gecontroleerd of de gebruiker lid was van de goede groepen:

• local administrator
• domain administrator
• Exchange organization management groep

Dit was het geval dus ik wist bijna zeker dat dit het probleem niet veroorzaakte. Toen maar eens kijken of ik de domain controller kon bereiken dit was ook geen probleem. Je vraagt je misschien af waarom moet de installatie contact kunnen maken met de domain controllers? Dit omdat Forefront the Hygiene Management groep update door de computeraccount van Exchange toe te voegen. Eigenlijk dus heel wazig tot we, omdat dit toch moest, wat poorten in de firewall hadden opgezet richting de DC’s in de andere lokatie.

Als laatste poging wilde ik een collega laten zien wat het issue was en stond verbaasd te kijken toen de installatie ineens doorliep. Natuurlijk waren we benieuwd naar de oorzaak en zijn we op onderzoek uitgegaan. Het probleem lijkt te zitten in het niet kunnen bereiken van de domain controller waar de PDC en RID Master FSMO rollen op draaien.

Al met al weer een leerzaam moment en waarom de installatie van de pre-release wel gelukt was ? Toen stonden alle servers nog op één lokatie.

Gepost in Exchange 2010 ~ Geen Reactie