ConfigMgr 2012 Application Deployment By Example: User EXE Deployment

Scenario: Deploy an application using the new application deployment capabilities of ConfigMgr 2012.

Criteria:

• Native install using EXE installer (instead of an MSI based installer)
• Deploy to all users in a specific AD security group
• Support uninstallation

The first nuance to the criteria is that we are deploying the application to users. For this to fully work properly, the application and application installer must support per-user installations. This is often not the case for EXE installers, but many do now support this. Without per-user installation support, the application will be available to every user on the system instead of just the user(s) we are deploying to. This may be acceptable, but is not the intent of this example. Accordingly, I have chosen FileZilla which does come in an EXE installer and does support per-user installation.

1. AD Targeting

Identify the users to deploy the application to and create an AD security group if necessary. For this, I will use an existing security group named “Bagginses” that contains Bilbo and Frodo:

2. Resource Discovery

Ensure that Active Directory User Discovery and Active Directory Group Discovery are enabled and discovering the target users as well as the target group:

Once Active Directory Group Discovery runs, it stamps the security group membership on each user object contained in the discovered groups.

3. Collection Targeting

Create a collection to contain just these users. Here’s the query for my “Bagginses” collection:

* Because Delta Discovery is enabled on both of my discovery methods and incremental updates is enabled on my collection, users newly added to the AD security group will automatically be added to the collection within about 15 minutes (5 minutes for delta discovery + 10 minutes for incremental updates). For this example, I created a new user and added them to the Bagginses collection; within less than 10 minutes, this new user was automatically in my collection – no updating or intervention needed. Note that enabling incremental updates on more than 300 collections is *not* recommended; incremental updates is a resource intensive task that will tax your site system if not carefully controlled.

4. Application Discovery

Install the application on a test system to ensure that you know the correct command-line to silently install the application per-user, to discover and test the silent uninstallation string, and to gather information on how to detect if the application is actually installed. Because this is a per-user install, make sure that you perform this test using a non-admin account and temporarily disable UAC so that auto-elevation does not get in the way.

These are three of the key, foundational features of the new application model in 2012: installation, uninstallation, and detection. If we were using an MSI, then no discovery is needed as these are all common for Windows Installers.

4a. Install command-line

Finding the correct switches for FileZilla was somewhat painful for a variety of reasons – poor documentation was the main one – but I finally settled on this for my install command-line:

FileZilla_3.5.3_win32-setup.exe /S /D=%appdata%\FileZilla\FTPClient

/S is for silent

/D is for target installation directory. This is a per-user install so going to the program files directory doesn’t line up with this requirement and would of course require a user account that is a member of the local Administrators group. A couple of other nuances with this option include the fact that the FileZilla installer UI doesn’t like environment variables (like %appdata%) and that the default FileZilla folder is FileZilla FTP Client (with spaces) but this command-line option didn’t like when I put quotes around the parameter so I had to compromise. Note that none of this has to do with Microsoft or ConfigMgr, but is still part of getting the task done and is why discovery and testing are important.

4b. Uninstall Command-line

This one was much easier because the FileZilla installer creates an uninstaller and a shortcut for it in the Start Menu so all I needed to do was use the command-line for the shortcut. This was also reflected in the registry at HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionUninstallFileZilla Client:

C:\Users\abcde\AppData\Roaming\FileZilla\FTPClient\uninstall.exe

One important change is to substitute the %appdata% environment variable for the corresponding part of the above path so that it is not user profile location specific and add the /S to make it silent:

%appdata%\FileZilla\FTPClient\uninstall.exe /S

4c. Detection

There are a variety of ways to detect whether an application is installed and so this may be subjective. For MSIs, this is as easy as querying the Windows Installer DB. For EXE based installers, there are a variety of ways to do it. In this case, I chose to do something similar to querying the Windows Installer DB: querying info displayed in Add/Remove programs (or the equivalent in Win 7). For FileZilla, this is the (user specific) registry key at
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\FileZilla Client and the registry value named DisplayVersion under the same key to verify the version.

4d. Testing

At this point, you should thoroughly test the above command-lines and application after installation to ensure it will work as expected.

5. Source File Preparation

Place the installation source files in your source repository, in this case, it’s just one file: FileZilla_3.5.3_win32-setup.exe. This location must be accessible via UNC to the site server where you are creating the application. For my environments, I always create a single, top-level shared folder with all things ConfigMgr available beneath it in a highly organized folder structure (more on that in another blog post).

Note: If the file was downloaded directly from the internet, it’s a good idea to remove any zone information in alternate data streams. This can be done with Explorer by opening the file properties and selecting Unblock, or by using streams.exe from SysInternals.

6. Application creation

Back in the ConfigMgr console, we’ll finally create out application.

– Navigate to Overview –> Application Management –> Applications in the Software Library workspace.

– Choose Create Application from the ribbon bar (or right-click context menu).

– Fill in the information in the Create Application Wizard according to these screenshots customizing as appropriate:

	Select Manually specify the application information.
	Fill in the fields appropriately.
	Fill in the fields appropriately.
	Create a new Deployment Type by selecting Add…
	Select Script Installer (Native)
	Fill in the fields appropriately.
	Provide the UNC path to the installation source files. Fill in the two command lines from the discovery: install and uninstall. Note that although FileZilla is a 32-bit app, we don’t need to run the installer or uninstaller as a 32-bit process on Windows 64-bit systems because this installer is a separate 32-bit process that will place all of the information needed in non-redirected locations. A look at when this is necessary in a future post.
	Add a detection clause so that ConfigMgr can detect previously installed instances, ensure that a new installation completes successfully, ensure that an uninstallation completes successfully, and to reinstall applications that have somehow been remove from a system/user where they are required.
	Based on the discovery, we are going to use this simple detection rule. It’s possible to get very complex here and to support a pseudo self-healing like Windows Installer does; to do so you would add many more d etections so that the application installer is run again if something is amiss like an executable or other files being missing.
	Fill in the fields appropriately. Ensure you leave it as Install for user.
	Nothing to see here, move along. There has been a lot of discussion on this one and some misleading information (some initially propagated by me, sorry) that you can use application requirements in place of collection targeting. That is a bad practice and not within the design scope. The main purpose of application requirements is to enable the ConfigMgr client agent to choose between multiple deployment types or limit the actual installation based upon some easily queryable and locally available (on the client) parameter. In this case, there’s nothing to add.
	No dependencies to add.
	All Done? No, that was just the end of the Create Deployment Type Wizard.
	Back to the Create Application Wizard.
	Now we’re all done.

7. Deployment

Finally, the last administrative step. Select your newly created application in the console and choose Deploy from the ribbon bar (or the right-click context menu). With application deployment, you are deploying the application, not the deployment type. Deployment types are chosen at deployment run-time by the client based upon the requirements and priority of the deployment types in an application. Here’s the screenshot tour of creating the deployment.

	Choose the collection for step 3.
	Add your content to a DP (or DP group) that is available and accessible to the client systems where this deployment will be applicable.
	Choose your intentions. In the spirit of the application model, I am leaving it as Available.
	Change the deployment’s start time if you don’t want it to be immediately available.
	Choose your notification preferences.
	Choose your alert preferences.
	Finished.

8. User Test Installation

Available, user targeted applications are available in the Application Catalog. This is a very good thing because users do not have to do anything for this brand-new deployment to shown in the Application Catalog as the user policy will be dynamically accessed directly from the MP when the user opens the catalog.

Other Notes and Comments

• UAC is still a factor in this because the installer was run with the user’s credentials. I honestly don’t know if this is an issue when using a Windows Installer based deployment type or not. Another future blog post.
• Using FileZilla for this example worked well except that the installer automatically detects whether the user is a local admin or not. If they are, it doesn’t do a per-user install and so the detection method I used above doesn’t work. Unfortunately, there is no way to force the per-user install from the command-line. This didn’t become evident to me until I first tested the deployment out. I don’t think there is a good work-around for this except to re-package the installer as an MSI. Fortunately, FileZilla is a simple application so that wouldn’t be a big deal; however, for a more complex app, that could be a big deal. Another solution is to use App-V and virtualize it (subject of another future blog post – I think that’s four so far).
• I saw irregularities with the Uninstall being properly detected – I’ll need to do some more testing and follow-up with the product group on that.

Thanks to Marty List for reviewing this post for me and adding/correcting a few things!