none
Move preexisting AD object then move back after deployment RRS feed

  • Question

  • Hi all - my current TS has a modified page for entering your computer name that states "If the AD object for this name already exists, make sure to move it to COMPUTERS OU now and move it back after you finish".

    It would be nice to automate this process to avoid people forgetting - if they forget then GPOs in the OU the AD object is in will break the deployment eg changing admin password.

    I've seen suggestions to forcefully move objects to a deployment OU but this is no use for me if we don't know what OU they need to move back to afterwards.  But I can't think of a way to store the original OU info during the process and make the moves.  Any one already do this?

    Wednesday, August 7, 2019 9:28 AM

All replies

  • Hello,

    Maybe you could use a script to do that?

    Please show script here : https://blog.ctglobalservices.com/scripting-development/jgs/vbscript-move-computer-object-to-another-ou-via-command-line-parameter/


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    Blog : http://sylvaincoudeville.fr

    Wednesday, August 7, 2019 9:30 AM
  • Hi Sylvain

    Moving the computer to a particular fixed OU seems to be possible - but what I would need to do is :

    • Is there an AD object already?
    • If there is - what OU is it in?
    • Store the current OU somewhere somehow
    • Move the AD object to default 'computers' OU
    • --- Deploy machine ---
    • Lookup the original OU we stored somewhere somehow
    • Move the AD object back to original OU

    As you can see my problem is how I can store the original OU I guess for moving it back afterwards - assuming moving the AD object is hopefully simple enough at the start & end of the TS

    Thursday, August 8, 2019 8:05 AM
  • Hi,

    OK, so you need to store the OU to bring backup computer object into the original OU after deployment.

    THE answer is : using your own MDT Variable !

    Take a look at https://scriptimus.wordpress.com/2011/07/19/mdt-scripting-managing-environment-variablespar/ : you'll learn how to store your own MDT variables in your scripts


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    Blog : http://sylvaincoudeville.fr

    Thursday, August 8, 2019 8:34 AM
  • This may sound silly but where is the variable stored?  Does it save it to a file on the machine being deployed?  I'm wondering since more than 1 may be deployed at once so presuming it's not stored at the deployment point somewhere?

    Also occasionally a deployment will fail or mess up halfway and need to be started over - at this point if it's stored on the machine then it would be lost and therefore never get moved back to the original OU?

    • Edited by Leozack Monday, August 12, 2019 7:51 AM
    Monday, August 12, 2019 7:51 AM
  • This may sound silly but where is the variable stored?  Does it save it to a file on the machine being deployed?  I'm wondering since more than 1 may be deployed at once so presuming it's not stored at the deployment point somewhere?

    Also occasionally a deployment will fail or mess up halfway and need to be started over - at this point if it's stored on the machine then it would be lost and therefore never get moved back to the original OU?

    As indicated in the article, the variable is stored in VARIABLES.DAT (the place where MDT stores all of its variables)

    So, the variable is stored until the end of the LTI process : in case of failure and start over, the variable is always available.


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    Blog : http://sylvaincoudeville.fr

    Monday, August 12, 2019 8:16 AM
  • I'm just testing with PXEboot and running your hello world scripts etc currently - so far so good.  Isn't the x:\minint held on the device?  When they fail (eg someone pulls the cable and then it carries on but misses stuff out) I have to restart them from scratch, so surely the process would now store the variable from scratch and the OU would be the deployment OU not the original it was moved from?  Or maybe I'm just not following it right
    Monday, August 12, 2019 8:26 AM
  • I'm just testing with PXEboot and running your hello world scripts etc currently - so far so good.  Isn't the x:\minint held on the device?  When they fail (eg someone pulls the cable and then it carries on but misses stuff out) I have to restart them from scratch, so surely the process would now store the variable from scratch and the OU would be the deployment OU not the original it was moved from?  Or maybe I'm just not following it right

    As already answered, the variables.dat is kept all over the LTI process, even after a failure.

    You can Google for more information


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    Blog : http://sylvaincoudeville.fr

    Monday, August 12, 2019 8:36 AM
  • As already answered, the variables.dat is kept all over the LTI process, even after a failure.

    Ok I presume you mean on the server then since the machines get wiped every time I have to redo a deployment.  I shall now try and get the OU read into a variable and read back after, and try to get the OU moves made.
    Monday, August 12, 2019 11:17 AM
  • As already answered, the variables.dat is kept all over the LTI process, even after a failure.

    Ok I presume you mean on the server then since the machines get wiped every time I have to redo a deployment.  I shall now try and get the OU read into a variable and read back after, and try to get the OU moves made.

    After PXE boot, you answer to LTI questions : answers are stored in VARIABLES.DAT that is store on the wiped machine (on local hard disk), not on the server.

    https://docs.microsoft.com/en-us/sccm/osd/understand/using-task-sequence-variables


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    Blog : http://sylvaincoudeville.fr

    Monday, August 12, 2019 11:49 AM
  • That's what I thought - meaning if it stores the original OU, then deployment moves it to the deployment OU, then it breaks - then when I run the TS from scratch it will wipe the partitions as usual and that info will be lost, so it will never be returned to the original OU?  I was trying to think of ways round this - like getting ZTI to store the original OU in an AD object attribute so it's always available to move back there at the end of a working deployment - but maybe I'm just not understanding where it is stored etc?

    I'll be honest, I've got about 20 tabs open yesterday/today and I can't find what I need to so those simple steps I listed above of checking/moving/moving back in a TS.  Some use a web service but I won't be able to use one.

    Tuesday, August 13, 2019 8:30 AM
  • Another was to reach your goal : store into customattribute1 (for example) of the computer object in AD the previous OU

    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    Blog : http://sylvaincoudeville.fr

    Tuesday, August 13, 2019 8:36 AM
  • Another was to reach your goal : store into customattribute1 (for example) of the computer object in AD the previous OU


    Yes I could use the comment field or something for this, but I'm drowning in tabs and articles and scripts looking for what feels like it should be a couple of lines of code to 1 find current OU, 2 save it to AD attribute, 3 move AD object, 4 read it back from AD after deployment, 5 move AD Object back.  So far all I've managed to get from all the info is how to test a ZTI script in saving something to the variables.dat which I can do ok.
    Tuesday, August 13, 2019 11:17 AM
  • So I'm trying to use vbscript in the ZTIscript but any CreateObject() calls are causing an error. I also seem unable to run any powershell commands in there either.

    So currently I have tens of tabs open about how to do all sorts of things but all I really want to do lookup the current OU & save it then move OUs, then later lookup the saved OU and move back.  I don't mind if I do it with ZTI or with separate powershell scripts in the TS.

    Could you help me find just the info I need for this purpose?  I don't like people who don't give it a try themself, but I've tried a bunch and not managed to get what I need going yet unfortunately as most of the help seems aimed at bigger processes - or uses the webservices that I won't have access to.

    Wednesday, August 14, 2019 9:53 AM
  • So I'm trying to use vbscript in the ZTIscript but any CreateObject() calls are causing an error. I also seem unable to run any powershell commands in there either.

    So currently I have tens of tabs open about how to do all sorts of things but all I really want to do lookup the current OU & save it then move OUs, then later lookup the saved OU and move back.  I don't mind if I do it with ZTI or with separate powershell scripts in the TS.

    Could you help me find just the info I need for this purpose?  I don't like people who don't give it a try themself, but I've tried a bunch and not managed to get what I need going yet unfortunately as most of the help seems aimed at bigger processes - or uses the webservices that I won't have access to.

    This piece of VBS code will give you the DN of the Computer :

    	On Error Resume Next
    	Const ADS_SCOPE_SUBTREE = 2
    	Dim strComputerName = "MYCOMPUTER"
    	Dim strDN
    
    	Set objConnection = CreateObject("ADODB.Connection")
    	Set objCommand =   CreateObject("ADODB.Command")
    	objConnection.Provider = "ADsDSOObject"
    
    
    	objConnection.Properties("User ID") = "readonlyaccount@domain.local"
    	objConnection.Properties("Password") = "password"
    	objConnection.Properties("Encrypt Password") = TRUE
    	objConnection.Properties("ADSI Flag") = 1
    
    	objConnection.Open "Active Directory Provider"
    
    	If Err.Number <> 0 Then
    		  MsgBox "Error number " & Err.Number & ", " & _
              Err.Description & ", has occurred"
    	End If
    	
    	
    	Set objCommand.ActiveConnection = objConnection
    
    	objCommand.Properties("Page Size") = 1000
    	objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
    
    
    	' Search for COMPUTERS LIKE 'prefix%' and gather name
    	objCommand.CommandText = "<LDAP://domain.local/DC=domain,DC=local>;(&(objectClass=computer)(name=" & strComputerName & "*));distinguishedName;Subtree"
    	
    	Set objRecordSet = objCommand.Execute
    
    	If Err.Number <> 0 Then
    		  MsgBox "getNextComputerName: Error number " & Err.Number & ", " & _
              Err.Description & ", has occurred"
    	End If
    
    	objRecordSet.MoveFirst
    	Do Until objRecordSet.EOF
    		strDN = objRecordSet.Fields("distinguishedName").Value
    		
    		objRecordSet.MoveNext
    	Loop
    


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    Blog : http://sylvaincoudeville.fr

    Wednesday, August 14, 2019 10:23 AM
  • This one, to move an object from one OU to another : https://ss64.com/vb/syntax-movead.html

    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    Blog : http://sylvaincoudeville.fr

    Wednesday, August 14, 2019 10:26 AM
  • And this one, to change an attribute on an object : https://ss64.com/vb/syntax-updateusers.html (you just need to adapt the script)

    All done!


    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    Blog : http://sylvaincoudeville.fr

    Wednesday, August 14, 2019 10:29 AM
  • Thanks for this but am I missing something - do I need to save these as separate scripts and call them from the ZTIscript?  If I try to include anything like this it doesn't work - eg the above code only gets to the 3rd line

    Dim strComputerName = "MYCOMPUTER"

    before it errors

    z:\scripts\Test.wsf(87,22) Microsoft VBScript compilation error: Expected end of statement

    Also it appears to have the PC name hardcoded rather than to lookup the DN for the current PC it's running on

    Wednesday, August 14, 2019 2:31 PM
  • I’m sorry but the forum isn’t a developer self service! :) This script is static, but with just 3 minutes of google search, i’m sure you can find a vbs script to gather the current computer name! I think this thread can be closed :)

    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    Wednesday, August 14, 2019 2:52 PM
  • Yeah ignore the static thing I was just mentioning it - I don't mind scripting when the script environment works - my problem is it only gets a couple lines into any code before it fails so far.

    So am I supposed to be calling these scripts from ZTI rather than including the code in the ZTI script itself? Because I've not read anywhere that says to do that but so far any time I put more than a few things into the ZTI script it will fail.

    Wednesday, August 14, 2019 3:24 PM
  • eg this script is all you need to get the current PC DM - but as soon as I put it into the ZTI script and run it from F8 in PXE it fails

    ' Constants required for name translate
    CONST ADS_NAME_INITTYPE_GC = 3
    CONST ADS_NAME_TYPE_NT4 = 3
    CONST ADS_NAME_TYPE_1779 = 1
    
    'Get the NETBIOS name of the domain
    SET objSystemInfo = CREATEOBJECT("ADSystemInfo") 
    strDomain = objSystemInfo.DomainShortName
    
    ' Get the name of the computer
    SET objNetwork = CREATEOBJECT("Wscript.Network")
    strComputer = objNetwork.ComputerName
    
    SET objTrans = CREATEOBJECT("NameTranslate")
    objTrans.Init ADS_NAME_INITTYPE_GC, ""
    objTrans.SET ADS_NAME_TYPE_NT4, strDomain & "\" & strComputer & "$"
    strComputerDN = objTrans.GET(ADS_NAME_TYPE_1779)
    
    wscript.echo strComputerDN
    

    "ZTI ERRIR - Unhandled error returned by Test: ActiveX component can't create object (429)"

    so either none of this stuff works in the ZTI script (my experience so far) or it WILL work when it's in an actual running TS but just not when run manually using "cscript z:\scripts\Test.wsf" etc

    Thursday, August 15, 2019 8:33 AM
  • eg this script is all you need to get the current PC DM - but as soon as I put it into the ZTI script and run it from F8 in PXE it fails

    ' Constants required for name translate
    CONST ADS_NAME_INITTYPE_GC = 3
    CONST ADS_NAME_TYPE_NT4 = 3
    CONST ADS_NAME_TYPE_1779 = 1
    
    'Get the NETBIOS name of the domain
    SET objSystemInfo = CREATEOBJECT("ADSystemInfo") 
    strDomain = objSystemInfo.DomainShortName
    
    ' Get the name of the computer
    SET objNetwork = CREATEOBJECT("Wscript.Network")
    strComputer = objNetwork.ComputerName
    
    SET objTrans = CREATEOBJECT("NameTranslate")
    objTrans.Init ADS_NAME_INITTYPE_GC, ""
    objTrans.SET ADS_NAME_TYPE_NT4, strDomain & "\" & strComputer & "$"
    strComputerDN = objTrans.GET(ADS_NAME_TYPE_1779)
    
    wscript.echo strComputerDN

    "ZTI ERRIR - Unhandled error returned by Test: ActiveX component can't create object (429)"

    so either none of this stuff works in the ZTI script (my experience so far) or it WILL work when it's in an actual running TS but just not when run manually using "cscript z:\scripts\Test.wsf" etc


    Sorry to say that, but if you are out of your current Windows installation, you can’t gather the computer name! I’ve just seen you are in a WinPE : in this environment, the current Windows installation isn’t loaded. So, you cannot get the computer name. To do that, you’ve only 2 ways: - launch LTI from the current windows installation (not via WinPE) - find a way to read Windows registry to get back computer name So, I have a big question for you: why don’t you use a « client refresh » scenario as TS? This one is launched from Windows, gather all network settings (including computer name and domain), and put them back after .

    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    http://snsv.consulting

    Blog : http://sylvaincoudeville.fr

    Thursday, August 15, 2019 9:17 AM
  • Refreshing from within the current windows session instead of booting to PXE and starting from there isn't something we've ever considered.  It is entirely possible assuming the machine is currently working at the time we want to deploy it with the latest version, so I could try that - thanks for the idea.  Most people don't even know you can go into the scripts folder and run ZTI scripts.

    I had considered WinPE may be to blame for everything I tested not working when it was working anytime I tested it on the server, but I'm new to editing ZTI scripts and was pleased to see I could test it from WinPE but I guess that only works for some things.  I could try running this from a working machine and see how it goes, otherwise I could revert to trying to make powershell scripts to do the move/moveback at start/end of the TS.

    Just to confuse me further, if I put the snippet above to show the DN into a vbs file and cscript it on the sever it works.  But if I rename it wsf and cscript it I get an error about matching ';' not found - so it doesn't look like I can test that way (and I'm not actually running the ZTI process since this is just a test file not included in the process)
    • Edited by Leozack Thursday, August 15, 2019 11:40 AM
    Thursday, August 15, 2019 11:20 AM
  • Hi all - I've had a lot of problems to deal with on our builds (lately the alerts for new users that MS have caused since the summer somehow) but I am looking to get this "OU store/OU move/deploy/read OU store/move OU" process added to our TS.
    Re-reading the above replies, it sounds like I can run a PS script in the TS at start/end to do the move, but I need to edit the wsf wizard to do the storing of the OU in the variables?
    If so does anyone have an example of these 3 steps?  I figure it must already exist and don't want to reinvent the wheel when I'm being pressured for other tasks too
    Friday, October 25, 2019 3:43 PM