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!
Have you figured out the uninstall irregularities with the use of uninstall executables? I know exactly why this is happening but havent found a work around for it. This happens with all of my applications that use uninstall exes.
-Rob
Yep. It happens because the exe spawns another process that actually performs the clean-up and then exits. So, the called exe is just a wrapper; however, ConfigMgr has no way to know this and only knows about the wrapper and not the spawned process. Thus, when the wrapper exits, ConfigMgr thinks the uninstall is finished and it runs the check for the condition but because the spawned process isn’t finished yet, the uninstall hasn’t finished and thus the condition isn’t fulfilled yet.
The recommended work-around is to wrap the uninstall in a script/batch file which you can include in the package) and add a 5-10 second delay after the uninstall command so that by the time the batch/script exits, the spawned uninstall process is also finished and the condition will thus evaluate to true.
Sounds like I need to get writing a new blog post 🙂
Your article does not address how to deploy a package that calls a local file. I am trying to get such an application to work but it does not even show up in software center. My initial requirement was only that it be windows 7 or 8. Ultimately it will also have to run based on a reg key being set but it just does not show up so it is not available to the user to run and I can not make it show up despite the fact that it looks like it should.
Hi Jim,
Not sure what you mean by a local file? What exactly are you trying to do. If you aren’t actually installing something, then you shouldn’t (IMO) be using an Application. If the installer is already local though, just put in the proper command-line including the local path just like you would if calling it manually from a command-prompt.
Also, that has nothing to do with deployment visibility in Software Center. Sounds like you have two separate issues but without more details, I can’t provide much help.
I have a program that can only be installed as user when the user is logged in.
it runs fine from a command line
When packaging it to run from SCCM, we get an error, because the user does not have permissions to the ccmcache directory.
So we package again, have a prerequisite file that copies the file to the user/appdata/local/temp directory. In the package, we set “Start In” directory to that. But the command line created is still calling from the ccmcache?
What on earth is going on? I’m not an SCCM guru, but this particularly does not make sense.
I think that you’ve posted something similar on the TechNet forums that Nash responded to. As he noted, don’t use the start in parameter. The current working directory is already set correctly and does not need to be modified. Also, why are you copying a file to the temp directory instead of just running it from the ccmcache (which is where it’s copied to)?
User does not have permissions to expand the components in the exe into ccmcache.
OK, but why is anything trying to be extracted to ccmcache? Is that what the Installer is doing itself is doing?
The installer expands itself into the current directory, temporarily, and runs 3 sub component installers in sequence based on commandline switches. All installers must run under the logged in user because they associate with the users outlook profile.
So, is this a home-grown installer? I rarely (if ever) see one extract files to the current directory — they typically extract to %temp%.
Hi Jason – any further thoughts?
Hi John,
Where did this installer come from? It’s making a very bad assumption and whomever created should be corrected.
Off the top of my head, I’d say the best option for you is to copy the installer to %temp% and then run it from there. You can easily do this using my copy files to local system script (http://blog.configmgrftw.com/copying-files-to-clients-using-configmgr/) and simply add one line to the end of the script to execute the installer with the appropriate command-line.