Blog: group policy

Recently I was deploying Cylance for a customer. The first approach I took to deployment was to create a group policy that ran a batch script at logon. I set up the policy and then restarted one of the test PCs I was working with. The group policy was being applied, but the software was not installing.

My research suggested disabling  asynchronous processing of group policies. To do that, I went to Group Policy and navigated to:  Administrative Templates\System\Logon. There is a policy called Always wait for the network at computer startup and logon and when that is enabled, it turns off asynchronous processing. As soon as I enabled that, the install worked.

Not long after I applied that policy, the customer called and said their users were having issues with one of their applications not launching. After some investigating, it turned out that the program required that a network drive be mapped first, before the program could launch. Clearly the order of operations was broken when I disabled asynchronous processing. So, I turned it back on, but the trick about group policies is that you have to go in and manually fix anything that was modified in the registry. I fixed that and everything started working. Moral of the story is always remember the policy changes you make, just in case you need to go unmake them.

I had two customers that needed to exempt a couple of systems from a group policy that disables USB/CD-ROM access, but I ran into the same issue both times when trying to do so.

I added the user to the appropriate group to block the GPO, but when I logged into the user’s PC, the drives still said access denied. I figured the group policy had not applied, so I forced it to apply and then I had the user both log off and back on and also restart with no success on the policy applying.

I did some digging and discovered that there is a bug in Windows that affects the Portable Device Enumerator Service. I tried several things with that service (restarting, looking at other depenedent services, etc) but nothing worked. Microsoft had a Hotfix available, so I tried that and still got nothing. Finally, after some additional research, I ran across a KB article that recommended going into Disk Management, uninstalling the driver for the CD-Rom and then rescanning the disks to let it re-install. As soon as I did that, everything started working properly. 

Here is the KB article with the Hotfix, in case it happens to work for someone else down the road: https://support.microsoft.com/en-us/help/2738898/users-cannot-access-removable-devices-after-you-enable-and-then-disabl

When enabling most roles and features in Windows Server 2012 R2, you can simply add the roles or features and the server will pull the installation files from the C:\Windows\WinSxS folder. However the installation files for .NET Framework v3.5 are not included in this folder and must be downloaded from the operating system installation ISO or from the Internet.[more] On the last page of the “Add Roles and Features” wizard, there is an option for an alternate source for the installation files. You should be able to set this to the drive where the ISO is mounted or attached, and point to the “DriveLetter:\Sources\SxS” folder.

When I used the alternate installation path to D:\Sources\SxS on a server I was building, I received a message saying it could not find the installation source. The solution in this case was to create a Group Policy Object that was scoped to the new server and set the installation file location in the GPO. The settings I used in the GPO are below. After applying this GPO, I was able to install .NET Framework 3.5 from the mounted Server 2012 R2 installation CD.

While making sure a server was being automatically patched every month through Windows Updates, I logged on and made the necessary changes to get the server into WSUS, but then I wanted to verify that this server would install and reboot automatically. Opening the Group Policy Management Console, I was greeted with "The Network Name could not be found."

Troubleshooting this message, I found that if I connected to the other domain controller, I could load the GPMC without any issues. Furthermore, the DC I originally attempted work on was reporting the following error:

Event Type:       Error
Event Source:     NtFrs
Event Category:   None
Event ID:         13568
Description:      The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.

Further troubleshooting showed that this DC didn't seem to have any replicated data from the other domain controller. Fortunately, this same event had a resolution in the log as well.

Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.

1. At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run "net stop ntfrs" followed by "net start ntfrs" to restart the File Replication Service.
2. At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again.

To change this registry parameter, run regedit.

Click on Start, Run and type regedit.
Expand HKEY_LOCAL_MACHINE.
Click down the key path:
   "System\CurrentControlSet\Services\NtFrs\Parameters"
Double click on the value name
   "Enable Journal Wrap Automatic Restore"
and update the value.

If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above.

After running through the steps listed above, everything synced up like it was supposed to and the GPMC started working on the original DC.

Recently I got assigned a task to investigate why users could copy/paste from their laptops to their View machine, but were unable to copy/paste in the opposite direction.  After doing some research I found out that this option is disabled for security reasons, but figured out how to fix it.  There are VMWare View Group Policy templates located on the View Connection Server in: c:\Program Files\VMware\VMware View\Server\extras\GroupPolicyFiles\ .

The policy for the “Configure clipboard redirection” is in the pcoip.adm template.  I added the policy to the VMWare View machines group and enabled it.  There are several different choices to pick from and I chose to “Enable it in both directions”.

After I added the policy to the VMWare View machines, I ran a “gpupdate /force” on my machine and noticed it didn’t fix the problem.  You have to restart the View machine in order for the policy to work.

During the installation and setup of VMware Capacity Planner we ran across a couple of servers that were not receiving performance data. After looking at GPOs and permissions, the problem still existed. It was discovered faulty performance counters could cause the problem. We connected via remote desktop to the problematic servers and opened the performance monitor. There was no data present and all the monitor names were changed to numeric values. This meant the performance monitors were corrupt causing the problem with VMWare Capacity Planner. The bank staff said they would address the problem.

An information security audit customer was using Group Policy to disable USB mass storage devices by setting the appropriate registry key from a value of 3 to 4.  They verified the registry values were what they expected and moved on to other things.

After I arrived onsite and spot checked the USB restrictions on some of these workstations none of them prevented the use of my flash drive.  They scratched their heads and checked the registry key and it had been changed back to a 3.  If they forced a GPO update, the key was changed back to a 4 and USB mass storage devices were restricted from then on.

What was happening was these systems had never had a USB mass storage device attached.  The first time one is connected, the system performs the initial installation steps, one of which sets this key to a 3 even if it was set to a 4.  After reapplying the GPO, the restriction finally took effect for good.

While working with a client, I recently promoted a new Windows 2008 R2 virtual server to a domain controller.  Prior to running dcpromo.exe everything looked and performed great, but I noticed a large amount of system resource issues following the promotion.  I also ran into several cases of not being able to open various management console snap-ins or other applications.  After troubleshooting various issues I finally decided that they all must have had a singular root cause. 

After digging around in the event viewer and scratching my head a bit, I asked another network engineer what I was missing. He looked around for a few minutes and asked me if disk quotas had been enabled via group policy.  I opened up the Group Policy Management console on another server and discovered a disk quota group policy object for terminal servers that had been applied to the Domain Controllers OU.  After excluding the new domain controller from receiving the policy, and then manually removing the existing disk quota entries the server was running at full speed with full functionality.

As part of a Citrix environment overhaul, another network engineer and I discovered a very frustrating limitation of using group policy with Citrix published applications. The problem centers around the inability to apply IE group policy settings using loopback mode processing. I'll warn you ahead of time, there are lots of details so hang with me....and remember this is all going to converge at the application of group policy. Here is what we found...

When a user with an empty roaming profile (new user) has their profile created as the result of running a published application, the user portion of the registry hive (ntuser.dat) is not created in its entirety. The users' hive can be loaded and a number of noticeable differences exist between it and the default user registry hive. If the user profile is created by logging on locally (console), via RDP to the same machine, or via Citrix published desktop on the same machine, the profile that is created is complete. I was unable to find any noticeable differences between the default user registry hive and that of the newly created roaming user profile when the profile was created in this way. Additionally, once an incomplete profile had been created via published application session, the profile could NOT be "fixed" by logging on via RDP or published desktop. Once the registry hive was created in an incomplete fashion, it seemed to be affected from then on. So why are we talking profiles...I thought this was about group policy? Well, it is...I'm getting there. [more]

We found that users running published applications did not have group policy correctly applied. We were trying to set policies on Internet Explorer using Internet Control Panel settings in the user portion of the GPO. Specifically, IE security zone settings such as trusted and intranet sites would not apply. We also noticed that each security zone seemed to be locked. In the Security tab of the Internet Options dialog box, all the icons were the same....blue IE symbol with a lock next to it. The "Sites" button and the "Custom Level" button were also grayed out. So, here is the where the profile problem merges with the group policy problem. I found that by manually exporting certain keys from the default user profile registry hive under \Software\Microsoft\Windows\CurrentVersion\Internet Settings\ and importing them into in a incomplete user registry hive, I could fix the problem. That is, once the keys existed in the user registry hive that pertained to the settings I was trying to set via group policy, the policy was applied correctly...no issues. Makes sense right....if the group policy is setting registry keys in order to apply certain policies, it’s not going to work if the keys don't exist in the first place.

So things have come full circle. Group policy isn't working because the user profile is messed up. So why is the user profile not getting created correctly? Well, this is actually a Microsoft problem --> http://support.microsoft.com/kb/899270. And the script they provide doesn’t work…we tried it. Actually, there is more to the problem than that, but here is a summary of the information that we gathered. By design, Citrix published applications, remote applications in Windows 2008, and the "start this application on connection" functionality of RDP (mstsc.exe) running against Windows 2003 servers implement limited logon functionality so that the session footprint is smaller than a normal desktop session. Part of the "limited functionality" is that the user session does not start explorer.exe. So, any application that depends wholly or in part on explorer.exe could have issues. Some of the important pieces of functionality that explorer.exe implements are the following:

1. The run registry entry
2. The RunOne registry entry
3. Startup applications 

If you have ever noticed the small gray box that is displayed the first time you log on as a new user, you have seen the effects of explorer.exe running at session logon. It goes by fast, but it says something like "applying internet explorer customizations", "setting up windows media player..."...stuff like that. That little box is normally initiated by explorer.exe. It is called runonce.exe. What we found was that if we initiated runonce.exe in a logon script, the user was created correctly when running published application; thus, group policy was applied correctly as well. Testing also showed that this process could also fix a previously created broken user registry hive (ntuser.dat). All we had to do is add the following to our logon.bat file

start /MIN %windir%\system32\runonce.exe /AlternateShellStartup

Citrix has documented this problem in a support article (http://support.citrix.com/article/CTX104374) and they refer back to the previous MS KB listed above. Numerous forums threads exist on this issue and we were unable to find a resolution elsewhere that did not include scripting registry imports to the user profile at logon. This workaround seems to be a more flexible and reliable.