locked
Using MDT to re-join computers to a domain after a re-image RRS feed

  • Question

  • Since 2010 we have been using WDS to build, capture and deploy our image across our organisation (A High School) which has worked well enough. While WDS can do all this the build and capture is a little clunky and relies on you to manually installing all programmes and then mounting the WIM file and inject the drivers so I have moved us onto MDT for the build and capture before importing the finished WIM file into WDS for deployment.

    This has worked much better as MDT makes it much quicker to get an image up and going (programme silent installs, testing is much quicker etc) and drive management is as simple as telling MDT to put ALL the drivers you want into the image but I have been reading that you should link MDT and WDS together.

    I followed the instruction and imported the LiteTouchPE wim file into WDS and we are able to PXE boot right into MDT and either make a new image or capture the one we are working on but I am trying to automate the deployment so it is more like what we have when just using WDS for deployment. Because I want to retain the ability to use MDT to make a new image I cannot customise the customesettings.ini file too much and instead I am relying on MDT task sequences for must of the customisations.

    Currently all our systems are pre-staged into WDS (I think it is actually Active Directory at the end of the day but you use wdsutil to pre-stage them) so when we boot into PXE WDS deploys and configures the machines using WDSClientUnattend and ImageUnattend XML file so that once the deployment is finished it is sitting at the logon screen waiting for the user to login already joined to the domain and our wireless network.

    I am having trouble trying to achieve this same result using our WDS + MDT combo with the main sticking point being trying to re-join the computer back to the domain (we re-image machines constantly so re-join back to the domain is a must). I wrote/found a PowerShell script that does the domain join but because an account already exists (all our machines are pre-staged under their service tag and GUID) it throws an error about their already being an account with that name (the computer still appear to join the domain and I can logon using my domain account). Because of this error MDT borks the deployment and doesn't finish up and complains about deployment being in progress etc.

    Is using WDS to boot the LiteTouchPE and then deploying through MDT the best way or are we better off going back to using MDT to do the build and capture and then using WDS and it's pre-staging to do the deploy? I really like that with MDT I can have a little more control over driver deployment (recently had a problem where we got a new laptop and injecting the new drivers into the WIM broke the entire image for all our machines except the new one) and software at the time of the re-image (I cannot install the Lenovo hotkey software in a virtual machine because it does a hardware check and fails to install so either the entire image needs to be made on a Lenovo or the software doesn't get installed).

    I am currently making a Windows 8.1.1 x64 Enterprise SOE/MOE/whatever you would like to call it using MDT 2013 with WDS running on Windows Server 2012 R2 x64.


    Monday, September 8, 2014 12:45 AM

All replies

  • Hello,

    It is better to use so-called "thin" images. These contain only the operating system (in a facility and captures vm). Subsequently pilots and soft will be deployed by the bais of MTD. 

    For drivers I recommend you to use selection profiles. Moreover it is necessary to put a condition in step "Inject Drivers". Condition Type: Variable called MODEL, variable value Latitude E6430 (change the value to the desired model). It is necessary to add more step Inject Drivers that type of position. 

    Application level, you import the different applications in MDT allowing you to select only the desired wizard when applications. If you want to automate this step you will need to indicate statically in the task sequence to install applications, this will require the creation of several task sequence.

    Best Regards

    Monday, September 8, 2014 9:32 AM
  • Hello,

    It is better to use so-called "thin" images. These contain only the operating system (in a facility and captures vm). Subsequently pilots and soft will be deployed by the bais of MTD. 

    For drivers I recommend you to use selection profiles. Moreover it is necessary to put a condition in step "Inject Drivers". Condition Type: Variable called MODEL, variable value Latitude E6430 (change the value to the desired model). It is necessary to add more step Inject Drivers that type of position. 

    Application level, you import the different applications in MDT allowing you to select only the desired wizard when applications. If you want to automate this step you will need to indicate statically in the task sequence to install applications, this will require the creation of several task sequence.

    Best Regards

    Well I am well aware the Microsoft recommends a thin image it is simply not practical in a School environment where Students change in and our of subjects and where the combination of subject specific software is nearly infinite the overhead is too great (maybe if we used something like SCCM where we could deploy applications based on OU or group membership).

    All your other points aside my problem/issue/question which appears to have been lost is, how do I rejoin a computer to the domain using MDT?  We re-image laptops constantly and using WDS they rejoin with no problems but using MDT an error is thrown because the account already exists.  In WDS we have all our machines pre-staged so is there an MDT equivalent that will let me re-image a laptop and have it re-join the domain under the same account without throwing and error.
    Monday, September 8, 2014 10:09 AM
  • your problem is configured in cs.ini user account. In order to reset the accounts it is necessary to use a domain admin account ad or implement the necessary delegation on or containing computer accounts
    Monday, September 8, 2014 11:37 AM
  • your problem is configured in cs.ini user account. In order to reset the accounts it is necessary to use a domain admin account ad or implement the necessary delegation on or containing computer accounts

    Thanks I will take a look again but I am pretty sure it is the same account with the same permissions (after all it does join the domain it just complains about the account already existing).
    Monday, September 8, 2014 11:52 AM
  • A user has the right to join up to 10 machines that has never been reached by cons it is not right if the account exists. I do frequently junctions to the domain with mdt and I never have any problems when I appropriate rights ad
    Monday, September 8, 2014 12:47 PM
  • A user has the right to join up to 10 machines that has never been reached by cons it is not right if the account exists. I do frequently junctions to the domain with mdt and I never have any problems when I appropriate rights ad

    It maybe because I am trying to domain join them using powershell in a tasksequence rather than using the wizard or customsettings.ini.  I could not find a way other than using powershell to do a domain join as a task sequence.
    Tuesday, September 9, 2014 10:33 AM
  • Tries to use the cs.ini why you gotta put variables to indicate the area to join as well as the user name and password
    Wednesday, September 10, 2014 7:14 AM
  • A user has the right to join up to 10 machines that has never been reached by cons it is not right if the account exists. I do frequently junctions to the domain with mdt and I never have any problems when I appropriate rights ad


    It maybe because I am trying to domain join them using powershell in a tasksequence rather than using the wizard or customsettings.ini.  I could not find a way other than using powershell to do a domain join as a task sequence.
    Any reason why your doing a powershell script instead of the "Recover From Domain" Step?
    Wednesday, September 10, 2014 12:44 PM
  • Any reason why your doing a powershell script instead of the "Recover From Domain" Step?
    Because my understanding (please correct me if I am wrong) is that the Recover From Domain relies on information being entered into either the Wizard at the start of into the custtomsettings.ini and should the domain join fail it retries with the same information using the Recover From Domain task sequence.
    Thursday, September 11, 2014 5:09 AM
  • actually you return the information to the cs.ini and you ask that this information does not appear. there is no reason why it fails, I have done hundreds of times and everything to work well every time
    Thursday, September 11, 2014 9:30 AM
  • If i were you i would just make the customsettings.ini i want with all the customization properties you would need and use another Deployment Share to make your images.

    Then on your deployment share put this in cs.ini:

    JoinDomain=corp.contoso.com
    DomainAdmin=JoinAccount
    DomainAdminDomain=corp.contoso.local
    DomainAdminPassword=password

    Thursday, September 11, 2014 5:58 PM
  • And give the join account the correct permissions!

    http://deploymentbunny.com/2012/02/02/back-to-basic-permissions-needed-in-ad-to-mess-with-computers-during-os-deployment/

    Friday, September 12, 2014 9:41 AM
  • BWMerlin - You may be trying to over-engineer the system a bit too much. :^)

    MDT works best for domain join when you either add information through the WIzard *OR* pre-populate the information in the CS.ini file. Don't forget the permissions :^) Recover from domain was designed as a vbscript domain join recovery option (if it failed), but there are other non-obvious reasons for also using it. Normally, MDT will inject the domain join information into the unattend.xml file added to the machine just before OOBE setup.

    Additionally, note, aside from what is said above, if you have a homogeneous environment, it may be possible to just use MDT to *create* the images, and inject them into your existing WDS environment to *slam* them onto every machines. Note, that when MDT has finished capturing these images, they should work just as if you took the images from the Microsoft Windows Install DVD. This works if you really don't need to select any options (random computername/same Locale & Timezone/Same Applications).


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com


    • Proposed as answer by Keith GarnerMVP Saturday, September 13, 2014 4:32 AM
    • Edited by Keith GarnerMVP Saturday, September 13, 2014 4:34 AM
    • Unproposed as answer by BWMerlin Saturday, September 13, 2014 7:08 AM
    Saturday, September 13, 2014 4:32 AM
  • BWMerlin - You may be trying to over-engineer the system a bit too much. :^)

    I think you maybe right, I think I trying to get SCCM like result out of a product that was simply not envisaged to do this.
    Saturday, September 13, 2014 8:53 AM