Monday, November 17, 2014

Understanding IIS 7.0 URL Authorization

Prerequisites

This walkthrough requires installing the following IIS above features on top of the default install:
  • "ASP.NET" under "Internet Information Services" – "World Wide Web Services" – "Application Development Features"
  • "URL Authorization" under "Internet Information Services" –" World Wide Web Services" – "Security"

Scenario

Let's simulate a scenario where you have a secure directory that only Alice, Bob and the Administrators group can access. Within this directory we have a file called bobsSecret.aspx that only Bob is supposed to access.

Scenario Setup

For this scenario we need three users: Alice, Bob and Fred. We also need a new group called BobAndFriends in which Alice and Bob are members. Create the three accounts and the group via the Windows User Manager or by starting an elevated command prompt and enter the following commands
net user Alice /add
net user Bob /add
net user Fred /add
net localgroup BobAndFriends /add
net localgroup BobAndFriends Alice /add
net localgroup BobAndFriends Bob /add

1. Open Explorer and go into the %systemdrive%\inetpub\wwwroot directory.
2. Create a directory called "secure".
3. Change into the "secure" directory and create a new file called "default.aspx". You can do this with notepad or any other text editor.
4. Paste the following code into the default.aspx page:
<%@Language="C#"%>
<%
string currentUser = Request.ServerVariables["LOGON_USER"];
if (currentUser == "")
currentUser = "anonymous";
Response.Write("Current User: " + currentUser);
%>

5. Create another file called bobsSecret.aspx and paste the following code into it:
<%@Language="C#"%>
<%
string currentUser = Request.ServerVariables["LOGON_USER"];
if (currentUser == "")
currentUser = "anonymous";
Response.Write("Current User: " + currentUser);
Response.Write("
My secret: I used Apache before I discovered IIS7.
");
%> 6. Now see if the two web pages work by requesting http://localhost/secure/ and http://localhost/secure/bobsSecret.aspx.

Configuring Authentication

Authentication answers the question "who" wants to have access. Authorization answers "if" the authenticated "who" actually gets access. So, before experimenting around with URL authorization, we must enable authentication because without knowing "who" wants to have access, we cannot answer the "if".
1. Start INETMGR by typing INETMGR in the "Start Search" menu.
2. Open the machine node in the left tree view, then open the "Default Web Site" node and select the "secure" directory.
3. Double click "Authentication."
4. Disable "Anonymous Authentication" and enable "Basic Authentication."
5. Now request http://localhost/secure and http://localhost/secure/bobsSecret.aspx again. You will get prompted for credentials. Enter "Alice" as username and her password. You will be authenticated as "Alice".
Note: If you use Internet Explorer, you may to hit Ctrl+F5 so that Internet Explorer refreshes the cached version of the Asp.Net page.

Configuring URL Authorization

Now secure the two pages so that only Alice and Bob have access:
1. Double click the "secure" web directory again and select "Authorization Rules".
2. Remove the "Allow All Users" rule.
3. Click "Add Allow Rule…" and select the "Specified roles or user groups:" radio button and add "BobAndFriends" and click the "OK" button.


4. Close all Internet Explorer windows because Internet Explorer caches the credentials that you entered in the previous step.
5. Open Internet Explorer and try to access the page using Fred's credentials. You do not get access.
6. Now try Bob's credentials or Alice's credentials. You get access.

Configuring URL Authorization for a single web page

Now we still have the problem left that Alice can still access BobsSecret.aspx. Here is how you fix it:
1. Double click the "Secure" web directory again and select "Content View" at the bottom of the page.
2. You will see a list of files in the secure folder namely "default.aspx" and "bobsSecret.aspx".
3. Right click on bobsSecret.aspx and select "Feature View"

4. Now you are making only changes for the bobsSecret.aspx page as indicated in the statusbar.
5. Select "Authorization Rules" again. You see the inherited settings, i.e. the BobsAndFriends group is allowed to access bobsSecret.aspx.
6. Remove the "BobsAndFriends" rule.
7. Now click "Add Allow Rule…"
8. Click the "Specified users:" radio button, enter "Bob" and click "OK".


9. Close all Internet Explorer windows and request http://localhost/secure/bobsSecret.aspx
10. Only by entering Bob's credentials will you get access.

URL Authorization Advanced Topics

The next paragraphs show some advanced URL Authorization topics.

Configuration

You do not have to use the User Interface to specify URL Authorization settings. You can specify URL Authorization rules directly in your web.config file. The IIS configuration section is delegated by default--you can distribute authorization rules together with web content. Below, see how the %systemdrive%\inetpub\wwwroot\secure\web.config file looks after following this walkthrough:
xml version="1.0" encoding="UTF-8"?>




users="*" roles="" verbs="" />
accessType="Allow" roles="BobAndFriends" />





path="bobsSecret.aspx">



users="" roles="BobAndFriends" verbs="" />
accessType="Allow" users="Bob" />





Differences Between ASP.NET URL Authorization and IIS URL Authorization

There are small but important differences between ASP.NET UrlAuthorization and IIS URL Authorization. Both modules can be installed via the IIS Setup. IIS URL Authorization installs when you install the "URL Authorization" feature in the IIS Setup User Interface:

ASP.NET Url Authorization is installed when you install ASP.NET on top of IIS. If you are an ASP.NET expert, you recall that ASP.NET UrlAuthorization is implemented in the System.Web.Security.UrlAuthorizationModule module. The corresponding configuration section is system.web/authorization. Here is the configuration entry.
name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" preCondition="managedHandler" />

The IIS URL Authorization module is implemented in the global module urlauthz.dll.
name="UrlAuthorizationModule" image="%windir%\System32\inetsrv\urlauthz.dll" />

It is important to keep in mind that the managedHandler precondition is on the ASP.NET UrlAuthorization module. The precondition tells you that the URL authorization module is invoked only when the code that handles the request is mapped to managed code, typically an .aspx or .asmx page. IIS URL Authorization, on the other hand, applies to all content. You can remove the managedHandler precondition from the ASP.NET Url Authorization module. It is there to prevent a performance penality you have to pay when every request (such as a request to .html or .jpg pages) would have to go through managed code.

Rules Evaluation

There are also differences in the order in which IIS and the two URL authorization modules evaluate authorization rules. ASP.NET URL Authorization is developer-focused and developers have full control over which rules they set. IIS URL Authorization keeps the Administrator in mind and tries to make sure that developers cannot override the rules an Administrator sets.
An example:
Suppose the administrator wants to ensure that all users of a particular site must be authenticated. To do this is, set the following configuration on the site root:
lockElements="clear">
accessType="Deny" users="*" />


This configuration denies access to anonymous users (* = anonymous users, ? = authenticated users). With the lockElements="clear", you ensure that no one on a lower level can clear the inheritance of this setting. Your setting would be inherited to all applications and virtual directories of this site. It comes to a lock violation when you try to use the statement at a lower level.
For more information on configuration locking, see http://msdn2.microsoft.com/en-us/library/ms178693.aspx.
You can also lock the clear element in ASP.NET Url Authorization. The problem is that ASP.NET URL Authorization evaluates authorization rules from the bottom up, i.e. it first evaluates rules in the current web.config file before it evaluates parent rules. As soon as a match is found, access is granted or denied. In the above example, you can still grant access to anonymous users by specifying as an authorization rule in the secure web.config file. Because it gets evaluated first, anonymous users would be granted access.
The IIS URL Authorization module evaluates deny rules first. Because you deny access to anonymous users, you cannot simply override that rule. The other big difference is that parent rules are evaluated first. This means that if you deny access for Fred at a higher level, you can't allow access to Fred on a lower level.

Differences table:


Difference ASP.NET URL Authorization Behavior IIS URL Authorization Behavior
Rule evaluation Order:
a) Lower level first going up to the parent
b) Order of appearance in rule collection
Order:
a) Deny rules get evaluated first starting at the parent
b) Allow rules starting at the parent.
c) Order of appearance in rule collection
IIS User Interface No IIS User Interface "Authorization Rules" User Interface
Configuration section system.web/authorization system.webServer/security/authorization
Module System.Web.Security.UrlAuthorization %windir%\system32\inetsrv\urlauthz.dll
Content Applies only to content that is mapped to a managed handler (can be turned off via managedHandler precondition) Applies to all content

Using Domain Accounts and Groups

You must specify domain accounts and groups using the following:
 or username>\

This example uses the machinename, assuming our accounts were created on machine iis7test:
xml version="1.0" encoding="UTF-8"?>




users="*" roles="" verbs="" />
accessType="Allow" roles="iis7test\BobAndFriends" />





path="bobsSecret.aspx">



users="" roles="iis7test\BobAndFriends" verbs="" />
accessType="Allow" users="iis7test\Bob" />





Using Non-Windows Identities

URL Authorization is not only for Windows identities. It works well for non-Windows, too. Use it together with ASP.NET Membership and Roles and for custom identities, in case you write your own authentication module.

Summary

URL Authorization is a powerful new way to specify authorization rules for web applications. Now you can specify rules in XML without using Windows Access Control Lists any longer.

Allow an IIS Manager User Account to Connect to a Site or an Application (IIS 7)

Allow an IIS Manager user to connect to a site or an application when you want to let the user configure delegated features in that site or application in IIS Manager.
IIS Manager user credentials consist of a user name and password pair that are created in IIS Manager and are used exclusively for IIS Manager to access the IIS configuration files. Before allowing an IIS Manager user to connect to a site or an application, you must first add the IIS Manager user account at the server level in IIS Manager. For more information about how to add IIS Manager users, see Create an IIS Manager User Account (IIS 7).
noteNote
For IIS Manager users to connect to sites and applications for which you grant permission, you must configure the management service to accept connections from users who have IIS Manager credentials. For more information about how to configure the management service, see Configuring the Management Service in IIS 7.

Prerequisites

For information about the levels at which you can perform this procedure, and the modules, handlers, and permissions that are required to perform this procedure, see IIS Manager Permissions Feature Requirements (IIS 7).
Exceptions to feature requirements
  • None.

To allow an IIS Manager user to connect to a site or an application

  1. Open IIS Manager. For information about opening IIS Manager, see Open IIS Manager (IIS 7).
  2. In the Connections pane, expand the Sites node and select the site for which you want to grant permission to an IIS Manager user. Or, expand the site and select the application for which you want to grant permission to an IIS Manager user.
  3. In Features View, double-click IIS Manager Permissions.
  4. On the IIS Manager Permissions page, in the Actions pane, click Allow User.
  5. In the Allow User dialog box, select IIS Manager to select a user account that is valid within IIS Manager but that is not a Windows account. Then click Select to open the Users dialog box.
    noteNote
    If the IIS Manager option is disabled, the management service is not configured to accept connections from IIS Manager users. For more information about how to configure the management service, see Configuring the Management Service in IIS 7.

  6. On the Users dialog box, select a user and then click OK.
  7. Click OK to dismiss the Allow User dialog box.

See Also


Monday, November 10, 2014

Error 1935 when you try to install Microsoft Office 2010 or 2007

If you see "Error 1935. An error occurred during the installation of assembly component" when you install Office 2010 or 2007 or one of the Office stand-alone products like Excel, restart the computer and try to run setup again as a quick first step.

If the error still appears after restarting the computer, try these other methods to fix the problem:
Run the System Update Readiness tool
IMPORTANT The System Update Readiness tool can only be used on Windows 7 or Windows Vista operating systems. If you have Windows XP, try one of the other methods in this article.

Select and download the System Update Readiness tool for your version of Windows:

For more information about the System Update Readiness tool and links to download versions for Windows Server operating systems, read What is the System Update Readiness Tool?

Repair or update Microsoft .NET Framework components
First, check installed programs to see if the latest version of .NET Framework is installed. To do this, follow these steps:
  1. Click Start (or Start > Run in Windows XP).
  2. Type appwiz.cpl, and then press Enter.
  3. Look for Microsoft .NET Framework 4 Client Profile in the list of installed programs. See image.
If you find Microsoft .NET Framework 4 Client Profile, follow these steps to repair it:
  1. Close all applications.
  2. Click Start (or Start > Run in Windows XP).
  3. Type appwiz.cpl, and then press Enter.
  4. Click Microsoft .NET Framework 4 Client Profile and click Uninstall/Change (or Change/Remove in Windows XP). See image.
  5. Choose the option to Repair .NET Framework 4 Client Profile to its original state, and then click Next. See image.
  6. When the repair is complete, click Finish, and then click Restart Now to restart the computer.
If you can't find Microsoft .NET Framework 4 Client Profile, download and install it to update the computer. You can download the file from:

Microsoft .NET Framework 4 (Web Installer)
Try to install Microsoft Office again. If error 1935 continues to occur, follow the steps to uninstall and reinstall .NET Framework from the computer.

Uninstall and reinstall Microsoft .NET Framework components
IMPORTANT The .NET Framework Setup Cleanup Utility provided here should only be used only after you've tried the previous options.

To uninstall .NET Framework components from the computer follow these steps:
  1. Create a temporary folder on your desktop.
  2. Visit the .NET Framework Cleanup Tool User's Guide blog and download the dotnetfx_cleanup_tool.zip file.
  3. When prompted, click Open, and then click Extract Now. Extract the files to the folder you created.
  4. Find cleanup_tool.exe in the folder you created and double-click it.
  5. In the "Do you want to run the .NET Framework Setup Cleanup Utility?" message, click Yes.
  6. Click Yes to accept the license agreement.
  7. In the Product to cleanup window, choose a .NET Framework version that you want to remove.

    Note You can't remove .NET Framework versions that are part of the Windows operating system. If you have Windows 7, you can't remove .NET Framework versions 3.5 or lower. If you have Windows Vista, you can't remove .NET Framework versions 3.0 or lower. If you have Windows XP, you can't remove .NET Framework versions 2.0 or lower.
  8. Click Cleanup Now.
  9. Restart the computer once the .NET Framework component is removed.
  10. Download and install the following components, one at a time, based on your operating system:
  11. Restart the computer, and run Windows Update to install updates.

How to Configure Windows Firewall to Work with SQL Server

1. Open the Windows Firewall

Go to control panel >> Windows Firewall

Turn on Windows Firewall

2. Add SQL Server Default Port 1433 on Exception, if you are using default instance.

Add SQL Server default port in Windows firewall exception list

3. Add custom SQL Server Port, if you are using named instance. To know the custom port, you may view/edit SQL Server port configurations by going into properties of TCP/IP protocol in SQL Server Configuration Manager for a specific instance of SQL Server as shown below.
view or edit sql server port configuration
By clicking on Properties, you will get the TCP/IP properties. Go to the IP Addresses tab and here you may edit/view port configurations for a specific instance of SQL Server.

Then Add a Port, refer to #2, suppose the custom port is 55120.
Add SQL Server custom port in Windows firewall exception list

4. SQL Server Browser service, you would also add port 1434 UDP in exception list as shown below.

Add SQL Server browser service in Windows firewall exception list






Monday, November 3, 2014

Configure Automatic Updates by Using Group Policy

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server Update Services
When you configure the Group Policy settings for WSUS, use a Group Policy object (GPO) linked to an Active Directory container appropriate for your environment. Microsoft does not recommend editing the Default Domain or Default Domain Controller GPOs to add WSUS settings.
In a simple environment, link the GPO with the WSUS settings to the domain. In more complex environment, you might have multiple GPOs linked to several organizational units (OUs), which enables you to have different WSUS policy settings applied to different types of computers.
After you set up a client computer, it will take a few minutes before it appears on the Computers page in the WSUS console. For client computers configured with an Active Directory-based GPO, it will take about 20 minutes after Group Policy refreshes (that is, applies any new settings to the client computer). By default, Group Policy refreshes in the background every 90 minutes, with a random offset of 0 to 30 minutes. If you want to refresh Group Policy sooner, you can go to a command prompt on the client computer and type: gpupdate /force.
noteNote
On client computers running Windows 2000, you can type the following at a command prompt: secedit /refreshpolicy machine_policy enforce.

The following is a list of the Group Policy options available for configuring WSUS-related items in the environment.
noteNote
In Windows 2000, Group Policy Object Editor is known as Group Policy Editor. Although the name changed, it is the same tool for editing Group Policy objects. It is also commonly referred to as gpedit.

Load the WSUS Administrative Template

Before you can set any Group Policy options for WSUS, you must ensure that the latest administrative template has been loaded on the computer used to administer Group Policy. The administrative template with WSUS settings is named Wuau.adm. Although there are additional Group Policy settings related to the Windows Update Web site, all the new Group Policy settings for WSUS are contained within the Wuau.adm file.
If the computer you are using to configure Group Policy has the latest version of Wuau.adm, you do not need to load the file to configure settings. The new version of Wuau.adm is available on Windows XP with Service Pack 2. Administrative templates files are stored by default in the %windir%\Inf directory.
ImportantImportant
You can find the correct version of Wuau.adm on any computer having the WSUS-compatible Automatic Updates installed. You can use the old version of Wuau.adm to initially point Automatic Updates to the WSUS server in order to self-update. After the Automatic Updates self-updates, the new Wuau.adm file appears in the %windir%\Inf folder.

If the computer you are using to configure Group Policy does not have the latest version of Wuau.adm, you must first load it by using the following procedure.

To add the WSUS Administrative Template

  1. In Group Policy Object Editor, click either of the Administrative Templates nodes.
  2. On the Action menu, click Add/Remove Templates.
  3. Click Add.
  4. In the Policy Templates dialog box, select Wuau.adm, and then click Open.
  5. In the Add/Remove Templates dialog box, click Close.

Configure Automatic Updates

The settings for this policy enable you to configure how Automatic Updates works. You must specify that Automatic Updates download updates from the WSUS server rather than from Windows Update.

To configure the behavior of Automatic Updates

  1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
  2. In the details pane, click Configure Automatic Updates.
  3. Click Enabled and select one of the following options:
    • Notify for download and notify for install. This option notifies a logged-on administrative user prior to the download and prior to the installation of the updates.
    • Auto download and notify for install. This option automatically begins downloading updates and then notifies a logged-on administrative user prior to installing the updates.
    • Auto download and schedule the install. If Automatic Updates is configured to perform a scheduled installation, you must also set the day and time for the recurring scheduled installation.
    • Allow local admin to choose setting. With this option, the local administrators are allowed to use Automatic Updates in Control Panel to select a configuration option of their choice. For example, they can choose their own scheduled installation time. Local administrators are not allowed to disable Automatic Updates.
  4. Click OK.

Specify Intranet Microsoft Update Service Location

The settings for this policy enable you to configure a WSUS server that Automatic Updates will contact for updates. You must enable this policy in order for Automatic Updates to download updates from the WSUS server.
Enter the WSUS server HTTP(S) URL twice, so that the server specified for updates is also used for reporting client events. For example, type http(s)://servername in both boxes. Both URLs are required.

To redirect Automatic Updates to a WSUS server

  1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
  2. In the details pane, click Specify Intranet Microsoft update service location.
  3. Click Enabled and type the HTTP(S) URL of the same WSUS server in the Set the intranet update service for detecting updates box and in the Set the intranet statistics server box. For example, type http(s)://servername in both boxes.
  4. Click OK.

Enable Client-side Targeting

This policy enables client computers to self-populate computer groups that exist on the WSUS server.
If the status is set to Enabled, the specified computer group information is sent to WSUS, which uses it to determine which updates should be deployed to this computer. This setting is only capable of indicating to the WSUS server which group the client computer should use. You must actually create the group on the WSUS server.
If the status is set to Disabled or Not Configured, no computer group information will be sent to WSUS.

To enable client-side targeting

  1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
  2. In the details pane, click Enable client-side targeting.
  3. Click Enabled and type the name of the computer group in the box.
  4. Click OK.

Reschedule Automatic Update Scheduled Installations

This policy specifies the amount of time for Automatic Updates to wait, following system startup, before proceeding with a scheduled installation that was missed previously.
If the status is set to Enabled, a scheduled installation that did not take place earlier will occur the specified number of minutes after the computer is next started.
If the status is set to Disabled, a missed scheduled installation will occur with the next scheduled installation.
If the status is set to Not Configured, a missed scheduled installation will occur one minute after the computer is next started.
This policy applies only when Automatic Updates is configured to perform scheduled installations of updates. If the Configure Automatic Updates policy is disabled, this policy has no effect.

To reschedule Automatic Update scheduled installation

  1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
  2. In the details pane, click Reschedule Automatic Update scheduled installations, click Enable, and type a value in minutes.
  3. Click OK.

No Auto-restart for Scheduled Automatic Update Installation Options

This policy specifies that to complete a scheduled installation, Automatic Updates will wait for the computer to be restarted by any user who is logged on, instead of causing the computer to restart automatically.
If the status is set to Enabled, Automatic Updates will not restart a computer automatically during a scheduled installation if a user is logged on to the computer. Instead, Automatic Updates will notify the user to restart the computer in order to complete the installation.
Be aware that Automatic Updates will not be able to detect future updates until the restart occurs.
If the status is set to Disabled or Not Configured, Automatic Updates will notify the user that the computer will automatically restart in 5 minutes to complete the installation.
This policy applies only when Automatic Updates is configured to perform scheduled installations of updates. If the Configure Automatic Updates policy is disabled, this policy has no effect.

To inhibit auto-restart for scheduled Automatic Update installation options

  1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
  2. In the details pane, click No auto-restart for scheduled Automatic Update installation options, and set the option.
  3. Click OK.

Automatic Update Detection Frequency

This policy specifies the hours that Windows will use to determine how long to wait before checking for available updates. The exact wait time is determined by using the hours specified here, minus 0 to 20 percent of the hours specified. For example, if this policy is used to specify a 20-hour detection frequency, then all WSUS clients to which this policy is applied will check for updates anywhere between 16 and 20 hours.
If the status is set to Enabled, Automatic Updates will check for available updates at the specified interval.
If the status is set to Disabled or Not Configured, Automatic Updates will check for available updates at the default interval of 22 hours.

To set Automatic Update detection frequency

  1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
  2. In the details pane, click Automatic Update detection frequency, and set the option.
  3. Click OK.

Allow Automatic Update Immediate Installation

This policy specifies whether Automatic Updates should automatically install certain updates that neither interrupt Windows services nor restart Windows.
If the status is set to Enabled, Automatic Updates will immediately install these updates after they have been downloaded and are ready to install.
If the status is set to Disabled, such updates will not be installed immediately.

To allow Automatic Update immediate installation

  1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
  2. In the details pane, click Allow Automatic Update immediate installation, and set the option.
  3. Click OK.

Delay Restart for Scheduled Installations

This policy specifies the amount of time for Automatic Updates to wait before proceeding with a scheduled restart.
If the status is set to Enabled, a scheduled restart will occur the specified number of minutes after the installation is finished.
If the status is set to Disabled or Not Configured, the default wait time is five minutes.

To delay restart for scheduled installations

  1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
  2. In the details pane, click Delay restart for scheduled installations, and set the option.
  3. Click OK.

Re-prompt for Restart with Scheduled Installations

This policy specifies the amount of time for Automatic Updates to wait before prompting the user again for a scheduled restart.
If the status is set to Enabled, a scheduled restart will occur the specified number of minutes after the previous prompt for restart was postponed.
If the status is set to Disabled or Not Configured, the default interval is 10 minutes.

To re-prompt for restart with scheduled installations

  1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
  2. In the details pane, click Re-prompt for restart with scheduled installations, and set the option.
  3. Click OK.

Allow Non-administrators to Receive Update Notifications

This policy specifies whether logged-on non-administrative users will receive update notifications based on the configuration settings for Automatic Updates. If Automatic Updates is configured, by policy or locally, to notify the user either before downloading or only before installation, these notifications will be offered to any non-administrator who logs onto the computer.
If the status is set to Enabled, Automatic Updates will include non-administrators when determining which logged-on user should receive notification.
If the status is set to Disabled or Not Configured, Automatic Updates will notify only logged-on administrators.

To allow non-administrators to receive update notifications

  1. In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
  2. In the details pane, click Allow non-administrators to receive update notifications, and set the option.
  3. Click OK.
noteNote
This policy setting does not allow non-administrative Terminal Services users to restart the remote computer where they are logged in. This is because, by default, non-administrative Terminal Services users do not have computer restart privileges.

Remove Links and Access to Windows Update

If this setting is enabled, Automatic Updates receives updates from the WSUS server. Users who have this policy set cannot get updates from a Windows Update Web site that you have not approved. If this policy is not enabled, the Windows Update icon remains on the Start menu for local administrators to visit the Windows Update Web site. Local administrative users can use it to install unapproved software from the public Windows Update Web site. This happens even if you have specified that Automatic Updates must get approved updates from your WSUS server.

To remove links and access to Windows Update

  1. In Group Policy Object Editor, expand User Configuration, expand Administrative Templates, and then click Start Menu and Taskbar.
  2. In the details pane, click Remove links and access to Windows Update, and set the option.
  3. Click OK.