locked
Local admin account issue during capturing RRS feed

  • Question

  • I think the issue with the discrepancy between the local admin account of the machine to be captured and the admin account of MDT.

    From the donor machine I can successfully drill into the deployment share\scripts\Litetouch VBS then credentials screen pops up asking to enter the credentials to access the network share this obviously is the MDT admin account  so I enter it and move next, then goes through Bootstrap and asks for credentials again saying "Specify credentials for connecting to network shares". On some documentations this is the local administrator account to be used to access the donor machine after the reboot to continue with the capture process (after the sysprep goes through and machine reboots)

    When I enter the donor machine local admin account credentials it says wrong (but looks for the donor machine admin account after the reboot?), only accepts when the MDT server admin account details entered and moves to the next step. Then the machine goes through some process and reboots and I can see the system is trying to access the machine with the same details entered (the MDT administrator account) earlier were I think it should have been the local machines admin account which is not accepted?

    The other problem is that the local admin account is disabled but I have enabled it just to see if that was the issue but no luck. Also created an identical account on both the server and client with same passwords, both admins on server AND donor client, then the process just stalls after accepting the credentials. Really driving me nuts.

    The interesting thing is that when I do a fresh deployment I can capture that with no issues because the local and server admin accounts are the same (assuming that is the issue)

    this only happens when trying to capture an image which wasn't deployed by the MDT server.

    Any help would be greatly appreciated 


    • Edited by Ginogingin Thursday, October 1, 2020 2:59 PM update
    Thursday, October 1, 2020 2:20 PM

Answers

  • 'When you update the Windows wim', do you mean modify or capture a new WIM?

    No. The only time you need to create a new boot image to WDS is:

    1. Install new version of ADK
    2. Add drivers for use within WinPE (new WinPE drivers)
    3. Make changes to your bootstrap.ini file

    Just modifying your customsettings.ini is not a need to update and replace your boot file.
    Only the three conditions above.

    If you capture a modified WIM to replace with an existing one, just Import OS into your Share,
    open your TS and replace the Install Operating System OS and delete the old OS. There is no need at that point to update your Task Sequence.

    • Marked as answer by Ginogingin Monday, October 5, 2020 4:24 PM
    Monday, October 5, 2020 1:42 PM

All replies

  • Anytime you're running a script such as the LiteTouch file which resides on the server, you use the server admin p/w, because that is the account which accesses it.

    To launch the VBS you need the server p/w. To access the Bootstrap it is also the server p/w. You can add the username and p/w right in the Bootstrap so it doesn't ask but it seems in your case you don't want everyone just going through not needing the p/w. It is normal that the Bootstrap asks for the server p/w unless it is supplied IN the Bootstrap file.

    If you built your image using a different admin account then add a line in your Task to enable the admin account.

    cmd /c net user administrator /active:yes  (but it's always recommended to ONLY build your image as admin).

    If you built your image using the local admin account, what I do is let the unattend enable it.

    Looking at the unattend, under 4 Specialize, the first line is enabling the admin acct.

    Also in section 7, oobesystem, the second line is autologon. That's where you enter the admin p/w and user UserAccounts, also enter the admin p/w.

    Overall, the best recommendation is to use something like Hyper-V to build your master image, then let MDT capture it and deploy it.

    Friday, October 2, 2020 2:25 PM
  • Thanks you so much for the very useful info. Really weird as now issue is with the deployment initial stage.

    Can boot into pxe pulls the Winpe and then before the boot.ini kicks in  the command prompt opens up and just sits there.

    The path is "X:\WINDOWS\system32\cmd.exe"

    Again the machine boots into pxe and I can see the Microsoft Deployment Toolkit background but just sits with the command prompt open. 

    Even tried restoring earlier snapshots which I was sure it was working. This is just before it asks for the username, password and the domain window. The first screen after pxe boot. There is obviusly something preventing the credentials screen to open, would it be the boot.ini or customsettings.ini playing up?

    Update: When I check the BDD log it seems the system is failing to read the : "Deploymentshare$\control\\TS.XML" file. The funny thing is that there is no TS.XML file within the Control directory.  Is it looking for a file that doesn't exist?

    Also just make things more confusing, I had restored to an earlier snapshot, tried for a physical deployment and was able to complete the deployment however received the same issue with virtual deployment. When I compared the BDD logs of both failed and successful incidents noticed the successful one gone through after the line:

    Mapping server share: \\"server"\DeploymentShare$ (and so on) then:

    Property NotWizard is now - ]LOG]! (and so on)

    the unsuccessful one was reaching to the same point of :

    Mapping server share: \\"server"\DeploymentShare$ THEN

    Mapped Network UNC Path Z: = \\"server name"\deploymentShare$]LOG] (and so on)

    Mapped Network UNC Path Z: = \\"server name"\deploymentShare$]LOG] (another repeat line)


    • Edited by Ginogingin Saturday, October 3, 2020 4:32 PM
    Saturday, October 3, 2020 1:48 PM
  • Hey many thanks again for the useful info

    Eventually resolved the issue by creating a new deployment share. I think the initial structuring was wrong and using more than one Administrator account didn't help either. All working now.

    Just want to know though, when I update the windows wim do I have to re-create the boot image and upload it to WDS?

    We would create a whole new boot image if the boot.ini and customesettings.ini is modified and import the boot PE image to WDS.  WHen something is modified, eg driver inf added, usually we would only need to update the deployment share but  Under which other conditions we would need to re-create a whole new image and upload it to WDS?

    When we import a new wim do we also update the existing task sequences which were linked to the old wim or the system just picks up the new wim replacing the old one?



    • Edited by Ginogingin Sunday, October 4, 2020 10:18 PM
    Sunday, October 4, 2020 8:53 PM
  • 'When you update the Windows wim', do you mean modify or capture a new WIM?

    No. The only time you need to create a new boot image to WDS is:

    1. Install new version of ADK
    2. Add drivers for use within WinPE (new WinPE drivers)
    3. Make changes to your bootstrap.ini file

    Just modifying your customsettings.ini is not a need to update and replace your boot file.
    Only the three conditions above.

    If you capture a modified WIM to replace with an existing one, just Import OS into your Share,
    open your TS and replace the Install Operating System OS and delete the old OS. There is no need at that point to update your Task Sequence.

    • Marked as answer by Ginogingin Monday, October 5, 2020 4:24 PM
    Monday, October 5, 2020 1:42 PM
  • Thank you so much, you have been very helpful!
    Monday, October 5, 2020 4:26 PM
  • So glad to come across with an expert for MDT. Could I also ask? When creating a new deployment share to a different location (drive or partition) can we just copy the content (the whole structure of the existing Deployment Share) over and have the configured tasks and sequences intact to save us recreating them again on the new location? Because when we create a new DS we just have to go through setting up everything from start.

    Is there a way of taking a backup of the current deployment share and restore to the same or different location when needed?

    Friday, October 9, 2020 10:32 AM