Deploying Office 2010 with Configuration Manager 2012 Beta 2

The new application model in Configuration Manager 2012 will require administrators to study up on how best to deploy software – this isn’t anything like traditional software distribution like you would find in ConfigMgr 2007.

I recently set up Office 2010 as an application in ConfigMgr 2012 Beta 2.  Here are the steps I used – not necessarily the only way to do it, but it worked for me.

Create the application

First you need to create a new application.  If this were a simple MSI, you could just choose the MSI file and the whole process would be simpler.  But Office 2010 is a little different than your typical application, so we need to manually define the information.

Specify general information

Now you need to specify some general identification and ownership information.  This information is primarily for the ConfigMgr administrator’s use, as the end user can see different information in the software catalog.

Notice the “Allow this application to be installed from the Install Application Task Sequence Action without being manually deployment” checkbox.  If you are planning to have MDT install this application dynamically in a task sequence (by specifying the application name in CustomSettings.ini, e.g. Applications001=Office 2010), you will need to check this box.

Specify how it should appear in the software catalog

ConfigMgr provides a software catalog, the Software Center, where end users can choose from optional applications (deployed as “available”, i.e. non-mandatory).  You need to specify how the application should show up in the catalog – you can even specify different languages.

Add a new deployment type

The high-level “application” doesn’t say how to actually install the application.  That’s done by one or more deployment types (similar in concept to the old package/program concept, where one package can have multiple programs, but in this case each deployment type can have different content – maybe one deployment type is an MSI install and another uses App-V).

Again, because Office 2010 isn’t a typical application, you need to manually specify the deployment type details.

Specify the deployment type details

You need to give the deployment type a name.

Specify install and uninstall details

Now you need to specify the source files, the installation command line, and the uninstall command line.

Since we are deploying Office, the install command line is pretty simple, just specify SETUP.EXE.  This assumes that the package source contains an “Updates” folder with an MSP patch file that is configured to install Office without any user intervention.

The uninstall command line is a little harder to come up with – I just copied the command that Office placed in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Office14.PROPLUS or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Office14.PROPLUS on a 64-bit computer).  It isn’t very complicated, just specifying “SETUP.EXE /uninstall PROPLUS”.  (I haven’t actually confirmed that this command line works, so test appropriately.)

Add a new detection rule

ConfigMgr 2012 will automatically reinstall an application targeted to a computer if it detects that it is no longer present.  In order for this to work, you need to specify a detection rule so that ConfigMgr can figure out if it is still installed.

First add a new detection MSI detection rule.  In the case of Office 2010, you can check for the present of any of the MSIs that are installed by the Office Setup program. I usually pick the one for the main product, Office Professional Plus, as that uniquely identifies the specific Office SKU that is installed. You browse to the “proplusww.msi” file in the “ProPlus.WW” folder so that you don’t need to type in the MSI product GUID.

Specify user experience settings

Typically you want to install Office in the system content and whether or not a user is logged on (both are mandatory settings for the task sequence to install the application).  Neither of these settings are defaults, so be sure to change them:

There are a few more screens, but you can take the defaults for each of them.

Now you have successfully created the application, but you aren’t done yet.

Distribute content

The source files specified on the deployment type still need to be distributed to your distribution points.  (You don’t need to do each deployment type separately, just once for the application.)  There are different options you can choose for distributing the content.  In my case, I’ll just keep it simple and distribute it to every one of my distribution points (one of them):

Deploy

At this point, you are ready to deploy.  You don’t choose to deploy a specific deployment type.  Instead, you deploy the application itself.  It’s pretty simple in this case, with only one deployment type, as it’s fairly obvious which one will be installed.  But if you had multiple deployment types, you would need to specify rules to determine which one is used.

There’s no doubt that this will take ConfigMgr administrators some time to get used to – just one of the big changes coming in ConfigMgr 2012.g