|
|
|||||||
Anyone know how to programmatically synchronise a domain? (Not ADs) |
||||||||
|
|
|||||||
Yep.. From the DC: NET ACCOUNTS /SYNC /DOMAIN That should work to sychronize the user accounts database. Brian |
||||||||
|
|
|||||||
But it's not COM... this is the COM forum... No fair... I could have come up with that one too. |
||||||||
|
|
|||||||
Actually it is just NET ACCOUNTS /SYNC. Besides, Les was right, I am looking for a COM solution - and I need to be able to run this from a Member Server. |
||||||||
|
|
|||||||
com but not ad? so no ldap objects present... Shawn???? |
||||||||
|
|
|||||||
I can do this with the Lanman module in Perl but have come up empty searching MSDN for an WMI or ADSI interfaces related to Netlogon Control or SAM replication for NT4 Lanman server. [ 14 June 2002, 13:48: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
I haven't seen a way to do it through ADSI as of yet, but I really haven't had time to look too much, lately, so I'll work on it. Brian |
||||||||
|
|
|||||||
I've gotten stuck on this. You said you did NOT want to use ADSI? You DO want to sync the user accounts database? I was trying to do it WITH ADSI (WINNT:) and keep getting problems with the error "IDispatch pointers not allowed in expressions" When trying to use OpenDSObject with KiXtart... so I'm pretty sure that's not going to work unless I'm missing something simple (where is Shawn??)... Back to the drawing board.. Brian |
||||||||
|
|
|||||||
If I may speak for comjf, I believe he just said he's not running AD and not that he was excluding ADSI. |
||||||||
|
|
|||||||
I have not yet been able to get OpenDSObject to work either. |
||||||||
|
|
|||||||
I have ADSI installed, but no Active Directory so I am limited to the WinNT: provider. Go Brian Go Michael. |
||||||||
|
|
|||||||
Ahh, young apprentice, I sense that the force is strong with you. And that you have abided by the the Jedi motto: There is no "try" - there is only do, or not do. But, one must learn to pick their battles with much care - and to engage where one might win. I sense this is a hopeless battle - frought with much danger ... pain ... rofl ... Brian, have you checked the domain object in the ADSI SDK (no have) ... but me thinx WMI might be more evolved for this. Like Howard (and you) I searched the "Weeb" too and turned-up nothing (other than the usual lanman stuff) ... |
||||||||
|
|
|||||||
Yeah.. I've been looking at DSBIND and DSREPLICASYNC... But (maybe I'm wrong) I thought I had to use OpenDSObject to use those functions. So, if that is the case, this is a dead end unless I can get that to work. As for WMI... I didn't see anything related to sychronizing the SAM database... but I'll look again. Brian |
||||||||
|
|
|||||||
Another thing.... does this have to be done "programmatically"? I mean.. it's possible to execute a remote command "NET ACCOUNTS /SYNC".... without all that much work involved. Brian |
||||||||
|
|
|||||||
Brian - yes I COULD use RCMD or similar and run NET ACCOUNTS /SYNC on a DC, but where is the fun in that, besides that answer shouldn't be allowed in a COM forum |
||||||||
|
|
|||||||
I sure am gettin razzed a lot today for trying to help out! Brian |
||||||||
|
|
|||||||
DSREPLICASYNC - good catch - now the trick is to find a SCRIPTABLE version of this, somewhere, and thats usually the mind killer. |
||||||||
|
|
|||||||
Sorry Brian. I assume you are doing something like: code:When I replace the password with something valid I get:$dso = GetObject("WinNT:") quote:hmm, really useful. (I get the same error when password is incorrect as well) |
||||||||
|
|
|||||||
Yeah.. that's something like I was doing, however mine was more like: $obj = GetObject("WinNT:") $dom = $obj.OpenDSObject("WinNT://@LDOMAIN","administrator","password",&1) I was getting type mismatches for awhile... when I didn't define username and password..then i was getting "IDispatch Pointers not allowed in expression" ... so not sure what I'm doing wrong. Brian |
||||||||
|
|
|||||||
There was something about AdsSecurity.dll to be installed in order to use OpenDSObject but even after registering that DLL both on the PDC and a local workstaion used to run the script I still couldn't get it to work. |
||||||||
|
|
|||||||
Reading up on DSREPLICASYNC (and DSREPLICASYNCALL) it seems to be very AD specific in that it is talking about replicating with all servers in the site. Will this call work for an NT Domain? Does anyone know how to call this from WSH or VBScript? Recent posts on WSHPipe might enable me to achieve this in a roundabout fashion |
||||||||
|
|
|||||||
I know you don't want non-COM stuff but at least you can do this remotely via a local SHELL. nltest.exe /server:YourRemoteCompter /sync or nltest.exe /server:YourRemoteCompter /repl quote: [ 14 June 2002, 17:53: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
As a side to this issue, I have never been able to use OpenDSObject in my Perl OLE stuff because I could never satify the NULL require as the third parameter to OpenDSObject. I tried every thing imaginable. M$ engineer suggested I use3 VB (vbNullString) or C++ ((void*)0). Can you get any farther by just executing code under an account with Admin perms and using GetObject which uses the security context of the current user? |
||||||||
|
|
|||||||
About this OpenDSObject stuff, yeah, the WinNT provider does support that. In fact, I just ran this script (from a Domain User Account), that TOGGLES the disabled on/off for a given user: break on $dso = GetObject("WinNT:") $user = $dso.OpenDSObject("WinNT://@LDOMAIN/SHAWN.TEST,USER", "shawn.tassie", "password" , 0) ?"disabled=" $user.accountdisabled $user.accountdisabled = $user.accountdisabled = 0 $user.setinfo ?"disabled=" $user.accountdisabled exit 1 The output from that was: M:\>kix32 t disabled=0 disabled=-1 0 The operation completed successfully. M:\> Run a second time: M:\>kix32 t disabled=-1 disabled=0 0 The operation completed successfully. M:\> Now, the machine I ran this on was joined to the domain in question, could this be a diff ? Because if memory serves, there are issues when crossing domain boundaries - may this be the problem. I think Bryce has researched this issue throughly (ie, invested much time in getting it to work), would be nice to get some thoughts from da-man. [ 14 June 2002, 18:08: Message edited by: Shawn ] |
||||||||
|
|
|||||||
The more I look at this, the more I don't think there is a route from point A (getting the OpenDSObject method to work) to point B (doing something useful with the SAM database). However, this seems to be a good exercise, nevertheless. (DSBIND and others are FUNCTIONS, not methods, properties, or objects.) Brian |
||||||||
|
|
|||||||
The only real benefit to OpenDSObject is that you can bind with alternate credentials. This of course means a script with plain text userid and password (for an account that presumably has some kind of admin rights). I personally don't think that I would use it... Thanks to Howard (again) - NLTest is almost perfect. I just ran it with the /SYNC option and forced a BDC to transfer the entire SAM from the PDC (Ooops, better use /REPL next time ) I would have liked a COM solution, but NLTest is fine too. Michael. |
||||||||
|
|
|||||||
Hi Brian, You have probably seen this already: ADS Authentication Enum I was having trouble getting OpenDSObject working as well (different project) and then tried adding ADS_SERVER_BIND (512) as I had seen it in some example Microsoft code. It now works for me - might be worth trying... HTH, Michael. |