Automating & Distributing half a ton of software

Hints and Tips on software packaging, software distribution and AppCompat activities Patrick Pepin Montréal, Québec [email protected] Twitter: @softomatic

[soft-o-matic]

Check us out on WordPress...

[soft-o-matic]

Cost Savings by Rationalizing Software in the Enterprise

We all heard that it is preferable to keep a low number of software in an enterprise to keep integration and support costs down; but depending on the IT politics in place, economics and culture inside a given enterprise, it’s not always an easy thing to keep. For instance, not every IT department has a rule of “charging back” the different clienteles and departments for their purchases and services, and I’ve seen places where it really spirals out of control where department managers would just introduce any piece of junk software they found in the abyss of the Internet. I’m sure you noticed there’s just a gazillion of those, and the number keeps on growing every day!

Here are observations I’ve made often through different contracts: .There is always a someone that claims that he absolutely has to have a specific piece software for his department, although the enterprise is already positioned for another one that does similarly the same thing.

.There is always a someone to tell you that acquiring a specific software isn’t very costly, or, even better, free for the enterprise.

.There’s always someone that doesn’t want to upgrade the version of his software even if it’s dating back from the 90’s and there has been 10 major version updates since; or on the opposite, someone that wants the latest version of a software although the enterprise has not acquired it yet and doesn’t care that half of the company isn’t ready to move on to it yet.

So unless these people can justify that spending all the associated costs with the different software integration activities needed is still inferior to the benefits the introduction of a software product can bring to the enterprise, it should not happen.

"But what are the associated costs of integrating a single software in my enterprise?" Well, for this there is no magic number that exists for every organization, but if your IT department has a little history, you should be able to come up with an average cost.

I’m currently finishing off a big software rationalization for a big Canadian bank. Out of 24,000 PCs dispersed within 10 subsidiaries, and close to 50 geographical office locations, they were keeping a little more than 18,000 distinct software programs of different versions and editions. That’s close to 1 software program per PC!

Moving from Windows XP to Windows 7, we needed to know, before starting any work at all, what are the costs to keeping each piece of software solely from the point of view of integration and support? Well, simply put, we dissected all the different tasks that needed to be done, made an average of it, and we were all astonished by what costs the enterprise had to engage to keep every single piece of software it had.

Here’s an overview of the activities they have: .Software analysis .Documenting the installation .Packaging (automating or virtualizing) the software .Documenting the recipe for software packaging .Tests and QA .Communication with clients or project managers .Deploying software and debugging .Technical support .Software Patches/Updates analysis .Patches/Updates packaging .Patches/Updates Tests and QA .Communication to users and project manager for them patches .Deploying and debugging patches and updates .Removing software (License control or Software end of life) …etc

Taking into account that the average life cycle of software is about 36 months, find your average time worked for each activity, multiply it with the average hourly rate and you’ll have a pretty good idea just how much your average software costs on a 3-year term. So even if the software is a shareware / freeware and no license cost is attached to introducing it, your IT department can easily spend a few thousand dollars to make it available to users in the enterprise.

Coming back to that client of mine, we came up with the “magic cost number” of 10,000. That is: every single piece of software that gets through the door will be costing the enterprise 10,000$ for the next 3 years. That’s the cost of a small car. Multiply this with the 18,000 different software products you get the astronomic total cost of 180,000,000$. Even for a very successful bank, this is absolutely a nut-bar crazy cost when you think that this only covers software integration and technical support.

Of course, if you are part of a small enterprise, you might think my numbers are exaggerated and I’m the nut-bar crazy here, and that none of these nonsense integration activities are actually needed. In fact, for some people, “integrating a piece of software” only means putting the install binaries on a USB stick, go “sneaker-net” on the few PCs that need it, and install as you feel is adequate, and that’s perfectly fine. Each enterprise has it differently: not all have many geographical sites located far apart, and “normalizing an installation” might not be part of your vocabulary. Still, there are a number of activities involved, and if your company has a little history, you should be able to come up with a “magic cost number” too to better justify the introduction of a new software.

So, what are the different ways to go about this? There’s no shortcut way lf doing. I mean, you have to:

.Start with a complete software inventory, make a domestic database (aka Excel) and try to make some sense with it.

.Identify manufacturer, application name, version and edition, and optionally languages supported and software architecture (16bit, x86, x64, …)

.Mark all software that is not business related. Ex.: Games, Toolbars, demos, trials, …etc

.Mark all software for which a superior version is readily available in your enterprise. Ex.: we hade all Adobe Acrobat Reader versions from v.3 to v.11. We solely kept v.11

.Mark all obsolete software

.Regroup all software that do similarly the same thing and try to only keep one. Ex.: we had Jaws Pdf, Pdf995, CutePDF, Nuance PDF converter, Acrobat Writer Pro and Standard. We kept Nuance’s and Acrobat Standard v.11. This is also an opportunity to save on some software license costs.

.Then, involve the different departments of your organization and have them identify what products are “line-of-business” for them, meaning which software brings money to the company , and make sure that if any of these products were removed from earlier rationalizing activities you did, you bring them back into the list and never remove them again.

.Finally, still with your list of software, try adding the number of times each software is found on any given PCs in your organization and come up with scenarios where you would only be keeping products that are found on more than 1 PCs, more than 3 PC, more than 5 PCs, more than 10 PCs. These results will be very handy and you’ll be sharing your findings with your IT manager/director. Using your “magic cost number” to multiply with the different results (and with the original number of products found) should clearly show the savings for your enterprise and help in choosing which scenario to adopt (products only found on more than 1 PC, more than 2, more than 3, …etc).

Once you have your definitive list, you should review them with your different software suppliers and make sure you are no longer paying for software licenses and maintenance contracts for products you are no longer using; and also ask for a discount where you re-positioned the use of a single software (where you were originally having many different products that did similarly the same thing) since your volume has changed.

With this method, we went from a whopping 18,000 products to merely 1,300 products, a cost saving of 167,000,000$, not even taking into account cost savings from the software licenses we no longer needed!

I almost forgot: after showing these savings to your director, it’s probably a good time to ask for a raise…

[soft-o-matic]

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 Pepin

[soft-o-matic]

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!

[soft-o-matic]

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!