Are you saying that setupComplete.cmd is starting before the er.. setup is complete ? Im interested, because im struggeling with unexplained failures during provisioning, although the March MCP patches have helped a lot with general reliability, im still not at 100% - and a 99% succesfully provisioned device is no use to anyone :-(
this remains unresolved, so thanks for checking in on the matter.
I can say that 'I think' setupcomplete.cmd is running before mini-setup is complete. Here is why:
I know that the provisioning agent is installed/launched because of its existence in this file.
I know that during mini-setup I see provisioning kick off long before I expect it to; it is running concurrent with mini-setup which I don't expect.
This problem occurred when I took my original desktop image and pushed it to a new laptop via provisioning. I re-entered audit mode and modified the image before uploading a new iteration of it. Next I deployed that image to a bunch of laptops and began to see the problem consistly across 100% of the target computers. I have seen something similar before when I didn't clean a bunch of provisioning-related/sysprep-related stuff from my image. I suspect that I once again have left-over artifacts on the image which cause provisioning to jump-start before it is supposed to do so. Though I have no idea what to look for when cleaning the image.
and I agree, a 99% success rate on an image is still a failure.
Hum..interesting. Today I was "forced" to actually implement provisioning without using CTOS - I have a site where the connection to the core is so thin that the clients were failing to reliably download the 12Mb of stuff that CTOS injects. The solution is not pretty, and certainly not best practice, but did seem to work. Basically I captured the LDProvisioning folder from a standard installation, and zipped it. I wrote a provisioning mini template to download the zip file from the local preferred server and unzip it on the client. I then modify setupComplete.cmd to run
- C:\LDprovisioning\cba8inst.msi /qn
- A reboot action
and this seems to work, in as much as provisioning then continues to run just the same as using the build in CTOS action. However, im still seeing random failures with the final agent installation (an exe from a local preferred server) and sometimes with the inject scripts action (not enough bandwidth for that! Im not sure I believe that)....
anyway, we also use DPINST to install the drivers injected by the HII action - again not best practice, but some drivers were unsigned and prompted for installation). I had the feeling that provisioning was moving on while DPINST was still running, so we have an action which uses an AutoIT script to wait for the DPINST process to exit before moving on. I wonder if there is some process that we could identify to ensure that the Windows setup is actually complete - although AFAIK we are not seeing that issue, there is a 10 Minute gap between the CTOS rebooting and the next action.
None of which actually helps you im afraid...but keep us posted.
This original problem remains today and here is how I can produce it:
I take a machine and provision it with an image which is placed in audit mode before it is captured.
The provisioning process goes off without a hitch and I'm left with a fully functional machine.
Lets say I re-enter audit mode, make some changes, then re-upload the image and re-deploy it to another machine.
During the provisioning process of the 2nd machine I can see that the provisioning agent jumps ahead and will try to run while sysprep.exe is running.
I know there is something left over on the image which screws this up but I have no idea what it is. In order to make a previously provisioned machine into a model image again I need to perform some kind of cleanup operation. I've started with removing the unattend file but I really don't know what else to reset.
did you check the setupComplete.cmd in c:\windows\setup\scripts to see if there are any entries in there?
im not sure where else the CTOS agent references are.
The setupcomplete.cmd contains the following line item:
I know this is considered 'normal' because this file is how provisioning is able to continue during the windows setup process. What I'm not clear about is whether this file has to be empty to begin with.
This is a good suggestion and I will retest with this file empty on my image.