Group Policy objects store information in two locations: a Group Policy container and a Group Policy template.
Group Policy Container
The Group Policy container is an Active Directory container that stores GPO properties; it includes sub-containers for computer and user Group Policy information. The Group Policy container has the following properties:
· Version information. This is used to ensure that the information is synchronized with the Group Policy template information. Indicates the number of changes made to the GPO.
· Status information. This indicates whether the GPO is enabled or disabled.
· List of components (extensions) that have settings in the GPO.
· File System path. The UNC path to the Sysvol folder.
· Functionality version. This is the version of the tool that created the GPO. Currently, this is version 1.
For example, the Group Policy container stores information used by the Software Installation snap-in to describe the state of the software available for installation. This data repository contains data for all applications, interfaces, and APIs that provide for application publishing and assigning.
Group Policy Template
Group Policy objects also store Group Policy information in a folder structure called the Group Policy template that is located in the System Volume folder of domain controllers (Sysvol) in the \Policies sub-folder. The Group Policy template is the container where Security Settings, Administrative Template-based policy settings, applications available for Software Installation, and script files are stored.
When you modify a GPO, the directory name given to the Group Policy template is the GUID of the GPO that you modified. For example, assume that you modified a GPO associated with a domain called Seattle. The resulting Group Policy template folder would be named as follows (the GUID is an example):
%systemroot%\sysvol\<SYSVOL>\Seattle.yourcompanyname.com\Policies\{47636445-af79-11d0-91fe-080036644603}
where the second sysvol is shared as Sysvol. (The default location of the Sysvol folder is %systemroot%).
Gpt.ini File
At the root of each Group Policy template folder is a file called Gpt.ini. For local Group Policy Objects, the Gpt.ini file stores information indicating the following:
· Which client-side extensions of the Group Policy Object Editor contain User or Computer data in the GPO.
· Whether the User or Computer portion is disabled.
· Version number of the Group Policy Object Editor extension that created the Group Policy Object.
[General]
gPCUserExtensionNames //Includes a list of GUIDs that tells the client side engine which Client Side Extensions have User data in the GPO.
The format is: [{GUID of Client Side Extension}{GUID of MMC extension}{GUID of second MMC extension if appropriate}][repeat first section as appropriate].
GPCMachineExtensionNames //Includes a list of GUIDs that tells the client side engine which Client Side Extensions have Machine data in the GPO.
Options..//Refers to GPO options such as User portion disabled or Machine portion disabled.
GPCFunctionalityVersion //The Version number of the Group Policy extension tool that created the Group Policy object.
The Gpt.ini file for Active Directory GPOs contains the following entries, which are stored in Active Directory:
Version=0 //Version number of the Group Policy Object
DisplayName //Display name of the GPO
Local Group Policy Objects
A local Group Policy Object exists on every computer, and by default it contains only security policy (that is, other types of policy settings are not configured by default).The local GPO is stored in %systemroot%\System32\GroupPolicy, and it has the following ACL permissions:
· Administrators: full control
· Operating system: full control
· User: read
Group Policy Template Subfolders
The Group Policy template folder contains the following subfolders:
· User. Includes a Registry.pol file that contains the registry settings to be applied to users. When a user logs on to a computer, this Registry.pol file is downloaded and applied to the HKEY_CURRENT_USER portion of the registry.
· Applications. Contains the advertisement files (.aas files) used by the Windows installer. These are applied to users.
· Documents and Settings. Contains the Fdeploy.ini file, which includes status information about the Folder Redirection options for the current user’s special folders.
· Microsoft\RemoteInstall. Contains the OSCfilter.ini file, which holds user options for operating system installation through Remote Installation Services.
· Microsoft\IEAK. Contains settings for the Internet Explorer Maintenance Snap-in.
· Scripts\Logon. Contains all the user logon scripts and related files for this GPO.
· Scripts\Logoff. Contains all the user logoff scripts and related files for this GPO.
· Machine. Includes a Registry.pol file that contains the registry settings to be applied to computers. When a computer initializes, this Registry.pol file is downloaded and applied to the HKEY_LOCAL_MACHINE portion of the registry.
· Scripts\Startup. Contains the scripts that are to run when the computer starts up.
· Scripts\Shutdown. Contains the scripts that are to run when the computer shuts down.
· Applications. Contains the advertisement files (.aas files) used by the Windows installer. These are applied to computers.
· Microsoft\Windows NT\Secedit. Contains the Gpttmpl.inf file, which includes the default security configuration settings for a Windows 2000 domain controller.
· Adm. Contains all of the .adm files for this GPO.
The User and Machine folders are created at install time, and the other folders are created as needed when policy is set.
Registry.pol Files
The Administrative Templates snap-in extension of Group Policy saves information in the Group Policy template in Unicode files referred to as Registry.pol files; they are stored in the Group Policy template. These files contain the customized registry settings that you specify (by using the Group Policy Object Editor) to be applied to the Computer (HKEY_LOCAL_MACHINE) or User (HKEY_CURRENT_USER) portion of the registry.
Two Registry.pol files are created and stored in the Group Policy template, one forComputer Configuration, which is stored in the \Machine subdirectory, and one forUser Configuration, which is stored in the \User subdirectory.
When you use the Administrative Templates extension of the Group Policy Object Editor to define customized registry settings, two Registry.pol files are created and stored in the Group Policy template. One Registry.pol file is for Computer Configuration-related registry settings and is stored in the \Machine sub-directory, and the other is for User Configuration settings and is stored in the \User sub-directory.
The header contains version information and signature data, both DWORD values:
REGFILE_SIGNATURE 0x67655250
REGISTRY_FILE_VERSION 00000001 (increments each time the file format changes)
The registry values begin with an opening bracket ([) and end with a closing bracket (]):
[key;value;type;size;data]
where:
Key is the path to the registry key to use for the category. Do not includeHKEY_LOCAL_MACHINE or HKEY_CURRENT_USER in the registry path. The location of the file determines which of these keys is used.
The following value has special meaning for this field:
· **DeleteKeys—a semi-colon-delimited list of values to delete.
For example: **DeleteKeys NoRun;NoFind.
Value is the name of the registry value. The following values have special meaning for this field:
· **DeleteValues—a semi-colon-delimited list of values to delete. Use as a value of the associated key.
· **Del.valuename—deletes a single value. Use as a value of the associated key.
· **DelVals—deletes all values in a key. Use as a value of the associated key.
Type is a data type. The field can be any of the standard registry value types, for example:
· REG_DWORD
· REG_EXPAND_SZ
· REG_SZ
Note that although the file format supports all the registry data types (such asREG_MULTI_SZ), the Administrative Templates node does not support these registry types: REG_BINARY, REG_MULTI_SZ.
Size is the size of the data field in bytes. For example, 4.
Data is the raw information. For example, 4 bytes of data 0x00000001.
It is possible that the valuename, type, data, and size could be missing or 0. In this case, only the key should be created.
This pattern of [] entries continues until the end of the file.
The following special values are used for deleting keys and values:
· **DeleteKeys // Semi-colon-delimited list of keys to delete.
For example: **DeleteKeys REG_SZ NoRun;NoFind.
· **DeleteValues // Semi-colon-delimited list of values to delete.
Used as a value of the designated key.
· **Del.valuename // Deletes a single value name.
Used as a value of the designated key.
· **DelVals // Deletes all values in a key.
Used as a value of the designated key.
The Registry.pol file contains data to be written to the registry based on the settings specified with the Group Policy Object Editor, and the names of any scripts and their command lines (in the form of registry keys and values).
How Registry.pol Files Are Created
The following section outlines how to form Registry.pol files:
· When you start the Group Policy Object Editor, a temporary registry tree is created that consists of two nodes: USER and MACHINE.
· As you navigate the Administrative Templates node of the Group Policy Object Editor, .adm file nodes are displayed. The .adm files within the Group Policy Object Editor nodes are loaded dynamically when a particular node is selected, and the .adm file is then cached.
· When a policy is selected in the details pane (the right side of MMC console window), the temporary registry is queried to determine whether the selected policy already has registry values assigned to it; if it does, those values are displayed in thePolicy dialog box.
If the selected policy does not have a registry value assigned to it, the default value from the .adm file or from the associated MMC snap-in extension is used.
· After you modify a policy, the registry values that you specify are written to the appropriate portion of the temporary registry (either MACHINE or USER).
· When you close the Group Policy Object Editor, the temporary registry hives are exported to the Registry.pol files in the appropriate folders of the Group Policy template.
The next time you start the Group Policy Object Editor for the same Group Policy Object for which you have previously set Group Policy settings, the registry information from the corresponding Registry.pol files is imported into the temporary registry tree. Therefore, when you view the policy settings, they reflect the current state. |
Wednesday, 3 October 2012
Where are Group Policy objects stored
Monday, 9 July 2012
Trouble hooting AD Replication issues PART 1
AD Replication is not working between NYC
and london
1.
Deleted
all the replication partners configured manually for and under NYC-DC-01
2.
Ran
command repadmin /kcc on NYC-DC-01
3.
Opened
dssite.msc on nyc-dc-01 and confirmed replication partner got populate
automatically as DCLON1
4.
Tried
replicate now and it was able to pull replication from DCLON1
5.
Ran
command repadmin /kcc on DCLON1
6.
Opened
dssite.msc on DCLON1 and confirmed replication partner got populate
automatically as NYC-DC-01
7.
Tried
replicate now but it failed with error message
---------------------------
Replicate Now
---------------------------
The following error occurred during the attempt to
synchronize naming context pcdir.int.gnl from domain controller NYC-DC-01 to
domain controller DCLON1:
The naming context is in the process of being removed
or is not replicated from the specified server.
This operation will not continue.
---------------------------
OK
---------------------------
8.
Above
error message points out to DNS issues
9.
On
NYC-DC-01 confirmed it was point to Infoblox servers for name resolution
10.
DNS
server was also installed on NYC-DC-01 and was running secondary zone for
PCDIR.INT.GNL getting transferred from Infoblox servers
11.
Checked
and confirmed all the records for domain controller NYC-DC-01 were registered correctly
12.
Tried
ping GUID for NYC-DC-01 from DCLON1 and vice versa and both worked fine
13.
Tried
access \\nyc-dc-01 from DCLON1 and vice versa
and this also worked fine
14.
Checked
event viewer on DCLON1
15.
Found
event ID getting generated every time ran command repadmin /kcc on it for all
the partitions
Event
Type: Warning
Event
Source: NTDS KCC
Event Category: Knowledge
Consistency Checker
Event
ID:
1925
Date:
31/05/2012
Time:
07:48:01
User:
NT AUTHORITY\ANONYMOUS LOGON
Computer:
DCLON1
Description:
The attempt to establish a replication link for the
following writable directory partition failed.
Directory partition:
CN=Configuration,DC=pcdir,DC=int,DC=gnl
Source domain controller:
CN=NTDS
Settings,CN=NYC-DC-01,CN=Servers,CN=NYCUS,CN=Sites,CN=Configuration,DC=pcdir,DC=int,DC=gnl
Source domain controller address:
d634407b-dd98-43e2-a6ec-b14d09ddd5b1._msdcs.pcdir.int.gnl
Intersite transport (if any):
CN=IP,CN=Inter-Site
Transports,CN=Sites,CN=Configuration,DC=pcdir,DC=int,DC=gnl
This domain controller will be unable to replicate
with the source domain controller until this problem is corrected.
User Action
Verify if the source domain controller is accessible
or network connectivity is available.
Additional Data
Error value:
1753 There are no more endpoints available from the
endpoint mapper.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
16.
Checked
under registry key on DCLON1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Registry value:
TCP/IP Port
Value type:
REG_DWORD
Value data: 65000
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Registry value:
DCTcpipPort
Value type:
REG_DWORD
Value data: 65000
17.
Checked
the same setting under NYC-DC-01 they were not defined
18.
Checked
for the same registry keys under all the domain controller in London site and
they were listed in all
19.
Created
the values in NYC-DC-01 also
20.
Restarted
the domain controller for getting the registry changes in use
21.
Checked
replication from NYC-DC-01 was it worked fine for DCLON1
22.
Ran
command repadmin /kcc on DCLON1 again and this time different events got
registered
Event
Type: Error
Event
Source: NTDS Replication
Event
Category: Replication
Event
ID:
2042
Date:
31/05/2012
Time:
08:05:09
User:
NT AUTHORITY\ANONYMOUS LOGON
Computer:
DCLON1
Description:
It has been too
long since this machine last replicated with the named source machine. The time
between replications with this source has exceeded the tombstone lifetime.
Replication has been stopped with this source.
The reason that
replication is not allowed to continue is that the two machine's views of
deleted objects may now be different. The source machine may still have copies
of objects that have been deleted (and garbage collected) on this machine. If
they were allowed to replicate, the source machine might return objects which
have already been deleted.
Time of last
successful replication:
2012-03-28
13:25:21
Invocation ID of
source:
057af820-f810-057a-0100-000000000000
Name of source:
d634407b-dd98-43e2-a6ec-b14d09ddd5b1._msdcs.pcdir.int.gnl
Tombstone
lifetime (days):
60
The replication
operation has failed.
User Action:
Determine which
of the two machines was disconnected from the forest and is now out of date.
You have three options:
1. Demote or reinstall
the machine(s) that were disconnected.
2. Use the
"repadmin /removelingeringobjects" tool to remove inconsistent
deleted objects and then resume replication.
3. Resume
replication. Inconsistent deleted objects may be introduced. You can continue replication
by using the following registry key. Once the systems replicate once, it is
recommended that you remove the key to reinstate the protection.
Registry
Key:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow
Replication With Divergent and Corrupt Partner
For more
information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
23.
Created
registry key
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow
Replication With Divergent and Corrupt Partner
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Strict
Replication Consistency
Both values set
to 1
24.
Did
replicate now from DCLON1 for NYC-DC-01 and this time it worked fine
25.
Ran
command repadmin /syncall /ePAD from both the domain controllers and confirmed
all the partitions were getting replicated
26.
Restarted
NTFRS service and confirmed SYSVOL and Netlogon were also getting replicated
Therefore the issue here are was firstly
AD replication was set to work only on specific port over the firewall and
secondly since replication had not worked since long time NYC-DC-01 was been
marked as tombstone. Please feel free to confirm if any more details are
required.
Thursday, 31 May 2012
Configure Automatic Updates by Using Group Policy
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.
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.
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.
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
- In Group Policy Object Editor, click either of the Administrative Templates nodes.
- On the Action menu, click Add/Remove Templates.
- Click Add.
- In the Policy Templates dialog box, select Wuau.adm, and then click Open.
- 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
- In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
- In the details pane, click Configure Automatic Updates.
- 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.
- 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
- In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
- In the details pane, click Specify Intranet Microsoft update service location.
- 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.
- 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
- In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
- In the details pane, click Enable client-side targeting.
- Click Enabled and type the name of the computer group in the box.
- 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
- In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
- In the details pane, click Reschedule Automatic Update scheduled installations, click Enable, and type a value in minutes.
- 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
- In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
- In the details pane, click No auto-restart for scheduled Automatic Update installation options, and set the option.
- 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
- In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
- In the details pane, click Automatic Update detection frequency, and set the option.
- 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
- In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
- In the details pane, click Allow Automatic Update immediate installation, and set the option.
- 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
- In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
- In the details pane, click Delay restart for scheduled installations, and set the option.
- 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
- In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
- In the details pane, click Re-prompt for restart with scheduled installations, and set the option.
- 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
- In Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Update.
- In the details pane, click Allow non-administrators to receive update notifications, and set the option.
- Click OK.
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
- In Group Policy Object Editor, expand User Configuration, expand Administrative Templates, and then click Start Menu and Taskbar.
- In the details pane, click Remove links and access to Windows Update, and set the option.
- Click OK.
Subscribe to:
Posts (Atom)