AD object creation immediate recognition in subsequent exchange cmdlets

PowerShell Help
1

I have some utilities that create AD objects and then use Exchange cmdlets to reference those objects.
Initially, the exchange cmdlets could not find the new AD objects until I found that one could point to a DC in a cmdlet.
So I’ve used $psdefaultparametervalues to set the server parameter for all AD cmdlets and the Domaincontroller parameter for all EX cmdlets to the same DC.
Problem is that even with that, the EX cmdlets sometimes complain that the newly created AD object doesn’t exist.
I don’t want to have long ‘sleep’ commands between my AD object creation and subsequent use.
Anyone else dealt with this issue please?
Thanks
David Z

2

i got this in MS orchestrator, problem is your exchange will pick its closest / fastest DC which is not always the same one each time. If you have your exchange hosted in the same location as a DC or multiple DC’s, replication can still be upto 60 seconds.

you could look at RepAdmin to force replication of objects to a specific DC, but again this is not instant and still requires some time,

https://technet.microsoft.com/en-us/library/cc770963(v=ws.11).aspx

i had an issue where i have multiple exchange controllers and multiple DC’s dotted around the globe, however orchestrator is very flexible and allows you to specify domain controller and create different profiles for each exchange location (EMEA, AUS, EA & AMR etc…)

3

Thanks - I thought that specifying the -domaincontroller parameter on Exchange cmdlets forced it to use that DC? Although it appears to ignore that!

4

just a thought if for example its a user object your creating, could you not start from exchange?

i.e creating a user mailbox will also create the AD object

5

Problem is that my script does many more things. Like create an AD group then use that group in add-mailboxpermission, where the latter cmdlet fails to see the group.

6

I was sure the -domaincontroller setting should work as advertised so I went back and read the fine print. What I noticed is that this setting specified an FQDN whereas I was using the NetBIOS name of the DC. This seemed to fix it. And I found set-adserversettings so I threw that command in as well with the -preferredserver option.

7

glad you have it working, yes i have also hit problems with remote PS & using none FQDN format.