Revisited: Example of Naming Convention For Packages – Part 2 of 2

I was recently hired by a Montreal-based company that merged with other offices located all around the globe. In their request, I have to look at the way things are being organized, especially with regards to naming conventions and its ability to define all language and environment combinations.

So here’s a revisited edition of my “Naming Convention Part 2 of 2”, originally posted on January 26^th 2014. If you’ve read it before, please move on to 3^rd and 4^th token which correspond to Languages and Environments.

– – – – – – – – – – – – –

Now that we have our “application part” out of the way  (see Naming Convention Part 1 of 2), 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 consistent with the way SCCM2012 handles the different types of packages.

1^st token – 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 differentiate between an x86 software installed on an x86 platform and that same x86 software installed on an x64 where some differences existed. 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).

2^nd token – 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.

3rd token – Languages:
This is the less understood category and brings constant discussions within an IT group. The use 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. After going through the entire list of software of this new client with offices throughout the globe, this is what we came up with.

Each language is to be referred to a 1-character code, all available languages at user-level are listed in this token and the first letter of the token should identify the default language at installation. Please notice ‘Multilingual’ (‘M’) that identifies a software that detects and switches to the System’s language automatically, and ‘Undefined’ (‘0’) where no language exists in a given packaged product (most likely an engine or set or libraries).

• Multilingual M
• Undefined    0
• English          E
• French          F
• Spanish        S
• Arabic           A
• Chinese        C
• Dutch            D
• German        G
• Italian            I
• …                  .

4^th token – environment:
This is another tricky one: We think a package should be meant for the masses, regardless of the working platform, office location, department …etc. With this in mind, we use the term ‘ALL’ in most cases, unless someone identifies the need for a specific setting requiring a different package for a smaller number of people in the organization. Should this case happen, the term ‘ALL’ should be replaced with whatever identifier best describes the special feature or targeted clients.

(Examples)

• ALL: Used most of the time as this package should serve the vast majority
• WinXP: specific to be deployed on a Windows XP machine
• MetricSystem: specificies that this edition was configured with settings for the Metric system (implies that the ‘ALL’ package edition is configured with settings for the Imperial system)
• HR: specific to be deployed to people of the HR department
• London: specific to the people of the London office
• …etc.

As long as you get a short identifier that is explicit to what it’s meant for.

• 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

Now put them all together, and these are examples of the folder names you could see, if you were to look at what’s contained in the, say,  WinZip_16.5_Corel top level folder:

(examples)

• _Src_x86x64_Mefs: in which we have a big self-extracting EXE file provided by the 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_Mefs_ALL: AppV5 package in x64 software architecture, containing English, French and Spanish languages available at user-level but installed by default in the language of the OS.
• AppV5_x64_F_Finance: AppV5 package in x64 software architecture and French UI language only, 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_x64_E_Finance: AppV5 package in x86 software architecture and English UI language only with that same 128bit encryption support described here above.
• AppV5_x86_F_ALL: AppV5 package in 32bit software architecture and French UI language only.
• AppV5_x86_E_ALL: AppV5 package in 32bit software architecture and English UI language only.

Now that we got the Folders and Files part of the way, see my other Post: How you should name your actual Collections and Deployments in SCCM2012.

 
Patrick@softomatic.ca
514-992-6442

the Montreal Zombie walk: http://montrealzombiewalk.com/en/

How to make an MSI package « Citrix-friendly »?

The current blog was made possible with the huge help of Jonathan Pitre. Jonathan is an awesome Citrix expert working in the Montreal area –
check out his blog: http://wasthatsohard.wordpress.com/ ;
and his twitter : https://twitter.com/PitreJonathan
– his inputs literally saved us many time around!

How to make an MSI package « Citrix-friendly »?
This question often occurs when working in an environment where both physical and virtual desktops (mainly XenDesktop) exist. Jonathan and I came up with a nice list of things to look for (or to avoid) when packaging and deploying MSIs to a Citrix environment. You might know of other criteria – if you do, please don’t hesitate to add them up in the Comment section here below – but we think you should cover most if not all your bases if you keep these in mind.

The criterias are split into 3 sections:

1. Product Pre-Analysis,
2. Packaging,
3. Distributing/Publishing,

…to which I added my own two cents on the importance of that criteria.

– PRODUCT PRE-ANALYSIS –

Check with vendor if the software product is supported on Citrix

Why : To get support in case something goes wrong

Importance : Depends on the severity of the given software product. Some vendors don’t even know what Citrix is, so you and your department be the judge of this…

Make sure your acquisition department purchased the « enterprise-grade » license

Why : Some software products have both consumer-grade and enterprise-grade licenses/agreements, and sometimes the consumer-grade license is not really functional in a multi-user /multi-launching context

Importance : “Nice-to-have”, but check the multi-user / multi-launching context beforehand. Then again, you might do a favor to your acquisition department: sometimes changing to the enterprise-level agreement is more favorable money-wise when you have an important number of licenses.

Check if a the software product has a contextual menu and is only licensed for a limited number of users in your enterprise

Why : You might have published an application so the main shortcut isn’t showing up to some users, but you might have forgotten that the software can also be launched using a “contextual menu” (ex.: by right-clicking on a file or folder, as in for WinZip) and yet not everyone is allowed to use it because of limited licensees. In this case, you might get your company/client in trouble.

Importance : Essential

Look out for software that makes use of video rendering

Why : This will literally hog your server resources

Importance : Check how pertinent it really is to have that kind of product onto a Citrix server with many users at once. Maybe this calls for a fat installation onto a dedicated glorified-PC/workstation solution for each user that needs this.

– PACKAGING –

Disable all automatic updates and automated online checks from the product

Why : A user should not be the one deciding when and how to update a software on a given server for everyone else; and even if he did, that server might be only one server of a greater farm of servers which will not replicate the update; and still, your Citrix box should be in a read-only state, so next time it reboots everything will be reverted to how it was previously. And to top it off, these kinds of update messages often generate calls to your helpdesk and should not be welcomed.

Importance : Essential

Remove all Services, Automated tasks (Scheduled Tasks/AT Commands) and AutoRuns

Why : Imagine if 50 users on a given server were each running a copy of a Service or kept re-running an Automated Task. Keep in mind that a Server literally serves many people at once (contrary to a dedicated PC) and the more of these Services/Tasks you allow on a server, the less concurrent users you will support on that server, opening the door to purchasing more and more servers.

Importance : Very important, unless the presence of a given Service is essential to the well-functioning of the software product. Sometimes these Services and Automated Tasks are simply meant the start up the main software a little bit faster than it would.

Avoid icons in the System Tray

Why : Another resource hog that has little use on a Server.

Importance : Very important, unless the presence of a given icon is essential for accessing specific functionalities of the software product.

Avoid Welcome screens and Configuration wizards

Why : Quicker access, Less resources used and Less support

Importance : between Nice-to-have and Very important

Never use ActiveSetup technology

Why : ActiveSetup is meant to populate user registry entries/config file in the user context before Windows Explorer gets launched. Citrix XenApp makes no use of Windows Explorer (so ActiveSetup will never get launched anyway); and the one server where the ActiveSetup is happening is probably of a much greater server farm which will not replicate to & the server “read-only state” it’s in makes this action useless. Find another mechanism in your MSI package to come around this user content.

Importance : Essential (depending on the importance of the user content to be copied)

Remove package content under c:\users\%username%\AppData

Why : An application on a Citrix box is meant to be shared among different users. Never target a single user when installing a software product.

Importance : Essential

Beware of application that hardcode content directly to the System Drive (often referred to your C: drive)

Why : The System Drive should be kept for anything related to the System and the System only; often a separated drive is reserved for anything related to “Applications”. Try to see if a configuration file for that given software product contains this setting, and try to modify it in a way to redirect the content to the Apps Drive instead.

Importance : Between “Best Effort” and “Essential”. Might need some “hacking” – so check with the vendor, see what’s his take on this hardcoding …

– DISTRIBUTING/PUBLISHING –

Run command “change user /install” before installing a software product

Why : To disable .ini file mapping to the home directory (ref.: http://technet.microsoft.com/en-ca/library/cc730696.aspx)

Importance : Essential.

Install the software product and all its dependencies on the same server

Why : Well … stating the obvious, but some people tend to forget this basic step …

Importance : Essential

 
Patrick@softomatic.ca
514-992-6442

 

Photo: Montreal’s Osheaga Music and Arts Festival

taken from: http://fr.canoe.ca/divertissement/musique/nouvelles/2013/08/04/21023531-qmi.html

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

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