Spoon Server to publish older versions of Internet Explorer

In today’s blog I want to discuss about that occasional need to use an older version of Internet Explorer. I know that some of you might read this and think “who the heck needs an older version of IE?”, but believe me I must be asked this every other week – I do not kid you!

It all comes down to one thing: unavoidable business web apps that did not evolve as quickly as Microsoft spits out new versions of IE.

I know some of you worked around this by installing an older version of Chrome or Firefox and that worked just fine. But it might happen that some of your users absolutely need to access this very old government web site and nothing else but IE7 works. You’ve already migrated everyone to IE10 and even started to roll out IE11, but this site must be access by these 15-20 users – there’s just no way around this. I say “government web site” because it happens that many of their infrastructures are known to be outdated and don’t update very quickly for a multitude of reasons – but I could as well have said the same thing about some in-house development or some supplier provided product that stalled in its evolution, and you have to somehow make do with it, no matter what you think of it.

No 2 versions of Internet Explorer can co-exist on one single machine (I know, Duh!), and it’s well known that using AppV to virtualize any version of Internet Explorer is a shot in the dark. Microsoft also states that you cannot do it, and if you happen to make it work (I know some people have made it worked to a certain extent), forget about any form of support from them! So what do you do? You roll back Internet Explorer versions on those user’s PCs until you get that site working as you want? That’s certainly feasible but these users will mostly miss out or behave poorly with other more recent web sites.

There are different options for you, depending of what your infrastructure is made of: RDP, Citrix, rollback to a different version of IE for users who absolutely need it, but did you consider a “Spoon Server”?

I was first made aware of the product Spoon (spoon.net) by Rory Monaghan (@Rorymon), a fellow blogger. Please go check his most-excellent blog, if you don’t know him already, at http://www.rorymon.com/blog/.

Spoon (http://spoon.net) is a rather new company that developed a small client utility to connect to their online repository of pre-virtualized apps – and it all happens in the cloud! Nothing else but the Spoon plugin to install on your Windows PC and you can even access many applications absolutely free of charge – check out their public repository of apps at https://spoon.net/hub/. For a few dollars a month, you can also access private repositories of applications, most particularly what they call the “Browser Sandbox Repository” (https://spoon.net/browsers) where you will find a very impressive list of browsers and versions. This is particularly useful to web app developers that wish to test their app against different browsers.

More recently, Spoon came out with its Spoon Server product for companies that wish to operate within a more private context (aka: not from the cloud). This solution is a bit more expensive than the cloud version one, but can possibly answer your user’s needs should they require to handle sensitive data using the virtualized apps.

Installing and maintaining a Spoon Server solution is quite straight forward:

• Start by downloading the latest version of Spoon Server from https://spoon.net/server and install it on a Windows Server 2008/2008 R2/2012.
• Make sure you have ports 80, 81 and 443 opened on that server for users to stream applications, and for you to manage the Spoon Server remotely;
• Create user accounts or use the LDAP option to connect to your enterprise’s Active Directory;
• Download and publish and the virtualized application needed from spoon.net (also referred to as “containers” or “.svm files”);
• Download and install the Spoon plugin on the Windows PC that need it and configure it to connect to your Spoon Server;
• Configure which user account will access which virtualized application;

…and you’re done!

patrick@softomatic.ca

514-992-6442

image: Festival Montréal En Lumières

February 16th to March 1st 2015

web site: http://www.montrealenlumiere.com/home.aspx

(Updated 2015-01-15) Download and Test Latest most common Redistributables for your Windows Desktop

Downloads

Adobe Flash Player – http://www.adobe.com/products/flashplayer/distribution3.html

Adobe Shockwave Player – http://www.adobe.com/shockwave/download/alternates/#sp

Adobe Reader 11.0.x (FTP site) – ftp://ftp.adobe.com/pub/adobe/reader/win/11.x/11.0.00

Adobe Customization Wizard and ADMT Template (FTP site) – ftp://ftp.adobe.com/pub/adobe/acrobat/win/11.x/11.0.00/misc/

Apple Quicktime – http://www.apple.com/ca/quicktime/download/

Apple iTunes – http://www.apple.com/ca/itunes/download/

Microsoft DirectX 9.0c (later versions are now covered through Windows Update) – http://www.microsoft.com/en-in/download/details.aspx?id=34429

Microsoft .Net Framework 1.1 – http://www.microsoft.com/en-ca/download/details.aspx?id=26

Microsoft .Net Framework 3.5 (containing .Net 2.0 sp1, 3.0sp1 and 3.5sp1) – http://www.microsoft.com/en-ca/download/details.aspx?id=21
http://www.microsoft.com/en-ca/download/details.aspx?id=22

Microsoft .Net Framework 4.0 – http://www.microsoft.com/en-ca/download/details.aspx?id=17718

Microsoft .Net Framework 4.5.1 – http://www.microsoft.com/en-ca/download/details.aspx?id=40779

Microsoft .Net Framework 4.5.2 – http://www.microsoft.com/en-ca/download/details.aspx?id=42642

Microsoft Internet Explorer 11 (for Win7)- http://www.microsoft.com/en-ca/download/details.aspx?id=40902

Microsoft Internet Explorer Administration Kit (IEAK) 11 – http://www.microsoft.com/en-ca/download/details.aspx?id=40903

Microsoft Live Essentials (Movie Maker, Photo Gallery, OneDrive, Messenger, Write, Parental Controls) –http://windows.microsoft.com/en-US/windows-live/essentials-install-offline-faq

Microsoft Visual B/C++/F#/J# Redistribuable x86/x64 library bundle – http://www.wincert.net/forum/topic/9790-aio-microsoft-visual-bcfj-redistributable-x86x64/

Microsoft Silverlight – http://www.microsoft.com/getsilverlight/Get-Started/Install/Default.aspx

Windows Help Program (to have Windows open legacy .hlp files) (WinHlp32.exe) – http://support.microsoft.com/kb/917607

Google Chrome (MSI) – https://www.google.com/intl/en/chrome/business/browser/admin/

Mozilla Firefox – http://www.mozilla.org/en-US/firefox/new/

Oracle/Sun JRE / JDK – http://www.oracle.com/technetwork/java/javase/downloads/index.html?ssSourceSiteId=otnjp

Tests

Adobe Flash Player – http://www.adobe.com/software/flash/about/

Adobe Shockwave Player – http://www.adobe.com/shockwave/welcome/

Microsoft .Net checker (from Raymond.cc) – https://www.raymond.cc/blog/download/did/1741/

Microsoft .Net Version Detector (from ASoft) –http://www.asoft-ware.com/download.php?id=11

Microsoft DirectX – http://support.microsoft.com/kb/179113#which version installed

.hlp sample file – http://www.softomatic.ca/sample.hlp

.chm sample file – http://www.softomatic.ca/sample.chm

Microsoft Silverlight – http://www.microsoft.com/getsilverlight/Get-Started/Install/Default.aspx

Oracle Java (JRE) – http://www.java.com/en/download/installed.jsp

Patrick@softomatic.ca
514-992-6442

photo: Blackstrap BBQ (http://blackstrapbbq.ca/)

taken from “La Bouche Pleine” blog (http://bouchepleine.com/)

SCCM2012: Deployment Types Priority Order and Requirements

Another recurring question is “How to organize your many deployment types for a single AppModel when each of them has a different set of requirements associated with it?”.

This is a very good question and you have to know your environment well and understand SCCM’s behavior, particularly when you have more than two Deployment Types to handle. In fact, the more Deployment Types you have for a single AppModel, the harder it is to wrap your head around a solution for it.

The key to this resides in the priority order of your Deployment Types, and the thing to remember is to always arrange the priority order of your Deployment Types from the most specific to the most generic.

Here’s an example of what I mean:

Let’s say you have 5 Deployment Types for AppModel PGP Desktop v10.1.2, all of them MSIs:

Priority	Product	Package Description	Requirements
1	PGP Desktop 10.1.2	MSI x64 Fr	OS= French x64
2	PGP Desktop 10.1.2	MSI x64 En	OS=English x64 -OR- Chinese x64 -OR- Spanish OS
3	PGP Desktop 10.1.2	MSI x86 Fr	OS= French x86
4	PGP Desktop 10.1.2	MSI x86 En	OS=English x64 -OR- Chinese x64 -OR- Spanish OS
5	PGP Desktop 10.1.2	MSI x64 En – Finance Dept	OS=x64, AD User Group=Finance

As you can see, I have a mix of x86 and x64 software architecture, a mix of French and English editions, and one that has the mention “Finance Dept.”

Contrary to what is commonly understood, the behavior of SCCM is not to analyse each and every Deployment Type and select the one that best fit your client, but rather choosing the first one in line that meets the requirements you set starting off with priority #1!

I often state the case of one client of mine where the SCCM technician had placed a Deployment Type with no requirements at all at the #1 priority spot of an AppModel that had many other Deployment Types set. The result was that his entire environment ended up with the same Deployment Type everywhere, and all other Deployment Types for that specific AppModel were never installed. It is certainly of good practice to use a form of “catch-all” Deployment Type (aka: with no requirements at all), but you should always place it at the very last spot of your priority order: this way, all possibilities are always covered.

You also have to know your environment well to come up with the best strategy. Coming back to my example, let’s say that:

• This client has way more English speaking users (say 70%) that are already set with an English OS PC;
• A very small group of users (5%) work on Spanish and Chinese OS but are fine using the English edition of this software;
• That the rest of the users work on French OS but require using the French edition of this software. This is especially true in Quebec where regulations at the provincial level exist about this;
• The people of the Finance department absolutely have to use a specific English x64 edition customized to their needs (aka: with a Transform file) and this is controlled according to their membership to an Active Directory User Group simply called “Finance”. Notice the word “specific” here? That should have already ring a bell as to where this Deployment Type should be located in the priority order;
• 60% of your environment is using a x64 OS architecture; the rest (40%) being x86.

This would probably be a correct strategy to use:

Priority	Product	Package Description	Requirements
1	PGP Desktop 10.1.2	MSI x64 En – Finance Dept	OS=x64, AD User Group=Finance
2	PGP Desktop 10.1.2	MSI x86 Fr	OS= French x86
3	PGP Desktop 10.1.2	MSI x64 Fr	OS= French x64
4	PGP Desktop 10.1.2	MSI x86 En	OS=x86
5	PGP Desktop 10.1.2	MSI x64 En	OS=x64

Notice that

• The “Finance Dept” Deployment Type is certainly the most specific of the bunch, and should be set right at the top;
• Then follows: French x86 OS, French x64 OS;
• Finally, since the Deployment Types at positions #4 and #5 are the most generic of the lot, I’ve taken the liberty to clean up a little on their requirements side.  Since the English editions of the software should reach the majority of people (read: “most generic”), should it be English OS or Chinese OS or even Spanish OS, once the most specific are reached, only the requirements for software architecture should remain here.
• Optionnaly, I could even have had the requirement “OS=x64” removed completely for the last Deployment type (“MSI x64 En”) thus creating a form of catch-all option.

Of course, you might think that there are other combinations here that could have answered the problem as well, and by no means am I implying that my suggested strategy here is the one and only that prevails. My goal here is to make you see how to simplify things. Keep in mind that whatever you put in place one day, might only have to be supported in months from now – by you or even by someone else in your IT organization. The simpler it is set today, the simpler it is to support tomorrow.

So, to wrap things up:

• Take into account your environment specifications (and possibly regulations that might apply)
• Put a simple set of requirement rules to each Deployment Type to respond correctly and quickly
• Set the priority order of your Deployment Types based on the “most specific to most generic” rule

Happy St. Patrick’s day everyone!

Patrick@softomatic.ca
514-992-6442

Photo taken from: http://lentimages.com/st-patricks-day-parade-montreal-2014/

St. Patrick’s parade in Montreal: http://www.montrealirishparade.com/parade

Collections and Deployments Naming Convention in SCCM 2012

I promise, this one will be a shorter blog than all my previous ones! 🙂

Another challenge i’ve faced is the need to have an efficient Naming Convention for collections/deployments in SCCM 2012. 1300 products with a mix of device-centric and user-centric, install and uninstall, some forced (required) and some optional (thru Software Center) deployments.
And remember: you can never have 2 collections with the same name in your CM database, although 1 same program can be installed thru a variety of ways and behaviors.

Also, many different levels of technicians were going to be given access to the SCCM console, so this collection naming had to be explicit, easy to flow through and quick to find what you’re looking for.

For the 1st part, if you’ve gone through my Package Naming Convention, you’ll find your way in my collection naming since it’s using a very similar pattern:

• [Product Name] [Version] [Manufacturer]

Notice here that I’m reintroducing spaces. I’m not a fan of spaces when it comes to files and folders, but in SCCM spaces are less likely to give you a hard time then files and folders – so since I prefer that the collection name to be readable, spaces are welcomed back.

The 2nd part is where the magic happens: a serie of 3 letters that explains the target and behavior expected for each product collection:

• U or D to express a “User” or “Device” collection;
• A or R to express whether you want to “Add” or “Remove” a given program;
• F or O for a “Forced” (required) or “Optional” (thru the use of the Software Center) program;

Putting all these 3 letters together, and identifying them within parentheses at the end of the collection name brings a variety of results:

• (UAF)
• (UAO)
• (URF)
• (DAF)
• (DAO)
• (DRF)

What’s missing here? That’s right: (URO) and (MRO)!

Why? Because there’s no such thing as “Optional Removal” of a program with SCCM 2012. If a user installed a program himself using Software Center, he can remove it himself the same way. Try it to see: options get greyed out.

I then prepared all my collections using a mixed of Excel (Concatenate) and PowerShell on the SCCM Console and there I got close to 8,000 collections set in SCCM all looking like that (using Adobe Reader as an example):

• Adobe Reader 11.0.5 Adobe (UAF)
• Adobe Reader 11.0.5 Adobe (UAO)
• Adobe Reader 11.0.5 Adobe (URF)
• Adobe Reader 11.0.5 Adobe (MAF)
• Adobe Reader 11.0.5 Adobe (MAO)
• Adobe Reader 11.0.5 Adobe (MRF)

…OK, you’re right, that’s only the collection name. You then have your deployment to set accordingly to what the collection name is promising to do – but you get the idea.

Patrick@softomatic.ca
514-992-6442

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…

Patrick@softomatic.ca
514-992-6442

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