Guidelines on the max number of Platform layer versions?

[Nick Panaccio]

I know this has been mentioned in the past, but can't find the posts. Either way, I'd like to know if there are guidelines as to how many Platform layer versions we can/should use? I ask because I've run into an issue with adding a 6th version to my XD 7.15 LTSR Platform layer. Receiver 4.9 LTSR CU1 is installed in the base version of that layer, and I have 4 other layers where I did other work. I created a 6th version in order to upgrade Receiver to CU6, and it fails every singly time with the same oddball error - "Module ...\DVCRenderingAdapter.dll failed to register" (related CTX article). If I create a brand new Platform layer, using the same OS layer version, I can install CU6 just fine.

 

So, is there a recommended maximum number of Platform (or any) layer that we should adhere to? We're running App Layering 1902.

[Gunther Anderson]

Nope, no restriction and no reason why it would matter.  Every time you Add Version to any layer, we clone the previous version.  We don't try to be intelligent, careful or subtle in the process.  Creating version 2 is identical to version 14.  The difference is just the migration of your OS layer over time (I'm re-maiking a very old Platform Layer right now because it was made on W10 1703 and my upgraded 1803 OS layer really doesn't seem to like it any more).

 

One thing you could do (if you have infinite free time) would be to try making your R6 based on R4 instead of 5.  Or 3, or whatever - to see if you can identify the version where the upgrade goes bad.  The answer will still basically be the same: recreate, rather than try to fix whatever is broken.

 

Note that one major difference between your existing layer and your new layer is that one is a software upgrade, and the other is a straight install.  If you're really curious to tease out the differences, you could make a new layer and run through the install sequence you did in your various versions before, at least starting with 4.9 LTSR CU1 and upgrading to CU6.

 

But it's not the number of  versions, it just the accumulated changes in the layer and the OS.  Sometimes it's just appropriate to make a new platform layer, especially because the software that tends to be installed there is very sensitive to OS changes.

[Nick Panaccio]

Thanks, gunthera. That was my next step, to try and create v6 based on v5, then v4, etc. to narrow down the problem layer. I do plan on creating a new Platform layer when we install our next LTSR CU, though. This layer only has this many versions because we had to address a few issues early on. I can cut it down to 2 version now.

[Nick Panaccio]

I've spent the majority of the day trying to figure out which combination broke this. I had to go back to v1.3 of my OS layer to get Receiver to upgrade in this Platform layer. I tried the most recent OS layer with every version of my Platform layer before reversing that. The only changes made in v1.4 of my OS layer, where this starts to fail, was that I ran Windows Update and also updated the custom Start layout. I ran WU in an earlier OS layer, too, so I'm not sure why this time it mattered. I guess I could try creating a new OS layer based on v1.3 and performing all of the tasks in more recent versions (WU, Start layout, etc.), but it's just as easy to go the new Platform layer route. I just hope that this doesn't come back to bite me later on with an App layer or something.

[Nick Panaccio]

Out of curiosity, I created a new OS Layer version based off an early version that I know allowed me to upgrade Receiver. I then made all of the changes to that version that had been done in multiple OS layer versions. I added a new version to my Platform layer using this new OS layer, but Receiver failed with the same exact error message. That's a little discouraging and frustrating, because I don't see why this wouldn't work. I love App Layering, but stuff like this is a real pain.

[Gunther Anderson]

I understand your pain.  But the ability to just recreate the platform layer is a good thing.  I'm fond of saying, "I don't want to understand the problem.  I want to find out where it happens and just delete and recreate it."  I do often have to understand problems, and when we can, we report them to Engineering to see if we're doing something wrong that we can fix.  But the strength of App Layering is that when something goes really wrong like this, you don't have to rebuild your entire image.  Just the bit that went bad.

[Nick Panaccio]

That's a good point. The Platform layer is a little more involved for me because of these USB microphone drivers, but once XenServer LTSR is updated with USB redirection, this will be much nicer. I will say that it scared me a little when I created my 2nd version of this new Platform layer (to apply Citrix Optimizer and VMware OSOT optimizations) that my VM had no network connection. I had never seen that before, but the compiled image seemed to be fine.