Resetting Default Domain Policy & Replacing EFS Certificate

I have inherited some pretty messy domains over the last couple years when it comes to GPO’s, and knowing the short and sweet way to reset the Default Domain and Default Domain Controller policies has come in handy.  As I hope you know, Microsoft only suggests only making changes to these policies for account, account lockout, password, and Kerberos policies.  I agree that it should stay clean, there is no reason not to break things out into different GPO’s in this day and age.  But alas let’s move on before this becomes a rant.

To reset either of the default GPO’s, you use the dcgpofix utility.  The syntax is quite simple, just take a backup of the GPO you’re resetting before you do it as I’m sure you already know.

Reset the Default Domain Policy:

Reset the Default Domain Controller Policy:

Reset both the Default Domain Controller and Default Domain Policy:

Wha-Lah you are done.  Go and set you account/account lockout/password/Kerberos settings as dictated by your organization.  You may run into an issue where the utility is unable to recreate the EFS certificate as seen below:

This is pretty simple, you will just have to create a new certificate for EFS and add it to the policy manually.  Now you can accomplish this in a number of different ways, but I’m going to show you the simplest (in my opinion) in which you create a self-signed certificate that will out live you.  Open up a PowerShell or Command Prompt as Administrator and move to the directory that you would want to save the certificate.  Once there run the following, where “CertName” is whatever you would like to name the certificate:

This will generate your self-signed certificate in whatever directory you’re sitting in.  Now you need to import it into your Default Domain Policy to be used for EFS.  Open your Group Policy Management Editor and navigate to “Computer Configuration\Policies\Security Settings\Public Key Policies\Encrypting File System”.  Once there right click EFS and select the “Add Data Recovery Agent…” option.

Move through the wizard selecting the “Browse Folders…” option to select your certificate.  You will likely get a pop-up saying “Windows cannot determine if this certificate has been revoked”.  This is just because it is a self-signed certificate, so select Yes when prompted to install the certificate.  Next your way through the rest of the wizard and you are all set.

Hide Settings Pages in Windows 10 with GPO

The new settings page in Windows 10 provides a nice clean UI for all of the Windows settings, but until the Creator Update (1703) could not be managed via GPO.  Now we have the tools to control this, but you must first start by adding the Windows 10 (1703) Administrative Templates to your Group Policy PolicyDefinitions folder or Central Store.  Once you have done that you will be able to find the “Settings Page Visibility” GPO under “Computer Configuration\Administrative Templates\Control Panel”.

When enabling this GPO you have two different methodologies of accomplishing your task; you can choose to show only certain pages, or choose to hide specified pages.  The syntax for each is as follows:

The page names are pretty intuitively named (ex. the about page name is “about”), but you can find a pretty good listing from this Microsoft Blog post.

Enable “Single-Click” with GPO

If you have ever worked with touchscreen computers, you will certainly understand how much of a pain it is to try and double-click a desktop icon without dragging it.  As I have many kiosks in my environment currently, I hunted down how to enable the single-click option by pushing a couple registry updates with GPO (see comment by Sergio Calderón here).  The registry updates are as follows:

The second is optional, it just underlines the icon when is selected.  Little quality of life feature.

Controlling Windows 10 “Bloatware” Apps

It is no secret that Windows 10 has a nasty habit of installing software that we do not want installed in our environments, and this seems to be something that Microsoft has no intention of changing in the near future.  The only “easy” solution is to get your hands on Enterprise LTSB, but then you do not get feature updates.  Anywho, presented with this issue and the fact that my customers only pay for Windows 10 Pro (shocker) I came up with a PowerShell script to only keep the apps that I dictate installed, with a little help from the Obi-Wan you all hear about so frequently.

A quick run-down for those who are not yet familiar with Windows 10 there are two types of packages that we are concerned with today; AppxPackages and AppxProvisionedPackages.  AppxPackages are the packages of the currently installed Microsoft apps for a particular Windows User Profile on the machine.  AppxProvisionedPackages are the pesky devils that install the apps upon new user profile creation on the machine.  Naturally, the latter are the ones we are most concerned with, but we want to ditch any of the AppxPackages that may linger on.

Also, I have included a quick check to make sure the PowerShell script will only run on Windows 10 1703 or lower.  This way I have time to test on the next version and make sure this script doesn’t screw anything up before I allow it to run on client machines.

When it comes to deployment I push with GPO and run the script at computer startup, but I run a batch script that copies the .ps1 file down to a restricted folder on the local machine first.  I do this because this script needs to run as system to be fully effective.  I also add the following arguments when running the script to hide the PowerShell window while it’s running.

WSUS Trials and Tribulations

Recently I have been working on a WSUS deployment with 2012R2.  Let’s just say it isn’t the smoothest deployment of a feature/role that I have ever done.  With that fun little preface, let’s dig into the challenges that I have faced with this.

For starters, the initial installation of the WSUS role and it’s additional features went off without a hitch.  I synced the server up with Microsoft, did my initial approvals, and set my GPO’s as needed.  It wasn’t until I realized that I had no client machines in my Unassigned/All Computers OU that something was up.  And down the rabbit hole I went for a frustrating amount of time.  The first issue I came across and resolved was my GPO settings.  For record, you need the following two GPO’s applied:

•Configure Automatic Updates

•Specify intranet Microsoft update service location

My issue was with the latter.  I had the format of “Set the intranet update service for detecting updates: ” and “Set the intranet statistics server” as “http://server>”.  This should have included the port number (8530 for non SSL) “http://server:8530“.

Following getting this GPO change applied I finally started (albeit be quite slow) getting client machines connecting.  Great!  Except all the Windows 10 machines in my environment were showing as Windows Vista…how insulting!  So after some digging all over I found a Windows update to correct that little oversight (KB3095113), which you can download here.

We seem to be getting somewhere eh?  Nope!  I saw that my WSUS server had grabbed some updates since I installed the role, so I figured why not install it right?  Might be a useful patch (which in reality, it was).  But naturally it broke stuff.  Post installing the update (KB3159706) I could no longer connect to the WSUS server via the WSUS Console.  Yay!  After digging through Event Viewer logs and hating all things Microsoft, I found the error that led me to the solution: ID 507 “Update Services failed its initialization and stopped.”  I did some Googling and found out that there were manual configuration steps to complete the update (Maybe a little notification for something like that next time Microsoft?  Please?).  Below is the manual steps required to complete the installation for the update:

•Open an elevated CMD and run the following command:

It will take a little while, but eventually you will see “Post install has successfully completed.”

•Add the “HTTP Activation” feature found at “.NET Framework 4.5 Features > WCF Services > HTTP Activation.”

•Restart the WSUS service and you should be able to connect with the WSUS Console again.

After all that heartache, I finally have a functioning WSUS deployment.

Creating an ADMX/ADML Central Store

As time goes on, Microsoft releases new features to be controlled with Group Policy.  You add these new GPO’s by downloading .admx and .adml files from Microsoft and adding them to your Domain Controller.  You do this by first creating a Central Store for your admx/adml files, assuming that you do not already have one in place.  Note that this process is unnecessary if you have a single Domain Controller as they are all pulled from from the local PolicyDefinitions folder.  When you have multiple Domain Controllers in your environment you want them to share the same PolicyDefinitions so there are not any discrepancies.

To do this, login to your Primary Domain Controller (or the DC with the highest version of Windows Server) and navigate to C:\Windows.  You will find a directory name PolicyDefinitions here.  Copy that directory and paste it in the following directory C:\Windows\SYSVOL\domain\Policies.  This pasted PolicyDefinitions folder will now be the central store that all DC’s will grab its admx/adml files from (aka a central storage location for all GPOs for your domain).  After this you simply download the admx/adml files that you wish to add from Microsoft and paste them into your newly pasted PolicyDefinitions folder and the corresponding language folder(s).  For example, if I wanted to add GPO’s for controlling Microsoft Office 2016, I could do so by downloading the admx/adml files from here and then adding them to the appropriate folders.  Easy peasy!

Windows 7 Not Connecting to Wired Network Prior to Login

This is an issue that historically I have found often with wireless network connections, but very rarely with wired connections. This has always been easily resolved by simply pushing the pretty standard GPO found below:

Computer Configuration\Policies\Administrative Templates\System\Logon

Always wait for the network at computer startup and logon

Naturally I stumbled upon a case where this was not the case. I pushed the GPO and even changed the local GPO to no success (the main indicator being an error in the event log saying it couldn’t contact DC during logon). One Google search later I found the answer (here). Set the following local GPO:

Computer Configuration\Administrative Templates\System\Group Policy

Startup policy processing wait time = 120

You can play with the wait time numbers, but 2 minutes worked for me.  As one would expect this does slow the boot time significantly (by two minutes, who would have thought), but it will get you up and running.