SCCM AppModel Detection Method by Registry

Something we came across this week is how the Detection Method by Registry in SCCM 2012 really works.

I’ll start by saying that I’m a big fan with this whole new Detection Method feature. I made a lot of scripting in the past to come around this functionality, and I was very excited when I first heard that SCCM 2012 was going to come with this option built right in. Of course, AppV and MSI packages, being treated natively by SCCM, make it even easier when it comes to detect the presence of these package formats on a given computer. But when there’s the need to use a « script-like » package (aka: other than MSI or AppV), you absolutely have to enter a way to detect the presence of such package.

I have to say that my current customer is very stubborn to use AppV or MSI every way possible – which is absolutely fine by me! When you’ve made packages in a « pre-MSI era » like in my case, MSIs and AppVs are such a charm! But we came across a problematic MSI package (graciously provided by McAfee) where we needed to update the Endpoint Encryption Agent but have been provided with a newer version that contains the exact same ProductCode GUID as the current version has, which is a no-no in Windows Installer best practices. We first had the idea to rename the ProductCode by generating a different GUID right in the MSI provided by manufacturer , but this is also not recommended particularly when a customer risks having his support voided by the vendor. The manufacturer has no intention to correct this mistake as they claim it is their way to have his clients avoid deploying two (2) different versions of their agent (it’s crazy how so many people have no idea how the UpgradeCode property works).

Anyway, we had to treat this MSI with SCCM2012 as if it were a « script » package format and had to come up with a Detection Method which we found a registry entry for. This is where we stumbled!
Something we thought would be fixed in seconds got us to dig a little deeper. In fact, even books and Internet references had very little to say about this.

To summarize our findings, let just say that the way Microsoft uses the registry terminology in SCCM2012 is not quite accurate.

Let’s take the following fictitious as an example:

They way Microsoft refers to each of these registry components:
• HKLM\SOFTWARE\VMware, Inc.\VMWare Tools = the Registry Key
• InstallPath = The Registry Name
• REG_SZ = the Registry Type (or Registry Data Type)
• C:\Program Files\VMWare\VMware Tools\ = the Registry Data or Registry Value

So, now looking at the Detection Rule by Registry Clause and trying to fit our chosen Registry entry for our problematic MSI:

Our first reflex is to think that the “Value” field located in the middle of the Clause window really means the “Registry Value” (or “Registry Data” depending on how you call it), which forces us to think that the Registry Name should be appended to the complete Registry Key.

The result was really not what was expected: SCCM kept reinstalling the updated version Endpoint Encryption Agent again and again, never finding the given registry key.

Reflecting on how this Detection Method by Registry really works, we’ve re-disposed the different registry information as such:

• « Key » = The actual Registry Key as it should be referred to
• « Value » (the one in the middle of the Clause Windows) = The Registry Name
• « Data Type » = the actual Registry Data Type
• Then : choose your « Operator » (we used the « Equals » for our specific need here)
• And finally the last « Value » field at the bottom = the actual Registry Value

And that works just fine!

Patrick@softomatic.ca
514-992-6442

Example of Naming Convention For Packages – Part 2 of 2

Now that we have our “application part” out of the way, it’s time to tackle the rest which contains all other product and package details, such as: software architecture, language, package format, targeted platform, targeted department or service, …etc. Again, since this should be equivalent to how your AppModel in SCCM2012 will look, this part should reflect your Deployment Types section.
This part is a bit trickier: some of the package details are constantly required and some subject to exceptions, while others are rarely used particularly when it comes to targeted platform and targeted department.

2nd Folder Level:
Let’s start this off by covering the three main details that are always required and in order of importance (according to us): package format, software architecture and language. Keep in mind: we want to keep this consistant with the way SCCM2012 handles the different types of packages.

Package Formats:

• _Src: Keep a copy of your original software sources as they were provided to you
• MSI: Anything Windows Installer, should it be MSIs, MSTs, MSPs and all associated cab files and external files that is triggered by a Windows Installer mechanic
• AppV45: Anything concerning AppV 4.5. You want to keep a close eye to these packages, particularly knowing that you’ll have to eventually convert them to AppV 4.6 or AppV5 because of compatibility / co-habitation existing only with Appv 4.6sp2 and 5.x clients
• AppV46: AppV 4.6 sp2
• AppV5: AppV5 (surprised?)
• MISC: Everything else. Could be a batch file, a vb script, a command-line, a setup.exe followed with arguments …etc

*exceptions: We did amend these by adding “-64” a few times during our last 18 months or work. This was mainly to differenciate between an x86 software installed on an x86 platform and that same x86 software installed on an x64 where existed some differences. Many of the Adobe products part of the CS5 / CS5.5 got in that category, although that corresponded to less than 1% of the lot (approx. yield: 2,000 packages).

Software Architecture:

• 16bit: Yes, they still exist and you are sometimes doomed to make do with them. We also labelled as 16bit all products that even had as little as one 16bit component in them, such as a driver for instance. They’re often the result of a lazy developer (did I dare say that?) that didn’t look for finding / developing the equivalent x86 component. Again, try to have your customer upgrade this to an updated version of the software, and if not keep in mind that a Global Condition might have to be set as this product will most likely fail to install on a x64 box.
• x86: Most of the programs we use today are still in this architecture, and will most likely work on a x64 platform – except if they have a 16bit component in them. You might want to consider labeling them as “16bit” if they are not compatible with your x64 targeted platform. Note: Some customers prefer to label this as “x32” instead of “x86” – which is absolutely fine as long as you are consistent using always the same identifier.
• x64: Any x64 software. *Exceptions: We came across a couple of products (ie: McAfee) where the main launcher was a setup.exe which contained both x86 and x64 sources in them. The resulted category ended up being “x86x64”. You could also choose to “duplicate” the source in this case and treat them as separate packages to avoid amending your naming convention, but then you’ll have to support the evolution (patches, upgrades and removal / replacement) of 2 packages instead of just 1.

Language:
This is the less understood category and brings constant discussions within an IT group. The application of this label should be adapted to your customer’s culture. Do you list ALL languages available for a given software, or just the default language in which it is installed with? Do you want to let the users know if they can change the software language themselves by manually changing a setting in a menu, or if the software language changes automatically according to the OS UI (preferred UI language)? Nonetheless, this demands to sit with your customer and come up with the best strategy for this. Also keep in mind that very few IT dept. keep a high level of language details when it comes to software and, as perfect you would like this to be, it will be a hard thing to keep up with.
In reference with that same customer I was previously talking about, we concluded that 90% of their staff work in French, more than 9% work in English and less than 1% work in a language other than French or English (Arab, traditional Chinese and Spanish). After going through their entire list of software, it became obvious that the way to go was gonna be:

• Fr: For products strictly installed in French
• En: For products strictly installed in English
• ML-Man: For products that contain both French and English UI where the user can change manually the language UI himself
• ML-Auto: For products that contain both French and English UI where the software UI follows automatically the OS “preferred UI language”
• Ch: For products strictly installed in Traditional Chinese
• Ar: For products strictly installed in Arab
• Sp: For products strictly installed in Spanish

A forth optional token:
We kept an ace in our sleeve with this naming convention, and we call it the “optional token”. Put it simply: in case you have a package meant for a specific platform, specific department, a specific feature installed or else, this is where it should be flagged. We had the following previously identified should we need them:

• WinXP: specific to be deployed on a Windows XP machine
• Win2003: specific to be deployed on a Windows 2003 server
• Win2012: specific to be deployed on a Windows 2012 machine
• HR: specific to be deployed to people of the HR department
• Accounting: specific to be deployed to people of the Accounting department
• …etc.

As long as you get a short identifier thats explicit to what it’s meant for. You get the idea.
Again here, some of the same small tweaks that make it work better:

• Avoid accents or special characters
• Remove spaces and change every first letter of every word with an upper case . Use the underscore solely to differentiate Package Format, Software Architecture and Language (and the “optional token” when present)
• As for the language, you might want to refer to a 2-character language standard to keep this tight

Putting it all together, these are the folders you’ll see, in that specific order, if you look at what’s contained in the WinZip_16.5_Corel top level folder:

• _Src_x86x64_ML: in which we have a big self-extracting EXE file provided by rhe manufacturer which in turn has the x86, x64 and many language sources for WinZip v16. The leading underscore (“_”) character make this folder show up at the top in alphabetic order.
• AppV5_x64_En: AppV5 package in x64 software architecture and english UI language
• AppV5_x64_Fr: AppV5 package in x64 software architecture and french UI language
• AppV5_x64_Fr_Finance: AppV5 package in x64 software architecture and french UI language, specific for the Finance department which is installed in a way that WinZip encrypts solely in 128bit. Instead of putting “Finance” as the optional 4th token, we could have identified this as “128bitEncryption” instead.
• AppV5_x86_En: AppV5 package in x86 software architecture and english UI language
• AppV5_x86_Fr: AppV5 package in x86 software architecture and english UI language
• AppV5_x86_Fr_Finance: AppV5 package in x86 software architecture and english UI language with that same 128bit encryption support described earlier.

Now that we got the Folders and Files part of the way, my Next Post: How you should name your actual Deployment Types in SCCM2012.

Patrick@softomatic.ca
514-992-6442

Example of Naming Convention For Packages – Part 1 of 2

Now here’s a subject on which we get to talk often with different clients.

I myself have came up with many different varieties in the last 15 years and every year that goes by brings a new technology that brings a new twist to this. Should it be MSIs vs AppV4.6 vs AppV5, x86 vs x64 architecture, some French products, some English products, some multilingual products: you’ll find a new surprise at every turn and you’ll keep making amendments to what you thought was the best naming there can be.

Now I have to say that the latest naming we came up with for one of our very big clients (54,000 desktops and more that 2,000 applications) really got us to tweak this very efficiently. I also have to mention that SCCM2012 really made it easy for us since the way Microsoft has organized it’s AppModel (Application vs Deployment Type) in an almost-flat fashion can be mimicked at folder level. I can say that 18 months and 2,000 packages later, this naming convention really paid up big time for them.

Let’s start by talking about SCCM2012’s AppModel: with the variety of computers we now have, Microsoft understands that it’s important for a desktop administrator to assign a computer (or a “user” in a user-centric approach) to an application, but more so to install the correct package for this given application depending on a number of factors such as computer architecture, OS language, primary device, …etc. What was previously done using scripts, launchers and wrappers, is now mainly done by creating more than 1 package for a given application, called a Deployment Type in SCCM2012, and setting an order and applying different sets of conditions for each.

As an example: you could assign Joe to WinZip v16, but depending on the PC Joe connects to he could receive the x86 or the x64 version, the French or the English edition, the MSI or the AppV5 one. In this same example, WinZip could be offered in 8 different ways: x86 French MSI, x86 French AppV5, x86 English MSI, x86 English AppV5, x64 French MSI, x64 French AppV5, x64 English MSI and x64 English AppV5. Now this is an extreme example, but in some environments it is certainly possible to find as many as 8 Deployment Types (or even more) for a single application. All of this justifies the need to come up with a solid naming convention prior to even start packaging. Don’t hesitate to invite your colleagues to “play for the red team” by bringing real-life tricky examples against it and try to punch holes in your newly found standard.

My 1st Folder Level: Since this has to work by folder structure, let’s start by looking at the very 1st folder level. Referring to the way SCCM organizes its AppModel, this first part should only contain basic information relative to the application itself. We found that 3 pieces of information are really important here: Manufacturer, Application Name and Version. To be really efficient here, you should put them in order of importance, which we found to be: Application Name, then Version, and then Manufacturer. The main reason we found that the Manufacturer made more sense being put right at the end was mainly because companies change of names, get bought out or merge with one another. As for the Application Name, even in company buy-outs/renaming/merger, the Application Name often remains as it is the way we rely to the product. It’s a branding and history shown that it doesn’t change as often as the manufacturer’s name. Having the Manufacturer at the very first part of your naming will most likely get your alphabetic ordering messed up when a change in name occur in between versions.

An example of this is again WinZip. Their version 15 was manufactured by WinZip Computing LLC, while their version 16 is now manufactured by Corel. Getting your manufacturer at the beginning would have your version 16 show up way earlier in your list since Corel starts with a “C”, while your version 15 would show up at the very end with the “W”s. Now remember that early in your packaging activities, when you have say 50 or even 100 products listed, this whack in the sorting in not so dramatic; but a few months or years from now when you have over say 1,000 products and packages, sorting plays out a great deal, especially when many different people need to browse / find products in that listing of yours.

Small quick tweaks that make it work better:

• Avoid accents or special characters
• Remove spaces and change every first letter of every word with an upper case
• Use the underscore solely to differentiate Application Name, Version and Manufacturer
• Avoid repeating the Manufacturer name in both Application Name and Manufacturer
• Keep popular versionning format rather than the less known one (Ms Office 2013’s real version is 15.0.2703.1000, but who else knows this but you really?)
• Try to keep a reasonable number of characters: Enough to be easy to read, but not too many to risk busting the “256 characters limits” when importing your packages in SCCM (Yes, the limit still exists!)

Here’s what it looks like when adding some products:

• AcrobatPro_11.0_Adobe
• AcrobatStd_11.0_Adobe
• Chrome_17_Google
• Chrome_28_Google
• DotNetFramework_4.0_Microsoft
• OfficeProPlus_2013_Microsoft
• Quicktime_7.7.4_Apple
• WinZip_15.5_WinZipComputingLLC
• WinZip_16.5_Corel
• … And it looks even better with a lot more products!

Patrick@softomatic.ca
514-992-6442