June 21, 2016 at 4:21 am #44094
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?
June 21, 2016 at 10:50 am #44109
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,
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...)
- This reply was modified 2 years ago by Mark Prior.
June 21, 2016 at 11:19 am #44112
Thanks – I thought that specifying the -domaincontroller parameter on Exchange cmdlets forced it to use that DC? Although it appears to ignore that!
June 21, 2016 at 12:03 pm #44116
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
June 21, 2016 at 10:04 pm #44245
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.
June 21, 2016 at 10:50 pm #44255
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.
- This reply was modified 2 years ago by David Zemdegs.
June 22, 2016 at 8:30 am #44292
glad you have it working, yes i have also hit problems with remote PS & using none FQDN format.
You must be logged in to reply to this topic.