Share via

But I swear I installed the DS/IS hotfix!?

  • Article

Before the E2k3 SP1 GUI lets you move mailboxes cross-site and the Object Rehome tool lets you move DLs and Custom Recipients cross-site, they both check to see if the “DS/IS Hotfix” is installed. This hotfix is the KB.836489 hotfix, and is also included in the (readily downloadable) KB.841765 5.5 Post-SP4 rollup hotfix.

I've blogged about this hotfix a bit before ( here ), but didn't really get into why we need the hotfix or how we check if it's installed. Let's cover that today...

Why we need the hotfix for mixed-mode cross-site moves:
In Exchange 5.5, public folders (and mailbox folders) are ACLd by placing the MAPI DN (ie - the Obj-dist-name or LegacyExchangeDN) of a mailbox or DL onto the folder, in combination with what permissions are being granted. So, if you add  “Joe” to a public folder “client permission” so that he can read or write to a specific public folder, what you're actually doing is storing his mailbox DN (something like /o=org/ou=site1/cn=recipients/cn=joe) on the public folder, along with the “read” or “write” permission info. This permission is not ever removed unless it's done explicitly, so if “Joe” leaves the company at some point and his mailbox is deleted, the permission remains -- now pointing to a non-existing directory object.

Enter DS/IS. There are two “remove unknown user account from ACLs” checkboxes in DS/IS: one for public folders, and one for private folders (mailboxes). These “ACL” checkboxes are to be distinguished from the other two checkboxes in DS/IS: one to create directory objects for mailboxes that don't have them, and the other to create directory objects for public folders that don't have them; the dreaded “public folder rehome“ checkbox. While you generally won't want to run the directory object checkboxes unless you need to (and you'll know when you do!), it's recommended to run the ACL checkboxes somewhat regularly if you've deleted mailboxes or DLs that have previously been used to ACL folders.

Therein lies the problem. When we move mailboxes or DLs cross site with the new mixed-mode cross-site move functionality of Exchange 2003 SP1, we're really going to end up removing the original site's mailbox and creating a new mailbox in the target site. Exchange 5.5 will not think it's the same mailbox (or DL), which is a big part of why cross-site moves can be so difficult in mixed-mode!

And what happens if you run DS/IS to remove “unknown user accounts” after the cross-site move function has removed the original mailbox or DL? Well, the traditional DS/IS code would think the mailbox had been deleted and would remove the permissions from the folder. Not good. The mailbox still exists, just in the new site, so that's not what we want to happen.

The DS/IS hotfix in KB.836489 was introduced (and is a prerequisite requirement) for cross-site moves, to make sure that these moved mailboxes aren't seen as deleted mailboxes. The new hotfix causes DS/IS to check not only for the actual DN of the mailbox or DL in the ACL (ala Obj-Dist-Name) but, if this DN can't be found, it will also look for an object that has an X500 proxy address of the moved mailbox DN. This X500 proxy address is added to the new, target-site object during the cross-site move, thus allowing the new object to be properly ACLd on the folder -- updating, rather than removing the ACL.

How we check for the DS/IS hotfix during cross-site moves:
When moving mailboxes or DLs cross site, the tools check to see if the hotfix has been applied to ALL 5.5 servers that have a public folder store. The move mailbox GUI is even nice enough to provide a list of servers where it doesn't believe the hotfix has been applied. So what do you do when you are POSITIVE that you've applied the hotfix to the “EXMAIL4” server, but the GUI says it's not? Why does this happen?

The process to check for the DS/IS hotfix is roughly as follows:

  1. Figure out what our target site is -- what site are we moving the mailbox (or DL) to? For the sake of example, let's say we're moving the mailbox from “Site1“ to “Site2“.
  2. Look through the list of Config_CAs to see which one “owns“ this naming context. One of the Config_CAs will have this site listed in msExchServer2ExportContainers, and this is the Config_CA (and therefore the SRS) that owns this 5.5 site.
  3. Open a connection to this SRS. If the SRS is offline or unavailable, we're done here and the prereq fails.
  4. Query the SRS for a list of all 5.5 servers that have a public folder store defined.
  5. Scan the list of 5.5 servers for the heuristics attribute on each server object. If the server object in this SRS directory doesn't have the proper heuristics attribute (to indicate that the hotfix has been applied), we fail the prereq.

And that's it; if we DO have the proper heuristics attribute stamped on all of the servers in our query, we pass the prereq test and move on.

Obviously, the two questions that come out of this are: 1) What is the specific heuristics value I'm looking for? and 2) Why might it think the hotfix is not applied?

1) What is the heuristics value: The value 0x80000 (or 524288 in decimal) is bitwise “or'd“ against the heuristics value. This is really easy to eyeball (in Exchange 5.5 Admin “raw mode“) and see if the hotfix is applied. If your heuristics value is, say, 300 or 500... the hotfix is not applied. If the heuristics value is 500,000+, chance are that it has been.

2) Why might it still not think the hotfix is applied: If you connect to the directory where the hotfix was applied and it shows the increased heuristics value, then you KNOW that the hotfix was actually applied successfully. But remember, it's actually on one, particular SRS that the heuristics value is checked... not on each hotfixed 5.5 server directly. The real question is “has the updated heuristics value replicated across 5.5 directory replication to the target-site's SRS?“ If you connect to the SRS from step 2 in the above sequence using the Exchange 5.5 Admin program, you can check if the heuristics value has replicated in. Chances are, if the prereq is failing it has not. Then the real problem is figuring out why 5.5 directory replication is broken.

5.5 directory replication is so very important to the success of cross-site moves in Exchange mixed-mode, that you'll be glad you fixed any directory replication problems BEFORE the moves rather than During and After. It'll save your helpdesk a lot of phone calls from unhappy end-users!