Q: My company recently migrated from Exchange Server 2003 to Exchange Server 2010. I’m trying to perform some basic administrative tasks, but it appears I lack sufficient Exchange 2010 permissions. What caused this problem, and how do I fix it?
A: An insufficient permissions problem is actually quite common after a company moves from Exchange 2003 to Exchange Server 2010. The issue usually crops up when the Exchange administrator tries to move user mailboxes from a legacy Exchange server to an Exchange 2010 server. Administrators then receive the following error message:
Error: Mailbox database <database name> is offline.
MapiExceptionLogonFailed: Unable to make connection to the server (HR=0x80040111, EC=1010)
After a series of diagnostic codes, the message goes on to say:
Warning: When an item can’t be read from the source database or it can’t be written to the destination database, it will be considered corrupted. By specifying a non-zero BadItemLimit, you are requesting Exchange not copy such items to the destination mailbox. At move completion, these corrupted items will not be available at the destination mailbox.
This means that either the database is offline (which is easy to verify) or the mailbox contains corrupt items. You can generally rule out mailbox corruption if the mailboxes are functioning properly prior to the attempted move and if the error occurs regardless of which mailbox you’re trying to move.
There are two solutions to this problem:
Adjust Exchange 2010 computer account permissions. Admins often encounter this problem because Exchange 2010 lacks the necessary permissions to interact with the mailbox store on the Exchange 2003 server. Therefore, you might be able to fix the problem by adding the Exchange 2010 mailbox server’s computer account (in Active Directory) to the Exchange 2003 server so that it gives the Exchange 2010 mailbox server full control access to the mailbox store.
To do so, navigate through the Exchange System Manager on the Exchange 2003 server to First Storage Group -> Mailbox Store. Next, right-click on the Mailbox Store and select Properties.
When the Mailbox Store’s Properties sheet appears, select the Security tab, then assign full control to the Exchange 2010 mailbox server’s computer account. Make sure to then either reboot the server or restart the Information Store Service on the Exchange 2003 server.
Use ADSI Edit to fix Exchange 2010 administrative permission problems. You can also fix insufficient-permission problems in Exchange 2010 using Microsoft’s Active Directory tool -- ADSI Edit. If you do use ADSI Edit, be sure to back up your Active Directory. ADSI Edit makes direct modifications to the Active Directory database, bypassing the usual safeguards in the process. Making a mistake here can have catastrophic effects.
Open ADSI Edit and right-click on Default Naming Context, then select Settings. When the Connection Settings dialog box appears, choose the Configuration option from the Select a Well Known Naming Context drop-down list (Figure 1).
Figure 1. Select the Configuration context in ADSI Edit.
Click OK and navigate through the console tree to Services -> Microsoft Exchange -> <your Exchange organization> -> Administrative Groups -> First Administrative Group. Remember that “First Administrative Group” is the default administrative group name and that you may need to use a different administrative group depending on how your Exchange organization is configured.
Next, check your public folder store and mailbox database permissions. To check the mailbox databases, navigate to CN=Databases | CN=<your mailbox database> (Figure 2).
Figure 2. Check mailbox databases’ permissions using ADSI Edit.
Right-click on the object that represents your mailbox database, then select the Properties command. When the properties sheet appears, go to the Security tab and click the Advanced button. Tick the Include Inheritable Permissions From This Object’s Parent check box (Figure 3), then click OK to complete the process.
Figure 3. You must enable inheritable permissions in ADSI Edit.
You must now enable inheritable permissions in your public folder hierarchy. To do so, select CN=Folder Hierarchies, then set the permissions for the CN=Public Folders object (Figure 4).
Figure 4. You must also enable inheritable permissions on the Public Folders object in ADSI Edit.
Either of these methods should correct the administrative permissions problem. Manually granting permissions to the Exchange 2003 server is safer, but the ADSI Edit tool is Microsoft’s preferred method to resolve the issue
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO at a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
Dig deeper on Microsoft Exchange Server Permissions
Related Q&A from Brien Posey
Expert Brien Posey explains how using a Bunch of Redundant Independent Clouds architecture can protect data, but not without three common hurdles.continue reading
Brien Posey dives into the complications users might run into with thinly provisioned VMware data stores and how to address them.continue reading
VSphere APIs for I/O Filters, available with the next release of the hypervisor, lets third-party products access a VM's I/O stream to provide ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.