I'm seeing the same issue at a current client. It's on a Dell D620, just in case its hardware specific. The original symptom was a failure to to copy down the sysprep.inf. I did some troubleshooting and discovered that diskpart didnt do its job and assign a drive letter to the partition in the previous command. I ran it manually and it worked fine, but it was obviously lagging. As the workstations sits now services.exe under WinPE is using 100% CPU. I'll let you know if I make any progress.
I am running into similar issues.. We actually ended up building an 8.7 virtual core and at the end of the HII script had it inject the agent for the 8.8 core.
This of course is a temp solution.. We have a case open with LANDesk on this.. I did notice one thing off the bat is the PXEREP image has increased in size so machines that use 256MB of ram are erroring out with vurtual memory erorrs in 8.8 when running the VBscripts. I shrunk the image down to get past that.. The other problems I am seeing are on the GX280's they error out with a CBA timeout error, and on the gx270's The script will fail at random sections. These machines work fine in 8.7 so its not a driver issue.
Do you have any GX280's? We actually have a similar process with our vbscripts.. Im just curious.. In your 2nd vbscript which dynamically pulls the Image based on IP, are you just grabbing the gateway and using a case statment once it finds a match setting an ENV variable ex %imagestore% which would then be in your drvmap remexec line?
Whats funny is my OSD script isn't even customized yet. This is an out-of-the-box Deploy script created on the 8.8 core.
I tried making a custom script out of the box as well, and it failed... I even took an 8.7 winpe image changed the all.reg and Cert files and I still had the same issue.. Makes me thing its something core related...?
Ok try this. I am not 100% sure its the solution because I couldn't get the issue to happen 100% of the time.
There is a new line added with 8.8. Try remming it out.
;REMEXEC17=diskpart /s X:\LDClient\rmvol.txt
Basically it's purpose is to remove all existing volumes, mainly to insure we don't already have an H or I drive, which we will be mapping.
I did and every attempt since then has been successful. I'd appreciate some feedback so I can pass it on to LANDesk.
Nope, further testing this morning shows even with that line remarked out it still happens sporadically. It seems that when diskpart runs it causes services.exe to run at a high CPU, slowing down the process to the point where imaging fails.
The GX270 was failing during the sysprep injection.. I'll comment that line out and see if that helps.. On the GX280's I get a CBA_ERROR:-1917761385 I did a packet sniff on the core server and noticed that as soon as the script is selected off the menu the core and the client do what looks like a UDP ping (XFERWAIT) is inside of the packet on port 3892 back and forth and the task never starts...
The injection fails because there is no C drive. If you open a command prompt in PE aftre it fails and try to navigate to C: it will say drive not found. The real failure is that in the line prior, diskpart fails to associate the drive letter C: to the partition due to the high services.exe CPU utilization. The image is there and if you manually run diskpart and assign the C drive to the partition you will see the data.
On my GX270 I did have a C Drive mounted... I think I might be looking at a different issue...
OK, think I found a workaround.
Ryse, yes that's exactly what the 2nd script does...grabs the IP and uses a CASE statement to select the "IMAGESVR" variable, then maps a drive using encoded VB so I could include some credentials in the script (not as secure but not worried about it in our environment). Removed the %imageserver% drvmap line in all my scripts. Also completely removed the line regarding "diskpart -s rmvol.txt". Seemed that intermittently it would throw the machine into 100% CPU utilization. Wasn't worth it and assvol.txt and wipedisk0.txt seem to take care of setting the disk up just fine.
My workaround has been working great in our HII environment. All I did was to create a batch that runs the exact same commands that the OSD script is running and put some ldsleep pauses in between the command lines. I honestly don't know why it helps, but it does. I created a 2 second delay (ldsleep 2) between the "diskpart wipedisk0.txt" command and the C: format command in the batch and it works great every time, even without the RMVOL.txt command being run at the beginning. I was surprised because i'm still doing the same commands, just in a batch with pauses instead of letting the OSD script run normally.
The other thing that I changed in 8.8 was instead of downloading the files during the OSD script to inject scripting support, I added them to the PE image and just ran the batch that registers them. Also included my VB scripts in the PE image so there's one less line for downloading in the OSD script. In all my troubleshooting it seemed the more lines I could remove the better everything ran. I still see TASKMGR hit 100% periodically during the OSD process but it goes back down, where before once it hit 100% I might as well just reboot because it would fail all the time.
Hope this helps, so far all my PC and laptop models are taking our HII image perfectly with these changes. I'd still like to know what changed from 8.7 to 8.8 because I used the same scripts in 8.7 without any of these modififcations and they worked great.
The problem you describe is exactly the same we had in our company. When de vbscript.cmd copying (vbscript functionality) files slowly, we know that the diskpart commands will fail. We also find out that the more lines you use the greater the chance that the scripts is getting slower and the cpu is consuming more and more. Its looks like our problem was solved to change the order of some lines and running an external .cmd script that is running the diskpart lines from the local X: drive (WinPE). I know it sounds weird but it seems to help. We are testing this on all type of machines now en will get back on this. If our method fails we can try yours, anyway thanks for the workaround.