Jump to content
Welcome to our new Citrix community!
  • 0

ELM 2011 - Windows Server 2019 - Failure to create Platform Layer


Ronnie Moller

Question

This is a fresh install for a new client. Our first usage of 2011 ELM.

The OS layer has created properly, following the same procedures we use for past installations.

 

When creating the platform layer, the job fails with the message

an error was encountered while processing the registry

 

Looking thru the diagnostic logs, I see the following relevant message

2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.regservices] registryServices::setFailureActions(1495): service 'Uniservice' does not have FailureActions set.  Putting in defaults.
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.regservices] registryServices::setMachineType(2127): registryServices::setMachineType: setting machine type to 0
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.regservices] registryServices::clearCfsBlockBootValue() clearing out the BLOCK_NEXT_BOOT key if it exists.
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.regservices] registryServices::cleanupNetworkConfig(1257): bicRegistryAssembler::cleanupNetworkConfig: Delete the value is set to 1 - Is Image Export is set to 0, Uniservice value found = 0, keep setting = 0,  bnistack start value of 0 was set to  0
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.regservices] win7BootPrep: setting up the BCD
2020-12-21 15:22:44 ERROR 1540 [uni.ca.syslib.reghive] registryKey::findDirectSubkey(281): registryKey::findDirectSubkey: could not find subkey under Objects (length 38, key {0de3b90a-3fda-11eb-b387-c41df62406b1})
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.bicreg] bicRegistryAssembler: closing all open registry hives
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.reghive] closeHive(8028): closeHive: closing F:\windows\system32\config\SAM
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.reghive] closeHive(8028): closeHive: closing F:\windows\system32\config\SECURITY
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.reghive] closeHive(8028): closeHive: closing F:\windows\system32\config\SOFTWARE
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.reghive] closeHive(8028): closeHive: closing F:\windows\system32\config\SYSTEM
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.reghive] closeHive(8028): closeHive: closing F:\windows\system32\config\DEFAULT
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.reghive] closeHive(8028): closeHive: closing F:\Boot\BCD
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.reghive] closeHive(8028): closeHive: closing F:\windows\system32\config\COMPONENTS
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.reghive] closeHive(8028): closeHive: closing F:\windows\system32\config\DRIVERS
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.reghive] closeHive(8028): closeHive: closing F:\windows\system32\config\ELAM
2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.reghive] closeHive(8028): closeHive: closing F:\windows\system32\config\BBI
2020-12-21 15:22:44 ERROR 1540 [uni.ca.syslib.interface] AssembleRegistry_internal(289): AssembleRegistry_internal: job 0x0 caught a UniException (unknown error)
2020-12-21 15:22:44 ERROR 1540 [uni.ca.syslib.UniException]  0# SetBootDriverFlagsValue in UniSystemLibrary
 1# SetBootDriverFlagsValue in UniSystemLibrary
 2# SetBootDriverFlagsValue in UniSystemLibrary
 3# SetBootDriverFlagsValue in UniSystemLibrary
 4# SetBootDriverFlagsValue in UniSystemLibrary
 5# SetBootDriverFlagsValue in UniSystemLibrary
 6# SetBootDriverFlagsValue in UniSystemLibrary
 7# SetBootDriverFlagsValue in UniSystemLibrary
 8# AssembleRegistry in UniSystemLibrary
 9# AssembleRegistry in UniSystemLibrary
10# 0x00007FFAD94E61EC

2020-12-21 15:22:44 INFO  1540 [uni.ca.syslib.interface] AssembleRegistry_internal(290): AssembleRegistry: job 0x0 done

 

I am unable to find anything documented to the missing subkey {0de3b90a-3fda-11eb-b387-c41df62406b1}, or what could be causing this issue.

 

Any suggestions?

 

The process to create the OS was following Carl Stalhood's guide  (https://www.carlstalhood.com/app-layering-os-layer) and we did use George Spiers' script before shutdown of the OS.

Link to comment

6 answers to this question

Recommended Posts

  • 0

I tried turning off the "Offload Composing", and still received an error. What is odd is this OS layer finalized and imported ok, but could not be used for either a platform layer or an app layer, both giving the same error.

 

I opened a case with Support, and they pulled more logs, but where unable to figure it out.

 

I created a very basic install and tested with platforms and apps, and the 2nd os layer worked properly.

 

The only difference I can identify is the 1st OS layer was originally created as an EFI layer, and had 4 partitions. I converted to BIOS, and restructured the partitions, but I am guessing that the registry had an entry for the wrong partition table.

 

Given that it works when creating a fresh OS on BIOS, I do not see a problem with 2011 ELM, and consider this a fluke in my process of converting EFI to BIOS.

 

For what its worth, I never did try to boot or use the EFI bios install, even though it is supported according to the documentation.

Link to comment
  • 0

Good checks, the various layer tests. Yes, we mark the type of OS, for future reference. so altering the partitions, after the fact, should not work.

 

Well, for importing a UEFI OS you need to use the import script, noted in our docs. If you did use it and a second attempt to import a new UEFI OS layer fails, we need to figure out why it is failing. Also, I would not continue to use that OS layer, that has failed to create other layers.

 

Thanks for the update!

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...