Share via

More DS/IS prerequisite validation info for cross-site, Exchange mixed mode mailbox moves

  • Article

Back in July of last year, I posted about how the DS/IS hotfix prereq check works and why you need to apply it. Since that time, I’ve run into one other item I wanted to talk about in the process that I didn’t provide enough detail on in the original post.

Here’s a recap of the “check for the DS/IS hotfix” prereq steps from the earlier blog post:

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.

Notice in Step #3, “Open a connection to this SRS” is sort of undefined. After Step #2, we’ve determined which SRS owns the site which is the target of the move. But if we try to open a connection to this SRS and fail to connect it for some reason, what happens?

Well, a very common error code to see in this case is: “Unable to find a responsive Exchange 5.5 server in the specified site. ID NO c1034a34”. This error is somewhat misleading because we’re not REALLY trying to find a responsive Exchange 5.5 server, but rather, an SRS that acts just like an Exchange 5.5 directory.

If you run into this error, it means that the Exchange System Manager UI was unable to connect to the particular SRS that owns the naming context of the target site. You will probably need to confirm that this SRS is running, that there’s no firewalls blocking RPC communication between the ESM GUI and the SRS, etc. If you cannot connect to this SRS directory with 5.5 Admin from the machine running the ESM GUI, it is unlikely that the ESM GUI will be able to connect to do the prerequisite check!

But let’s go back even one step more. What if you are trying to run through the prereq check yourself, manually, and you can’t find the proper Config_CA listed in Step #2? If you’re using the ADC management UI to go through each listed Config_CA, it’s possible the Config_CA you’re looking for is not listed!

Each connection agreement is associated with one-and-only-one ADC server. There’s an attribute called msExchHomeSyncService stored on each connection agreement to link that connection agreement back to its owning ADC. It’s this association that causes each connection agreement to be listed subordinate to a particular ADC server in the ADC management GUI.

Here’s where it gets a little dicey. If you remove the ADC service from a server while it still has connection agreements associated with it, these connection agreements will become unassociated with *ANY* ADC server… they become “orphaned”, essentially. If you look at the msExchHomeSyncService attribute on such a CA, it will be blank. This means when you look through the list of all CAs in the ADC management GUI, you will not even see this CA listed. There’s a bit more info on this whole situation and how to recover from it in KB.319486.

Note that if you end up with the owning SRS for the target site as an orphaned SRS, you have bigger problems than the failure of the DS/IS prereq check! You will definitely want to clean up the ADC to make sure all connection agreements are properly in place, and that all SRS replication functionality is restored before attempting to move mailboxes cross site! Be sure to carefully follow the steps in KB.319486 and maybe rerun the ADC Tools (in the ADC management GUI) for good measure before attempting such moves.

Comments