Scripted OS Install (SOI) Fails in Automation

book

Article ID: 171822

calendar_today

Updated On:

Products

Deployment Solution

Issue/Introduction

SOI task fails to complete in Automation.
 

In the console you will see this error message:
Exception has occurred in function ExecuteCommand.cpp() at Line No 1995. Type of exception is GeneralError. Error is Default Message Exception in ExecuteClassException. Error Description is Unable to create new process. Value of Windows error code = 6 and message is The handle is invalid.

In your DSTasks.log you will find that setup.exe is schedule to run (ExecuteClass::Module Name = Z:\sources\setup.exe) but then fails to, generating this error message: 

File:ExecuteCommand.cpp,Line:4370 ERROR: Exception has occured in function ExecuteCommand.cpp() at Line No 1995. Type of exception is GeneralError. Error is Default Message: Exception in ExecuteClassException. Error Description is  "Unable to create new process". Value of Windows error code = 6 and message is " The handle is invalid."

This occurs because the setup.exe file is not present or is a zero K file. 

 
 

Cause

A bug native to Deployment Solution 8.x is causing the file importation process to create faulty GUID folder structures when copying SOI files to C:\Program Files\Altiris\Notification Server\NSCap\bin\Deployment\Packages\SOI. There are currently two known permutations of this issue.

The importation process may create two separate GUID folders in the above location, one of which contains the Source > OEM subfolders, while the other contains the rest of the Windows files.

Alternatively, the bug may cause the creation of a single GUID folder, but with the Windows files placed directly in the GUID folder instead of inside the Sources subfolder, where they belong.



Both faulty file structures prevent the SOI from recognizing or calling upon the correct resources to complete the installation process.
 

Environment

Deployment Solution 8.x
 

Resolution

Solution: Issue will be addressed in 8.5 RU1 due first quarter 2019

Workaround:

Resolving this requires modifying the faulty GUID file structure created by the buggy importation process in C:\Program Files\Altiris\Notification Server\NSCap\bin\Deployment\Packages\SOI.

If your import created two separate folders for your SOI files:

  1. Access the Notification Server and navigate to C:\Program Files\Altiris\Notification Server\NSCap\bin\Deployment\Packages\SOI
  2. Locate the recently imported GUID folder (A) containing Sources > OEM
  3. Locate the recently imported GUID folder (B) containing the rest of the Windows files
  4. Copy the contents of the second GUID folder (B) into the Sources subfolder of the first GUID folder (A)
  5. Open the Task Scheduler on the Notification Server 
  6. Run the NS Package Refresh task 
  7. Run the NS Delta Resource Membership update
  8. Access the Package Server and open the Symantec Management Agent
  9. Hit the Update Configuration button in the top right-hand corner to download the updated SOI package
  10. Re-try the SOI job 

If your import created a single GUID folder but incorrectly order the contents:

  1. Access the Notification Server and navigate to C:\Program Files\Altiris\Notification Server\NSCap\bin\Deployment\Packages\SOI
  2. Locate the recently created GUID folder containing the files of the failed SOI job 
  3. Copy all the file inside the GUID folder into the Sources subfolder
  4. Open the Task Scheduler on the Notification Server 
  5. Run the NS Package Refresh task 
  6. Run the NS Delta Resource Membership update
  7. Access the Package Server and open the Symantec Management Agent
  8. Hit the Update Configuration button in the top right-hand corner to download the updated SOI package
  9. Re-try the SOI job 

Regardless of which faulty file system you encounter, this is how it should look when you're done with the above steps:

 

Attachments