Management Utilities Configuration for UAC Environments
Management Utilities Configuration for UAC Environments
For optimal use of SyAM Management Utilities, Windows client machines should be configured with User Account Control disabled or set to the least restrictive setting. Recognizing that this option is impractical for some environments, this document explains how to configure Management Utilities for a network with UAC enabled on client machines. The procedures outlined here have been tested on Windows 7 (32-bit and 64-bit) and Windows 8 systems with default UAC settings.
For the default configuration of Management Utilities and the Windows System Client, features such as Client Deployment and Third Party Software Deployment use credentials that give administrative access to target machines, as well as access to the network share (Default Application Path) where installation files have been uploaded. When UAC is enabled on the target machine, the machine’s Local System account can run the installation with elevated privileges, but this account does not have access to shared network directories. The configuration outlined in this document works around these limitations.
Configuring the Management Utilities Service
A system service called SyAM Management Utility is installed as part of the Management Utilities installation. By default, the service is run by the Local System account. For a UAC environment, this must be changed so that the service is run by a local administrator, or in an Active Directory environment, a domain administrator.
On the Management Utilities server, navigate to Administrative Tools – Services. Find the service SyAM Management Utility. Click the Stop link to stop the service, then right-click the service and choose Properties.
In the Properties dialog, click the Log On tab. Click This account. Enter the account (e.g. MYDOMAIN\Administrator) and password with confirmation. Click OK.
Start the service.
Verify that the service status is Started, and Log On As is set to the administrator account.
In UAC environments, when deploying the SyAM System Client or third party applications, two authentication templates are used. The first template (called Windows Domain Admin in our example) uses default settings along with your admin username, password and domain name. This is the authentication template that is typically created the first time you log in to Management Utilities. You will use this authentication template in a Client Deployment or Third Party template to provide credentials for accessing the network share.
To create the second template (in this example, Windows Local Admin) copy the existing template to preserve the credentials, then change the name so the original template is not overwritten. Check the Install as local system option. Uncheck the Grant logon as service, Remove permissions when finished, and Impersonate this user locally options. Save the template. You will use this authentication template in a Client Deployment or Third Party job to have installation files pushed from the Management Utilities server, rather than pulled by the target machine.
Deploying the SyAM System Client to Windows machines with UAC depends on proper configuration of the Client Deployment template, and of the deployment job.
The Client Deployment template has an option to copy the installation executable to the target system before running the installation. This option must be checked in the Client Deployment template.
The authentication template selected in the Client Deployment template is used to access the network share, so we use the same template as for a normal non-UAC deployment.
When you create a job to perform Client Deployment on a system or group of systems, an Authentication Template is specified for the Client Deployment task. This should be the other template (in our example, Windows Local Admin) that has the Install as local system option selected and the other three options deselected. Click OK after selecting the template.
For the Set Area Manager IP task, choose the default Authentication Template (in our example, Windows Domain Admin) rather than the template for local installation.
Unattended Installation Wizard
When using the Unattended Installation Wizard, choose a Client Deployment template that specifies normal Domain Admin authentication and has the Copy this file locally option selected. Once the templates have been selected and the schedule has been set, the Add / Edit A Job screen is displayed. Click the Edit link for the Client Deployment task, and set the Authentication Template to Local Admin. You should also click the Edit link for the Set Area Manager IP Address task to make sure the Authentication Template is the normal Domain Admin template. Click Save Changes when finished, and the wizard job will be queued to run as scheduled.
Third Party Software Deployment
A Third Party deployment that uses a single installation executable is handled in the same way as a System Client deployment. The Authentication template specified in the Third Party template is used to access the network share, so you’ll use the normal Domain Admin template. The Copy these files locally option must be checked. Then, when setting up the Third Party deployment job, choose the Local Admin template.
The more complex cases are installations such as Microsoft Office, where not just the installation executable but other files in the network share’s Office subdirectory must be accessed, as well as the installations that use batch scripts, including all .MSI installations. In these cases, an installation will require two batch scripts and two Third Party templates. A single job will run the two Third Party tasks, the first of which copies files to the target machine, while the second runs the installation locally. Two tasks are required because we need to use different authentication templates.
First we’ll look at the Office installation. This batch script copies the Office installation subdirectory from our network share to the target machine. We’ve chosen xcopy parameters to make sure all subfolders are copied without prompting. Please keep in mind that in this case we are copying over 700 MB to each target system. We’ll name the script copy-office.bat and we’ll upload it to the default application directory.
xcopy \\192.168.100.158\apps\Office2010 C:\syaminstall\Office2010 /C /E /H /I /Q /Y
The second batch script installs Office using our customized .MSP file as documented in the SyAM Tool Tip on Office installation. We’ll call this script install-office.bat and upload it to the default application directory.
setup.exe /adminfile office2010.MSP
Create a Third Party template for the copy, using the normal domain authentication template to access the network share. Check the option to copy files locally.
Create a template for the installation step in the same way.
When creating the job, the first task is Third Party deployment using the first template, and for this step the normal domain authentication is used.
Next, add a brief Wait task.
Finally, add the second Third Party task for the install, using the Local Admin authentication.
The job is now ready to run. When it’s completed, a separate Status message should appear for each Third Party deployment task.
Another case to consider is the .MSI installation. In a non-UAC environment, we would use a batch file, such as this example for installing Google Chrome.
msiexec /i \\192.168.100.158\apps\GoogleChromeStandaloneEnterprise.msi /qn
The problem for this batch script in a UAC environment is that it must be run either by the domain admin account, which can’t perform the install silently without triggering a UAC prompt, or by the Local System account, which has no access to the network share. Again, we split the installation into two script files. First, the copy:
copy \\192.168.100.158\apps\GoogleChromeStandaloneEnterprise.msi C:\syaminstall\
Second, the installation:
msiexec /qn /i C:\syaminstall\GoogleChromeStandaloneEnterprise.msi
As with the Office installation, a Third Party template is created for each step, and when creating the job that runs them, the copy uses domain admin authentication and the install uses local admin authentication.
Installing Windows Patches
Management Utilities has two methods for updating Windows patches on target systems. A Patch Management template can be created to install patches of one or more particular types (Critical, Security, etc.) and a job can be created to run the template against a system or group of systems. Using this method, patches can’t be selected individually, but jobs can be run on demand or on a regular schedule. When creating a Patch Management template for use in a UAC environment, check the Copy every patch locally option.
When creating the job to run the Patch Management task, choose the local authentication template.
The other method is to perform a patch scan (on a single system, selected systems in a group, or on the entire group) by right-clicking in the Groups area to display the context menu, and then choosing Patch Scan Now. Use the local admin authentication template for the patch scan.
For patch deployment, after selecting the desired patches and systems, choose the local admin authentication template and check the Copy every patch locally option.