I wanted to share some lessons learned recently as a result of working a case where the goal was to create a new mail contact in a remote forest. Existing contacts were able to be edited, so permissions didn’t appear to be the issue. I was able to set up a cross-forest trust in my lab, and reproduced the problem. This problem really only exists in Exchange 2007, as Exchange 2010 supports opening a Remote Powershell instance where you could connect directly to the remote forest from a server in the source forest.

Here I am trying to create a new mail contact. I tried to keep the parameters I used pretty simple. By specifying the domain controller as a DC in the remote forest, I ensure that I am talking to that forest when I attempt to create the contact. I’ve highlighted a few things that stood out to me.

If you see the same thing I did (well, since I’ve been nice and highlighted it), you probably know why the operation failed. Yes indeed, the LDAP Add request is passing an attribute value that contains the source forest. No wonder why the remote domain controller was responding with an error!

Luckily, Powershell allows you to control some additional settings via $AdminSessionADSettings. Checking the current settings, I found the following listed

This time, both Netmon and the verbose output from the cmdlet show that the Configuration partition being referenced to set the objectcategory is for the correct domain/forest, and the add request succeeds.

Did you reboot the server after following the steps? I think I mentioned that in my post, but I have seen where it takes a reboot for all the settings to be effective (especially the registry change for AdminDebug).