1 Reply Latest reply on Dec 7, 2016 2:11 PM by jParnell

    OSP & Reboots

    jkhill Specialist

      We’re trying to mature our OS Provisioning process and appear to be hitting a limitation of the feature that I think is really just a limitation of our understanding of how it works. 


      A simplified version of one of our OSP templates is:

      • OS Installation
      • Post-OS installation
        • Inject unattend file
        • HII
        • Copy some files
      • System configuration
        • Set Administrator password
        • Set windows key
        • Join domain
        • Install agent
        • Activate windows
        • Install a handful of distribution packages that don’t require a reboot
        • Install MS Office but don’t reboot
        • Patch
        • Reboot


      I would like to install several additional distribution packages that require interstitial reboots:

      • Install .NET 4.6.2
      • Reboot
      • Install App X
      • Reboot
      • Install App Y
      • Reboot


      In our testing, OSP stops working after the first System Configuration | Reboot action (in bold above).  It has been explained to me that the problem is tied to a firm-wide GPO that changes the name of the local Administrator account:  once the machine joins the domain, OSP can no longer log in as “Administrator” so the provisioning task is stuck.


      This seems like a strange limitation.  I would think that we should be able to start pushing scheduled tasks as part of the OSP package once the agent has been installed but I am assured that we can’t – at least not as part of the fully automated OS Provisioning process. Obviously, I could push scheduled tasks to the new machine once OSP has completed, but would require manual intervention that I’m trying to avoid.


      Am I missing something or is this in fact a limitation of the product?  Are there any workarounds?


      Also, we're using 9.6 SP1 right now, with plans to move to 2016.3 or later in the next 3-6 months.

        • 1. Re: OSP & Reboots

          We run into this problem as well when we were migrating from MDT to OSP. MDT likes to use the built in admin account; you can configure OSP to do that as well, but it becomes difficult. As far as I am aware, your options are:


          1.) The method we use: Use a domain service account opposed to the built in admin (domain\OSPaccount). This method forces you to use Unattend.xml to do domain joins prior to OSP picking the task back up after the unattended Windows installation.

          2.) Use a registry import to configure autologin to login to the updated Administrator credentials (.\NewUserName) prior to your first reboot (I can provide an example reg file if desired)

          3.) Avoid the domain join until the end of your template (there's a way to do it via VBS, but this is likely to be your hairiest choice, and one I'd avoid if at all possible)