App Layer Script Path Not Running on Startup

[Darryl Sakach]

We are in the process of rebuilding our layers for Server 2019. They are currently built on Server 2016. One of the app layers being rebuilt has a Script Path configured in the App Layer properties. The script itself is part of the App Layer. Everything related to the script appears to be configured the same on the new 2019 layer as it was on the 2016 layer. The app layer script does not run on startup. It would generate some output if it executes just like it does on the 2016 image, but no output is generated on the 2019 image.

 

How can I debug this issue? Is there any logging related to the layer scripts?

 

ELM 20.5.0.1008

VDA and PVS TDS are 1912 CU1

VSphere 6.7

[Rob Zylowski]

Make sure you gave a startup script pointing to kmssetup.cmd.  That is what runs the layer scripts. 

[Darryl Sakach]

Checking local group policy I do not find a kmssetup.cmd in the Scripts (Statup/Shutdown).

 

[Rob Zylowski]

The you should add it.   That is normally added when the gold image tools are unzipped.

[Darryl Sakach]

I previously installed the OS machine tools 20.05 and ran Setup_x64.  I have also now reinstalled and rerun them (repair and modify). I also tried the 20.09 version of OS Machine tools, Still no entry in startup policy. Any idea why? My fear is something more than the Startup script could be missing.

[Rob Zylowski]

Could be a policy you have or something with the way we add the gpo.  As long as you have the script files in windows\setup\scripts and the entry to c:\windows\setup\scritps\kmsdir\kmssetup.cmd as a startup script you should be ok.  Tere is nothing specical going on. 

 

BTW you should use your original os layer.  It never works to reinstall the settup64.  our drivers cant be uninstalled.

[Darryl Sakach]

I ran the gposetup.cmd manually and it appears to have run successfully. It appears this did not run when I unpacked the OS Machine Tools as there are no gposetup logs present. There is a runipkato.cmd file directed to 2019s so it appears the install.cmd did run. I have no idea why the gposetup.cmd did not run, yet the SetKMSVersion.hta did run.

[Darryl Sakach]

So although running gposetup.cmd properly placed kmssetup.cmd in the local gp, that local gp is being overwritten by the platform layer startup script config for the new C:\Program Files\Citrix\Provisioning Services\CPVOfficeActivation.cmd. I have confirmed that the kmssetup.cmd is in the startup script gp in the OS layer, but when I publish the OS Layer along with my PVS 1912 Platform Layer the only entry in startup scripts is the CPVOfficeActivation script. Is it accurate to say that all startup scripts should be configured in the OS Layer?

[Rob Zylowski]

I would only use kmssetup then use a layer script for any others.  You can create an app layer to make the layer script that would otherwise be in the platform layer which doesn't support layer scripts.  That was you wont have things launching on all your packaging machines.

[Thomas Rodgers]

With ELM version 20.5 there was a change with the Applayering tools exe which now uses the 7zip self extractor process

 

After the extract it runs the "C:\Windows\Setup\scripts\install.cmd" file. In this file it has two commands

Quote

 

@echo Off
REM install.cmd
REM This script is automatically run after self-extraction completes

call .\kmsdir\gposetup.cmd
start /D c:\windows\setup\scripts mshta.exe c:\windows\setup\scripts\SetKMSVersion.hta

 

 

As the gposetup.cmd is run not in full folder context we believe it has an issue running this command with the new 7zip self extractor

[Darryl Sakach]

Thank you for the update.

 

For my purposes I have been able to resolve the issue by running 'call .\kmsdir\gposetup.cmd' from a cmd prompt.

 

As far as the PVS startup script overriding the kmssetup.cmd startup script, I recreate my PVS Platform Layer and the PVS Startup script was not created in this new version.