Managing Application Servers with WSUS

Common Problems

The most common issue with managing Windows Updates for application servers with WSUS is that end users will often see update notifications that are actually for the application server.  It is visible through either a Terminal Services session or a Citrix session.  This is problematic because end users, in this scenario, have the rights and abilities to install Windows Updates on the application server itself……often times resulting in a reboot of the application server.

Steps to Resolve

The first step to resolve this problem is in Group Policy.  It is highly advisable to group the different types of machines into OU’s such as “Laptops”, “Citrix Servers”, etc.  This allows you to form policies that apply for computers that are isolated in their own OU.

I will assume that the application servers are in their own OU with their own WSUS policy, and start discussing the Group Policy settings that must be configured.  In the Computer Configuration of the Application Server WSUS policy, browse down to Administrative Templates\Windows Components/Windows Update.

Set the “Allow non-administrators to receive update notifications” to “Disabled”

Also make sure that “Configure automatic updating” is set to 3 - Auto download and notify for install.  This will allow you push out updates to the servers and they will not auto install.  I usually push out updates the day before I do my weekly server maintenance routine.  This allows 24 hours or more for the installation packages to be pushed out to all servers in the organization.

The next issue is that some application vendors recommend adding users or user groups to the Local Administrators group of the application server.  This is the hardest issue to work around, but with some patience and tenacity it is possible.

The Goal

The goal is to get the users or user groups out of the Local Administrators group and get them into the Power Users group.  This is not a simple migration as some additional permissions will likely need to be set in order for this migration to work.

The best method of testing this is to take one application server and disabled application access temporarily on that machine (I work with Citrix and this is fairly simple to do).  Once there are no published apps being hosted from the “test” server, it is time to start the re-configure process.

It is best to pick a specific user or user group that is associated with one application and remove that user or user group from the Local Administrators group and add the user or user group to the Power Users group on the application server.

The next steps all have to do with folder permissions.  Full rights must be manually granted to the Documents and Settings folder, the folder where the application itself is installed and at least read rights to the \Windows\System32 folder.  Full rights must also be granted to the \Program Files\Common Files\xxx application folder.

Finally, some testing…

Once this is complete, it is time to do some testing.  I sent out an email to the organization and informed them that we would be doing testing and if there were a problem to call into the support dept.

It is all trial and error from here on out.  All issues that come up will be folder permission related.  You just need to look at the specific error and find the folder/file that is causing the error and add at least read or full permission for the user or user group.

This can be a timely process, but as long as the end users are informed, they will ususally be understanding.  The beauty is that if something is not configured properly, you can remove the affected server from the application pool, have the user that got the problem log out of their session and log back in and they will hit a different application server.

Once all the folder permissions are set, you will be able to manage your application servers with WSUS.  This is really handy if any of your application vendors publish a list of compatible Operating Systems/Patches and Hotfixes…….

Tags: Tech Support, adding users, administrators group, application server, application servers, application vendors, citrix, citrix servers, computer configuration, end users, maintenance routine, next issue, policy settings, power users group, reboot, server maintenance, tenacity, terminal services session, windows components, windows updates, wsus

Tags: adding users, administrators group, application server, application servers, application vendors, citrix, citrix servers, computer configuration, end users, maintenance routine, next issue, policy settings, power users group, reboot, server maintenance, tenacity, terminal services session, windows components, windows updates, wsus