Application packaging options for SCCM

When I started my career ten years ago, the world of application and desktop deployment was a much more diverse place regarding the tools being used in the enterprise. Over the years, I’ve worked with SMS, Marimba, Enteo, Radia, LANDesk Management Suite and Altiris to name just a few.

In more recent years I’ve noticed a trend forming. System Center Configuration Manager has been adopted by the majority of my clients. Some have migrated from tools like Marimba and Enteo to SCCM while others have moved up from SCCM 2007 to 2016. Regardless of the route taken, I’ve come to a pretty startling realization, that in the last few years I’ve not worked for a company that wasn’t either already using or transitioning to SCCM!

SCCM for application deployment just makes sense.

A colleague at my first SCCM customer put it simply: “we need to start using a Microsoft tool for deploying Microsoft products”. This particular customer was using an old version of Enteo at the time and faced many challenges. They were deploying a fat image and then sequentially deploying a handful of additional applications based on user needs. These builds had a pretty high failure rate and due to the size of the image, took quite a long time just to fail! SCCM would prove to be a big step up for them, but it was an opportunity to adopt a simpler, more efficient and dynamic method for deploying desktop images and builds.

Some organizations use the excellent Microsoft Deployment Toolkit for their desktop imaging. If you work for such an organization, you’re in luck! You’ll already be very familiar with the task sequence UI in SCCM, and you can re-use a lot of what you’ve already created!

The same client was also using Windows Server Update Services (WSUS) for managing patches on servers and desktops. You know what tool is great for deploying Windows updates/patches? SCCM!

There’s some great functionality in SCCM. You can automate the rollout of patches, easily customize the user prompt and natively integrate with your Operating System Deployments using task sequences. Best of all, as my colleague had suggested, you’re using a Microsoft tool to deploy your Microsoft patches all through a single console.

SCCM and Intune integration

There are some other excellent features in SCCM such as integration with Intune. While in my opinion, Intune is not the greatest Mobile Deployment Management (MDM) tool on the market today it does integrate perfectly with SCCM to provide a solution for deploying iOS, Android and Windows apps to your devices. In fact, you can even use it for deploying traditional MSI’s, if you so wish. However, I highly recommend using SCCM itself for deploying your traditional MSI’s as it is much more feature-rich.

Distributed administration

SCCM is not just for the desktop team either! In a previous job, we created roles for the Desktop team, Helpdesk team, Citrix team, Exchange team and Server team. These roles limited each team’s access to ensure they could only use the features required e.g. the Exchange team only needed the patch management capabilities, so they could only use that feature.

Compliance

Another aspect of SCCM I like is the compliance feature. This allows you to set a compliance baseline on your end-user devices. Basically, you can set a baseline for what your devices should have set e.g. what applications are critical and required, what services need to be running, what settings need to be applied, etc. and SCCM ensures compliance.

Maintaining compliance with SCCM
To ensure devices stay compliant, you can set an auto-fix to run when something is out of compliance. For example, you can insist that the WMI service must always be running. If an administrator decides they want to disable it, SCCM can poll, see the service has been disabled and restart the service.

You now have a single agent to try and claw back some control in your environment.

Application packaging and deployment using SCCM

My main area of expertise is applications. I have always thought creating a desktop image can be a lot of work initially but after the initial creation, it becomes routine to maintain. Patching tends to become routine. Most other areas of IT management can be heavily automated and made routine.

What’s not so routine? Those damn pesky applications. There’re thousands of applications out in the wild, all of which have seemingly been developed following different standards and practices. Getting a hold on application packaging and deploying them effectively can be time-consuming and costly!

Supported package types

SCCM provides a variety of application package types for application deployments. Among these are traditional application packages such as MSI’s and scripted installs but you can even deploy to Macs!

If modern Windows applications are your thing, you can also deploy your .appx applications. You can even deploy applications using task sequences for your more complex installs. With so many options, you have the flexibility to use whatever you feel like or whatever is easiest on a per-app basis.

Problems migrating to SCCM

A recurring theme in the deployment tool migrations that I have been involved in is that companies got stung by using proprietary application deployment features from other products. The company I worked for that using Enteo took advantage of their extremely useful framework for wrapping the installs. In some cases, they modified a registry key, copied some files and then ran the vendors .exe. Almost all of the applications used that wrapper in one way or another.

Another customer I worked for used Marimba and had also created packages that used Marimba features for making changes to the desktop rather than through the install string or package.

Using custom features left both in a tricky spot when they wanted to use SCCM. They couldn’t just take their applications and deploy them. And SCCM was not the problem! If they wanted to move to another tool such as Altiris, they would have run into the same problem!

So before you decide to throw caution to the wind, I would suggest that you consider your migration an opportunity to standardize on your application packaging. In my opinion, packaging is not something you do in a deployment tool! So, if you found this article by searching: Using SCCM to package applications, let me stop you right there! DO NOT USE A DEPLOYMENT TOOL TO PACKAGE APPLICATIONS! With that out of the way, how should you package your Windows applications to deploy your desktops or servers using SCCM?

Application packaging options

Windows Installer is an MSI, which you’ve likely come across before. This package type has been around since 2000 but never received the widespread adoption it deserved. When deploying an MSI you avail of some killer features which are still as useful today as they ever were, such as the ability for the install to gracefully rollback and undo what it had done to the point of failure. This is so much better than scripted installs which can fail part of the way through and leave your users systems in an unknown state.

Applications deployed with MSI could also auto-repair. If a user accidently removed files belonging to the application, it would simply fix itself.

If you’re thinking “Rory if MSI is so awesome why hasn’t it received widespread adoption?” It’s because unfortunately for MSI, vendors found new and interesting ways to circumvent the attempt at standardization of installs on Windows. If you look at Google’s enterprise MSI for Chrome, you’ll see that the shortcut table does not contain any shortcuts. The file table does not contain any files. Rather than use the tables provided, Google decided in their infinite wisdom to embed their own installer into the MSI and execute it as a script from the MSI’s custom actions table. This completely negates the features of MSI such as the graceful rollback but in fairness, who can blame them? Even Microsoft’s product teams opt to release their applications as .exe installs.

Windows app package is still relatively new.  With many ignoring Windows 8 in favor of moving to Windows 10, there’s not a whole lot of demand for .appx applications of yet. Microsoft has released a beta desktop converter tool for moving your Win32 applications into the new format but as of writing, I would have to say this is nowhere near ready for prime time yet!

Web application is just for deploying a shortcut with the target set to a website (URL). This is not the best way to publish or advertise sites to your users.

Not listed in the screenshot is the option for a scripted install or task sequence. In certain cases, you may want to use a scripted install or task sequence. A scripted install can be useful when deploying a large application that must be deployed using the vendor provided installation media.

To give you an example, I worked on an SQL product which had a .exe that embedded multiple MSI’s. I would usually extract the MSI’s and deploy the application using these, however, in this instance deploying the MSI’s broke the application. I discovered some SQL patches were actually being executed as part of the exe. I had no choice! I had to deploy with the .exe. Task sequences can be great when you have multiple installers or require multiple reboots during an installation.

Which option addresses all of my concerns out of the box?

Microsoft App-V!! It doesn’t discriminate against funky vendor installs, and it doesn’t care if Google or Microsoft’s product teams didn’t produce a standardized installer.

App-V uses a tool called the Sequencer to do a snapshot of an application install. If you can install the application, you can attempt to sequence it. No need to try and figure out how to remove a shortcut that was installed by a custom action in an MSI or disable auto updates in an MST on top of a dud MSI. It can also capture windows updates as part of the install. There’s no need to worry about splitting them out or compromising and deploying as a .exe.

App-V can simulate install related reboots as part of the sequencing process. So again, no need to create a task sequence to handle multiple reboots.

If you’re worried about a scripted install failing on your machine and leaving it in a broken state, that’s not a problem with App-V. Everything required for the install and configuration of the application is contained in a virtual file system and virtual environment unique to the application. It will not conflict with or break anything on your machines.

If you found this article by searching ‘Using SCCM to package applications’, let me stop you right there! DO NOT USE A DEPLOYMENT TOOL TO PACKAGE APPLICATIONS!

Rory Monaghan

App-V solves all kinds of common problems encountered in enterprise IT. As stated the applications use a self-contained virtual environment which runs isolated. With App-V, you can sequence and deploy multiple versions of the same application side by side on the same machine without being concerned about conflicts. You don’t need to worry about the old problem of DLL hell. Application uninstalls won’t remove a file required by another application on the system.

App-V is a great choice for standardizing your application packages.

Wait, isn’t App-V a Microsoft product? Won’t this tie me to using the Microsoft deployment tools? NO! You can deploy App-V applications using several different methods including PowerShell scripting and even MSI! The App-V sequencer automatically generates an MSI, which you can deploy to any App-V client machine.

With the native App-V deployments tools, you can also stream applications to your user’s desktops. It’s pretty cool! You assign an application to your user; they instantly see the shortcut appear on their desktop. When they launch the application, it streams the bits of the application down to their client machine and the application starts. No installation dialog in sight!

A word of warning: The App-V native deployment tools are severely lacking and are not very scalable across multiple geographic locations. Luckily for us, SCCM scales very well over many geographic locations, in fact, Microsoft themselves deploy to over 300k devices using SCCM and guess what, with SCCM you can stream your App-V applications to your users. Instead of streaming using the App-V tools, it leverages the SCCM distribution points and streams from your user nearest DP.

That streaming capability is not in other deployment tools. Also, if you have a spotty network or low latency, it’s not advisable to use the streaming.

Streaming is not the only option. You can also cache the entirety of the application down to the user’s machines when deployed. This provides optimal performance! If you ever want to move to something like LANDesk Management Suite, you could just wipe the slate clean and still deploy App-V applications using their MSI’s. You are not tied to Microsoft.

App-V in the real world

App-V has been a godsend on some of the projects I’ve worked on.

• For a pharmaceutical customer, it helped to reduce our requirements for XenApp Silos. Thanks to App-V eliminating application conflicts, it meant we no longer needed to Silo as a fix! Having all of our applications across all of our XenApp servers also gave us much greater user density and a better end user experience overall.
• I worked for a healthcare company with over 50k users that had many web applications dependent on legacy runtimes like Java 6. By sequencing this dependency with App-V, we ensured they could continue to use the web app and also enhance security by ensuring this ran isolated.
• On yet another project for a large bank with over 60k users, who were running desktops with very stringent restrictions, poorly written in-house applications were a major problem as many required file\folder permission changes in order to work in their environment. The developers were slow to make changes when requested, and any permission changes set by our packages required security approval.  App-V allowed applications to write to their isolated virtual file system. And because this didn’t write to the local file system it didn’t cause errors or require any special approval or code changes. SUCCESS!

Shortcomings of App-V and SCCM

If this all sounds too good to be true, there are a few shortcomings! SCCM can be overwhelming! It’s such a large product that touches so many areas that it can take quite a while to master. Designing and implementing the infrastructure requirements can be challenging, to say the least. Of course, like any product it can also fail at times which can be disheartening, and while App-V is very powerful, it comes with a pretty steep learning curve.

Sequencing an application is easy but troubleshooting issues can be intimidating to those who are not seasoned application packagers. Applications with drivers and COM+ component services have compatibility issues with App-V and will either need to be deployed as a different package type or will require some extra effort to deploy with your App-V package. App-V training is a necessity, and you may even find yourself hiring an App-V expert to help with the transition.

Cost effective ways to expedite your App-V sequencing efforts.

Some vendors have produced great tools that allow you to bulk load and report on your existing application packages compatibility with App-V to give you an idea of the effort required. These tools include:

• Citrix AppDNA
• Dell ChangeBase
• Flexera Application Manager
• Autonoware ConversionBox, etc.

In conclusion

SCCM seems to be growing from strength to strength, with all of the great features and capabilities I have written about it comes as no surprise. The fact we all work daily on Windows and must purchase the OS licenses also makes licensing SCCM pretty convincing. As stated numerous times in this post, using a Microsoft deployment tool to deploy Microsoft products does make sense and it’s clear to see that SCCM is dominating in the enterprise deployment space.

The application problem is an ongoing headache for every organization, but it can be more manageable by standardizing your packaging and using a tool like App-V to move your application deployments into the modern day! No more install related reboots, no more application conflicts, no more getting tied to a single deployment tool, and no more helpdesk tickets for broken installs or install failures. Go ahead, take the next step ☺