Many administrators make a habit of provisioning users' desktops with a core set of applications, but some make applications available for users to install on their own. One of the simplest ways to allow self-installation is through features built right into the OS.
There are a few advantages to letting users install only the applications they need. First, it simplifies desktop deployment. Because the deployment images contain few -- if any -- applications, they are smaller and easier to manage than an image that contains a collection of applications.
Plus, application installation by the user helps keep licensing costs low. Organizations that license applications for use on every desktop often waste money, because there will always be some users that do not use certain applications. When users deploy only the applications they need, you may save money, because it will likely use fewer licenses.
How Active Directory aids application installation
So what's the best way to allow users to install their own applications? Thankfully, this doesn't mean giving users administrative permissions on their desktops and a set of installation DVDs. There are many third-party products that allow users to deploy applications that have been authorized by the administrator, but you can also provide user application installation capabilities using features that are built into the operating system. That provides more control for you, the admin.
More on user application installation
Enhance desktop management with user-installed apps
Liquidware adds departmental-installed apps to FlexApp
Explaining user environment virtualization
The trick to application deployment using only OS components is to use the Active Directory to facilitate the process. Active Directory offers two different application installation methods: You can either assign an application or you can publish it.
Assigning applications. Applications can be assigned to either users or computers. Assigned applications are automatically deployed without end-user involvement.
If you choose to assign applications, it is usually best to assign them to a computer rather than a user. If an app is assigned to a user, it is automatically installed onto any computer that the user logs in to (an icon will install initially, and the full application installation will complete when the user attempts to run it for the first time). That means you could end up consuming an excessive number of software licenses if a user moves from computer to computer a lot.
Publishing applications. If you want to allow users to install applications on demand, then you should publish the apps. Applications can be published to users but not to computers. When a user logs on, the published applications are not automatically installed. So, if the user wants to install a published application they need to open the Control Panel and use the Programs applet to install it.
Publishing applications is fairly straightforward. The first step is to create a software distribution point, which is nothing more than a file share where the application installation files reside. Keep in mind that users must have access to the distribution shares to deploy applications.
The next step is to create a Group Policy setting that will publish the application. To create this setting, open the Group Policy Editor and navigate to User Configuration > Policies > Software Settings > Software Installation (Figure 1). Next, right-click on Software Installation and choose the New > Package commands from the resulting shortcut menus.
At this point, you must specify the application you want to publish. There are two important things to know about this process.
First, do not browse to the application that you want to publish. If you do, the Group Policy will use the absolute path to the application (such as C:\distribution point\setup.msi). If you use an absolute path, the application deployment process will fail. To enter the correct path, make sure to include the Universal Naming Convention used by the deployment share (such as \\server\deployment_share).
In addition, the application you are publishing must be in the correct format. Windows Server has supported publishing MSI packages since at least Windows Server 2003. Windows Server 2012 also supports publishing Down Level Application Packages (ZAP files).
After publishing applications, simply explain to users that they can install those applications through the Control Panel.