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
- 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
I would like to install several additional distribution packages that require interstitial reboots:
- Install .NET 4.6.2
- Install App X
- Install App Y
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.