Citrix App Layering makes it easy to manage your operating systems and applications as individual entities and compose multiple images from these as required.
To help ensure the best possible App Layering experience, I’ve put together the below 5 tips that I recommend admins follow.
Frameworks go in the OS Layer
The .NET Frameworks are inextricably intertwined with the OS and, typically, newer versions are backward compatible, so we highly recommend that .NET be managed as part of your OS layer. Since Framework updates are delivered via Windows Updates, just like OS updates, these updates will be downloaded and applied at the same time as the OS inside of an OS layer version. This makes it one less layer to worry about keeping updated.
Keep It Clean
During the layer editing process, every file and registry creation deletion or modification gets written into the layer disk. So, to keep the layer as clean and as small as possible, it is important to remember that everything you touch will become part of that layer. You should never open a web browser to download an application installer as this causes lots of temporary files and even your internet history to get written inside of the packaging machine. Instead, you should download the application installer or updates using your local desktop and then transfer them to a network share that can be accessed by the packaging machine. Be sure to extract any zipped or compressed installers before copying to the network share, as this will keep lots of temporary files and writes out of the layer as well.
ProTip: as a packaging machine will not be part of your domain, you should use the Fully Qualified Domain Name of your file server when connecting to it from within the packaging machine. You may also consider creating a layering-specific service account and share, then mapping that on the server to a drive letter. If you map the share while creating an OS Layer version and check the “Save My Password” box, the share will be mapped every time the Packaging Machine starts up.
Lastly, before you move on to finalizing your layer, always remember to do some housekeeping first. Deleting any installers from the desktop, deleting any temp directories, and emptying the recycling bin will help to reduce the layer size and prevent those leftover files from getting presented on a published desktop later.
MiniTip: If you ran Windows Updates as part of an OS layer version or a Microsoft product Application layer, you should delete the contents of the software distribution download folder. This is the location that Windows Update downloads the updates to prior to applying them. Note, only delete the contents of the folder, do not delete the actual Download folder.
C:\Windows\SoftwareDistribution\Download
Prerequisites First
When you begin to create your application layers, and you have done a few simple ones to become familiar with the process, you should look for any applications that integrate with other apps or that require a component to be installed first. These required or underlying applications should be layered first and will be then selected as prerequisite layers when you go to create a layer for the subsequent application. This helps to keep your patch footprint as small as possible, allowing you to have only one place to apply updates even though multiple other applications rely upon it.
Typically, Microsoft Office is an application that many others will require or integrate with, so you’ll want to create that layer early. Then, when creating a layer for any application that integrates with office, you can select your Office layer as a prerequisite and it will be included on the packaging machine that gets created.
Sometimes, it can be hard to decide if a software component required by another application should be layered first as a stand-alone layer, or just included in the same layer as the app itself. You should consider if there is any other application you plan to layer that will use that component, how often are there patches or security fixes for that component, and how hard is the component to install. If it’s just a small feature that isn’t updated often, or doesn’t take too long to install, you won’t be saving yourself much time having it as a separate layer, so you might as well just install it in the same layer as the application itself.
Wrap It Up
When you have finished installing your application on the packaging machine and have tested it, you should then focus on any configuration or licensing that needs to be done prior to finalization or “sealing” the layer. For simple applications, this can be nothing more than turning off the auto-updater and making sure there are shortcuts on the desktop and start menu for all users. Forgetting to disable auto updating will cause CPU load and disk usage on your deployed machines as the app tries to download and update itself, plus it may result in your users running a newer, different version of the application than you intended them to get via the layer.
For more complicated applications, such as those that communicate with a management server like antivirus, you should follow the manufacturer’s steps to “generalize” or remove any unique client identifiers. If this is not done, your deployed machines may fail to communicate with the control server at all, or every machine will identify to the server as the same client, making them indistinguishable.
Licensing should be your last thought prior to clicking the shutdown for finalization. If your app requires a product key or license file, how will that get applied to the published machines or when the application gets elastically attached? You should always consider this: does a product key need to be installed on each machine at first launch…does this need to be scripted…do you use a third-party management tool like SCCM to manage licenses?
Other applications, especially Microsoft Office, need to have their product keys installed and activated during the install process, but then be “Rearmed” just before you finalize the layer. This will cause the application to auto KMS activate on next launch, which will be on a published desktop.
MiniTip: There is a long list of Application Layer Recipes on the Unidesk forums that describe how to best layer and license common applications. Additionally, we have our thorough Microsoft Office Recipe that goes into detail on the various licensing and activation considerations.
Finish with NGEN
Every time you click the “Shutdown For Finalize” shortcut on the desktop of a packaging machine, we are actually performing a handful of checks on the state of the machine prior to shutting the machine down. One of the most important parts is checking if there are any background queued .NET native images that need to be generated. Anytime you apply updates to the framework through Windows Updates every .NET application or framework resource that uses that updated component must be recompiled.
These native image generations are very CPU and storage intensive operation, so to not interfere with the user experience windows creates a queue to be run later. By default, the NGEN or Native Image Generator process will begin to process the queue after the machine has been idle for 15 minutes, you can observe this in task manager as the NGEN.exe process. If this queue doesn’t get processes prior to finalizing a layer, the list of images to generate would get merged into your published image. Which would mean that each individual machine built from that layered image would each being to process their native generation queue when idle. This could easily result in virtual host resource contention from the parallel compilations.
Rather than allowing your packaging machine to sit idle until the background process completes the image generations, you can trigger the NGEN process command line. The recommended command is ‘ngen.exe update’ which will force generation of anything in the queue, but run it as a foreground process. Do not use the force switch as it will rebuild every assembly whether it is needed or not, which will take a long time and increase your layers size. It’s worth mentioning that a 64-bit operating system will have two different .NET framework, each with their own queues, so you will likely need to run NGEN from both framework paths.
MiniTip: The PVS image optimization utility will generate and queued images when you click the save button, so you may have been unknowingly clearing the queue on your traditional images.
ProTip: Create an NGEN generation script like the .bat file shown below, and place it on the desktop in an OS layer version. Then anytime you get a warning that a background image generating is blocking finalizing you can simply right click and run the script as admin instead of having to use the command prompt.
NgenUpdate.bat
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe update
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update
C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe update
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ngen.exe update
There you have it! I hope you found these tips helpful. Happy packaging and feel free to leave a comment or question below. If you’re not currently using Citrix App Layering — the most comprehensive app layering and OS management solution available — I encourage you to go to Citrix Cloud to sign-in or to create a new account to access your 60-day free trial. The Citrix App Layering service includes full feature functionality and eligible customers with active Customer Success Services Select can use this service for production roll out.
