Sunday, February 28, 2010

Errors moving mailboxes to an Exchange 2010 DAG

I ran into this today, doing my first production DAG with a copy on a kind of slow connection.

Error: Move for mailbox '/o=First Organization/ou=First Administrative Group/cn=Recipients/cn=user' is stalled because DataMoveReplicationConstraint is not satisfied for the database 'Database' (agent MailboxDatabaseReplication). Failure Reason: Database a409ab86-ce24-4fcf-bd2a-14fd633090aa does not satisfy constraint SecondCopy. Some database copies are behind.

Sure enough, a quick check of get-MailboxDatabaseCopyStatus showed that my CopyQueueLength was fairly high on the server across the WAN. As a result, my mailbox moves were failing with the above error. However, they don't fail right away, the StatusDetail shows StalledDueToHA. Some stayed there up to two hours waiting for the log shipping to catch up on the remote server before failing.

To show a more detailed output on move progress, I was using:
Get-MoveRequest Get-MoveRequestStatistics | ft displayname,*stat*,perc*,totalmailboxsize

So what Exchange 2010 is doing here is smart. Exchange Active Manager doesn't want that CopyQueueLength to be over 10 files, or the replay queue length over 50. More constraints here.

The workaround is to disable this limit, so your moves can occur and the seeding can occur over time. This is one of three Microsoft recommended fixes. One is fix your database health, one is upgrade your WAN. This third one is a workaround that should be reconfigured after the initial mailbox moves.

Set-MailboxDatabase -DataMoveReplicationConstraint None

The default here is SecondCopy. More information on the other settings at the link above. This change DOES require a restart of the Exchange Replication Manager service. Be forewarned, if you have a queue length already, the replication manager will hang on stopping and attempt to complete the copies before stopping, so it might take some time.

Of course, once your moves are done, and your database's CopyQueueLength is normalized, you should re-enable this constraint using:

Set-MailboxDatabase -DataMoveReplicationConstraint SecondCopy

Tuesday, February 23, 2010

Normalizing Phone Numbers to E.164 format in Excel

Recently, I had the need to import some users for a large company. In order to populate as much of their Active Directory as possible, they wanted their phone numbers to be in a standardized format. Both Microsoft and Cisco have standardized on E.164 (additional information here) as a numbering standard, which basically starts with + [country code] + phone number.

This particular customer is US based only, so all the numbers in their spreadsheet had a US country code of 1. If I had a multinational organization, some additional coding would need to be done to account for other country codes.

My major need was to simply re-input all the different numbering standards the various internal organizations had inputted their phone numbers as. In other words, normalization. This helps to set up AD for later integration of OCS, or other VoIP systems, as well as Exchange 2007 or Exchange 2010 UM.

Either way, the Excel formula I was using here was the following:

In logical order..

  1. Replace ( with null
  2. Replace ) with null
  3. Replace space with null
  4. Replace hyphen with null
  5. Replace period with null
  6. Replace x with ";ext=" (which is the E164 standard for non-DID numbers)
  7. Concatenate the +1 country code

Here again without the horrible color:

The end result, computer readable phone numbers!

Saturday, February 20, 2010

OCS reporting GUI interface!

Saw this on the OCS team blog.

"The report allows you to enter the SIP URI of any 2 users that you want to view archived messages from. If you enter “Any User” (case sensitive) for either of the user input boxes, you are able to view any message from any user to a specific user as well as any user to any other user. You can use the Start Date and End Date to narrow down the search to a specific date range. Once you have entered all of the inputs, click on View Report."

Monday, February 15, 2010

Exchange 2010 Backup Product Support Matrix

Well, the #1 recent article here is my Exchange 2007 and Exchange 2010 Backup how to. The reason, of course, is that Exchange 2010 has been out since November 2009 and select few have yet announced or released Exchange 2010 support, and many companies are still trying to find how to backup Exchange 2010 in their production environment.

While I have not used many of these yet, I am hoping to try to demonstrate them all and update this post as new information comes. However, if you have made a significant investment in any of the below (or others, email me!) and are waiting for support, the best thing you can do is ask your vendor. The more input received, the more important you are making it for them!

Here is a chart of my findings thus far:

VendorProductExchange 2010 SupportExchange 2010 SP1 SupportDAG support
CommvaultCommvaultNon-DAG in 8.0, DAG in 9.0UnknownYes in 9.0
SymantecNetBackupYes in 7.0UnknownYes in 7.0
SymantecBackup Exec 2010Yes, in Backup Exec 2010, must run x64 on BE ServerYes, in Backup Exec 2010 R2Yes in Backup Exec 2010
i365eVaultExpected by EOYExpected by EOYUnknown
MicrosoftDPM 2010YesYesYes
MicrosoftWindows Server BackupYesUnknownYes

By the way, if you know of ANY updates, feel free to comment, or email me directly at If I said Unknown above it's more likely that your web site didn't make this information readily accessible. If I receive emails from the appropriate domain names, I will post it as official, more so if you can provide a link!

Uninstalling Exchange 2003 - 8240 error - 0x80072030

Ran into this one today, and hadn't encountered it in quite some time.

This error is due to the fact that someone had listed their own user as the postmaster account in Exchange 2003, and that person had since left the organization and had their account deleted.

So the error above is shown:
Setup encountered an error while checking prerequisites For the component "Microsoft Exchange":
0X80072030 (8240): There is no such object on the server.

This is easily fixed in ADSIEdt.msc - first, let's find out the user.

I've clipped the name to protect the guilty :)

As you can see, the deleted Objects distinguishedName here shows the user selected as the msExchAdminMailbox has been deleted.

In ADSIEdit, browse to CN=Configuration, DC=DOMAINNAME,DC=Com\CN=Services\CN=Microsoft
Exchange\CN=EXCHANGEORGNAME\CN=Global Settings\CN=Message Delivery. Go to the properties of Message Delivery, and scroll down to the msExchAdminMailbox.

Now, we need to fix the error. Pick who you want to be the new admin (I picked Administrator) and put their DN in this field. In my case, this is CN=Administrator,CN=Users,DC=Domain,DC=com. If you aren't sure of your DN, browse to your user in ADSIEDIT and you can directly copy/paste the DistinguishedName from your user object into this field.

Once done, no service restarts needed, as the uninstaller is just checking these fields.. You can now select Remove for Exchange 2003!

Thursday, February 04, 2010

Exchange 2010 Management tool start up problems

Something that has been posted a LOT on the Exchange 2010 Forums on Technet - people with issues starting the EMC or EMS in Exchange 2010. Many of these step from the slightly different management via WinRM. The Microsoft Team blog posted a GREAT write up on how to troubleshoot the different common errors and address them all!

Migrating PKI from Windows 2003 to Windows 2008 R2

Many customers are running into the need for a Windows 2008 or newer PKI infrastructure in order to enroll and auto enroll newer client operating systems like Windows 7, Vista, and Windows 2008 Server.

Actually, many business customers found the lack of certificate support in Vista (without upgrading their CA's later) as one of the reasons it wasn't business ready. With Windows 7 being almost 10 years newer than Windows XP, many business customers are ready for a software refresh and Windows 7 has enough other appealing features to help that decision along.

There are basically two routes to go; in place upgrade or migration. The only time I would attempt an in place is on a VM so that a snapshot could easily be taken and rolled back in the case of a failure. A migration gives a fresh start, but requires some additional time to complete because between steps you need to wait for certs to issue to clients.

Because certificates are fairly sensitive information, I won't post screen caps, but rather overview the process.

Research and Design

Research what your existing CA is in use for. Anything it has issued needs to be either determined to be invalid (expired, not in use, not needed) or documented as something to replicate on the new CA. The other decision on design is around what CA architecture and hierarchy you want or need. Depends on the size and complexity of your organization this can differ greatly. For most organizations under 2000 users, I would say a single CA is sufficient, and if an additional are needed, use the PKI planning guides that Microsoft provides, or better yet, read Komar's 2k8 PKI book.

Implement and Re-Issue certs

Depending on your usage, this could take a long time. Audit existing certificates, revoke the ones that are not in use or expired, and start re-issuing them on the new CA architecture. For larger organizations, this may take months to complete. Luckily, you can choose to have both CA's active. I recommend changing the certificate templates on the old CA to read only, and no longer allow enroll and auto enroll as you migrate each template type successfully, this way, the old CA still validates certificates issued that you haven't updated while you can work on updating them, without any noticeable downtime.

Decommission Legacy CA

The "easy" part for sure. Removing a CA (Unlike uninstalling Exchange) there are no checks or audits to make sure you did everything correctly. If you didn't notice that your Cisco ASA or VPN Concentrator had a certificate issued and miss it, it may cause some issues for you. I recommend stopping and disabling your legacy CA for a few days or even weeks (this depends on your comfort level, and organization) before you make the decision to decommission. Even then, before you decommission, I would also really recommend taking a complete backup of the server.