Exchange 2007 Issues: Mailbox Management

It goes without saying that the release of any major new version of an enterprise software product will require the administrators of those products to go through an additional learning curve, which will naturally prompt many new questions on the processes and procedures involved with the product. Exchange 2007 is no exception here.

I’ve noticed over the last few months that there are many questions posted around the various newsgroups, mailing lists and forums that can be categorized in the “In Exchange 2007, how do I….?” format. It’s clear that since there has been a major architectural change with Exchange 2007, there are many new features for administrators to explore and understand as well as many new procedures to follow. I’ve seen many questions asked and experienced quite a few head-scratching moments myself, so in this article I’ve compiled a couple of issues and their resolutions that relate to Exchange 2007 mailbox management. Hopefully in the future months ahead I can put together additional articles that cover some of the other issues and situations that administrators find themselves in when embarking on the road to understanding Exchange 2007 administration. Obviously I’ll be detailing what I consider to be the correct resolutions to those issues. Although the two issues below are primarily mailbox and/or user account issues, their symptoms are seen in Outlook Web Access (OWA).

Mailbox Version Error in OWA

When Exchange 2000 was released, Microsoft taught us that we should create user accounts and mailboxes at the same time using the Active Directory Users and Computers snap-in. This was a different approach to Exchange 4.0, 5.0 and 5.5 since back in those days the NT4 domain user accounts were created separately to the actual mailboxes. The procedure of creating both user accounts and mailboxes within the Active Directory Users and Computers snap-in remained the same in Exchange 2003 and so this process became firmly ingrained in the Exchange administrator’s mind. I’m sure you are all familiar with the process, but as a reminder the screen shot in Figure 1 shows the mailbox creation screen as seen when creating a user account in Active Directory Users and Computers.

Figure 1: Creating an Exchange Mailbox

However, this process changed with the introduction of Exchange 2007 with the news that the creation of mailboxes was now moved back into the Exchange Management Console (and, of course, the Exchange Management Shell if you prefer to do things from the command line). It comes as no surprise then that some Exchange administrators have attempted to create mailboxes on an Exchange 2007 server from within the Active Directory Users and Computers snap-in. Look at Figure 1 again, and you’ll notice that the Server field is set to be an Exchange 2007 server since the administrative group name is that of the Exchange 2007 administrative group. When in a transition phase from Exchange 2000 or Exchange 2003 to Exchange 2007, it follows that the Exchange 2007 servers will be available in the drop-down server list that you can see in Figure 1. After all, the Exchange 2007 servers are coexisting nicely with the Exchange 2000 or Exchange 2003 servers so this makes sense. However, selecting the Exchange 2007 server as the target server for a new user account is not the correct process to follow. Having said that, let’s look at what actually happens if you do this.

The first thing to note is that the Active Directory Users and Computers snap-in actually allows you to create the user account and mailbox as normal. If the administrator is not aware that they shouldn’t be doing this in the first place, they aren’t going to be any the wiser at this stage. Let’s now see what happens if you try to access this mailbox via Outlook Web Access. The first thing that will be seen after the credentials are supplied is the normal opening OWA screen that you see when you first access a new mailbox via OWA. This screen allows you to set the default language and time zone options. So far so good. After choosing the relevant options on this screen, the next thing that will be displayed is the error shown in Figure 2 below.

Figure 2: Initial OWA Error

That’s not so good. Expanding the Show details option reveals much more information, as seen in Figure 3. TheException part of the screen gives you the following message:

“There was a problem accessing Active Directory.”

You will notice that I’ve highlighted the Inner Exception text, the important information, in red. Specifically, the error states:

“Property Languages cannot be set on this object because it requires the object to have version 0.1 (8.0.535.0) or later. Current version of the object is 0.0 (6.5.6500.0).”

Figure 3: Expanded OWA Error

You can probably deduce from this error message that the mailbox has incorrect version information since it wasn’t created using the Exchange Management Console or Exchange Management Shell. In fact, if you view this mailbox in the Exchange Management Console under the Mailbox object of the Recipient Configuration node, you will see it listed with a Recipient Type Details setting of Legacy Mailbox, even though the Server column shows the Exchange 2007 mailbox server. This can be seen in Figure 4.

Figure 4: Legacy Exchange Mailbox

Perhaps more confusing to the administrator is that the mailbox can be opened in Outlook but not via OWA. To fix the problem you do not need to delete and re-create the account using the Exchange 2007 tools. Instead, you can run the following Exchange Management Shell cmdlet:

Set-Mailbox User5 –ApplyMandatoryProperties

Obviously in this example we’re targeting the mailbox for User5, so remember to replace this alias with the correct alias in your environment. This should be enough to get the mailbox working correctly since it will now be configured with the correct Exchange 2007 properties.

Insufficient Access Error in OWA

Another error that can occur when connecting to a mailbox via OWA can be seen after moving mailboxes from Exchange 2003 to Exchange 2007. In this case, the mailbox is moved correctly to Exchange 2007 by using either the Exchange Management Console or the Exchange Management Shell. No errors are recorded during the mailbox move. After the mailbox move, the user attempts to log into Outlook and is successful. However, like the other situation that has been discussed within this article, an attempt to use OWA to access the mailbox proves unsuccessful.

In this example, the user credentials are supplied and after that the default OWA time zone and language screen is displayed as would be expected. After the OK button is clicked on this screen, the same basic error screen that you see above in Figures 2 and 3 is displayed, although this time the error text in the Inner Exception part of the screen reads as follows:

“Active Directory operation failed on {FQDN of domain controller}. This error is not retriable. Additional information: Insufficient access rights to perform the operation.”

The key part of this error is the phrase “Insufficient access rights to perform the operation”. This can occur in the situation where the user trying to access OWA is currently a domain administrator via membership of a group such as Domain Admins, or was one at some point in the past.  If that isn’t the case, it’s worth reading on anyway as there’s something to check on the account. Taking an example case presented here, User3 was once a member of the Domain Admins group although that user has since been removed from this group. Then, Exchange 2007 was installed and User3’s mailbox moved across from Exchange 2003. Why should the fact that User3 was once a member of Domain Admins cause an OWA login issue? Let’s check the permissions on this account in Active Directory Users and Computers. Here’s what to do:

1. Run the Active Directory Users and Computers snap-in and locate the user account.
2. Bring up the properties of the user account and go to the Security tab. If you don’t see the Security tab, choose View / Advanced Features.
3. On the Security tab, click the Advanced button.
4. You should now see a screen similar to the one shown in Figure 5. Notice the fact that the check box Allow inheritable permissions… is not selected. This is the problem. If you re-select this check-box and close the property pages of the user account, you should now find that OWA works for this user. This assumes that all necessary Active Directory replication has completed, of course.

Figure 5: User3’s Permissions

Generally, for security reasons, it’s not a good idea to assign a mailbox to an administrator account. If this is done, a process runs automatically to clear the check box shown above which ultimately prevents the OWA log on process.