Registry Keys for Tweaking Windows Update

Registry Keys for Tweaking Windows Update

In this article, I will show you some registry keys that are associated with Windows Update. As I do, I will show you the various settings that you can assign to those registry keys.

Although Windows Update and WSUS are both generally pretty simple to configure, you can sometimes gain a higher level of control over them by making a few minor modifications to the Windows registry. In this article, I will show you some registry keys that are associated with Windows Update. As I do, I will show you the various settings that you can assign to those registry keys.

Before We Begin

Before I get started, I need to keep the lawyers happy by telling you that modifying the Windows registry can be dangerous. Incorrectly modifying the registry can destroy Windows and / or your applications. I therefore strongly recommend that you perform a full system backup prior to attempting any of the techniques that I am about to show you.
Now that I’ve gotten the standard disclaimer out of the way, there is one more thing that I need to tell you before I get started. The registry tweaks that I am about to show you are intended for machines that are running Windows XP. You can apply the tweaks to individual machines directly, or you can apply modifications as a part of a login script. Also, some of the keys that I am going to be talking about may not exist by default. If you want to use a key that does not exist, you will have to create it. You should also keep in mind that Windows Update’s behavior can be controlled by a group policy, and that if a group policy is in effect, it can cause portions of the registry to be overwritten after you have made changes.

Elevation of Privileges

One of the problems with receiving updates from a WSUS server is that users are not allowed to approve or disapprove of updates unless they are a member of the local administrators group. However, you can use the registry to give users an elevation of privileges that will allow them to approve or disapprove of updates regardless of whether or not they are a local administrator. On the flip side, you could also deny end users the ability to approve updates, reserving that right for Admins.
The registry key that controls this behavior is: HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateElevateNonAdmins
The ElevateNonAdmins key has two possible values. The default value of 1 allows non administrators to approve or deny updates. If you change this value to 0, then only administrators will be allowed to approve or deny updates.

Target Groups

One of the nice things about WSUS is that it allows you to use client side targeting. The idea behind client side targeting is that you can set up different computer groups, and you can roll out updates on a group basis. Client side targeting isn’t used by default, but if you decide to use it, then there are two different registry keys that you will have to create. One of these keys enables client side targeting, while the other specifies the name of the target group that the computer belongs to. Both of these registry keys must be created at:

HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate

The first key is a DWORD key named TargetGroupEnabled. You can assign this key a value of either 0, which disables client side targeting, or of 1, which enables client side targeting.
The other key that you will have to create is string value named TargetGroup. The value that you would assign to this key is the name of the target group that the computer should be assigned to.

Assigning a WSUS Server

If you have been involved in networking for a while, then you probably know that network designs tend to change over time. Things like company growth, new security requirements, and corporate restructurings often force the underlying network to change. So what does this have to do with Windows Update? Well, WSUS is scalable and can be deployed in a hierarchical manner. This means that an organization can have a multitude of WSUS servers deployed. If a PC is moved to a different part of the company, then the WSUS server that it was initially configured to use may no longer be appropriate for its new location. Fortunately, a couple of simple registry modifications can be used to change the WSUS server that the PC gets its updates from.
There are actually two registry keys that are used when specifying a WSUS server. Both of these keys are located at: HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdate. The first key is named WUServer. This registry key holds a string value which should be entered as the WSUS server’s URL (example: http://servername).
The other key that you will have to change is a string value named WUStatusServer. The idea behind this key is that the PC must report its status to a WSUS server so that the WSUS server knows which updates have been applied to the PC. The WUStatusServer key normally holds the exact same value as the WUServer key (example: http://servername).

The Automatic Update Agent

So far I have talked about how to connect the PC to a specific WSUS server or to a specific target group, but this is only half of the process. Windows Update uses an update agent that actually installs the updates. There are a number of registry keys located at HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU that control the automatic update agent.

The first of these keys is the AUOptions key. This DWORD value can be assigned a value of either 2, 3, 4, or 5. A value of 2 indicates that the agent should notify the user prior to downloading updates. A value of 3 indicates that updates will be automatically downloaded and the user will be notified of installation. A value of 4 indicates that updates should be automatically downloaded and installed according to a schedule. For this option to work, the ScheduledInstallDay and ScheduledInstallTime keys must also be set. I will talk more about those keys later on. Finally, a value of 5 indicates that automatic updates are required, but can be configured by end users.

The next key that I want to talk about is the AutoInstallMinorUpdates key. This key can be set to a value of either 0 or 1. If the key is set to 0, then minor updates are treated just like any other update. If the key’s value is set to 1, then minor updates are silently installed in the background.

Another key related to the Automatic Update Agent is the DetectionFrequency key. This key allows you to specify how often the agent looks for updates. The key’s value must be a whole number between 1 and 22, and indicates the number of hours between each detection attempt.
A related registry key is the DetectionFrequencyEnabled key. As the name implies, this key either enables or disables the Detection Frequency function. Setting this key to a value of 0 causes the DetectionFrequency key to be ignored, while setting it to a value of 1 causes the agent to use the DetectionFrequency value.

The next key that I want to talk about is the NoAutoUpdate key. If this key is set to a value of 0, then automatic updates are enabled. If the key’s value is set to 1, then automatic updates are disabled.
The last registry key that I want to talk about is the NoAutoRebootWithLoggedOnUsers key. As you probably know, some updates simply cannot be applied without rebooting the system. If a user happens to be logged in, then a system mandated reboot can be very disruptive. This is especially true if the user has walked away from their desk without saving their work. This is where the NoAutoRebootWithLoggedOnUsers key comes into play. The key can be assigned either a value of 0 or 1. If the value is set to 0, then users will receive a five minute warning and then the system will reboot automatically. If the value is set to 1, then users will simply receive a message asking them to reboot their systems, but they can reboot at their leisure.

Conclusion
There are a whole lot more registry keys related to Windows.
update

Part 2:

In this article, I will continue the discussion where I left off in Part 1 by exploring the remaining Windows Update related registry keys.
In Part 1 of this article series, I explained that although Windows Update is self configuring for the most part, there are a large number of registry keys that you can use to tweak Windows Update’s behavior. This is especially useful if you are downloading updates from a WSUS server. In this article, I will continue the discussion where I left off in Part 1 by exploring the remaining Windows Update related registry keys.

Before We Begin:

Before I get started, I have to keep the lawyers happy by telling you that making modifications to the registry can be dangerous. Making an incorrect registry modification can destroy Windows and / or any applications that are running on the machine. You should therefore make a full system backup before attempting any of the registry tweaks that I am about to show you.
One other thing that I want to mention before I get started is that if you try some of these modifications and you don’t get the results that you are expecting, try checking to see if there is a group policy that mandates Windows update settings for the machine. Group policies can sometimes modify a registry key so that it follows the mandated behavior rather than using any modifications that might have been previously made.
Finally, I want to mention that I ended Part 1 of this article by discussing some of the registry keys found in the HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftwindowsWindows Update section of the registry. All of the registry keys that I will be discussing in this article are found in this section of the registry as well. None of the registry keys that I am about to show you exist by default, but you can create them to achieve the desired behavior. If you choose to create a registry key, then please keep in mind that the key names that I will be showing you are case sensitive and any of these keys that you create should be created as DWORD values.

Disabling Windows Update

The first key that I want to show you is the NoAutoUpdate key. You can use the NoAutoUpdate key to either enable or disable Windows update. Normally, this probably isn’t a key that you want to use, but it does have its place. If you happen to work in an environment with no Internet connection and you don’t have a WSUS server either, then you might disable Windows Update just to keep it from being a nuisance.
I don’t recommend creating this registry key unless you need to disable Windows Update. If you do need to disable Windows update, then you can create a key named NoAutoUpdate with a DWORD value of 1. Changing the value to 0 re-enables automatic updates.

Reboot Reminders

Have you ever applied an update to a server and then had Windows prompt you to reboot the server at a time that just wasn’t convenient? Personally, I’ve always found it annoying that Windows Update keeps prompting you to reboot your server every few minutes while you are trying to work. You can however change the reminder frequency. To do so, simply create a registry key named RebootRelaunchTimeout. The value that you assign to this registry key should reflect the number of minutes that you want Windows to wait between reminders. For example, if you wanted a reminder every half hour, then you would set the value to 30. You can set the RebootRelaunchTimeout registry key to use any positive integer from 1 to 1440.
Of course you also have the option of getting rid of reboot reminders completely. To do so, create a registry key named RebootRelaunchTimeoutEnabled, and set the value to 0. If you decide later that you want to re-enable reboot reminders then just change this key’s value to 1.
If you have ever worked with scheduled updates, you might have noticed that Windows can be configured so that the computer automatically reboots after an update requiring a reboot is applied. When automatic update is configured in this way, the user will receive a warning message before their computer reboots. The warning says something like “your computer will reboot in 5 minutes”. As you might have already guessed though, this reboot count down is controlled by the Windows registry. You can therefore tweak the registry to give users more or less warning prior to a reboot.
To create a custom reboot count down, simply create a registry key named RebootWarningTimeout. You can then assign this key a value that corresponds to the number of minutes that you want to give the user from the time that the warning is first displayed until the computer is rebooted. For example, setting this registry key to a value of 10 would give the users a ten minute warning. Valid values include positive integers ranging from 1 to 30.
If you plan on using the RebootWarningTimeout key to specify a custom reboot warning countdown, you will have to use the RebootWarningTimeoutEnabled registry key to enable it. To do so, create a registry key named RebootTimeoutWarningEnabled, and set its value to 1. Setting this value to 0 will cause Windows to use a five minute reboot countdown regardless of what has been set through the RebootWarningTimeout key.

Applying Missed Updates

Although Windows Update gives you the ability to schedule updates, things can happen that cause a computer to miss the scheduled update period. For example, the computer could be turned off at the scheduled update time. When a scheduled update is missed, Windows will attempt to install the update the next time that the computer is booted. However, it can be disruptive to the user to have updates installed as soon as their computer boots up. You can therefore set a timer to control the number of minutes that Windows should wait after the system boots to install missed scheduled updates.
Before I show you how to set the timer, I should mention that this only applies to missed scheduled updates, not updates with an expired deadline. With that said, you can create the timer by creating a registry key named RescheduleWaitTimer and assigning it a value that reflects the number of minutes that Windows should wait from the time that the system boots until missed updates are installed. Valid values are positive integers ranging from 1 to 60.
If you plan on using the RescheduleWaitTime registry key, you will have to use a second registry key to enable it. The name of the second required key is RescheduleWaitTimeEnabled. Assigning this key a value of 1 will enable the reschedule wait timer registry key, where as setting this key to a value of 0 will cause the wait timer to be ignored.

Scheduling Installations

I have talked a lot about scheduled installations, but I want to show you one last trick. You can use the registry to set the installation schedule. There are two registry keys that are used when scheduling an update. The first of these keys is ScheduledInstallDay. I recommend assigning this key a value of 0 which tells Windows that updates should be installed regardless of what day it is. You can however specify a day by specifying a positive integer ranging from 1 to 7. The number that you specify designates a day of the week. A value of 1 sets the installation day to Sunday. Setting the value to 2 sets installation day to Monday. If you are going to limit installations to one day a week, then I recommend using Wednesday since most Microsoft patches are released on Tuesday.
One thing that you need to know about the ScheduledInstallDay key is that it is ignored unless the HKEY_LOCAL_MACHINESSoftwarePoliciesMicrosoftWindowsWindowsUpdateAUAUOptions key is set to a value of 4. I discussed this key in Part 1.
The last key that I want to talk about is the ScheduledInstallTime key. This key tells Windows what time of day updates should be installed. Valid values for this key are positive integers ranging from 1 to 24, which reflect the hour of the day in military time. As such, a value of 3 would reflect a 3:00 AM installation time. A value of 13 would be a 1:00 PM installation time.

Conclusion
As you can see, there are a tremendous number of registry keys that can be used to configure Windows Update. If you are thinking about trying these keys out, I recommend testing your settings on a single PC before rolling out your changes on a large scale.

Follow @aleemxp

Running Windows Under Non-Admin Accounts - XP

Running Windows Under Non-Admin Accounts - XP


WINDOWS XP - Running Windows Under Non-Admin Accounts

Everyone knows that one of the most important principles of network security is least privilege: grant ordinary users only those rights and permissions they need to get their work done and no more. For example, if ordinary users don’t need access to sensitive data stored in the Accounting share, don’t give them any permissions on that share, either through shared folder permissions on the share itself or NTFS permissions on the folder underlying the share.

Least privilege is more than a security principle, it’s also a lifesaver as far as the day-to-day job of administrators is concerned. Reason is, users are curious creatures and tend to push the envelope of what company policies allow and forbid them to do. Give a user local administrator privileges on their computer and they’re likely to try all sorts of things like installing additional software, changing configuration settings, and even poking around the registry to see if they can “tune” their machine to make it run better. From an administrator’s point of view however, this can be disastrous since the wrong tweak might break some application or even render their machine unusable. The user then cries for help and as an administrator you pretty much have two choices: wipe their machine and re-image it from your standard desktop image or spend useless hours trying to troubleshoot their problem. The second choice is usually a waste of time unless, contrary to company policy, the user has been saving important files on their machine instead of on the network. And the first choice is almost like spitting in the wind—you re-image the user’s machine and he just goes and fools around with it again.

Group Policy is one way of locking down what a user can and cannot do on their computers and using their credentials. But what if company policies (or culture or politics or on the job realities) mean that your users need to have the ability to install their own software and configure settings on their machines? If this is the case, you have two choices: give your users local admin privileges, or don’t. Since the first option causes the troubles I’ve described above, let’s explore the feasibility of the second option.

The Pain of Running As Non-Admin

If you choose not to make a user’s domain account a member of the local Administrators group on their machine, the user is likely to complain loudly for a number of reasons including the following:

When they try and install software on their machine, the install will usually fail with an error of some sort.

When they try to adjust the Date and Time in Control Panel, they get a dialog box saying they don’t have sufficient privileges to do so.

When they try and configure Power Options in Control Panel, they can change the setting in the GUI but when they click OK to apply changes they get an Access Denied message.

When they want to share a folder on their machine so another user can access their files, they can’t because there is no Share tab on the properties sheet for the folder they want to share.

Working around the last three complaints is fairly straightforward (I’ll show you how in a moment), but the problem of not being able to install software is a complex issue for several reasons. First, most software (including many of Microsoft’s own applications) requires local administrator privileges in order to install under any version of Microsoft Windows. On the face of it, this requirement is due to the fact that applications need to write to special areas of the file system and registry. But that’s not the real reason applications need admin privileges to install—the real reason is that developers are generally too lazy to bother creating Setup or Windows Installer packages that will work under non-admin privileges. This is because doing so involves going through a number of hoops as a developer, and that means extra work (which most developers want to avoid). But it also means developing these apps while running under non-admin privileges yourself, and again that involves lots of bother so most developers don’t bother—it’s much easier to develop an application if you are logged on as Administrator, so most apps are de facto designed to run under admin privileges as well.

Installing Software As Non-Admin

So how do you install software when you don’t have admin privileges on a machine? The tedious way is to log off, log on as Administrator, install your software, log off, log on again with your ordinary user account, and then start using the software as an ordinary user. The fancier way of course is to use the secondary logon feature (the Runas.exe command) of Windows 2000 and later. With .exe files (and .msc files or consoles) you can right-click on the icon and select “Run as…” and then specify local admin credentials for installing the program. Unfortunately the “Run as…” option doesn’t appear when you right-click on .msi files, but the workaround here is to use Runas to open a command prompt (cmd.exe) window using admin credentials and then run the .msi file to install the app.
Unfortunately, some programs after they’ve been installed with admin privileges using Runas still don’t work properly when you try and run them as an ordinary user. This is because when you use Runas to install something, any per-user settings that the install routine creates are written to the user profile for the local Administrator account instead of to the user profile of the currently logged-on ordinary user account. And of course that causes problems when you try and run the installed program later as an ordinary user. Once again, the developer who wrote the program could have worked around this issue, but why bother when everyone runs Windows as Administrator anyway?

I’ve experienced this kind of thing myself several times with both third-party Win32 apps and also .NET Framework applications, and it’s frustrating. For example, I recently wanted to take an e-learning course in ASP.NET application development from Microsoft. Unfortunately for some reason I couldn’t download the course (a .NET app itself) when logged on using my domain user account, so I opened an instance of Internet Explorer using local admin creds and successfully downloaded the course. But when I tried to run the course locally on my machine, it wouldn’t run when I was logged on as ordinary user. So I tried using Runas to run the course under admin privileges and it still wouldn’t run. In the end I had to log off, log on as Administrator, download the course, and run it while logged on as Administrator in order to get it to work. Frustrating! Maybe if I investigated the problem further I might have discovered why it didn’t work the first time, but that just illustrates in the first place why most people run Windows under admin privileges all the time—if you aren’t running as admin, you can waste a whole lot of time trying to make things work.

The Least Privilege Red Herring

Furthermore—and this is something that’s only recently started being considered by security experts—it may be that this whole least privilege issue is something of a red herring in the first place. Sure, if you’re logged on as Administrator and you browse the web and come across some nasty site and download a virus, that virus gains control of your system using your own credentials i.e. administrator. And if you were an ordinary user and browsed that same site, the virus would only have limited access (the level of privileges of a domain user) on your system so the potential damage would be mitigated. But actually it’s more complex than this. After all, if the malware you download is a worm that exploits a weakness in a Windows service, then it really doesn’t matter what account you’re currently logged on as.
Furthermore, the smartest black hat hackers out there are already busy trying to figure out new ways to create malicious code that can own your system even if your logon privileges are minimal. Because of this, the upcoming and highly-touted Least-privilege User Account (LUA) feature of Longhorn (now Windows Vista) that will do away with the deprecated Power Users group and enable LUA-compatible apps to be installed and run using ordinary user credentials is really no panacea for the security issues surrounding the use of least privileges. You can bet your bottom dollar that the bad guys out there will find some way of circumventing LUA or even leveraging it to their advantage, opening up a whole new kettle of worms.
So while least privilege is still a good idea, it’s certainly not the be-all or end-all of network security. In other words, you still have to think defense-in-depth and consider least privilege (or LUA) as simply one more obstacle in the way of hackers owning your system.

Some Non-Admin Workarounds

Going back to our list of things ordinary users complain about, let’s look at some workarounds. Say you’re logged on as an ordinary user and want to share a folder on your system. If you open Windows Explorer (explorer.exe) and right-click on the folder, there’s no Sharing tab so you can’t do it. And Runas doesn’t work with explorer.exe because Explorer is already running as your shell, so you’re out of luck there as well. Fortunately there’s a workaround: use Runas to start Internet Explorer (iexplore.exe) instead of Windows Explorer (explorer.exe). Then once IE is open, type C:\ into the address bar and click the Folders button on the toolbar and suddenly it looks like you’re in Windows Explorer. Now navigate to the folder you want to share and right-click it and select Sharing and Security and you’re on your way.

And while we’re at it, note that the folder tree in IE displays a Control Panel node. Select this node and in the right-hand pane you see all the Control Panel applets. Try using Date and Time to change your system time—it works! Since IE is running under admin creds, all the apps you access in it including Control Panel applets also run with admin credentials. Same goes for Power Options, Network Connections, System, and other applets that have reduced functionality when run as non-admin.
There’s an even easier way however (the IE method works but is a bit messy since iexplore.exe is not in the system path) and that’s to do the following:

Log off and then log on as Administrator.

Open Windows Explorer

Select Tools, then Folder Options, then View, and select the checkbox labeled “Launch folder windows in a separate process”

Close Windows Explorer and log off.

Now when you log on again as an ordinary user, you can right-click on explorer.exe (or its shortcut), select “Run as…”, specify the local Administrator account credentials, and Windows Explorer now opens running with admin privileges.

Conclusion

Running Windows as non-admin is challenging, and while there are some security benefits to doing so, the hoops you have to jump through to make things work can be daunting. Furthermore, these security benefits are not as great as many security people tout them to be, and it won’t be long until the bad guys figure out ways to install serious malware on Windows even when users are running as non-admins.

Follow @aleemxp