https://technet.microsoft.com/en-us/library/security/3062591.aspx
Download
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
訂閱:
文章 (Atom)