Move Computer to new AD Container using dsMoveObj

Started by limnos, November 25, 2014, 09:09:07 AM

Previous topic - Next topic

limnos

Trying to move a device from one container to another in the same domain.  I must be missing something simple, but have tried every incantation possible of LDAP name, etc.  The LDAP for the target device is:

deviceid=Environment("COMPUTERNAME")
;verified this is definitely the correct LDAP
sourceADSIpath = "LDAP://testbits.xxx.state.xx.us/CN=%deviceid%,OU=XXXComputers,DC=TESTBITS,DC=XXX,DC=STATE,DC=XX,DC=US"

targetADSIpath = "LDAP://testbits.xx.state.xx.us/OU=XXXComputers,OU=DBM,OU=BITS,DC=TESTBITS,DC=XXX,DC=STATE,DC=XX,DC=US"

I have tried it this way:
newadsipath=dsMoveObj("%sourceADSIpath%", "%targetADSIpath%" , "CN=%deviceid%")
pause("Object Moved to", newadsipath)

And this way:
newadsipath=dsMoveObj("%sourceADSIpath%", "%targetADSIpath%" , "")
pause("Object Moved to", newadsipath)

Also tried elimination the CN from the sourceADSIpath, etc.  No matter how I do it, it returns an "object does not exist" error on the dsMoveObj line.  What am I missing here?

td

Generally, using the correct credentials will fix a lot of DS errors.  And even though you assert that the paths are valid, you might want to consider checking for the existence of the object and the container using the dsIsObject function
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

limnos

I have full rights in the domain and using AD Users and Computers am looking right at the containers and objects, they are definitely there and in those locations.  It's a test domain.  I even moved the object manually to the target container to verify I had the rights to make the move.  That's why I don't understand why it keeps returning the "object doesn't exist" error when it clearly does exist.

td

You may have 'full rights in the domain' but that doesn't necessarily indicate the credentials the script is using when it is running and looking at AD using 'AD Users and Computers' does not necessarily give you a clear definition of the full LDAP path needed to perform the task using a script. 

Try the previously mentioned dsIsObject and dsIsContainer functions in an attempt to narrow down the problem. You could also use the dsSetCredentx function to use specific credentials to ensure that the script has the correct security context. 
 
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

limnos

When I run this:

OuPaths=dsGetChldPath("LDAP://testbits.xxx.state.xx.us/OU=XXXComputers,DC=TESTBITS,DC=XXX,DC=STATE,DC=XX,DC=US", "computer")

I get the full list of the handful of devices in the root container, including the target device.  It shows this for the target device:

LDAP://testbits.xxx.state.xx.us/CN=devicename,OU=XXXComputers,DC=TESTBITS,DC=XXX,DC=STATE,DC=XX,DC=US

Also, I ran as you requested, the following, and it responded "Yes" to both using my credentials in the test domain for dsSetCredent command.

sADSIPath = "LDAP://testbits.xxx.state.xx.us/OU=XXXComputers,DC=TESTBITS,DC=XXX,DC=STATE,DC=XX,DC=US"
; Does this object exist?
If dsIsObject(sADSIPath)
   Message("Is LDAP an object?", "Yes")
Else
   Message("Is LDAP an object?", "No")
EndIf

If dsIsContainer(sADSIPath)
   Message("Is LDAP a container?", "Yes")
Else
   Message("Is LDAP a container?", "No")
EndIf

td

There are still a few more possible problems that you have not indicated that you have checked.

Did you use dsMoveObj with credentials set using dsSetCredentx?  You might also run a test using dsSetCredentx with credentials and the authentication-method parameter set to 1|256 (257).  Moving an object generally requires higher privileged credentials and more secure authentication than simply getting an object's property values.  If this was not the case, directory services would be either very insecure or mostly unusable. 
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

I forgot to mention that you can also check the wwwbatch.ini file for the last ADSI error under the ADSI Extender section of the file. The file can be found in the C:\Users\{username}\AppData\Roaming\WinBatch\Settings folder.

Sometimes the contents are a bust but sometimes the error information can be very useful.  If nothing else, a web search on the key elements of the error information has been known to prove fruitful.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

limnos

Revisiting this again.  I keep getting a "1063:Object does not exist".  It's like it doesn't see this CN= as an object.  I'm using dsSetCredent and that seems to be working OK.  The CN in question definitely exists.  I can do the move manually, so the credentials, which are mine, definitely are sufficient.  Just trying to move the CN from one container to another.  It shouldn't be this hard...

deviceid=Environment("COMPUTERNAME")

newadsipath=dsMoveObj("%sourceADSIpath%", "%targetADSIpath%" , "")

where


sourceADSIpath = LDAP://testbits.xxx.state.xx.us/CN=%deviceid%,OU=DOTComputers,DC=TESTBITS,DC=XXX,DC=STATE,DC=XX,DC=US

targetADSIpath = LDAP://testbits.xxx.state.xx.us/CN=%deviceid%,OU=DBM,OU=DOTComputers,DC=TESTBITS,DC=XXX,DC=STATE,DC=XX,DC=US

td

The second parameter, targetADSIpath, to dsMoveObj is not correct.  It should be the container path and not the new path of the object to be moved.  In other words, get rid of the "CN=%deviceid%," part of the second parameter.  You might want to review the function's documentation in the help file. 

On the subject of keeping things simple, you don't need to use substitution went passing string parameters to a function.   Use

newadsipath=dsMoveObj(sourceADSIpath, targetADSIpath , "")

instead of

newadsipath=dsMoveObj("%sourceADSIpath%", "%targetADSIpath%" , "")

substitution in this case just wastes a few CPU cycles.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade