What is the ideal software delivery experience? Apple figured it out initially with the iPhone and later with other products, and Microsoft followed suit beginning with Windows 8. The App Store and the Windows Store are curated, safe spaces from which to purchase and download applications, and these stores provide fantastic user experiences. (Other platforms have package management systems with varying features and capability, but I have no experience with those, and my focus is on Windows software deployment.)

With an app store, an application and all of its updates come from one place. Because all of the apps available there go through a validation process, users can feel confident that they are not downloading malware. The apps install without prompting the user for information, and they work immediately. If an app requires configuration, it prompts the user and can save the configuration to a cloud storage location so that the app is immediately usable upon whichever device the user runs it. Software just works, and users can quickly get to the business of using the software instead of installing and configuring it.

The Desktop Difference

Contrast this with the installation and usage experience for traditional desktop applications. I’m going to focus on software for the Windows operating system for the rest of this post. Here are some typical steps to installing and using software.

1. Find the desired software somewhere on the Internet and buy it. If it is free, hope that you were not tricked into downloading malware instead of the software you wanted.
2. Run the installer. This is probably an executable program that must be run with administrative credentials, so you are basically giving complete control of your computer over to the setup program.
3. Answer configuration questions asked by the setup program. You may not be confident in your answers or may not have any idea how to answer some of them.
4. Restart your computer and then spend 20 minutes re-opening all of your programs and browser tabs.
5. Notice that the installer has put one or more icons not only on your Start menu, but also on the desktop and on the taskbar.
6. Further notice that the notification area shows that the new program is already running, even though you didn’t specify this.
7. Run the new program, and answer additional configuration questions asked by the program. Again, you may not know the answers to these questions.
8. Take a tour of new features!
9. Dismiss a “Did you know…” pop-up message or maybe a new feature advertisement pane.
10. Actually use the program.
11. Realize that you also need the program on another computer, and begin the whole process again.

This may seem extreme, but all of the above behaviors are commonplace. If you decide to uninstall a program, you may have to go through these steps.

1. Uninstall the application.
2. Specify options for removal. Should all components be removed? Should data be removed? You don’t really want to uninstall the program, do you?
3. Complete a survey about why you uninstalled the application.
4. Restart the computer and then spend 20 minutes re-opening all of your programs and browser tabs.
5. Discover that some components of the application are still installed but that there is no way to uninstall them through standard procedures.

Here is a concrete example that I observed and recorded in early 2015. There is one particular program that nearly everyone in my organization wants that, when it installs, puts shortcuts on the Start menu, on the desktop, and on the taskbar. Then, even if you delete the desktop and taskbar icons, when another user runs the program, it recreates those icons in that user’s profile. It even uses (or at least did so in early 2015) an undocumented feature of Windows Setup to insert itself into the first-logon experience so that it can create these icons before the user has ever decided to use the program, causing a two-second delay in the first logon experience. Then, when a user actually wants to run the program, the first thing it does is try to take over being the default handler for its particular file type. When the program actually opens, it displays a tab with a tour of new features and tries to get the user to create an account with the manufacturer. This entire experience is bad enough for regular users, but it is truly horrible for lab or classroom environments in a school or university because every single user logon is probably that user’s first time logging onto a given machine. What is this malware, you ask? It’s Google Chrome.

It didn’t have to be this way. Microsoft has published application user experience guidelines for years and years, and it has also had a “Designed for Windows” logo program for software since the Windows XP days (2001) and perhaps even before that. Unfortunately, these guidelines and programs seem to have been largely ignored by software vendors and their customers. I have some ideas about why this happened and thus why software distribution is in such a sorry state today, but my purpose here is not to assign blame; rather, I want to discuss the problems and arrive at some principles to guide the creation of solutions. I think the Apple App Store and the Microsoft Windows Store are reactions to the resistance of independent software vendors to write good software; these app stores codify into “law” the kinds of behaviors that have always been prescribed by user experience and logo program guidelines and make them non-optional, since the operating vendor acts as the gatekeeper for what appears in the store.

The installation, usage, and uninstallation steps listed above are disastrous for large-scale rollouts of software in an organization. It is disturbing to consider the amount of money spent on wages to employees that are not actually doing any work because they are struggling with bad software. If something goes wrong, they will hopefully call the organization’s help desk for assistance; this may reduce downtime, but it requires that another employee be on the other end of the telephone line to help with the issue. If your organization’s IT and top management are even mildly interested in data security and keeping support costs low, most users will not have administrative access on their machines and will thus not even be able to install software themselves. This leaves the deployment to the IT staff using any number of deployment tools available on the market, but there is still a lot of work required to deploy software in a way that mitigates the behaviors described above. In organizations with hundreds or thousands of client computers, manual installation of software expensive and error prone, so we must rely upon software deployment tools. There are numerous deployment and package management systems available, but they cannot help fix the fundamental problems built into software vendors’ setup programs by design. That task falls to the IT professional.

Guidelines for Great User Experience

My goal is to make the desktop application installation and usage experience as close to the idealized app store experience as possible. To guide the work toward that goal, some reference documentation and some specific principles are helpful.

Microsoft provides some great documentation on the proper behavior of Windows applications throughout their entire life cycle—installation, use, and uninstallation. See the following resources at the Windows Dev Center for the most recent versions of the Windows application design and certification guidelines:

• Design applications for the Windows desktop
• Certification requirements for Windows Desktop Apps

Everything written by Rob Mensching or anyone else on the WiX Toolset team is also fantastic source material for the way installers ought to work. With that knowledge, we must then set about the task of bending the software to our will, as the tagline of this blog suggests, by fixing or working around the terrible installers published by software vendors, so that we can provide the app store experience to users.

Here is my list of guiding principles with explanations.

1. The software must be able to be installed silently—that is, without any user prompts. This provides that app store-like experience of one-click installation. It also makes it possible for IT administrators to deploy software without user involvement.
2. The software must be able to be installed without forcing the computer to restart. A forced restart could cause data loss, and that’s obviously unacceptable.
3. Eliminate all first-run experiences. This one is sometimes difficult. Many programs want to interrogate the user the first time they run, but this is incredibly frustrating for the user if the application is updated often or in public computing spaces where a user may never sign into the same computer twice (thus getting the first-run experience every time).
4. Don’t ask the user questions he/she cannot answer. This is a special case of first-run experiences, but it bears mentioning separately. In my observation, there is often a clear mismatch between the level of understanding a software developer expects a user to have about a piece of software and the level of understanding that the user actually has. Many applications ask users questions that they just don’t know how to answer.
5. As a consequence of the previous four principles, provide any required configuration information either in the application deployment process itself (preferred if possible) or through an outside mechanism like Group Policy or Group Policy Preferences.
6. Don’t allow an application to overwrite user preferences.
7. Don’t allow an application to put icons on the desktop or the taskbar. This is a special case of user preferences, since these locations are intended to be for the user to customize. The only appropriate place for an application to put a shortcut is on the Start menu.

Some applications will easily work within these principles. If an application is packaged as a Windows Installer package, you’re already in pretty good shape. Unfortunately, many are provided as setup executables, and these require a variety of techniques to tame. Future posts will focus on individual applications that are common to many organizations—specifically, free readers, players, and browsers—and how to package them in System Center Configuration Manager so that the user experience is as much like an app store as possible.

An Easier Way

There are commercial products available to take care of free apps. I know people that subscribe to one of these services, and they are very happy with it. There are several reasons why an organization may not be able to do this though. An organization that only needs one or two apps covered by one of these auto-updater programs might have trouble justifying the cost for so little benefit. There may be concerns about performance or the additional management burden of another agent program running on every computer in the organization. There may also be security concerns, legitimate or not, that result in blocking such a subscription.

In any case, free readers, players, and browsers are useful for exploring the ideas described above in the context of a specific deployment tool (Configuration Manager) and practicing the techniques needed to achieve the goal of an app store-like application experience. Then when an important, paid-for, poorly-behaved app comes along, the principles and methods needed to fix it will be well understood.

I mentioned last time that any version of the .NET Framework beginning with ‘4’ is an in-place upgrade for any similar version with a lower minor version number. Applications that depend on .NET 4.0 as a minimum should run fine on any subsequent 4.x version. We need something to use as a prerequisite for such applications. Rather than force every computer in an organization to move up to the latest version, it would be more efficient to just use whatever version of .NET is included in the operating system. Note, though, that the .NET Framework feature can be turned off in some versions of Windows, so we do need an application package to ensure that it is turned on. With this in mind, let us build a new Configuration Manager Application.

Acquiring the Installation Files

We actually have everything we need already. All supported versions of Windows except for Windows 7 and Windows Server 2008 R2 have some 4.x version of .NET built in, and we can reuse our .NET 4.6.1 installer from last time to take care of the exceptions.

On your application staging file share (wherever you put application source files for Configuration Manager to find), create a folder for .NET 4.x. Mine will be \\fileserver\software$\Microsoft\.NET Framework 4.x. We don’t actually need any source files, and so as with .NET 3.5 on Windows 7 and .NET 4.6.1 on Windows 10 November Update, we will just provide Configuration Manager with a single file in that folder. I created a text file with Notepad in the folder containing the following text:

The following Microsoft .NET Framework 4.x versions are included as operating system compoments in the corresponding Windows versions, and so no content is required or available to install them on those versions.
-Windows 8/Windows Server 2012          .NET Framework 4.5
-Windows 8.1/Windows Server 2012 R2     .NET Framework 4.5.1
-Windows 10                             .NET Framework 4.6

Configuration Manager applications require a content folder, so this folder serves that role for the "Microsoft .NET Framework 4.x [Deploy as prerequisite only]" application's deployment types for these Windows versions.

That explains the presence of the otherwise empty folder to anyone reviewing this folder structure.

For Windows 7 and Windows Server 2008 R2, we will just install the latest version of .NET (4.6.1 at the time of this writing) in order to satisfy the requirement unless a lower 4.x version is detected.

Building the Configuration Manager Application

Windows 7 and Windows Server 2008 R2 (64-bit and 32-bit)

In the Configuration Manager Console, create a new Application. We are going to reuse the source folder and settings from our .NET 4.6.1 application package for our first deployment type. Here are the values I provided in mine:

I included the suffix “[Deploy as prerequisite only]” in the name of the package because it doesn’t make sense to show this package to users. If a user opens Software Center, he/she should see normal applications that can be installed, not supporting libraries with ambiguous names. Don’t deploy this Application on its own; just set it as a prerequisite for other Applications that need it. The bracketed text serves as a reminder of this principle.

Speaking of principles, I violated one of my own rules: There is no uninstallation program. This is acceptable because again, this is a prerequisite application, and also because this application package just ensures that an on-by-default feature is still turned on, on most systems. If you want users to be able to uninstall this application from Software Center in Windows 7, deploy the .NET 4.6.1 package we built last time as “available”, and it will be detected as already installed when this application is installed. Then the user can choose to uninstall it.

Finally, notice the detection logic. We don’t actually test for version 4.6.1; we merely test that some version of .NET 4.x has been installed. If the user has previously installed .NET 4.0, 4.5, 4.5.1, 4.5.2, 4.6, or 4.6.1, these will all signify that this application is already installed. Only if none of these is installed will .NET 4.6.1 be installed by Configuration Manager.

All Other Platforms

All of the other operating systems we are targeting can be satisfied by a single deployment type that merely turns on their built-in NetFx4 feature if it is turned off.

Here we use a Dism command to turn on the NetFx4 feature. This feature name refers to whichever 4.x version is built into the target platform, or, if it has already been upgraded, it turns on the upgraded replacement version. For example, Windows 8 includes .NET 4.5 as an OS feature, so turning on NetFx4 enables .NET 4.5 functionality. If .NET 4.5.2, for instance, has already been installed on Windows 8 and then disabled, turning on NetFx4 enables .NET 4.5.2 functionality.

Notice that we didn’t have to worry too much about Server Core in this application package. For the Windows 7/Server 2008 R2 deployment type, we just omit Server Core from the requirements as we did with the .NET 4.6.1 Application. For the other deployment type, since we are enabling an already-installed feature rather than running Microsoft’s buggy .NET 4.6.1 installer, there is nothing to worry about here regarding Server Core. The application package we just build will run fine on all supported platforms except a Server Core installation of Windows Server 2008 R2.

Coming Up

That wraps up our three-week focus on .NET Framework installation. Next time, we’ll build one more Global Condition to check a prerequisite, and then we’ll move on to the home stretch of building a robust Microsoft Office 2016 Application in Configuration Manager.