Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

Use PowerShell to get a list of GPOs without Authenticated Users in the delegation

Must have seen this recent Windows update that broke GPOs which were missing the Read permission for the “Authenticated Users” group. Solution is to get a list of these GPOs and add the “Authenticated Users” group to them. Here’s a one liner that gets you such a list –

This puts it into a file called GPOs.txt in the current directory. Remove/ Modify that last re-direct as needed.

Get a list of OUs with inheritance blocked & GPOs not applied

To get a list of OUs and the status of GPO inheritance:

To get a list of OUs that have GPO inheritance blocked:

To get a list of OUs that have GPO inheritance blocked and a don’t have a particular GPO applied to them directly:

There’s probably a better way to do this, but this is the best I could come up with …

AD Domain Password policies

Password policies are set in the “Computer Configuration” section at Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy.

The policy applies to the computer as user objects are stored in the database of the computer. A Domain Controller is a special computer in that its database holds user objects for the entire domain, so it takes its password policy settings from whatever policy wins at the domain level. What this means is that you can have multiple policies in a domain – each containing different password policies – but the only one that matters for domain users is the policy that wins at the domain level. Any policy that applies to OUs will only apply to local user objects that reside in the SAM database of computers in that OU. 

A quick recap on how GPO precedence works: OU linked GPOs override Domain linked GPOs which override Site linked GPOs which override local GPOs (i.e. OU > Domain > Site > local). Within each of these there can be multiple GPOs. The link order matters here. The GPOs with lower link order win over GPOs with higher link order (i.e. link order 1 > link order 2 > …). Of course all these precedence order can be subverted if a GPO is set as enforced. In this case the parent GPO cannot be overridden by a child GPO. 

By default the Default Domain Policy is set at the Domain level and has link order 1. If you want to change the password policy for the domain you can either modify this GPO, or create a new GPO and apply it at the Domain level (but remember to set it at a lower link order than the Default Domain Policy – i.e. link order 1 for instance). 

For a list of the password policy settings check out this TechNet page. 

Since Windows Server 2008 it is possible to have Fine Grained Password Policies (FGPP) that can apply to OUs. These are not GPOs, so you can’t set them via GPMC. For Server 2008 this TechNet page has instructions (you have to use PowerShell or ADSI Edit), for Server 2012 check out this blog post (you can use ADAC; obviously Server 2012 makes it easier). Check out this article too for Server 2008 (it is better than the TechNet page which is … dense on details). 

Roaming profile permissions and versions

Ever noticed that when you moved from Windows XP to Windows 7 the profile name as a .V2 appended to it? That’s because the profile format changed with Windows Vista and to avoid mistakenly loading the older profile format, Vista and upwards add a .V2 (version 2) to the profile folder name. This way a user can login to both XP and Vista/ 7 machines at the same time and the profiles won’t get mashed. 

Windows 8/ 8.1 changes the format again to version 3. This time, however, they don’t change the folder name. When a Windows 7 user logs in to a Windows 8/ 8.1 machine the profile format is upgraded in-place but the folder name is not changed. Later, if they log in to a Windows 7 machine there will be trouble. Workarounds include this one from a member of the AD team or using GPOs on the computers to redirect roaming profiles to different locations (the “Set roaming profile path for all users logging onto this computer” GPO setting). More information is available in this KB article which seems to be missing. 

Speaking of GPOs and roaming profiles, by default roaming profiles are configured with very minimal permissions. Only the Creator/ Owner and the Local System have full permissions to the roaming profile on the server. Administrators don’t have any permissions, including being able to see the existing permissions. There is a GPO setting which can be used to grant the Administrator group access to roaming profiles. This is a Computer policy, found under Computer Configuration > Policies > Administrative Templates > System > User Profiles and is called “Add the Administrator security group to roaming users profiles”. 

Once this policy is applied to computers, when a user logs in the computer adds the Administrator group to the ACL of the roaming profile. However, this policy has a catch in that it only takes effect on roaming profiles created after the policy was deployed. If a user has a roaming profile from before the policy was deployed, the Administrator group will not be added to it. Even if the user logs in to a new machine the Administrator group will not be added (because in effect the machine is downloading the existing profile and leaving things as they are). Of course, if you delete the roaming profile of an existing user so it’s recreated afresh then the Administrator group will be added. 

admin group gpo

 

The only way to assign access to the Administrator group in such cases is to take ownership of the user’s roaming profile add the Administrator group to its ACLs. Best to create a PowerShell script or a batch file and automate the whole thing. 

[Aside] Couple of GPO notes

Figured something that had been bugging me for long. Got a couple of Win 8.1 machines in my test lab and startup scripts would take a while to launch on them. Initially I thought it must be security related or something, then I noticed that the Win 7 machines in the lab don’t have an issue. This got my checking for any Win 8.1 changes with startup scripts, and found this blog post. Turns out with Win 8.1 startup scripts are delayed for 5 mins! Good news is this setting can be turned off via a GPO – Computer Configuration\Policies\Administrative Templates\System\Group Policy\Configure Logon Script Delay.

Another thing I learnt today was regarding applying language settings via GPO preferences. By default they don’t get applied until you press the F5/F6 key to mark it as enabled. 

Lastly, just as a reminder to myself – to change the default Start Menu power button from Shutdown to anything else, use this GPO setting

Tip: Overriding a GPO setting via Registry

At work our Desktops team has put a policy in place that enables Outlook cached mode for every one. Which becomes a pain in the a$$ when you have to disable and enable cached mode for some users as part of fixing issues (OST file corruptions, no incoming emails, etc).

Thankfully this is a setting you can temporarily override via the registry. Just got to modify a key under HKCU.

But … if you open the registry as the affected user and try modifying the key, you can’t because of lack of permission. Expected, right? What’s the point of a policy if users can modify the registry directly to override it. Admin users can modify the key, but if you open the registry as an admin then HKCU points to the admin and not the user.

Here’s how you workaround though: open the registry by doing a “run as” as the admin. Then go to HKEY_USERS. One of the entries there will be for the user logged in. (There shouldn’t be many entries, but if there are then you can find the one you want in one of two ways: (1) Use psgetsid from the Sysnternals tools to find the SID of the logged in user. That’s the entry you want. Or (2) go to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. You will find entries there with the same names as under HKEY_USERS. Check the ProfileImagePath key in each – the one with the path to the logged in user is the key you want).

Once you find the key of the logged in user under HKEY_USERS that’s it. Everything under here is the HKCU of the logged in user so any changes you make here reflect HKCU. Go ahead and change whatever you want – the change will succeed because you are now using an admin account to make changes to the logged in user’s HKCU. Hah!

Hope this helps someone.

GPO errors due to SYSVOL replication issues

So the other day at my test lab I noticed many of my GPOs were giving errors. Ran gpupdate /force and it gave the following message:

User policy could not be updated successfully. The following errors were encountered:

The processing of Group Policy failed. Windows attempted to read the file \\rakhesh.local\SysVol\rakhesh.local\Policies\{F28486EC-7C9D-40D6-A243-F1F733979D5C}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following:
a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.
Computer Policy update has completed successfully.

To diagnose the failure, review the event log or run GPRESULT /H GPReport.html from the command line to access information about Group Policy results.

Looked like a temporary thing so I didn’t give it much thought first. But when policies were still not being read after half an hour or so I figured something is broken.

Running gpresult /h didn’t have much to add. I noticed the there were errors similar to the one above. I also noticed that another policy had a version mismatch to the one on the server (this wasn’t highlighted anywhere, I just happened to notice).

I went to the path in the error message on each of my DCs (replace rakhesh.local with your DC name) to find out which DC had a missing file. As the message indicated, it was a replication issue. I had updated the GPO on one of the DCs but looks like it didn’t replicate to some of the other DCs; and my clients were trying to find the policy files on this DC where it didn’t replicate to, thus throwing errors.

Event Logs on the clients didn’t have much to add except for error messages similar to the above.

Event Logs on the DCs were more useful. “Applications and Services Logs” > “DFS Replication” is the place to look here. Interestingly, the DC where I couldn’t find the GPO above reported no errors. It had an entry like this:

The DFS Replication service successfully established an inbound connection with partner WIN-DC01 for replication group Domain System Volume.

Additional Information:
Connection Address Used: WIN-DC01.rakhesh.local
Connection ID: 11C8A7A0-F8A5-4867-B277-78DDC66E3ED3
Replication Group ID: 7C0BF99B-677B-4EDA-9B47-944D532DF7CB

This gives you the impression that all is fine. The other DC though had many errors. One of them was event ID 4012:

The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL\domain. This server has been disconnected from other partners for 118 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected.

To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group. This causes the server to perform an initial synchronization task, which replaces the stale data with fresh data from other members of the replication group.

Additional Information:
Error: 9061 (The replicated folder has been offline for too long.)
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: 0546D0D8-E779-4384-87CA-3D4ABCF1FA56
Replication Group Name: Domain System Volume
Replication Group ID: 7C0BF99B-677B-4EDA-9B47-944D532DF7CB
Member ID: 93D960C2-DE50-443F-B8A1-20B04C714E16

Good! So that explains it. Being a test lab, all my DCs aren’t usually online. In this case, WIN-DC01 is what I always have online but WIN-DC02 is only powered on when I want to test anything specific. Since the two weren’t in touch for more than 60 days, WIN-DC01 had stopped replicating with WIN-DC02. Makes sense – you wouldn’t want stale data from WIN-DC02 to overwrite fresh data on WIN-DC01 after all.

The steps in the Event Log entry didn’t work though. Being a SYSVOL folder there’s no option to remove a server from the replication group in DFS Management.

I searched online for any suggestions related to event ID 4012 and SYSVOL, adn found a Microsoft KB article. This article suggested running two commands which I’d like to post here as a reminder to myself as they are generally useful to quickly pinpoint the source of an error. Being a test lab I have just 2-3 DCs so I can go through them manually; but if I had many DCs it is useful to know how to find the faulty ones fast.

First command simply checks whether the SYSVOL folder is shared on each DC:

Next command uses WMIC to get the replication state of this folder on each DC.

A state of 5 indicates the group is in error. Interestingly, the “Access denied” message is one I had noticed earlier too when running dcdiag on the faulty DC.

I didn’t think much of it that time as there were no errors when running dcdiag from the working DC and also because I ran this command while I thought the error was a temporary thing. I still don’t think this is a permissions issue. My guess is that it is to do with the content freshness error I found in the Event Logs earlier. Possibly due to that the second DC is being denied access to replicate and that’s why I get the “access denied” error above.

From the KB article above I came across another one that has steps on how to force a of SYSVOL from one server to all the others. (In the linked article, the section ‘How to perform an authoritative synchronization of DFSR-replicated SYSVOL (like “D4” for FRS)’ is what I am talking about). Here’s what I did:

  1. I launched adsiedit.msc and connected with the default settings
  2. Then I opened CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=WIN-DC01,OU=Domain Controllers,DC=rakhesh,DC=local (replace the DC name and domain name with yours; in my case WIN-DC01 is the DC I want to set as authoritative) and …
  3. … I set msDFSR-Enabled=FALSE and msDFSR-options=1

    adsiedit

  4. Next, I opened CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=WIN-DC02,OU=Domain Controllers,DC=rakhesh,DC=local – WIN-DC02 being the DC that is out of sync – and set msDFSR-Enabled=FALSE.
  5. For AD replication through out the domain:

  6. The result of the above steps will be that SYSVOL replication is disabled through out the domain. I confirmed that by going to the “DFS Replication” logs and noting an event with ID 4114:

    The replicated folder at local path C:\Windows\SYSVOL\domain has been disabled. The replicated folder will not participate in replication until it is enabled. All data in the replicated folder will be treated as pre-existing data when this replicated folder is enabled.

    Additional Information:
    Replicated Folder Name: SYSVOL Share
    Replicated Folder ID: 0546D0D8-E779-4384-87CA-3D4ABCF1FA56
    Replication Group Name: Domain System Volume
    Replication Group ID: 7C0BF99B-677B-4EDA-9B47-944D532DF7CB
    Member ID: 09E14860-47F6-49EE-820E-43F7ED015FEB

  7. Then I went back to CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=WIN-DC01,OU=Domain Controllers,DC=rakhesh,DC=local but this time I set msDFSR-Enabled=TRUE.
  8. Again, I forced AD replication through out the domain.
  9. Next, I ran dfsrdiag pollad on WIN-DC01 (the DC with the correct copy) to perform an initial sync with AD. (Note: My DC was a Server 2012 Core install. This didn’t have dfsrdiag by default. I installed it via Install-WindowsFeature RSAT-DFS-Mgmt-Con in PowerShell).
  10. I checked the Event Logs of WIN-DC01 to confirm SYSVOL is now replicating (event ID 4602 should be present):

    The DFS Replication service successfully initialized the SYSVOL replicated folder at local path C:\Windows\SYSVOL\domain. This member is the designated primary member for this replicated folder. No user action is required. To check for the presence of the SYSVOL share, open a command prompt window and then type “net share”.

    Additional Information:
    Replicated Folder Name: SYSVOL Share
    Replicated Folder ID: 0546D0D8-E779-4384-87CA-3D4ABCF1FA56
    Replication Group Name: Domain System Volume
    Replication Group ID: 7C0BF99B-677B-4EDA-9B47-944D532DF7CB
    Member ID: 93D960C2-DE50-443F-B8A1-20B04C714E16
    Read-Only: 0

  11. Finally, I went back to CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=WIN-DC01,OU=Domain Controllers,DC=rakhesh,DC=local and set msDFSR-Enabled=TRUE. You can see what’s happening, don’t you? First we disabled SYSVOL replication on all the DCs. Then we enabled it on the authoritative DC and got it to sync to AD. And now we are re-enabling it on all the other DCs so they get a fresh copy from the authoritative DC.
  12. Lastly, I did a dfsrdiag pollad on WIN-DC02 … and while it should have worked without any issues, I got the following error:

    C:\Users>dfsrdiag pollad
    [ERROR] Access is denied when connecting to WMI services on computer: WIN-DC02.r
    akhesh.local

    Operation Failed

However, Event Logs on WIN-DC02 showed that SYSVOL was now replicating successfully and clients are now able to download GPOs successfully. So it looks like the “access denied” error is something else altogether (as I suspected initially, yaay!). I’ll have to look into that later – I know in the past I’ve fiddled with the WMI settings on this machine so maybe I made some change that I forgot to reset.

Good stuff!

Loopback GPO processing

It’s been a while since I dabbled in GPOs so today I stumbled upon something I knew but had forgotten.

There are two sort of settings in a GPO (Group Policy Object): Computer settings & User settings. Computer settings apply to the computer itself, use settings apply to the user logging in to the computer.

You apply GPOs to OUs (Organization Units). Thing is, usually your user objects and computer objects will be in separate OUs – say you have an OU for all your desktops, an OU for all your servers, an OU for all your regular user accounts, and an OU for all your admin accounts. In such a scenario how would you go about applying a GPO to only admin accounts that login to a server.

You might link the GPO to the server accounts OU thinking that will cause it to apply to all users logging in to that servers. And it will, but there are two catches:

  1. It will apply to all users logging in to that server, not just the admin accounts (unless you separately disable non-admin accounts from logging in to that server – in which case you are covered); and
  2. More importantly, any user settings in the GPO will not be applied to users that login as the GPO is set to apply to computer objects (because that’s what the OU contains) and since user settings don’t matter to computers these will not be applied to users that login. By default, a user’s policy settings come from GPOs applied to the user object, not the computer object.

You could, of course, apply the GPO to the admin accounts OU but that has the side effect of applying the GPO when admin accounts login to a regular computer too. Not what you want.

The way to resolve this is via loopback GPO processing. Loopback GPO processing tells the computer to apply the user settings assigned to it to all users logging in to that computer. You can use loopback GPO processing to replace the policy settings applied to the user with the user policy settings on the computer. Or you can use loopback GPO processing to merge the two (with the user policy settings on the computer taking precedence).

To enable loopback GPO processing for a particular GPO, go to its Computer Configuration\Administrative Templates\System\Group Policy section using GPMC, open the Configure user Group Policy loopback processing mode policy setting, and change it from Not configured to Enabled and select one of Replace or Merge.

Export and Import Group Policy Objects (GPOs)

This is useful if you want to trash your VMs for instance and start afresh. Good to have all your GPOs backed up and handy so you can easily restore to the new domain.

There’s two ways of exporting and import GPOs: you can use the Group Policy Management Console (GPMC) or you can use PowerShell.

Using the GPMC

gpo-restore

To backup a GPO: open the GPMC, drill down to the Group Policy Objects container, right click on the GPO in question and select Back Up. Follow the dialog boxes that appear and save the GPO to wherever you want on the computer.

Note that you have to go down to the Group Policy Objects container.  Right clicking on the links to the GPOs from any OU won’t get you the correct menu.

The folder where you backup GPOs to contains sub-folders that contain the GPO files and settings. The sub-folders are named after GUIDs that uniquely identify the instance of the backup. If you take another backup of the same GPO to the same folder, the sub-folder that is created will have a different GUID. Within these sub-folders you can double-click a file called bkupInfo.xml to see the details of the GPO that was backed up.

To restore a GPO: open the GPMC, right click on the Group Policy Objects container and select Manage Backups. In the dialog box that appears set the path to the folder containing the backed up GPOs and then select the GPO that you want to restore.

There is a catch though. You can only restore GPOs to the same domain where they were backed up from. Not domain with the same name, but same domain. And if you try to restore a GPO to a different domain, you get a very uninformative “Failed…” error.

To work around this, you can import GPOs. For that go down to the Group Policy Objects container, create a new GPO, right click the GPO, and select Import Settings. Follow the dialog boxes that appear to give the path of the folder containing your backed up GPOs, select the GPO you want, and import. The difference between import and restore is that the former does not carry over the security settings nor does it restore the links of the GPO.

Using Powershell

Before you can use PowerShell to manage GPOs you must import the grouppolicy module:

After that you use many PowerShell cmdlets to manage GPOs. For instance:

To backup a GPO use the Backup-GPO cmdlet:

Note the output gives you the GPO name, GUID, and a GUID for the backup instance. We encountered the latter when using the GPMC. The sub-folders created in the path that you specify are named with this backup instance GUID.

It is best to specify an absolute path to the cmdlet. If you must specify relative paths, be sure not to start it with a period else the cmdlet throws an error. Even without the period, I find some of these cmdlets give an error.

To restore a GPO use the Restore-GPO cmdlet. Same caveats apply as the GPMC – restores can only be done to the same domain. Else a cryptic error is thrown:

The workaround, as before, is to import the GPO. First create a new GPO, then import:

It is possible to skip explicitly creating a new GPO before importing. Simply add a switch -CreateIfNeeded to the Import-GPO cmdlet and it will automatically create a new GPO with the target name given. Also one can backup/ restore/ import all GPOs by specifying a -All switch to the cmdlet. For instance:

That’s all for now!