Enterprise Printing Introduction

Until now, I have focused all of my blog posts on deploying software. With this and subsequent posts, I use a broader definition of the word “deployment”. This is the first of a series of posts on deploying and managing printers in an enterprise.

Several of my coworkers and I were frustrated with inconsistent printer configurations, ad hoc printer deployment and management practices, and lack of printer driver management and deployment guidance in our organization. Online research yielded many results of how to implement specific technologies, but we found no big-picture guidance for managing printing in the enterprise. Over the course of about a year, we met biweekly on our own time to share research and experimental results, brainstorm, argue, and formulate a comprehensive enterprise printing service and strategy for our organization. We have implemented the service described in this blog series, and we offer this to the world as a model for enterprise printing implementation in any organization.

It was a privilege to collaborate with my colleagues Shaun Holmes, Matt Norton, and Branden Mazure on this project.

Problem and Goal

How do you deploy and manage printers? How do you provide users with connections to the printers that they need? How do you update printer software and drivers? How do you secure network printers?

These were some of the questions we faced as we began thinking about building and documenting an enterprise printing service for our organization. As we researched, we found a lot of vendor-specific documentation, a lot of which was not very good. We never found a comprehensive description of enterprise printing best practices, so we met and argued about it biweekly for a year, and this is the result.

Our goals:

  • Research and document high-quality enterprise printing guidance for use by ourselves and others to provide consistency and quality of service.
  • Build a system that we would want to use and which would provide as much flexibility and automation as possible.
  • Never think about printing again, except for when we want to.

Framework for Discussion

As we wrestled with the technical and human problems involved in enterprise printing, we arrived at the concept of “Enterprise Printing Competency” levels, or “EPC”. This is a framework where each idea builds and improves on the previous one, and if you stop at any point, you are better off than you were before.


“Enterprise Printing” refers to the management of network-connected printers using scripting or other tooling for automation, consistency, and reliability wherever possible. As examples, large departmental printers and multifunction copiers are in scope. Even a desktop printer used primarily by a single person is in scope if it is connected to the network. The following are not in scope:

  • Non-network-attached printers, such as a USB printer on a staff member’s desk.
  • Large printers or multifunction copiers without network connectivity.

To be clear, such out-of-scope devices would benefit from many of the practices described in this blog series, but I will make no effort to call these out. This is going to be a long series even with a narrow scope.

Many vendors would love to sell you their printer management products. In our organization, a large midwestern university, we use such a vendor solution to manage printers for student use, but we had no commercial solution for faculty and staff printers. The solution described here is for the latter case and uses capabilities already available in a Windows Server environment.

Continuum of Competency

The Enterprise Printing Competency (EPC) levels form a continuum. At the lowest level, EPC-0, all printer configuration and management is performed manually. Printing as an IT service is a high-maintenance, low-flexibility activity at EPC-0. As the EPC level of an organization increases, maintenance costs decrease and flexibility increases.

Illustration of Enterprise Printing Continuum of Competency

Here are the EPC levels shown above in table form for reference.

Enterprise Printing Competency (EPC) Levels
EPC Level Name
0 Manual Configuration
1 Names, Not Addresses
2 Secure Hardware
3 Print Servers
4 Deployment
5 High Availability, Part 1

The EPC continuum is open ended. We decided to stop at level 5 because we realized that it was all that was achievable in our organization at the time, but you can tell by the name that we imagined a future EPC-6 for further implementation of high availability (High Availability, Part 2).

Coming Up

In subsequent articles, I will describe each of the Enterprise Printing Competency levels in depth.

Posts in this series:

  1. Enterprise Printing Introduction

Providing a Great Software Deployment Experience

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:

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.

DEPRECATED: Deploying Any Version of Microsoft .NET Framework 4.x as a Prerequisite Application

This post describes how to turn on features of Windows that are no longer supported by Microsoft as of 12 January 2016, so I have published a new post to replace it. Please read the new post instead: Deploying Any Supported Version of Microsoft .NET Framework 4.x as a Prerequisite Application.

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:

Property Value
Application Properties
Name Microsoft .NET Framework 4.x [Deploy as prerequisite only]
Publisher Microsoft
Version 4.x
Deployment Type Properties
Name Microsoft .NET Framework 4.6.1 – Windows 7 and Windows Server 2008 R2 (64-bit and 32-bit)
Technology Script Installer
Content location \\fileserver\software$\Microsoft\.NET Framework 4.6.1\PreWin10v1511\
Installation program "NDP461-KB3102436-x86-x64-AllOS-ENU.exe" /q /norestart /ChainingPackage ADMINDEPLOYMENT
Uninstall program None (leave blank)
Detection method Rule 1:
Hive/Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full
Value: Install
Data type: Integer
Equals 1
Installation behavior Installation behavior: Install for system
Logon requirement: Whether or not a user is logged on
Installation program visibility: Hidden
Configuration Manager behavior: Determine behavior based on return codes
Requirements Operating system
One of Windows 7 SP1 (64-bit), Windows 7 SP1 (32-bit), Windows 2008 R2 SP1 (64-bit)
Return Codes 0 Success (no reboot) Installation completed successfully.
1602 Failure (no reboot) The user canceled installation.
1603 Failure (no reboot) A fatal error occurred during installation.
1641 Hard reboot A restart is required to complete the installation. This message indicates success.
3010 Soft reboot A restart is required to complete the installation. This message indicates success.
5100 Failure (no reboot) The user’s computer does not meet system requirements.

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.

Property Value
Deployment Type Properties
Name Feature Installation – Windows 8, Server 2012, 8.1, Server 2012 R2, and 10 (64-bit and 32-bit)
Technology Script Installer
Content location \\fileserver\software$\Microsoft\.NET Framework 4.x\
Installation program "%SystemRoot%\System32\Dism.exe" /Online /LogLevel:4 /Enable-Feature /FeatureName:NetFx4 /All /NoRestart /Quiet
Uninstall program None (leave blank)
Detection method Same rule as Windows 7 and Windows Server 2008 R2 deployment type
Installation behavior Same settings as Windows 7 and Windows Server 2008 R2 deployment type
Requirements Operating system
One of All Windows 8 (64-bit), All Windows 8 (32-bit), All Windows Server 2012 (64-bit), All Windows 8.1 (64-bit), All Windows 8.1 (32-bit), All Windows Server 2012 R2 (64-bit), All Windows 10 Professional/Enterprise and higher (64-bit), All Windows 10 Professional/Enterprise and higher (32-bit)
Return codes Leave defaults

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.