https://technet.microsoft.com/en-us/library/security/3062591.aspx
Download
2015年8月7日星期五
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月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
2015年2月20日星期五
Windows Server 2008 Repair Steps for No Boot Issues
http://social.technet.microsoft.com/wiki/contents/articles/4162.windows-server-2008-repair-steps-for-no-boot-issues.aspx
2015年2月15日星期日
Reset Domain Computer Account
When the secure channel fails, you must reset the secure channel. Many administrators do so by removing the computer from the domain, putting it in a workgroup, and then rejoining the domain. This is not a good practice, because it has the potential to delete the computer account altogether, which loses the computer's SID and, more importantly, its group memberships. When you rejoin the domain, even though the computer has the same name, the account has a new SID, and all the group memberships of the previous computer object must be re-created.
To reset the secure channel using the Active Directory Users and Computers snap-in:
To reset the secure channel using DSMod, type the following command, Rejoin the computer to the domain, and then reboot the computer.
To reset the secure channel using NetDom, type the following command:
To reset the secure channel using NLTest, on the computer that has lost its trust, type the command:
For example:
nltest /server:SERVER02 /sc_reset:CONTOSO\SERVER01
This command, like NetDom, attempts to reset the secure channel by resetting the password on both the computer and in the domain, so it does not require rejoining or rebooting.
Because NLTest and NetDom reset the secure channel without requiring a reboot, you should try those commands first. Only if those are not successful should you use the Reset Account command or DSMod to reset the computer account.
Source : http://web-foro.com/wl/CompanionContent/course/crse6425b_00_05_03_05.htm
To reset the secure channel using the Active Directory Users and Computers snap-in:
- Right-click a computer, and then click Reset Account.
- Click Yes to confirm your choice.
- Rejoin the computer to the domain, and then reboot the computer.
To reset the secure channel using DSMod, type the following command, Rejoin the computer to the domain, and then reboot the computer.
- dsmod computer "ComputerDN" –reset.
- netdom reset MachineName /domain DomainName /UserO UserName /PasswordO {Password | *}
where the credentials belong to the local Administrators group of the computer.
This command resets the secure channel by attempting to reset the password on both the computer and the domain, so it does not require rejoining or rebooting.
To reset the secure channel using NLTest, on the computer that has lost its trust, type the command:
- NLTEST /SERVER:SERVERNAME /SC_RESET:DOMAIN\DOMAINCONTROLLER
nltest /server:SERVER02 /sc_reset:CONTOSO\SERVER01
This command, like NetDom, attempts to reset the secure channel by resetting the password on both the computer and in the domain, so it does not require rejoining or rebooting.
Because NLTest and NetDom reset the secure channel without requiring a reboot, you should try those commands first. Only if those are not successful should you use the Reset Account command or DSMod to reset the computer account.
Source : http://web-foro.com/wl/CompanionContent/course/crse6425b_00_05_03_05.htm
2015年1月28日星期三
Windows Server edition downgrade
This way is probably not supported, and I would not try it on something like a DC... but here is what I recently did to downgrade Server 2012 R2 Datacenter to Server 2012 R2 Standard.
Edit: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
Key: EditionID
Change To: ServerStandard
Key: ProductName
Change To: Windows Server 2012 Standard
Note that in this example I am going to be "upgrading" to Server 2012 R2 Standard, so I put in Windows Server 2012 Standard as the ProductName, not Server 2012 R2 Standard. After the upgrade, this key will change itself to proper version.
Key: EditionID
Change To: ServerStandard
Key: ProductName
Change To: Windows Server 2012 Standard
Note that in this example I am going to be "upgrading" to Server 2012 R2 Standard, so I put in Windows Server 2012 Standard as the ProductName, not Server 2012 R2 Standard. After the upgrade, this key will change itself to proper version.
Next mount or insert your Server 2012 installation media, run the installer. Do not check for updates, I chose Server 2012 R2 Standard with gui as my OS, and pick Upgrade.
It will go through the standard upgrade process, and you now have downgraded from Server 2012 R2 Datacenter to Server 2012 R2 Standard.
After that I ran slui 3 from command prompt, entered my Server 2012 R2 Standard product key, and activation went through.
I'm about to test doing this on a DC, but honestly if you were to try this, I would demote the server, remove DNS and DHCP, then do the "downgrade".
2015年1月10日星期六
Windows version upgrade command
Displays the edition of the specified image.
- Dism /Online /Get-CurrentEdition
Displays a list of Windows editions that an image can be changed to.
- Dism /Online /Get-TargetEditions
Use the /Set-Edition option with no arguments to change an offline Windows image to a higher edition.
- Dism /online /Set-Edition: <edition name> /AcceptEula /ProductKey:12345-67890-12345-67890-12345
訂閱:
文章 (Atom)