Client Management Suite

Introduction

Windows 7 offers many benefits and the deployment of Windows 7 has been covered in detail on many other posts and sessions.  One aspect that has not been touched on quite as much is that of managing the Software Delivery aspect of Windows 7 with Notification Server 6.x.  Although many of us have plans to go to Notification Server 7.x, it may be a while and we cannot necessarily put off our migrations or pilots of Windows 7.  This article will hopefully point folks in the right direction as I have done quite a bit of testing and found these settings to work reliably.  That being said, not every environment is the same so what may work for me may not work for you.

Environment:

• Single Notification Server
• Off-Box SQL
• GPO's for Policies & Preferences
• Software Delivery for Baseline Software Deployment
• Deployment Server
• User's run as Limited User with UAC enabled

The biggest hurdle has been making Software Delivery run with UAC enabled and accounting for the changes in security, such as Session 0 isolation.  The approach that I took was to use as many of Microsoft's Best Practices and Symantec Best Practices as possible.  This meant leaving UAC enabled and making sure that the Admin Approval mode of Windows 7 was not crippled to replicate Windows XP functionality (i.e. no consent prompts for Administrators).  In addition, I wanted to make sure that minimal changes were needed for our existing packages to support this deployment method.

The following are how our packages are generally configured for silent installs:

• Packages are located on SAN and referenced via UNC on the Program
• Programs are set to run as System context
• Programs are set to install whether or not a user is logged on
• Programs are set to a Hidden window.
• Programs have the User Input required option turned off (accounts for no user stack available to the System account).

There are 10 GPO policies available for configuration to manage UAC across your network.  The following is how I have configured them:

Group Policy setting	Registry key	Applied Setting
User Account Control: Admin Approval Mode for the built-in Administrator account	FilterAdministratorToken	Disabled
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop	EnableUIADesktopToggle	Disabled
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode	ConsentPromptBehaviorAdmin	Prompt for consent on the secure desktop
User Account Control: Behavior of the elevation prompt for standard users	ConsentPromptBehaviorUser	Prompt for credentials on the secure desktop
User Account Control: Detect application installations and prompt for elevation	EnableInstallerDetection	Disabled (default for enterprise)
User Account Control: Only elevate executables that are signed and validated	ValidateAdminCodeSignatures	Disabled
User Account Control: Only elevate UIAccess applications that are installed in secure locations	EnableSecureUIAPaths	Enabled
User Account Control: Run all administrators in Admin Approval Mode	EnableLUA	Enabled
User Account Control: Switch to the secure desktop when prompting for elevation	PromptOnSecureDesktop	Enabled
User Account Control: Virtualize file and registry write failures to per-user locations	EnableVirtualization	Enabled

The key takeaway to note is the policy "Detect application installations and prompt for elevation".  Disabling this policy allows service accounts in the background to deploy the software without requiring consent to a dialog for installation.  We use an AD Altiris Service Account that does the heavy lifting of installing programs in the background.  This will allow it to not encounter problems with the actual installation of software.

The second component to all of this is verifying that the communication between the Altiris Agent and the Notification Server is stable and consistent.  What I would find is that for some reason after pushing a package out for installation, the first would be successful but every subsequent install would fail.  The error messages I would see in the Altiris Agent logs are that of "UncTransfer failed" and "Access Denied".  I looked at the Event Viewer Security logs and would see reference to the Filtering Platform policies changing with regard to Teredo.  Teredo is an IPv6 technology and this made me remember that there were some DAgent issues with it in the past.  I turned off IPv6 and started to push out packages again and I was able to successfully and consistently push out packages to my Windows 7 client.

The final takeaway from this is that as of now, setting the UAC policies as stated above and turning off IPv6 on the clients enabled consistent and reliable Software Delivery with NS 6.x.  I have talked to Symantec at the Vision Conference and in terms of 7.x versus 6.x they did state that there are a number of enhancements and changes made to the new agents to accomodate specific Windows 7 deployment issues.

We would all like to go there eventually but in the meantime, hopefully this will help folks get further along.  This all requires further testing on wider scale but I would love to hear feedback from everyone.  I am going to most likely open a support ticket with Symantec regarding the agents and their interaction with IPv6 to see if it is something specific with our environment or with the agent.  Good luck everyone!

-Adam