One of my favorite things about being a consultant is the opportunity to go into different organizations, learn what they do best and share what I have learned from previous organizations. SCCM is an amazing tool, but it is easy to get lost when you have several ways to get the same thing done, so I am starting this blog series on the best practices I have seen implemented.
We having already covered setting up a Default Limiting Collection to protect the critical systems in your organization and using the Summary Screen to avoid deployment mistakes. Now let’s take a look at a few best practices for application packaging.
SCCM 2012 introduced the Application Model for software distribution, which has opened up an entirely new set of options, functionality and sometimes problems for application packaging. Here are my top 5 best practices to keep in mind as you package applications for SCCM 2012.
1. Always try to use the Application Model first.
Packages still exist in SCCM 2012 and they work just as well as they always have, but always try to use an Application instead of a Package because it will save you time and give you more functionality.
First, the intelligence built into the application for Requirements, Dependencies and Detection Methods has eliminated 90% of the scripting I use to do for SCCM 2007. Sometimes I think back to the good old days of spending hours editing scripts in notepad, then I remember they weren’t really days, they were usually nights when I would rather be home doing something else. It simply takes less time to use the tools built into SCCM than it does to recreate the wheel.
Second, the more applications you have, the better they work together. To use dependencies to install prerequisites, you need the prerequisites to be applications. To have your full install only run on a user’s primary device, you need an application. The list goes on, but the point is Microsoft built new functionality into the Application Model, and a lot of that functionality simply does not work with packages. You’ve already paid for all the shiny new stuff, so you might as well start using it.
2. Get install documentation.
Trust me, there is documentation. It may be as little as one paragraph from the vendor, or it could be the 127 page novel a coworker wrote on all of the word processor installations used in your organization over the last 18 years. Whatever it is, find it and make sure you understand it before you start packaging. If you don’t, you will find yourself repackaging a lot of software to meet “new to you” requirements.
3. Look around before you start packaging.
Unless you are packaging custom software, chances are that someone else has already packaged the application. Do some searches on sites like ITNinja.com to see how other people have handled the same application. Even if you can’t find an exact match to the version you are packaging, you can always try the methods used for other versions because most of the time the install options do not change much.
4. Stay as close to a default install as possible.
Whenever possible, you want to stay as close to the default install as possible. There are a lot of highly customized environments out there that use tools like AdminStudio to repackage applications specifically for their environments, and it works well. However, when you customize you introduce the risk that your customizations will cause problems with application updates and future versions. In general, if the customization is not required for the software to function (such as the name of the server the application must connect to) or if it is set on less than 90% of the installs, it is a good idea to start asking questions about if it is really needed or is it just how it was been done in the past. If it is really needed, then go ahead and include it. Otherwise you can save yourself time now and in the future.
5. Test outside of SCCM first.
This is the most important step for efficient troubleshooting. There is enough that can go wrong installing software through SCCM that you only want to have to troubleshoot SCCM, not SCCM and the application at the same time. I recommend first going through a manual installation and use that as a point of reference for packaging. When you have your application ready to load into SCCM, try running it from an Administrative Command Prompt. This will simulate the way SCCM runs install and it is easier to identify missing files and syntax errors here, then when everything is running in the background through SCCM.
These five things don’t cover everything for application packaging, but they will set you in right direction for any applications you need to package.
Thanks for reading my SCCM Best Practices series. If you have any of your own best practices you would like to share, please leave a comment or send me an email at: email@example.com