The OWA saga continues…

After solving the msExchVersion mystery, it has become apparent that even more of our Exchange 2007 users were unable to access OWA.
After logging onto the site, a very similar error is displayed: Exception type: Microsoft.Exchange.Data.Storage.StoragePermanentException Exception message: There was a problem accessing Active Directory. My first step was obviously to verify the msExchVersion.
After ensuring that this was correct, and that the users were still unable to use OWA, I had to do more digging. Deeper delving into this issue, yielded the following KB from Microsoft: http://support.microsoft.com/kb/949527
To use OWA the Exchange Servers group must have write permissions to the msExchUserCulture attribute. Easy to resolve, just allow inheritable permissions from the parent to filter to the faulty object / objects, as per the KB article.
Easy enough on one account, but if you had to change this setting manually on multiple accounts, you could use Set-QADObjectSecurity –UnlockInheritance to accomplish the task. For more information see Dimitri’s blog

Legacy mailboxes on Exchange 2007

One of our users had a problem logging onto OWA today, and I noticed that the icon for his mailbox in the GUI displayed as a legacy mailbox, although he was located on an Exchange 2007 mailbox server.

After countless searches, I came across this article: http://support.microsoft.com/kb/941146. It explains that the msExchVersion property on the AD object is not set correctly, and that using set-mailbox –ApplyMandatoryProperties would resolve the problem. Looking at the help information on set-mailbox this could also be caused by users being created on Exchange 2007 server using the Exchange 2003 tools, although these users were migrated from Exchange 2003.

So, how to correct this? First get a list of all mailboxes on the Exchange 2007 server with the incorrect version. Using get-mailbox, the incorrect Exchange version displays as 0.0 (6.5.6500.0) The following command returns a list of these mailboxes by server (where SERVER1 is your Exchange 2007 server):
get-mailbox -server SERVER1 -resultsize unlimited | where {$_.ExchangeVersion -like "*0.0*"} | select Name, ExchangeVersion
Once you verify the list, pipe them to set-mailbox.

get-mailbox -server SERVER1 -resultsize unlimited | where {$_.ExchangeVersion -like "*0.0*"} | Set-Mailbox –ApplyMandatoryProperties  
This resolved the problem for me, easily, on multiple Exchange mailboxes. Running the get-mailbox command again, returned no results after applying set-mailbox to the problematic mailboxes.

Updated: Exchange Mailbox Cleaner

I have really been busy lately and have not had much time to spend on scripting. I did however find a litlle time to update this utility. Here is a list of changes:

 – After completing a query, the utility will now show you the total amount of data used by the mailboxes. (this obviously ignores single instance storage etc.)
 – You can now use the utility to move selected mailboxes to another store (This was a request from Aaron)
 – I have force removed the mandatory “confirm” on the Exchange verbs (move, disabled and delete) 

WARNING: This is a dangerous utility, and can wreck your Exchange system if you are not careful. Please test this in your test environment first, and adhere to your change control procedures before using this utility in the live environment. I take absolutely no responsibility for any damage caused by using this tool. The utility requires the Exchange Management shell, and if launched from a Vista / Windows 7 needs to be “Run as Administrator” The script can be downloaded from here: