Tag: Group Policy

Server 2016 & Windows 10 Start Menu Not Working

I’d been having some problems with the start menu in both Server 2016 and Windows 10 stopping working. Googling around revealed various posts and loads of the same advice on how to fix the problem. These included using the Deployment Image Servicing and Management tool with the /restorehealth switch;

DISM /Online /Cleanup-Image /RestoreHealth

Reinstalling all modern apps via PowerShell with the following command;

Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}

Creating a new user account and just using that, not an option if the problem affects all accounts on the machine. The only one of the options mentioned that did help was to re-install Windows, this left the start menu working. However as soon as I domain joined the machine again, it stopped working again after a restart. This led me to look at Group Policy as a potential culprit, and sure enough, moving the object to a separate OU and blocking all policy on it left the start menu working. After a long process of linking policies in one by one I came down to a very specific registry setting.

I’d set the ACLs on a specific registry subkey of HKLM, in this case it was HKLM\Software\Microsoft\RPC. These ACLs were missing one specific entry, namely APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES.
Adding this in with only read permissions and forcing a policy update brought the start menu immediately back to life. That ACL is one that has appeared in Server 2012 I think, but since that particular part of our policy predates 2012 that ACL wasn’t there. Oddly enough I’ve not seen this cause any problems with Server 2012/2012 R2/Windows 8/8.1, only with Server 2016 & Windows 10.

So the take away from this is to make sure if you restrict any registry ACLs, make sure you include read access for APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES.

If all this was helpful and worked for you, please drop a quick note in the comments.

Group Policy Preferences Processing Order

Just to clarify something that people should be aware of, the Group Policy Preferences processing order. Within each CSE the settings are applied starting at number one and working down from there. I know it sounds obvious, but the documentation generally read as “starting with the highest”, which I think leaves room for confusion as “the highest” could mean it finishes with one, especially when you look in the context of Group Policy and that the last setting applied wins.

Anyway, one and down from there.

Group Policy – Unattended Sleep Timeout

Update: Thanks to a helpful comment from Alain Roy, the answer is here – Sleep unattended idle timeout

There is a Group Policy setting called “Specify the unattended sleep timeout” located here;

Computer Configuration – Administrative Templates – System – Power Management – Sleep Settings

The description given for the policy is;

This policy setting allows you to specify the period of inactivity before Windows transitions to sleep automatically when a user is not present at the computer.

If you enable this policy setting, you must provide a value, in seconds, indicating how much idle time should elapse before Windows automatically transitions to sleep when left unattended. If you specify 0 seconds, Windows does not automatically transition to sleep.

If you disable or do not configure this policy setting, users control this setting.

If the user has configured a slide show to run on the lock screen when the machine is locked, this can prevent the sleep transition from occurring. The “Prevent enabling lock screen slide show” policy setting can be used to disable the slide show feature.

What I want to know is how on earth the system determines when it’s unattended. What if you’re watching a full screen video, is that unattended? What if you’re just running an Excel calculation, is that unattended?

I can find very little information, none in fact, on the Internet on how this is determined, but if anyone knows, please share.

Enabling Individual Settings Within A Group Policy Preference

When you’re creating a set of Group Policy preferences, you can set all kinds of settings in a very similar way to how you would if you were sat in front of the machine. For example, IE settings are very intuitively laid out and it really is just like doing it within the internet control panel screen;

IE Preferences

The key thing to remember though, is that in a lot of cases, just setting the preference isn’t enough, you have to enable it too. So for example, entering a homepage into the preferences panel will not make it actually apply, as you can see the lines underneath it stay broken red, which means that the setting will not get applied;

Setting Not Applied

Although it’s not mentioned within the policy at all, there are keys you can press to enable or disable individual settings, or the entire page, and these are documented on Technet.

Basically, to enable the homepage setting we saw above, after you’ve finished entering it, press F6 and this will turn the line under the settings to green and this means that then this will get applied;

Applied Setting

So from this you can enable or disable any setting from within the policy, and hopefully take a little more control over your Internet Explorer settings going forwards.

Managing Group Policy Templates Using A Central Store

Previously the common and accepted way to add a policy template into a new group policy was to do it from within the policy itself, that would be done by right clicking on Administrative Templates and then adding it from there, picking the correct template you were wanting to add, as below;

Add Policy Template

Though in a domain environment, you really should be looking at doing this centrally by creating a central policy store. Doing this has a few advantages, such as all the policy template files being replicated round all servers either via FRS or DFSR, and only having one place to go to update or add templates, making future management simpler. Microsoft have all the details, but it’s a fairly simple process;

  • Create the root folder for the central store %systemroot%\sysvol\domain\policies\PolicyDefinitions on your domain controller.
  • Create a subfolder of %systemroot%\sysvol\domain\policies\PolicyDefinitions for each language your Group Policy administrators will use.

    • Note: Each subfolder is named after the appropriate ISO-style Language name, for example, to create a subfolder for U.S. English, create the subfolder: %systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US

    This should make your life a little easier when it comes to managing policy templates.

    Group Policy Preferences For Different Versions Of Internet Explorer In the Same Policy

    So, you’re managing a Windows estate and you’re in the process of updating Internet Explorer versions that you’ve managed via Group Policy. At some point you’re going to have multiple versions of Internet Explorer out in the wild and need to manage the settings for them both. As you should know by now, Internet Explorer maintenance settings have been deprecated in favour of Group Policy preferences.

    The first thing to note is that even if you download the Group Policy templates for IE11 and install them correctly, you wont see an option for IE11, just IE10 and earlier.

    IE Group Policy

    Not to worry though, IE10 settings will apply just fine to IE11 and that is the desired behaviour. So, now you know how to configure settings for IE11, you might wonder how preferences for different versions of IE in the same policy would interact on the client machine. Well in the setup I looked at this had previously been done using item level targeting, which is in the common tab of the policy;

    IE Item Level Targeting

    The targeting was looking into the registry and checking for specific version strings which would only have the policy apply where the registry strings matched what was being checked;

    IE Item Level Targeting Registry Setting

    Now, while the above method would work it’s unnecessary. When you create a new setting within the policy, you’ll see some Item-level targeting is already put in place by Microsoft to ensure the settings only get applied to the right version IE on the client. The version of the IExplore.exe process running on the client machine is checked and then that is used to determine which IE settings to deploy from the GPO. So in my environment, as you can see below the settings would only apply to specific IE versions;

    IE Version Filters

    The XML file already contains all it needs to look for specific versions of IE, and as a result the various policies can co-exist with each other.

    In short, the item level targeting is done for you, no need to add any more targeting unless you need to filter things down further.

    Force Password Check With PDC When Login Failure Occurs

    I didn’t even know this setting existed as an option within Group Policy, but then again, Group Policy is a bit of a beast at the best of times.

    So, the PDC emulator is responsible in the domain for handling password replication to other domain controllers, a password change occurs on the PDC and this is then replicated out to all other domian controllers. But what if you have a large infrastructure and the password change hasn’t replicated out yet to the domain controller being used by a client to authenticate? Well there’s a policy setting you can apply to your domain controllers, that forces them to check with the PDC in the event they deny a logon request due to a bad password. The setting is called “Contact PDC on logon failure” and it is briefly detailed on TechNet, and within the Group Policy editor, lives at the below location;

    Computer Configuration\Policies\Administrative Templates\System\NetLogon

    Use with caution though, if used on domain controllers on slow WAN links, this will create a lot of traffic to the PDC, and in general it can create a lot of load on the PDC in large environments.