In this post, I will look at a popular community script called ADMXtoDSC. It allows you to convert your existing computer-based Group Policy and registry settings to a PowerShell DSC (Desired State Configuration) file.

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.

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.

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.

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.

1

ConvertTo-ADMXtoDSC-gpoName My_Custom_Policy-outputFolderC:\-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.

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).

1

My_Custom_Policy-outputC:\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.

1

Start-DscConfiguration-PathC:\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.

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.

This July, we asked for software tips from the 2017 Microsoft Office National Champions, a set of charming teens who are officially the best at using PowerPoint, Word, and Excel. The Verge recently followed these teens to the World Championship in California, where they tested their Office skills in a contest that out-nerds the spelling bee.

In order to provide industry-standard compliance with the SWIFT 2017 Standards MT release 2017, Microsoft is offering, to customer's with Software Assurance, updates to the flat-file (MT) messaging schemas used with the Microsoft BizTalk Accelerator for SWIFT. The A4SWIFT Message Pack 2017 contains the following: Re-packaging of all SWIFT FIN message types and business rules...

Independent rendering allows the browser to selectively offload graphics processing to an additional CPU thread, so they can be rendered with minimal impact to the user interface thread and the overall visible performance characteristics page, such as silk-smooth scrolling, responsive interactions, and fluid animations. This technique was pioneered in Internet Explorer 11, and is key

Azure Service Bus .NET Standard client is generally available. With it comes support for .NET Core and the .NET framework. And as mentioned in an earlier post it also supports Mono/Xamarin for cross-platform application development. This is only the start of greater things to come.

The Azure Service Bus team is extremely excited to announce general availability of our Java client library version 1.0.0. It allows customers to enjoy a solid Java experience with Azure Service Bus as it comes complete with native functionality.