Google Chrome in AppV4

The following recipe is to help sequence Google Chrome using AppV v4.

This recipe is a mix of different things I found here and there from other Internet fellas, and some of my own.
I know many of you moved to AppV5 in the past year or so, but AppV4 is still widely used and there seems to be a general consensus on how Google Chrome can be trickier to do using AppV4.

If you’re still downloading Google using that same old EXE setup every regular dude is, stop right there and get/favorite the following URL:
https://www.google.com/intl/en/chrome/business/browser/admin/
This will get you the “enterprise” setup, already in an MSI format.

Once you’ve downloaded a copy of the latest Google Chrome setup in MSI format, start your reference computer (the one with AppV4 Sequencer installed on),
launch the Sequencer (but don’t start your capture yet!) an add the following exclusions to the sequencer:

  • \REGISTRY\USER\%SFT_SID%\Software\Microsoft\Windows\CurrentVersion\Internet Settings
  • %CSIDL_COMMON_APPDATA%\Microsoft\RAC
  • %CSIDL_WINDOWS%\Microsoft.NET
  • %CSIDL_WINDOWS%\Installer
  • %CSIDL_PROGRAM_FILES%\Google\Update
  • %CSIDL_WINDOWS%\Tasks

Also make sure to disable the following capture behaviour:

  • “Allow Virtualization of Services”

Start your capture as you normally would (for those purists out there that still make a case of weather it’s a MNT or VFS, this one should be a VFS sequence) and capture the Google Chrome installer by simply running the Google Chrome MSI file.

When I last did this (January 2015) the version of Google Chrome was 39.0.2171.99 and its installation was entirely unnattended, so it should install the same way for you too.

Once the installation is completed, delete the install setup sources by deleting all content under C:\Program Files\Google\Chrome\Application\[version]|installer\*.*; otherwise your AppV bubble will end up being double in size for no reason.

DO NOT LAUNCH GOOGLE CHROME AT THIS POINT!
I know you will be tempted to do so, but something happens at AppV capture time that somehow makes it incompatible with Chrome (haven’t found out what yet). If you do, you’ll see your processor reach 100% usage with many instances of Chrome running and nothing showing up on screen.

Edit both Google Chrome shortcuts – one on the “Desktop” and the other in “All Programs” – by adding the following switches to “Chrome.exe”:
–disable-bundled-ppapi-flash -no-default-browser-check –disable-direct-write http://%5BYourDefaultHomePageUrlAddress%5D

OPTIONAL: Create 4 registry entries (doesn’t always behave as documented by Google, but worth the shot):

  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\AutoUpdateCheckPeriodMinutes, Reg Type of “REG_DWORD” with a value of “0”.
  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\DefaultBrowserSettingEnabled, Reg Type of “REG_DWORD” with a value of “0”.
  • HKEY_CURRENT_USER\SOFTWARE\Policies\Google\Update\AutoUpdateCheckPeriodMinutes, Reg Type of “REG_DWORD” with a value of “0”.
  • HKEY_CURRENT_USER\SOFTWARE\Policies\Google\DefaultBrowserSettingEnabled, Reg Type of “REG_DWORD” with a value of “0”.

Stop the appV capture and complete your AppV sequence as you normally would.

When at the Editing Shortcuts wizard, you might end up with two sets of shortcuts. It seems like the AppV4 sequencer captures some temporary files. Keep the ones pointing correctly to the chrome.exe binary file by deleting the wrongs ones.

Also make sure the switches for launching binary “chrome.exe” are set correctly:
–disable-bundled-ppapi-flash -no-default-browser-check –disable-direct-write http://%5BYourDefaultHomePageUrlAddress%5D

 

Here’s the recap:

  • Download the latest version of “Google Chrome For Enterprise” (in MSI)
  • Set your Exclusions before capturing (1 registry, 5 folders and 1 service)
  • Start the capture
  • Install Google Chrome
  • Delete the setup files
  • Edit the Google Chrome shortcuts in order to have the special set of switches
  • Edit the 4 registry keys (optional but worth the shot)
  • Stop the capture
  • Delete the extra set of shortcuts (pointing on temp files)
  • Make sure the special set of switches was captured

And you should be done!

Cheers all!

Patrick Pepin
514-992-6442

image taken from: http://www.mtlblog.com/

blog title: “30 free things to do this february 2015 in Montreal”

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

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 26th 2014. If you’ve read it before, please move on to 3rd and 4th 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.

1st 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).

2nd 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
  • …                  .

4th 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

Deploy a revised AppV package in a snap using ConfigMgr12 (SCCM2012)

You’ve now been deploying AppV packages using ConfigMgr12 for a few weeks or months and mastered the whole process, but you’ve just received and important update to one of the products you sequenced. How do you go about updating all your clients with this new update?

I’m taking into account that you already know how to edit and update an AppV bubble (AppV4 or AppV5), and that you’ve tested this new package again and again; you’re just puzzled as to how to translate the deployment/update operation using ConfigMgr12.

Let’s start with identifying where, in your DML (Device Media Library), are located both of your AppV packages (the current one and the revised one).

DML-Audacity_AppAndDeployTypes

*Note: Always keep your current AppV package (aka “not-containing-the-update”) in case your revised package fails and you need to rollback quickly.

You’ll notice I always use a package release number in my naming convention to clearly identify the different evolutions of a product’s packages.

 

Now, in ConfigMgr, go to the Application’s Deployment Types section and make a copy of the current Deployment Type.

CM12-AudacityCopyDeployType

 

To the question “Do you want to copy this deployment type and add it to application?” answer “Yes”.

CM12-AudacityCopyDeployTypeConfirm

Then, change its name to reflect the package release number, then click “Apply” and “OK”

CM12-AudacityChangeNameDeployType

 

Then choose to Update Content on the new Deployment Type …

CM12-AudacityDeployTypeUpdateContent

 

…and make sure to enter/browse the location of your revised package!

CM12-AudacityDeployTypeContentLocation

 

Once done, make sure to Increase its Priority in the Deployment Type list…

CM12-AudacityDeployTypeIncreasePriority

 

… so it becomes “higher” in the list than the “un-updated’ AppV package.

CM12-AudacityDeployTypeIncreasePriority2

 

Finally, find your associated Collection, and choose “Client Notification > Download Policy”

CM12-AudacityCollectionDownloadPolicy

Note: Choose Computer Policy or User Policy according to your Device-Centric or User-Centric Deployment

Depending on the time delay you set for your ConfigMgr clients, they should get this revised AppV package in no time.

 

Need to rollback quickly? Change the Deployment Type priority again to have your old package higher than your revised package, and trigger the Client Notification > Download Client Policy again on the given Collection.

 

Summary:

  1. Create your revised AppV package (not shown in this document)
  2. Identify this revised package clearly in your DML, and keep your current package where it’s at (in case of rollback)
  3. Make a copy of the Deployment Type, and change its Name
  4. Update Content on this new Deployment Type and be sure to locate the revised package folder
  5. Change the Priority Order to have this new Deployment Type “higher” in the list
  6. Find the associated Collection, and choose “Client Notification > Download Policy”

 

Patrick@softomatic.ca
514-992-6442

Picture of the Montreal Jazz Festival, taken from thestar.com

http://www.montrealjazzfest.com/default-en.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/)

Windows 7 : Support for East Asian Languages (as in WinXP)?

For those who used to support Windows XP/2003 systems in other OS language editions than Asian languages, one very important feature when exchanging documents with different parties around the world was the support for « East Asian Languages ».

This option used to be located in Control Panal > Regional and Language Options > Languages :

SupportEastAsianLanguages

Now moving to Windows Vista / 7 / 8, this option can no longer found. In fact, the Control Panel > Regional and Language Options > Languages tab no longer exists!

You’ll be happy to learn that this option is now natively supported in Windows Vista / 7 / 8 / 2008 / 2008-R2 / 2012.

A good way to demonstrate the support for this is to :

  • find a web page with some East Asian characters in it
  • copy and paste a section of the asian characters found in notepad

The Asian characters should be displayed exactly as in the web page (and not replaced by a bunch of generic square box ASCII characters)

Patrick@softomatic.ca
514-992-6442

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