Deploy / App Basic Training
Application management has never been easier – at least according to us. Our application distribution platform, otherwise known as Specops Deploy / App, leverages existing infrastructure and offers a Group Policy based approach to application management. You’re hooked, and naturally interested in some product reviews. But before you see what everyone is raving about, let’s get you caught up on some basic concepts, scenarios, and how it all works via this Basic Training post.
Working with Group Policy Objects
Specops Deploy / App settings work the same way as any other group policy setting. The closest comparable component is Group Policy Preferences. They both use SYSVOL based storage of Group Policy Object (GPO) settings, and have similar targeting mechanics.
Since any GPO can contain Specops Deploy / App settings, deciding on the best way to approach the task can be confusing. There are three common strategies: single GPO, standard + special application GPOs, administration unit GPO.
A single GPO is used to store all Specops Deploy / App settings. The GPO is linked high in the Active Directory (AD) structure to ensure that it hits as many computer objects as possible. Targets are used to narrow down which clients get applications.
A single administrator at a time should work with the policy to avoid corruption.
Standard + Special Application GPOs
A single GPO used for commonly installed applications, and one or more GPOs used for special applications. This is useful when grouping deployments based on application type, perhaps in a scenario where you want to keep server deployments separate from workstation deployments. This allows administrators to work with the deployment system at the same time, as long as each administrator works in separate GPOs.
Administration Unit GPOs
This is commonly found in large enterprises with sites in different countries. Administrators in one location can have their own GPO, with full control over everything that goes on in their part of the AD.
Avoiding GPO Corruption
Regardless of the strategy you use, you should never edit the GPO settings from more than one place at a time. If more than one administrator works in a policy at the same time, their changes will overwrite each other, resulting in a corrupted GPO. It is possible to remove the corruption by manually deleting the corrupt data from SYSVOL.
A Specops Deploy package contains information about a software installation and defines where the software installation is located, and how it is installed. The following are the different package types: Windows Installer, Windows Installer Patch, App-V, Legacy, Windows Store.
A Windows Installer package uses an msi-file as the installation source and is applied on the client through Windows Installer.
The advantage of an msi-based installation is the standardized way of registering the software in Windows. This makes it easy to install and remove the software in a centrally managed environment.
Windows Installer Patch
A Windows Installer Patch, or msp-file, is a type of msi-package that updates an existing software installation. Windows Installer patches are applied through Windows Installer and require little or no configuration.
Microsoft Application Virtualization packages are based on App-V 4.6 or 5.0 package files. These applications can only be installed on clients that have the App-V client installed.
The legacy package type indicates that the installation is run through a separate executable, typically a Setup.exe installation program. The setup file is responsible for all actions it performs during the software installation, and requires configuration parameters to silently install the software without end user intervention. In order to remove the installed software, you must also specify uninstallation commands for legacy setups.
The executable specified in the package, together with the parameters, start when the installation is executed. This means that the package can be used with anything that can execute on the client, such as scripts.
Windows Store Applications
Windows Store applications are applications that are designed for the new Windows start screen. Before you can deploy your Windows Store App, you need to package and sign it using the App Packager (MakeAppX.exe) and SignTool (SignTool.exe) executables.
A Specops Deploy target defines why a deployment should be acted on. A target consists of a set of criteria which the client will match against its own environment. If there is a match, the target is considered valid and the deployments associated with the target will be acted on.
A targeting strategy is needed to control which machines get what software. Standard applications that go to all machines can be treated differently than special applications that go to a few.
Membership based targets
Basing the target criterion on membership in OUs, security groups, or other logical groupings, is an effective way of gaining control. For example, OU membership is useful for standard applications that go to many machines. Security group membership can be combined with “uninstall if deployment falls out of scope of management” to have the software removed if they are taken out of the group.
OS or hardware based targets
Another common method of targeting deployments is identifying the operating system (or processor architecture) on the client. This allows you to deploy software that is specific to the operating system, like a 64-bit version of the software to 64-bit machines. You can also use hardware based targets to deploy model specific drivers to computer models.
Software dependent targets
An effective type of target is dependency between packages – using an already installed package as the criteria for a target. This will ensure that the target will only become valid if the package it depends on has been installed. This is especially useful for applying updates to existing software.
A deployment is the package and target combined with additional deployment parameters such as if the application should be advertised, installed/uninstalled, or when the package should be deployed.
When a deployment is created, the deployment settings are made available to clients through the normal Group Policy refresh. The clients are responsible for retrieving the current rules and applying them locally. This means that the deployment exists as a state rather than an activity, as it is impossible to know when each client will retrieve and act on the new settings.
Group Policy processing modes
Your deployments can be processed while the computer is starting (foreground), or after the computer has started (background).
Foreground processing is useful for when you want to deploy the application before the client can be used, for example, anti-virus software. Background processing offers flexibility and the ability to interact with the end user, making it ideal for any application where the installation time might be a concern.
Specops Deploy uses the background processing mode as the default setting.
The Client Side Extension compares the GPO to the registry on the local computer to determine what application is installed.
When a deployment is targeting a computer or user target, those deployment(s) will be enacted to the target, and the packages in those deployments will be installed. The deployments will be referenced as ‘Managed Deployments’.
If a deployment is deleted and the “out of the scope of management” was not selected, the deployment will be orphaned. This means that there is software still on the client system that is no longer managed by the Specops Deploy Application.
The Managed vs. Orphaned deployments are stored in the Registry on the client:
On a computer target:
[HKEY_LOCAL_MACHINE\SOFTWARE\Specopssoft\Specops Deploy\Client Side Extension\Managed Deployments\System\Deployment GUID]
On a user target:
[HKEY_LOCAL_MACHINE\SOFTWARE\Specopssoft\Specops Deploy\Client Side Extension\Managed Deployments\user GUID\Deployment GUID]
[HKEY_LOCAL_MACHINE\SOFTWARE\Specopssoft\Specops Deploy\Client Side Extension\Managed Deployments\Orphaned Deployments\]
Click here for more information: https://specopssoft.com/blog/orphaned-deployments/
For detailed control over an installation, you can use an installation script from the legacy setup package. This will require some scripting skills and knowledge of how the applications works.
The easiest way to work with installation scripts is to copy them (along with other configuration files) to the folder containing the source files for the application. This will ensure that they are downloaded to the client together with the installation package. The variable %SpecopsDeployExecuteDir% contains the path of the source folder on the client.
Note: The download and installation is performed in the content of the computer account (system) and not the user account.