- Scalability and availability for Azure Web Apps - Wed, Jun 28 2017
- Managing Azure Virtual Machine scale sets - Wed, May 31 2017
- Azure virtual machine scale sets - Mon, May 8 2017
Nano Server and Group Policy
Nano Server promised a minimal operating system designed for certain tasks and cloud-native applications, with less disk space, faster installations, and fewer updates and restarts. To achieve this promise, the Nano Server team included only a minimum number of components in the default installation. That's the main reason Nano Server doesn't have a management console, an editor, Group Policy and even local Group Policy tools. Instead of traditional Group Policy components, Microsoft decided to add several new cmdlets to improve security.
Many companies today still rely on Group Policy to define and deploy organization-wide settings for different purposes. Thus, if you've already invested in Group Policy for your server farm, you should think twice before putting Nano Server in your datacenter. Any current GPOs (Group Policy Objects) will not affect these servers, even when they are domain joined.
Of course, that doesn't mean Group Policy is dead. It's still the best and easiest way to configure your domain-joined devices and is still a good choice for client installations. However, Nano Server is in another league. Microsoft thinks servers deserve configuration options other than traditional GPOs. DSC aims to replace Group Policy on Nano Server installations. It allows you to create complex functions, apply logic and manage error handling. You can easily apply these configurations to a large number of servers.
If you've already been in the DSC game for a while, you've probably realized that some Group Policy capabilities overlap with DSC's capabilities. Therefore, you need to be careful about choosing either DSC or Group Policy for your environment. If you decide to go with DSC to manage and configure settings for your servers, consider using an excellent community script called ADMXtoDSC. This helps you convert existing registry-based Group Policy settings to DSC configuration scripts.
Manually converting Group Policy to DSC
Before detailing the script, let me give you a short intro about the relationship between Group Policy and registry settings. Group Policies are actually registry settings applied to your targets when you deploy the GPO. Windows stores each registry-based setting defined for Local Group Policy Objects in two different Registry.pol files under the Windows\System32\GroupPolicy folder—one for the computer (machine) and one for the user.
Registry.pol file location for Local Group Policy
You can find the same user/configuration files under the SYSVOL folder in domain environments.
Registry.pol file location for domain environments
The Registry.pol machine file applies to the HKEY_LOCAL_MACHINE registry subtree on the corresponding computer and to the HKEY_CURRENT_USER subtree on the target computer.
Registry.pol file location for domain environments
If you look at the Registry.pol file, you will recognize that it uses a special format to store data. The value between each semicolon (;) represents a specific setting.
To view the Registry.pol files and see which settings are stored on which registry key, you can use SDM's free Registry.Pol Viewer 1.5 Utility. The tool pulls all the data from the Registry.pol file and gives you a structured view of the settings.
Viewing registry.pol files
You can see all registry keys and values configured for this policy.
If you install the Group Policy Management Console, some useful cmdlets are available. One of them is Get-GPRegistryValue. You can use this cmdlet to retrieve registry-based policy settings for computer and user configurations. The command below simply displays all values from a particular registry key.
Get-GPRegistryValue -Guid D52164F7-FA75-47DE-A4BF-E4427787D17F -Key HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\WCN\UI
Using the Get GPRegistryValue cmdlet to retrieve policy settings
I just wanted to give a quick overview of the tools and cmdlets able to retrieve registry-based settings from an existing Group Policy infrastructure. With some script logic, time and hard work, you can parse each policy with the Get-GPRegistryValue cmdlet and then try to map parsed registry items to a DSC configuration file.
Converting with ADMXtoDSC
The ADMXtoDSC script saves us tremendous time. It includes a couple of functions and uses the Get-GPRegistryValue cmdlet to retrieve settings to build the corresponding DSC resources. Using the script is pretty straightforward.
ConvertTo-ADMXtoDSC -gpoName My_Custom_Policy -outputFolder C:\ -Verbose
ADMXtoDSC looks at the registry for the computer-based keys under HKLM\Software\Policies and HKLM\Software\Microsoft\Windows NT\CurrentVersion. This means that currently, the script cannot convert user-based registry policies to DSC files.
For the keys above, the script parses the policy settings in order to build a proper DSC resource. In the end, it produces a new DSC file The file includes all existing computer-based registry settings from a particular GPO.
The sample DSC script below configures the LLTDIO driver.
Configuration "My_Custom_Policy"
{
Import-DscResource –ModuleName PSDesiredStateConfiguration
Node localhost
{
Registry 'EnableRspndr'
{
Ensure = 'Present'
Key = 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\LLTD'
ValueName = 'EnableRspndr'
ValueType = 'DWord'
ValueData = '1'
}
Registry 'AllowRspndrOnPublicNet'
{
Ensure = 'Present'
Key = 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\LLTD'
ValueName = 'AllowRspndrOnPublicNet'
ValueType = 'DWord'
ValueData = '0'
}
Registry 'ProhibitRspndrOnPrivateNet'
{
Ensure = 'Present'
Key = 'HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\LLTD'
ValueName = 'ProhibitRspndrOnPrivateNet'
ValueType = 'DWord'
ValueData = '0'
}
}
}
My_Custom_Policy
The Configuration keyword is the name for your configuration script. ADMXtoDSC uses the Group Policy name here. For the node, it uses localhost by default.
The script then has registry sections that include all existing GPO registry settings. The Ensure keyword means the script will verify the presence of the corresponding key and values.
Deploying your DSC configuration
One of the best things about DSC is that you can easily create a Managed Object Format (MOF) file. This is a widely accepted standard that you can use with bunch of different tools to change WMI settings.
The command below helps you create a MOF file for each node listed in the configuration (in our case, it's just localhost).
My_Custom_Policy -output C:\Config
Creating a MOF file from a DSC script
Finally, you can use the Start-DscConfiguration cmdlet and specify the path to the MOF file we created.
Start-DscConfiguration -Path C:\Config -Wait -Force -Verbose
This then applies the entire configuration to the nodes.
Applying the DSC configuration
The DSC configuration script checks whether the registry keys exist and then modifies the corresponding settings. You can easily distribute the MOF file to multiple nodes using push or pull modes. Just like with Group Policy, DSC checks every few minutes to make sure the configuration is up to date.
Subscribe to 4sysops newsletter!
As mentioned at beginning of the article, Group Policy is not dead, and it's still the best way to configure client computers. However, DSC is a great way to check and configure settings for your servers. With ADMXtoDSC, you can easily convert your existing policies to DSC format.
Reference: https://github.com/gpoguy/ADMXToDSC
