Wednesday, April 6, 2016

SCOM Test Mailboxes and Recovery Databases

Hi Folks,

 As you well know Exchange Monitoring Management Pack can run synthetic transactions to help you measure the performance of monitored objects in your Exchange organization. It does it by running Test-OwaConnectivity, Test-ActiveSyncConnectivity, and Test-WebServicesConnectivity against Exchange and monitoring CAS protocols performance.

For synthetic transactions test mailboxes are used. And MS provides new-TestCasConnectivityUser.ps1 script out of box which allows creation of these mailboxes.

When attempting to create test mailboxes I got an error with the following text:

CreateTestUser : Mailbox could not be created. Verify that OU (Users) exists and that password meets complexity requirements.

I have checked my environment and Users container (default one in domain) was present in the AD environment and password that I used was long enough. However issues still persisted.

There are some good posts on how to have this problem solved. This post advises to use -OU parameter which didn't work for me. This post was suggesting to replace Users value of the $OrganizationalUnit variable to something like or DC=Users,DC=contoso,DC=com. Finally, there were articles like this one  which suggests to remove -OrganizationalUnit parameter from the New-Mailbox command which will force mailbox creation in the default Users container. In fact, once in Exchange 2010 environment the last method worked for me perfectly.

Unfortunately none of these approaches, including the last one, helped me. After some of Google-ing I ran into this his article. Following its instruction I found that the problem is with this bit of the code in the script:

new-Mailbox -Name:$UserName -Alias:$UserName -UserPrincipalName:$UserPrincipalName -SamAccountName:$SamAccountName -Password:$SecurePassword -Database:$mailboxDatabaseName -ErrorVariable err -ErrorAction SilentlyContinue

It keeps us blind without actually showing what caused mailbox creation to fail. Therefore, as the article author suggested I removed the 2 parameters -ErrorVariable err -ErrorAction SilentlyContinue and the code became like:

new-Mailbox -Name:$UserName -Alias:$UserName -UserPrincipalName:$UserPrincipalName -SamAccountName:$SamAccountName -Password:$SecurePassword -Database:$mailboxDatabaseName  -OrganizationalUnit:$OrganizationalUnit

By the way, I decided not to touch the original script but rather moved it (new-TestCasConnectivityUser.ps1) and its strings file (new-TestCasConnectivityUser.strings.psd1) to a separate folder (the 2 should be together or script won't run).

Script execution showed me that script attempted to create mailbox in the recovery database:

The root cause of the problem was in this section of the script:

It populates variable named $mailboxDatabaseName with the name of the last database. In my case it was a recovery database.

So I wanted to ensure is that my test mailbox is not provisioned in the recovery DB. You can do 3 things:
- create recovery DB after you create test mailbox
- remove recovery DB and then recreate it
- or do it as the author of the article has suggested, namely giving static value to the $mailboxDatabaseName variable

There's something universal that allows us to bypass recovery databases. When configuring $mailboxDatabaseName variable we need to add the following filter {$_.Recovery -ne "True"}. As the result Get-MailboxDatabase command returns only databases which are non-recovery. As the result I have got this section like below:

$mailboxDatabaseName = $null;
    get-MailboxDatabase -server $mailboxServer |Where-Object {$_.Recovery -ne "True"}| foreach {$mailboxDatabaseName = $_.Guid.ToString()}

After saving and running script my test mailbox was successfully created.

I hope if you ever run in this situation this article will help.