KACE Product Support Question

Scripted install hangs at "Set Engine Run Key"

03/24/2016 1977 views
My org has been using a K2000 to deploy scripted Win7 x64 images for a few years and have recently started to notice an issue, where after the "Windows  setup" screen, the deployment process will hang at "Set Engine Run Key" for anywhere from 30 minutes to a few hours, and sometimes it hangs here indefinitely.  During this time, all I see on the client is a black screen with a mouse cursor.

We are running K2000 version 3.7.120251 and are doing a scripted installation using Win7 x64 media.

Since deploying to the same PC will sometimes complete and sometimes not, that leads me to discount a driver issue (if a driver were missing, then one would think the deployment would never work).

At the black screen where the system is hanging, I can press shift + f10 to open a command prompt, and I have verified that the system has network connectivity at this point.  The contents of c:\windows\panther are available at this link.  I'm not sure what these are used for, but I've seen others include them in their posts requesting assistance.

If I open task manager while the system is on the black screen, I can see that svchost.exe is doing something, but as to what it's doing, i'm not sure and I don't know how to figure that out:


Based on the presence of wusa.exe, I'm guessing that the system is applying Windows Updates.

Any clue as to why this behavior would start suddenly without having made changes to the scripted install, or how we can prevent Windows Updates from running at this point?
0 Comments   [ + ] Show comments


All Answers

There are still many various possibilities, however the path you mention of c:\windows\panther is used to host the unattend.xml file that is used for image deployments. If the unattend.xml file has the option to update windows patches enabled then it could be applying these from the point the image was captured to the current release of patches.

Usually the set engine run key would indicate that the network driver may not be the best matched driver to use - could there be lots of extra drivers in the KBE build which may have the systems picking different network drivers for the install process?
Answered 03/24/2016 by: TheAustinDave
Brown Belt

  • Thanks for your comment.

    As mentioned, I wouldn't think that consecutive deployments to the same hardware would be picking different NIC drivers each time. If no changes are being made, one would presume that the driver selection / installation process would be identical in every deployment, or are you saying that is not the case?

    I checked the link you provided, but it seems to be for image deployment so I'm not sure it's relevant for scripted installations?
  • Follow up - I checked the unattend.xml file and couldn't seem to find any reference to updates. Do you know specifically where I'd find that?

    Based off of the link you shared, it seems the issue is that the KACE engine is supposed to be running and reporting in with the K2000. If I manually run c:\Kace\Engine\KaceEngine.exe from a command prompt while the deployment is stalled at a black screen, that gets it going again and the post install tasks pick up as they're supposed to, so the issue seems to be that for some reason the KaceEngine.exe file isn't running like it's supposed to be.

    In the unattend.xml file, I see the following:

    <SynchronousCommand wcm:action="add">
    <Description>KACE Engine</Description>

    So it looks as though KaceEngine.exe is supposed to get kicked off the first time the system boots, but my guess is that when the system is hanging at the black screen, it isn't progressing that far, so I'm assuming tthat's what I need to track down.
The scripted installs also have the option to enable the windows updates during the install, should be able to verify if that is the case by going into the scripted install and selecting the show option on the deployment details page.
Setup Configuration: (Hidden)Show
Answered 03/24/2016 by: TheAustinDave
Brown Belt

  • Ah, I see. The <ProtectYourPC> setting was set to 1, so I'm going to try setting it to 3 (disabled) and see what that does for me. Thanks!

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login


This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ