Problem solve Get help with specific problems with your technologies, process and projects.

Permissions and 'mixed mode' don't mix, part 2

If you run a mixed-mode environment, you have challenges when it comes to permissions. Part two of this two-part tip explains the workarounds to handle them.

Yesterday, I talked about some of the problems you may face if you are administering an environment with different versions of Exchange. As I mentioned, Exchange 2000 and Exchange 2003 both use AD. Although Exchange 5.5 is not AD aware, Exchange 2000 and 2003 are backward compatible to it through something called mixed mode.

One problem you may run into relates to public folder permissions. One possible solution, in addition to careful planning, is to run a DS/IS Consistency Adjustment.

Before I explain how to run a DS/IS Consistency Adjustment, I want to pass along some words of caution. First, you need to verify that all sites within your Exchange organization are accessible before running the check. If a site is not accessible at the time that the check is run, you could end up disconnecting the site or causing other major problems.

Second, don't try to run a DS/IS consistency check without manually confirming the existence of corresponding AD accounts first. The DS/IS consistency check will delete references to users who do not have AD accounts.

How to run a DS/IS consistency check
First open the Exchange Administrator program and select the server containing the public folders that you intend to replicate. Next, select the Properties command from the File menu to reveal the server's Properties sheet. Now, select the Properties sheet's Advanced tab and click the Consistency Adjuster dialog box.

When the DS/IS Consistency Adjuster opens, select the Remove Unknown User Accounts from the Public Folder Permissions checkbox and select the All Inconsistencies radio button. It is very important that all other checkboxes are deselected before running the consistency adjustment.

Once the consistency adjustment is complete, it is safe to start migrating public folders to the new server. Even so, there are some other issues that you must watch out for.

Remember that the original cause of the problem that I just described was a mismatch between the public folder's permissions and the AD membership. The DS/IS consistency check will guarantee that the Exchange 5.5 organization and the AD match by deleting anything in Exchange 5.5 that doesn't have a corresponding AD entry. Just because everything matches at the time of migration, though, doesn't mean that things will always match.

For example, suppose that you had a user with a mailbox residing on an Exchange 5.5 server, and access to a public folder that is also on that same server. Even if you deleted the user's mailbox, the user's ACL entries for the public folder remain. All of a sudden there are public folder permissions for which no account exists!

In an Exchange 2000 mixed-mode environment, all users would lose access to the public folder in question (except for the folder's owner). However, this issue was addressed in Exchange 2000 Service Pack 1 and in Exchange Server 2003. Service Pack 1 for Exchange 2000 allowed Exchange to tell the difference between an initial public folder migration and a subsequent permission update. If a mismatch occurs and is related to an update rather than to an initial deployment, the mismatch is simply ignored.

As you can see, some of the permission problems associated with mixed-mode environments can be solved by simply applying service packs or by upgrading to Exchange Server 2003.

However, there is one other issue that you need to be aware of. Exchange Server 2000 and 2003 provide a mechanism that allows you to view and /or alter public folder permissions through the Exchange System Manager (at the ptagNTSD level). If you alter the permissions at this level in a mixed-mode environment, then MAPI-based tools such as Outlook can no longer be used to control the folder's permissions. If you try, you will receive an error stating that there is an invalid Windows Handle.

Again, the solution is to avoid the problem in the first place. As long as you use only MAPI-based tools to modify folder permissions, you should never encounter this issue.

To read part one, click here,.

Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at

Do you have a useful Exchange tip to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.