Saturday, February 18, 2012 4:18 PM
I am writing a VBScript subroutine which receives an ADSI (AD LDAP) object.
Is there a way to find the domain controller that object is associated with?
I can look at the ADSPath attribute, but this only has the domain controller if the calling routine specified it.
I need the DC because this is an account freshly created by our provisioning system (ASP -> soon to be replaced but necessary until that's done) and I am then turning around and using Sapien's ActiveXPosh to execute an enable-mailbox command on the Exchange 2010 server and want to use the -DomainController parameter point to the DC where the account was just created.
Thanks for this...
Monday, February 20, 2012 4:12 AM
If your doing a serverless bind using the RootDSE in the calling routine then you can just use the ServerName property of the RootDSE object eg
Set objRootDSE = GetObject("LDAP://RootDSE") Wscript.Echo objRootDSE.ServerNameCheers
Monday, February 20, 2012 11:57 AM
Thanks for this Glen.
In this case, my VBScript subroutine is receiving the ADSI object from the calling routine. So I don't know whether they used RootDSE to find a domain controller or not. So I can't be guaranteed that if I use a RootDSE call to get a DC, that it will be the same one the calling program used for its LDAP object.
So I need to explore the properties or other attributes of the LDAP ADSI object I receive from the calling routine to try to find out the domain controller it is associated with.
If you have any thoughts it would be bery much appreciated. Right now, I'm basically taking a chance.
Tuesday, February 21, 2012 5:24 AM
>In this case, my VBScript subroutine is receiving the ADSI object from the calling routine
So what does the calling routine look like ? It shouldn't be hard to work out
The RootDSE will be the eventual root of any Active Directory object so you should be able to back track via the parent property on the object itself. I Suggest reading Robbie Allens cookbook http://books.google.com.au/books?id=Ga1nLk_xqcUC&lpg=PA100&ots=MJ86zdxQPn&dq=Rootdse%20parent%20vbs%20active%20directory&pg=PA100#v=onepage&q=Rootdse%20parent%20vbs%20active%20directory&f=false
Tuesday, February 21, 2012 12:11 PM
Thanks again Glen.
I was hoping to avoid burrowing into the provisioning application and just rewrite the mailbox provisioning subroutine to add support for both Exchange 2010 and Exchange 2003 mailboxes (the transition to the new platform will take six months in our global environment)
We have multiple domains to add fun.
But it seems we can't get the DC from the ADSI object, so I will poke at the ASP application to make sure the ADSPath contains the DC.