The GPMC shows precedence as a number.
The smaller the number—that is, the closer to 1—the higher the precedence.
Therefore, a GPO that has a precedence of 1 will prevail over other GPOs. Select the relevant AD DS container, and then click the Group Policy Inheritance tab to view the precedence of each GPO.
2015年11月8日星期日
2015年9月3日星期四
Don't be afraid of DNS Scavenging. Just be patient.
DNS Scavenging is a great answer to a problem that has been nagging everyone since RFC 2136 came out way back in 1997. Despite many clever methods of ensuring that clients and DHCP servers that perform dynamic updates clean up after themselves sometimes DNS can get messy. Remember that old test server that you built two years ago that caught fire before it could be used? Probably not. DNS still remembers it though. There are two big issues with DNS scavenging that seem to come up a lot:
"I'm hitting this 'scavenge now' button like a snare drum and nothing is happening. Why?"
or
"I woke up this morning, my DNS zones are nearly empty and Active Directory is sitting in a corner rocking back and forth crying. What happened?"
This post should help us figure out when the first issue will happen and completely avoid the second. We'll go through how scavenging is setup then I'll give you my best practices.
Scavenging setup
Scavenging will help you clean up old unused records in DNS. Since "clean up" really means "delete stuff" a good understanding of what you are doing and a healthy respect for "delete stuff" will keep you out of the hot grease. Because deletion is involved there are quite a few safety valves built into scavenging that take a long time to pop. When enabling scavenging patience is required. It will work just fine, but not today!
Note: For purposes of this discussion we are going to concentrate on the most common Windows DNS scenario: Windows Server 2003 DNS servers hosting AD integrated zones.
Scavenging is set in three places on a Windows Server:
- On the individual resource record to be scavenged.
- On a zone to be scavenged.
- At one or more servers performing scavenging.
It must be set in all three places or nothing happens.
Scavenging settings on a Resource Record
To see the scavenging setting on a record hit View | Advanced in the DNS MMC then bring up properties on a record.
Scavenging gets set on a resource record in one of three ways. The first is by someone coming in here, checking the "Delete this record when it becomes stale" checkbox and hitting apply. When you hit apply the time of day will be rounded down to the nearest hour and applied as the timestamp on the record. Static records have a timestamp of 0 indicating do not scavenge.
The second is when a record gets created by a client machine registering using dynamic DNS. Windows clients will attempt to dynamically update DNS every 24 hours. All DDNS records get set to scavenge. When a record is first created by a client that has no existing record it is considered an "Update" and the timestamp is set. If the client has an existing host record and changes the IP of the host record this is also considered an "Update" and the timestamp is set. If the client has an existing host record with the same IP address then this is considered a "Refresh" and the timestamp may or may not get changed depending on zone settings. More on this later.
The third way to set scavenging on records is by using DNScmd.exe with the /ageallrecords switch. Let's pause here for a few moments to consider a few important words: All, Records, Delete, Stuff. If you actually run this command against a zone it will truly set scavenging and a timestamp on all records in the zone including static records that you never want to be scavenged. Because of the time it takes scavenging to do it's thing people find this command and get tempted to give it a try. Do not. It will delete stuff. Have patience instead.
Once a timestamp is set on a record it will replicate around to all servers that host the zone. There is one caveat to this. If scavenging is not enabled on the zone that hosts the record then it will never scavenge so the timestamp is essentially irrelevant. The timestamp may get updated on the server where the client dynamically registers but it will not replicate around to the other servers in the zone.
Scavenging Settings at the Zone
Before a server will even look at a record to see if it will be scavenged the zone must have scavenging enabled. To access the scavenging settings for a zone right click the zone, select properties then on the general tab hit the "Aging" button. This screen is universal for the zone. If you view it on any DNS server where this zone is replicated it will be the same.
When you first set scavenging on a zone the timestamp seen at the bottom (reload zone if you don't see it) will be set to the current time of day rounded down to the nearest hour plus the Refresh interval. This also gets reset any time the zone is loaded or any time dynamic updates get enabled on the zone.
The "zone can be scavenged after" timestamp is the first of your safety valves. It gives clients time to get their record timestamp updated before the big axe swings. Since new record timestamps are not replicated while zone scavenging is disabled this also gives replication time to get things in order.
Refresh and No-Refresh intervals
The next safety valves are the Refresh and No-refresh intervals. Both of these must elapse before a record can be deleted.
The No-refresh interval is a period of time during which a resource record cannot be refreshed. Recall from earlier that a refresh is a dynamic update where we are not changing the host/IP of a resource record, just touching the timestamp. If a client changes the IP of a host record this is considered an "update" and is exempt from the No-refresh interval. The purpose of a No-refresh interval is simply to reduce replication traffic. A change to a record means a change that must be replicated.
After the (Record Timestamp) + (No-refresh interval) elapses we enter the Refresh interval. The refresh interval is the time when refreshes to the timestamp are allowed. This is the time when good things must happen. The client is allowed to come in and update it's timestamp. This timestamp will be replicated around and the No-refresh interval begins again. If for some reason the client fails to update it's record during the refresh interval it becomes eligible to be scavenged. Will it disappear immediately? Probably not but it is certainly possible.
Note: When setting Refresh and No-Refresh intervals be sure to allow enough time for clients to get several registration attempts during a Refresh interval. Failure to do so could allow a record to become eligible for scavenging simply from a failed refresh attempt.
One last thing before we leave the zone setting behind. If you right click on your server you will see the option to "Set Aging/Scavenging for All Zones...". Selecting this will take you to a screen similar to the one above. What does this do? This sets the default settings that will be used if a new zone is created by this server. Unless you check the subsequent box "Apply these settings to the existing Active Directory-integrated zones" it will not touch existing zones.
Scavenging settings on the Server
So you now have a resource resource record set to scavenge and a zone set to scavenge. All that is left is for somebody to come along, check all the timestamps and delete some stuff. This is done by any server that hosts the AD integrated zone.
Setting scavenging on the server is done by right clicking the server in the MMC, selecting properties, going to the advanced tab and checking the "Enable automatic scavenging of stale records" checkbox.
The Scavenging Period is how often this particular server will attempt to scavenge. When a server scavenges it will log a DNS event 2501 to indicate how many records were scavenged. An event 2502 will be logged if no records were scavenged. Only one server is required to scavenge since the zone data is replicated to all servers hosting the zone.
Tip: You can tell exactly when a server will attempt to scavenge by taking the timestamp on the most recent 2501/2502 event and adding the Scavenging period to it.
Although you can set every server hosting the zone to scavenge I recommend just having one. The logic for this is simple: If the one server fails to scavenge the world won't end. You'll have one place to look for the culprit and one set of logs to check. If on the other hand you have many servers set to scavenge you have many logs to check if scavenging fails. Worse yet, if things start disappearing unexpectedly you don't want to go hopping from server to server looking for 2501 events.
To facilitate strict control over which server is scavenging for a zone you can use DNSCmd.exe to specify exactly which servers may scavenge. For example the following command will make it so that only 192.168.1.1 and 192.168.1.2 DNS servers are allowed to scavenge on the contoso.com zone:
DNSCmd . /ZoneResetScavengeServers contoso.com 192.168.1.1 192.168.1.2
With the server now scavenging, zones enabled for scavenging, and resources records set what actually happens when the server does it's thing?
The scavenging process and final safety valves
When the last 2501/2052 event + the server scavenging period comes around the server is going to make a scavenging attempt. You can also manually initiate an attempt by right clicking the server and selecting "Scavenge Stale Resource Records". Note that manually making an attempt in no way bypasses the safety valves. These are the final safety valves before we "delete stuff":
- Is scavenging enabled on the zone? Pretty self explanatory.
- Is dynamic update enabled on the zone? If it's not there is a good chance timestamps will be old enough that mass deletions can occur.
- Is the scavenging server listed as one of the "Scavenge Servers" for the zone?
- Are we past the "zone can be scavenged after" timestamp on the zone? This gives the clients and AD replication to get things squared away before we start.
- Has it been longer than a refresh interval since this zone was last replicated in Active Directory? If scavenging gets enabled on a server that has replication issues this will prevent it from tombstoning a bunch of records that may be perfectly fine on other servers.
If all of the above checks are good then the zone is ready to be scavenged. At this point the scavenging server checks the timestamp on each individual resource record. If the current date/time is greater than the timestamp + No-refresh + Refresh then the record is deleted.
My best practices
Here is how I set scavenging up on a preexisting zone. This procedure is designed for maximum safety. Using default settings this process can take as long as 4-5 weeks (2 weeks Sanity phase, 2-3 weeks for Enable phase)
Setup phase
- Turn off scavenging on all servers. To confirm scavenging won't inadvertently run use the DNSCmd /ZoneResetScavengeServers to confine scavenging to a single server then ensure this server has scavenging disabled.
- Turn on scavenging on the zones you wish to scavenge. Set the refresh and No-refresh intervals as desired. If you want things to scavenge more aggressively I would recommend lowering the No-refresh interval at the cost of some replication traffic. Leave the refresh at the default.
- Add today's date plus the Refresh and No-Refresh intervals. Come back in a few weeks when this time has elapsed. Seriously you can't rush this.
Sanity check phase
Sift through your DNS records looking for any records older than the Refresh + No-Refresh interval. If you see any then something has gone wrong with the dynamic registration process and it must be corrected before proceeding. A thorough check at this point is the most important step in setup
Things to check if you find old records:
- Does an IPConfig /registerdns work?
- Who is the owner of the record (see security tab in the record properties)?
- Was the record statically created by an admin then later enabled for scavenging? If so you may need to delete the record to clear ownership and run an IPConfig /registerdns to get it updated.
- Is the server replicating OK with AD?
Do not proceed unless you can explain any outdated records. In the next phase they will be deleted.
Enable phase
The final step is to actually enable scavenging. Enable scavenging on the single server you used the /ZoneResetScavengServers command on.
Once enabled create a new test record and enable it for scavenging. Then map out the point in time when this record will disappear. Here is how:
- Start with the timestamp on the record
- Add the refresh interval
- Add the no refresh interval
- The result will be your "eligible to scavenge" time. The record will not disappear at this time though. It's just eligible.
- Check your DNS event logs for 2501 and 2502 events to find what hour the DNS server is doing a scavenging run.
- Take your "eligible to scavenge" time, find the most recent 2501/2502 event and add the server's Scavenging Period (from server properties | advanced tab) to it. This is the point in time when the test record you just created will disappear.
Lets look at an example with the following assumptions:
- Zone is set to a 3 day Refresh and a 3 day No-Refresh interval
- Server Scavenging period is set to 3 days
- Last DNS Event id 2501 or 2502 occurred at 6am on 1/1/2008
- We have a record with a timestamp of 1/1/2008 at 12:00 noon
Given these assumptions you can rub your temples for a bit and predict that the record will be deleted at approximately 6am on 1/10/2008.
Once scavenging is enabled you can check back periodically to look for the 2501 and 2502 events to see how things are going. You can also come back at the predicted date and time and see if your test record disappeared.
That's it!
標籤:
Active Directory,
DNS
Understanding aging and scavenging
Applies To: Windows Server 2008, Windows Server 2008 R2
The DNS Server service supports aging and scavenging features. These features are provided as a mechanism for performing cleanup and removal of stale resource records, which can accumulate in zone data over time.
With dynamic update, resource records are automatically added to zones when computers start on the network. However, in some cases, they are not automatically removed when computers leave the network. For example, if a computer registers its own host (A) resource record at startup and is later improperly disconnected from the network, its host (A) resource record might not be deleted. If your network has mobile users and computers, this situation can occur frequently.
If left unmanaged, the presence of stale resource records in zone data may cause some problems:
- If a large number of stale resource records remain in zones, they can eventually take up server disk space and cause unnecessarily long zone transfers.
- Domain Name System (DNS) servers that load zones that contain stale resource records might use outdated information to answer client queries, potentially causing the clients to experience name resolution problems on the network.
- The accumulation of stale resource records at the DNS server can degrade its performance and responsiveness.
- In some cases, the presence of a stale resource record in a zone can prevent a DNS domain name from being used by another computer or host device.
To solve these problems, the DNS Server service has the following features:
- Time stamping, based on the current date and time that is set at the server computer, for any resource records that are added dynamically to primary-type zones. In addition, time stamps are recorded in standard primary zones where aging and scavenging is enabled.
For resource records that you add manually, a time-stamp value of zero is used, indicating that these records are not affected by the aging process and that they can remain without limitation in zone data unless you otherwise change their time stamp or delete them. - Aging of resource records in local data, based on a specified refresh time period, for any eligible zones.
Only primary-type zones that are loaded by the DNS Server service are eligible to participate in this process. - Scavenging for any resource records that persist beyond the specified refresh period.
When a DNS server performs a scavenging operation, it can determine that resource records have aged to the point of becoming stale and remove them from zone data. You can configure servers to perform recurring scavenging operations automatically, or you can initiate an immediate scavenging operation at the server.
For more information, see either Enable Automatic Scavenging of Stale Resource Records or Start Immediate Scavenging of Stale Resource Records.
Caution |
---|
By default, the aging and scavenging mechanism for the DNS Server service is disabled. It should be enabled only when all parameters are fully understood. Otherwise, the server can be accidentally configured to delete records that should not be deleted. If a record is accidentally deleted, not only will users fail to resolve queries for that record, but any user can create a record and take ownership of it, even on zones that are configured for secure dynamic update. |
A server uses the contents of each resource-record-specific time stamp, along with other aging and scavenging properties that you can adjust or configure, to determine when it scavenges records.
Prerequisites for aging and scavenging
Before you can use the aging and scavenging features of DNS, several conditions must be met:
- Scavenging and aging must be enabled, both at the DNS server and on the zone.
By default, aging and scavenging of resource records is disabled. - Resource records must either be dynamically added to zones or manually modified to be used in aging and scavenging operations.
Typically, only those resource records that are added dynamically using the DNS dynamic update protocol are subject to aging and scavenging.
You can, however, enable scavenging for other resource records that are added through nondynamic means. For records that are added to zones in this way, either by loading a text-based zone file from another DNS server or by manually adding them to a zone, a time stamp of zero is set. This makes these records ineligible for use in aging and scavenging operations.
To change this default, you can administer these records individually, to reset and permit them to use a current (nonzero) time-stamp value. This makes it possible for these records to become aged and scavenged.
For more information, see Reset Aging and Scavenging Properties for a Specified Resource Record.
Note |
---|
In the case of changing a zone from standard primary to Active Directory-integrated, you may want to enable scavenging of all existing resource records in the zone. To enable aging for all existing resource records in a zone, you can use the AgeAllRecords command, which is available through the dnscmd command-line tool. |
Aging and scavenging terminology
The following table indicates new or revised terms that have been introduced to help specifically when discussing aging and scavenging.
Term | Description |
---|---|
Resource record time stamp
|
A date and time value that is used by the DNS server to determine removal of the resource record when it performs aging and scavenging operations.
|
Current server time
|
The current date and time on the DNS server. This number can be expressed as an exact numeric value at any point in time.
|
No-refresh interval
|
An interval of time, determined for each zone, as bounded by the following two events:
This value is needed to decrease the number of write operations to the Active Directory database. By default, this interval is set to seven days. It should not be increased to an unreasonably high level, because the benefits of the aging and scavenging feature might either be lost or diminished.
|
Refresh interval
|
An interval of time, determined for each zone, as bounded by the following two distinct events:
This value should be large enough to allow all clients to refresh their records. By default, this interval is set to seven days. It should not be increased to an unreasonably high level, because the benefits of the aging and scavenging feature might either be lost or diminished.
|
Start scavenging time
|
A specific time, expressed as a number. This time is used by the server to determine when a zone becomes available for scavenging.
|
Scavenging period
|
When automatic scavenging is enabled at the server, this period represents the time between repetitions of the automated scavenging process. The default value for this is seven days. To prevent deterioration of DNS server performance, the minimum allowed value for this is one hour.
|
Record refresh
|
When a DNS dynamic update is processed for a resource record when only the resource record time stamp, and no other characteristics of the record, are revised.
Refreshes generally occur for the following reasons:
|
Record update
|
When a DNS dynamic update is processed for a resource record where other characteristics of the record in addition to its time stamp are revised.
Updates generally occur for the following reasons:
|
Scavenging servers
|
An optional advanced zone parameter that enables you to specify a restricted list of IP addresses for DNS servers that are enabled to perform scavenging of the zone.
By default, if this parameter is not specified, all DNS servers that load a directory-integrated zone (also enabled for scavenging) attempt to perform scavenging of the zone. In some cases, this parameter can be useful if it is preferable that scavenging only be performed at some servers loading the directory-integrated zone.
To set this parameter, you must specify the list of IP addresses for the servers that are enabled to scavenge the zone in the ZoneResetScavengeServers parameter for the zone. This can be done using the dnscmd command, a command-line based tool for administering Windows DNS servers.
|
When scavenging can start
After all prerequisites for enabling the use of scavenging are met, it can start for a server zone when the current server time is greater than the value of the start scavenging time for the zone.
The server sets the time value to start scavenging on a per-zone basis whenever one of the following events occurs:
- Dynamic updates are enabled for the zone.
- A change in the state of the Scavenge stale resource records check box is applied. You can use DNS Manager to modify this setting at either an applicable DNS server or one of its primary zones.
- The DNS server loads a primary zone that is enabled to use scavenging.
This can occur when the server computer is started or when the DNS Server service is started. - When a zone resumes service after having been paused.
- If the zone is AD DS-integrated, replication for the zone must have taken place at least once since the DNS service was restarted or the domain controller was rebooted. When the previous events occur, the DNS server sets the value of start scavenging time by calculating the following sum:
Current server time + Refresh interval = Start scavenging time
This value is used as a basis of comparison during scavenging operations.
Example: the aging and scavenging process for a sample record
To understand the process of aging and scavenging at the server, consider the life span and successive stages of a single resource record, as it is added to a server and zone where this process is in effect and then aged and removed from the database.
- A sample DNS host, "host-a.example.microsoft.com", registers its host (A) resource record at the DNS server for a zone where aging and scavenging are enabled for use.
- When registering the record, the DNS server places a time stamp on this record based on current server time.
After the record time stamp is written, the DNS server does not accept refreshes for this record for the duration of the zone no-refresh interval. It can, however, accept updates before that time. For example, if the IP address for "host-a.example.microsoft.com" changes, the DNS server can accept the update. In this case, the server also updates (resets) the record time stamp. - Upon expiration of the no-refresh period, the server begins to accept attempts to refresh this record.
When the initial no-refresh period ends, the refresh period immediately begins for the record. During this time, the server does not suppress attempts to refresh the record for its remaining life span. - During and after the refresh period, if the server receives a refresh for the record, it processes it.
This resets the time stamp for the record based on the method that is described in step 2. - When subsequent scavenging is performed by the server for the "example.microsoft.com" zone, the record (and all other zone records) are examined by the server.
Each record is compared to current server time on the basis of the following sum to determine whether the record should be removed:
Record time stamp + No-refresh interval for zone + Refresh interval for zone- If the value of this sum is greater than current server time, no action is taken and the record continues to age in the zone.
- If the value of this sum is less than current server time, the record is deleted both from any zone data currently loaded in server memory and also from the applicable DnsZone object store in Active Directory Domain Services (AD DS) for the directory-integrated "example.microsoft.com" zone.
- If the value of this sum is greater than current server time, no action is taken and the record continues to age in the zone.
https://technet.microsoft.com/en-us/library/cc771677.aspx
標籤:
Active Directory,
DNS,
MCSE
2015年8月7日星期五
2015年7月20日星期一
Keep drivers for sysprep
configure the registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\Sysprep\Settings\sppnp set PersistAllDeviceInstalls to 1.
2015年6月17日星期三
Description of Group Policy Restricted Groups
Restricted groups allow an administrator to define the following two properties for security-sensitive (restricted) groups:
https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CCQQFjAB&url=http%3A%2F%2Fsocial.technet.microsoft.com%2Fwiki%2Fcontents%2Farticles%2F20402.active-directory-group-policy-restricted-groups.aspx&ei=lpqBVcLYCsyF8gXtgr6oDw&usg=AFQjCNHyPUtZcMS9YF25gLJeRZSuQdNvCg&sig2=-DcKcsUXLdKU4QuIoOp8vA
https://support.microsoft.com/en-us/kb/279301
- Members
- Member Of
Using the "Members" Restricted Group Portion of Policy
When a Restricted Group policy is enforced, any current member of a restricted group that is not on the "Members" list is removed with the exception of administrator in the Administrators group. Any user on the "Members" list which is not currently a member of the restricted group is added.Using the "Member Of" Restricted Group Portion of Policy
Only inclusion is enforced in this portion of a Restricted Group policy. The Restricted Group is not removed from other groups. It makes sure that the restricted group is a member of groups that are listed in the Member Of dialog box.Managing membership of Domain Groups by using Restricted Groups
Microsoft does not support using Restricted Groups in this scenario. Restricted Groups is a client configuration means and cannot be used with Domain Groups. Restricted Groups is designed specifically to work with Local Groups. Domain objects have to be managed within traditional AD tools. Therefore, we do not plan currently to add or support using Restricted Groups as a way to manage Domain Groups.https://www.google.com.hk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CCQQFjAB&url=http%3A%2F%2Fsocial.technet.microsoft.com%2Fwiki%2Fcontents%2Farticles%2F20402.active-directory-group-policy-restricted-groups.aspx&ei=lpqBVcLYCsyF8gXtgr6oDw&usg=AFQjCNHyPUtZcMS9YF25gLJeRZSuQdNvCg&sig2=-DcKcsUXLdKU4QuIoOp8vA
https://support.microsoft.com/en-us/kb/279301
Active Directory Group Policy Restricted Groups
The management of local groups on Workstations and servers in an organization can be done centrally by Group Policies. One of the ways to do that is to use Group Policy Restricted Groups.
Below is a table that summarizes the membership that could be updated using Group Policy Restricted Groups:
(*) Local Groups Nesting is not supported (http://technet.microsoft.com/en-us/library/ee681621(v=ws.10).aspx )
Creation of a new Restricted Groups Group Policy:
To create a new Restricted Groups Group Policy, proceed like the following:
IMPORTANT: You should refer to the table that summarizes the membership that could be updated using Group Policy Restricted Groups before applying the new group policy.
Expected behavior when using a Restricted Groups Group Policy:
When using a Restricted Groups Group Policy, the following behavior is expected:
Microsoft support for Group Policy Restricted Groups:
Description of Group Policy Restricted Groups: http://support.microsoft.com/kb/279301
Tips:
Tip 1: It happens that, for operational tasks, a user needs to be added as member of a local group to perform an action and then removed later. If a Restricted Groups Group Policy is used for the local group members then the user can be added as member of the group and automatically removed after the re-appliance of the group policy.
Tip 2: To add new domain members to a local group using Group Policy Restricted Groups without removing the current members, you can proceed like the following:
http://social.technet.microsoft.com/wiki/contents/articles/20402.active-directory-group-policy-restricted-groups.aspx
Below is a table that summarizes the membership that could be updated using Group Policy Restricted Groups:
Local Group | Domain Group | |
Using of 「Members」 |
|
Not applicable
|
Using 「Member Of」 |
Not Applicable (*)
|
|
Creation of a new Restricted Groups Group Policy:
To create a new Restricted Groups Group Policy, proceed like the following:
- Create a new Group Policy, go to Computer Configuration\Policies\Windows Settings\Security Settings\Restricted Groups and then select Add Group… after doing a right click on Restricted Groups
- Specify the name of the group to update its membership and then click on OK
- If you would like to add members to the group then click Add … for Members of this group
- If you would like to add the group as member of a local group then click on Add… for This group is member of
IMPORTANT: You should refer to the table that summarizes the membership that could be updated using Group Policy Restricted Groups before applying the new group policy.
Expected behavior when using a Restricted Groups Group Policy:
When using a Restricted Groups Group Policy, the following behavior is expected:
Type of update
|
Behavior
|
Update of 「Members」
| Any current member of the group that is not on the 「Members」 list will be removed (Local administrator user cannot be removed from Administrators group even if it is not in the 「Members」 list). All users / domain groups that are in the 「Members」 list and are not members of the group will be added as members. |
Update of 「Member of」
| The membership is added if it does not exist |
Description of Group Policy Restricted Groups: http://support.microsoft.com/kb/279301
Tips:
Tip 1: It happens that, for operational tasks, a user needs to be added as member of a local group to perform an action and then removed later. If a Restricted Groups Group Policy is used for the local group members then the user can be added as member of the group and automatically removed after the re-appliance of the group policy.
Tip 2: To add new domain members to a local group using Group Policy Restricted Groups without removing the current members, you can proceed like the following:
- Create a domain group and add the domain users / groups as member of it
- Use 「Member of」 feature to add the new domain group as member of the needed local group
2015年6月2日星期二
What Is the Central Store?
What Is the Central Store?
If your organization has multiple administration workstations, there could be potential issues when editing GPOs. If you do not have a central store that contains the template files, then the workstation from which you are editing will use the .admx (ADMX) and .adml (ADML) files that are stored in the local PolicyDefinitons folder. If different administration workstations have different operating systems or are at different service pack levels, there might be differences in the ADMX and ADML files. For example, the ADMX and ADML files that are stored on a workstation running Windows 7 with no service pack installed might not be the same as the files that are stored on a domain controller running Windows Server 2012. This could lead to administrators not seeing the same settings in a GPO.
The central store addresses this issue. The central store provides a single point from which administration workstations can download the same ADMX and ADML files when editing a GPO. The central store is detected automatically by Windows operating systems (Windows Vista or newer or Windows Server 2008 or newer). Because of this automatic behavior, the local workstation that the administrator uses to perform administration always checks to see if a central store exists before loading the local ADMX and ADML files in the Group Policy Management Editor window. When the local workstation detects a central store, it then downloads the template files from there. In this way, there is a consistent administration experience among multiple workstations.
Creating and Provisioning the Central Store
You must create and provision the central store manually. First you must create a folder on a domain controller, name the folder PolicyDefinitions, and store the folder at C:\Windows\SYSVOL\sysvol \{Domain Name}\Policies\. This folder is now your central store. You must then copy all the contents of the C:\Windows\PolicyDefinitions folder to the central store. The ADML files in this folder also are in a language-specific folder, such as en-US.
If your organization has multiple administration workstations, there could be potential issues when editing GPOs. If you do not have a central store that contains the template files, then the workstation from which you are editing will use the .admx (ADMX) and .adml (ADML) files that are stored in the local PolicyDefinitons folder. If different administration workstations have different operating systems or are at different service pack levels, there might be differences in the ADMX and ADML files. For example, the ADMX and ADML files that are stored on a workstation running Windows 7 with no service pack installed might not be the same as the files that are stored on a domain controller running Windows Server 2012. This could lead to administrators not seeing the same settings in a GPO.
The central store addresses this issue. The central store provides a single point from which administration workstations can download the same ADMX and ADML files when editing a GPO. The central store is detected automatically by Windows operating systems (Windows Vista or newer or Windows Server 2008 or newer). Because of this automatic behavior, the local workstation that the administrator uses to perform administration always checks to see if a central store exists before loading the local ADMX and ADML files in the Group Policy Management Editor window. When the local workstation detects a central store, it then downloads the template files from there. In this way, there is a consistent administration experience among multiple workstations.
Creating and Provisioning the Central Store
You must create and provision the central store manually. First you must create a folder on a domain controller, name the folder PolicyDefinitions, and store the folder at C:\Windows\SYSVOL\sysvol \{Domain Name}\Policies\. This folder is now your central store. You must then copy all the contents of the C:\Windows\PolicyDefinitions folder to the central store. The ADML files in this folder also are in a language-specific folder, such as en-US.
標籤:
Active Directory,
GPO,
MCSE,
Windows Server
Applying GPOs
Computer configuration settings are applied at startup, and then are refreshed at regular intervals. Any startup scripts run at computer startup. The default interval is every 90 minutes, but this is configurable. The exceptions to this default interval are domain controllers, which have their settings refreshed every five minutes.
User settings are applied at logon and are refreshed at regular, configurable intervals. The default for this is 90 minutes. Prior to Windows 8.1 and Windows Server 2012 R2, all logon scripts run at sign-in. By default, in Windows 8.1 and Windows Server 2012 R2, logon scripts run five minutes after sign-in. You can use Group Policy to remove this delay by modifying the Computer Configuration\Policies\Administrative Templates\System \Group Policy\Configure Logon Script Delay setting.
Note: A number of user settings require two sign-ins before the user sees the effect of the GPO. This is because multiple users signing in to the same computer use cached credentials to speed up sign-ins. This means that, although the policy settings are delivered to the computer, the user is signed in already. Therefore, the settings do not take effect until the next time the user signs in. The Folder Redirection setting is an example of this.
You can change the refresh interval by configuring a Group Policy setting. For computer settings, the refresh interval setting is found in the Computer Configuration\Policies\Administrative Templates \System\Group Policy node. For user settings, the refresh interval is found at the corresponding settings under User Configuration. An exception to the refresh interval is the security settings. The security settings section of the Group Policy is refreshed at least every 16 hours, regardless of the interval that you set for the refresh interval.
Note: A number of user settings require two sign-ins before the user sees the effect of the GPO. This is because multiple users signing in to the same computer use cached credentials to speed up sign-ins. This means that, although the policy settings are delivered to the computer, the user is signed in already. Therefore, the settings do not take effect until the next time the user signs in. The Folder Redirection setting is an example of this.
You can change the refresh interval by configuring a Group Policy setting. For computer settings, the refresh interval setting is found in the Computer Configuration\Policies\Administrative Templates \System\Group Policy node. For user settings, the refresh interval is found at the corresponding settings under User Configuration. An exception to the refresh interval is the security settings. The security settings section of the Group Policy is refreshed at least every 16 hours, regardless of the interval that you set for the refresh interval.
標籤:
GPO,
MCSE,
Windows Server
2015年5月31日星期日
Rebuild missing NETLOGON and SYSVOL on Server 2008/2012 R2
DFS Replication: How to troubleshoot missing SYSVOL and Netlogon shares
You may encounter a situation in which SYSVOL and Netlogon shares are not shared on a domain controller. The following additional symptoms or conditions may also apply:
How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)
You want to force the non-authoritative synchronization of SYSVOL on a domain controller. In the File Replication Service (FRS), this was controlled through the D2 and D4 data values for the Burflags registry values, but these values do not exist for the Distributed File System Replication (DFSR) service. You cannot use the DFS Management snap-in (Dfsmgmt.msc) or the Dfsradmin.exe command-line tool to achieve this. Unlike custom DFSR replicated folders, SYSVOL is intentionally protected from any editing through its management interfaces to prevent accidents.
https://support.microsoft.com/en-us/kb/2218556
You may encounter a situation in which SYSVOL and Netlogon shares are not shared on a domain controller. The following additional symptoms or conditions may also apply:
- The SYSVOL folder is empty.
- The affected domain controller was recently promoted.
- The environment contains domain controllers running versions of Windows earlier than Windows Server 2012 R2.
- DFS Replication is used to replicate the SYSVOL Share replicated folder.
- An upstream domain controller's DFS Replication service is in an error state.
How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)
You want to force the non-authoritative synchronization of SYSVOL on a domain controller. In the File Replication Service (FRS), this was controlled through the D2 and D4 data values for the Burflags registry values, but these values do not exist for the Distributed File System Replication (DFSR) service. You cannot use the DFS Management snap-in (Dfsmgmt.msc) or the Dfsradmin.exe command-line tool to achieve this. Unlike custom DFSR replicated folders, SYSVOL is intentionally protected from any editing through its management interfaces to prevent accidents.
https://support.microsoft.com/en-us/kb/2218556
標籤:
NETLOGON,
SYSVOL,
Windows Server
2015年3月30日星期一
Using Storage vMotion to migrate a virtual machine with many disks timeout
Using Storage vMotion to migrate a virtual machine with many disks timeout(1010045)
Symptoms
You may experience these symptoms:
- Storage vMotion fails.
- The Storage vMotion operation fails with a timeout between 5-10% or 90-95% complete.
- On ESX 4.1 you may see the errors:
In hostd.log
v ix: [7196 foundryVM.c:10177]: Error VIX_E_INVALID_ARG in VixVM_CancelOps(): One of the parameters was invalid 'vm:/vmfs/volumes/4e417019-4a3c4130-ed96-a4badb51cd0a/Mail02/Mail02.vmx' opID=9BED9F06-000002BE-9d] Failed to unset VM medatadata: FileIO error: Could not find file : /vmfs/volumes/4e417019-4a3c4130-ed96-a4badb51cd0a/Mail02/Mail02-aux.xml.tmp.In vmware.log
vmkernel: 114:03:25:51.489 cpu0:4100)WARNING: FSR: 690: 1313159068180024 S: Maximum switchover time (100 seconds) reached. Failing migration; VM should resume on source.
vmkernel: 114:03:25:51.489 cpu2:10561)WARNING: FSR: 3281: 1313159068180024 D: The migration exceeded the maximum switchover time of 100 second(s). ESX has preemptively failed the migration to allow the VM to continue running on the source host.
vmkernel: 114:03:25:51.489 cpu2:10561)WARNING: Migrate: 296: 1313159068180024 D: Failed: Maximum switchover time for migration exceeded(0xbad0109) @0x41800f61cee2
- vCenter Server logs contain entries similar to:
[yyyy-mm-dd hh:mm:ss.nnn tttt error 'App'] [MIGRATE] (migrateidentifier) vMotion failed: vmodl.fault.SystemError
[yyyy-mm-dd hh:mm:ss.nnn tttt verbose 'App'] [VpxVmomi] Throw vmodl.fault.SystemError with:
(vmodl.fault.SystemError) {
dynamicType = <unset>,
reason = "Source detected that destination failed to resume.",
msg = "A general system error occurred: Source detected that destination failed to resume.
Resolution
Note: A virtual machine with many virtual disks might be unable to complete a migration with Storage vMotion. The Storage vMotion process requires time to open, close, and process disks during the final copy phase. Storage vMotion migration of virtual machines with many disks might timeout because of this per-disk overhead.
This timeout occurs when the maximum amount of time for switchover to the destination is exceeded. This may occur if there are a large number of provisioning, migration, or power operations occurring on the same datastore as the Storage vMotion. The virtual machine's disk files are reopened during this time, so disk performance issues or large numbers of disks may lead to timeouts.
The default timeout is 100 seconds, and can be modified by changing the
fsr.maxSwitchoverSeconds
option in the virtual machine configuration to a larger value.
Note: Ensure this change is performed when the virtual machine is powered down.
To modify the fsr.maxSwitchoverSeconds option using the vSphere Client:
- Open vSphere Client and connect to the ESX/ESXi host or to vCenter Server.
- Locate the virtual machine in the inventory.
- Power off the virtual machine.
- Right-click the virtual machine and click Edit Settings.
- Click the Options tab.
- Select the Advanced: General section.
- Click the Configuration Parameters button.
Note: The Configuration Parameters button is disabled when the virtual machine is powered on. - From the Configuration Parameters window, click Add Row.
- In the Name field, enter the parameter name:
fsr.maxSwitchoverSeconds
- In the Value field, enter the new timeout value in seconds (for example:
150)
. - Click the OK buttons twice to save the configuration change.
- Power on the virtual machine.
To modify the fsr.maxSwitchoverSeconds option by editing the .vmx file manually:
The virtual machine's
.vmx
configuration file can be manually edited to add or modify the option. Add the optionfsr.maxSwitchoverSeconds = " <new value>"
on its own line.
For more information, see Tips for editing a .vmx file (1714).
Note: To edit a virtual machines configuration file, you need to power off the virtual machine, remove it from Inventory, make the changes to the vmx file, add the virtual machine back to inventory, and then power on the virtual machine again.
標籤:
storage vmotion,
vmware
2015年3月11日星期三
How to Clean up the WinSxS Directory and Free Up Disk Space on Windows Server 2008 R2 with New Update
It's finally here! After pages and pages of comments from you requesting the ability to clean up the WinSxS directory and component store on Windows Server 2008 R2, an update is available.
As a refresher, the Windows Server 2008 R2 update is directly related to my previous blog post announcing a similar fix for Windows 7 client.
The Windows 7 version of this fix introduced an additional option to the Disk Cleanup wizard that would cleanup previous versions of Windows Update files. KB2852386 adds a Disk Cleanup option on Windows Server 2008 R2, similar to the Windows 7 update.
What does this mean for Windows Server 2008 R2? After installing this update and prior to being able to perform the cleanup, the Desktop Experience feature must be installed. Why you ask? Disk Cleanup is not installed by default on Windows Server 2008 R2. It is instead a component installed with the Desktop Experience feature.
Why was the update not included as a DISM switch like Windows Server 2012 R2?
This was evaluated, however, due to the amount of changes required and the rigorous change approval process, it was not feasible to back port the functionality this way. Knowing that it would be some time before everyone could upgrade to Windows Server 2012 R2 and based on feedback from an internal survey taken of a subset of enterprise customers, it was determined that this update would still be useful in its Disk Cleanup form, even with the Desktop Experience prerequisite. We hope you agree. However, we are aware that for some of you, the Desktop Experience requirement will be a deal breaker, but decided to release it anyway hoping it will help in some instances.
How can I get the update?
The update is available on Windows Update. It can also be manually downloaded from the Microsoft Update Catalog. The KB article listed above will also direct you to a download link in the Microsoft Download Center.
Let's Cleanup those Old Windows Update Files!
First, let's take a look at our starting point. Looking at my Windows 2008 R2 Server with SP1 installed, according to Windows Explorer, the size of my Windows/WinSxS directory is as follows:
The size of the WinSxS directory will vary by server. Some of you will have smaller WinSxS directories, some larger.
Installing the update is just like installing any other update. Just download and double-click on the .msu file:
Installing the update does not require Desktop Experience to be installed beforehand, but if you check your WinSxS directory again, you'll see there has been no change to the size. This is expected as we need to run Disk Cleanup in order for this to take effect. It also does not require a reboot to install the hotfix.
But…we can't do anything with what we just installed until we get Disk Cleanup which is installed with the Desktop Experience feature.
When installing Desktop Experience, it does require additional features. Select the button to Add Required Features and click Next and then Install:
A reboot is required to finalize the install.
Click Close and Reboot when prompted.
After we reboot, a Disk Cleanup option can be found under Start --> All Programs --> Accessories --> System Tools:
On launch, Disk Cleanup prompts for the drive you want to clean up:
After clicking Ok, a scan is performed:
Several options are provided for cleanup, including a new option for Windows Update Cleanup:
Just like the Windows 7 cleanup, mileage will vary. Also like Windows 7, the actual cleanup occurs during the next reboot. After the reboot, taking a look at the WinSxS directory, it has shrunk to the following:
Automation
My super knowledgeable scripting cohort Tom Moser wrote a PowerShell script that automates THE ENTIRE PROCESS. Can I get a cheer? Ok. So maybe it is a bit much to expect IT admins to cheer, but can I get an appreciative grunt? The script certainly beats the alternative of doing this all manually.
You can find the script on the TechNet Script Center here:
What does the script do?
In short, the script does the following:
1) Installs Desktop Experience, if not previously installed, and performs a reboot.
2) Sets the appropriate registry keys to automate the cleanup. The script will cleanup not only previous Windows Update files as well as Service Pack files.
3) The script then initiates the cleanup.
4) If Desktop Experience was not previously installed, the script uninstalls it.
5) Performs final reboot.
For more details, read below.
The script can be run from any directory on the server. It has two parameters: LogPath and a switch called NoReboot. LogPath will allow the user to specify a log location or if none is specified, by default, the script will create a log in the same directory from which the script was executed. NoReboot allows the user to suppress reboots, but will require manual reboots by an administrator.
Note: Make sure to check the log file to verify the process completed successfully and to verify there is no manual interaction required. If the script has completed successfully, the log will end with CleanMgr complete.
The script has several phases, using a registry key to keep track of progress. After initial run, it inserts itself as a scheduled task, which runs as local system. The final phase removes the task.
Depending on pending reboots, etc, we have found that this phase may generate a few reboots. Do not be concerned if the server reboots a few times.
Other Options
Aside from the cleanup mechanism included with this fix, if you have applied SP1 and have not cleaned up afterwards, I'd highly recommend doing so by running the following command from an administrative command prompt:
dism /online /cleanup-image /spsuperseded
or
If you have installed the Desktop Experience feature and thus have the Disk Cleanup utility, you can select the following option to do the same thing:
Specifying the /spsuperceded switch or choosing to remove service pack backup files will remove the ability to uninstall the service pack. If you haven't done it before, it is certain to free up some space.
The Origins of this Update (Hint: Windows Server 2012 R2)
I've mentioned a couple of times that this is a back port. What does that mean? Well, it means that this functionality is already built into a later operating system. In this case, that operating system is Windows Server 2012 R2. Not only do we have several mechanisms to automatically cleanup previous versions of Windows Update files like this update does, we even have the ability to more accurately determine the size of the component store (aka the WinSxS directory).
The command to accurately determine the size of the component store on Windows Server 2012 R2 is as follows:
Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore
Running this command analyzes the component store to determine the size and whether cleanup is recommended. Notice in the screen shot that it provides you with the Windows Explorer reported size and the actual size:
Notice that the component store is much smaller than Windows Server 2008 R2 right out of the gate? This isn't because I've used Features on Demand to remove roles and features. It's because by default in Windows Server 2012 R2, we compress all unused binaries. Another win for Windows Server 2012 R2!
Looking at the breakdown of the 5.12GB. We see that Shared with Windows accounts for 3.83GB of the 5.12GB. Shared with Windows refers to the size of the files that are hardlinked between the WinSxS directory and the Windows location of the file. Because these hardlinks appear to take up space, but don't really, we can subtract them from our component store size. Therefore, the actual size of the component store is the total of Backups and Disabled Features plus Cache and Temporary Data or 1.28GB.
But back to our cleanup.
In the above screen shot, it's stated that component store cleanup is recommended. We can manually cleanup the component store on Windows Server 2012 R2 by running the following command:
Dism.exe /online /Cleanup-Image /StartComponentCleanup
What does this do? When this runs, Windows cleans up the previous versions of the component that was updated. In other words, it is doing exactly what our update does for Windows Server 2008 R2 SP1. It removes previous versions of the files updated by Windows Updates.
After running /StartCompomentCleanup, upon analyzing the size again, we see it is as follows:
So no notable difference really. Largely because we've been running this cleanup all along. This same command is run every 30 days as a scheduled task with a time limit of 1 hour.
With the scheduled task however, the task will wait at least 30 days after an updated component has been installed before uninstalling the previous versions of the component. This scheduled task can be found in Task Scheduler under the Task Scheduler Library\Microsoft\Windows\Servicing\StartComponentCleanup directory:
More information on this can be found here: http://technet.microsoft.com/en-us/library/dn251565.aspx
If you're in all out spring cleaning mode and want to perform super deep cleanup, you can use the /resetbase command with the /startcomponentcleanup to remove all superseded versions of every component in the component store:
Dism.exe /online /Cleanup-Image /StartComponentCleanup /ResetBase
This removes the ability to uninstall any updates applied until this point in time.
And don't forget the ability to completely remove any role or feature which also reduces the size. Take a look at one of my earlier blogs for more details on Features on Demand: http://blogs.technet.com/b/askpfeplat/archive/2013/02/24/how-to-reduce-the-size-of-the-winsxs-directory-and-free-up-disk-space-on-windows-server-2012-using-features-on-demand.aspx
Here's a handy table showing when we introduced the various different cleanup and WinSxS size reductions by operating system:
Operating System | Compress Unused WinSxS Binaries | Cleanup Previous Windows Update Files | Automatically Clean Up Previous Windows Update Files | Cleanup All Components | Features on Demand |
Windows Server 2008 R2 | With KB2852386 | ||||
Windows Server 2012 | With KB2821895 | x | x | x | |
Windows Server 2012 R2 | x | x | x | x | x |
Want more information on how all this works under the covers?
Check out the following series on the AskCore team blog for an in-depth look at servicing improvements on Windows Server 2012 R2:
More on the Desktop Experience Feature
The Desktop Experience feature includes the following components and features:
* Windows Media Player
* Desktop themes
* Video for Windows (AVI support)
* Windows SideShow
* Windows Defender
* Disk Cleanup
* Sync Center
* Sound Recorder
* Character Map
* Snipping Tool
* Ink Support
Most of these are not automatically turned on with the exception of Windows Defender whose service is started after reboot. You'll likely want to stop the service and disable it after reboot. Not all 3rd party anti-viruses conflict with Windows Defender, but there have been reports that some do.
~ Charity Shelbourne and Tom Moser, Spring cleaning servers since 1998
Update May 15th, 2014
We are aware of a method of copying in the appropriate Disk Cleanup/CleanMgr files into the appropriate location to avoid installing the Desktop Experience. If this were a tested and supported option, we certainly would have included these details in this post and definitely would have used this method to automate the cleanup. However, it was determined early on that this method would not be supported. If you decide to do this, do so at your own risk.
http://blogs.technet.com/b/askpfeplat/archive/2014/05/13/how-to-clean-up-the-winsxs-directory-and-free-up-disk-space-on-windows-server-2008-r2-with-new-update.aspx
訂閱:
文章 (Atom)