While working with Group Policy this month, I ran across an oddity I have never seen before, “Extra Registry Settings” These were inside the default domain policy and I had no idea why they were there. So, I did some research.
What are they?
These keys come from when you have had an ADM or an ADMX installed. Then you create a policy. Later down the road, the ADM or ADMX is removed. These keys will be left behind. So, it’s a tattoo. More like a tattoo on the tattoo artist. You can read more about GPO tattooing here. The main difference between a normal tattoo and this tattoo is one happens on the end user’s computer, while the other happens on both the Group Policy and the end user’s computer.
This is one of those things that can go Very deep. To keep things simple, I will keep it general.
How do you remove it?
Inside the Group Policy Management Module that is installed with Rstat, you have a remove-GPRegistryValue command that can do what you are looking for. You will need the following, The Name of the policy and the key. Please note, these keys live in the HKEY_Local_Machine. Thus, you will need to add such to the command. Your registry might live in the Current users. Do a little research. Here is the code that I used to remove these two items:
Once you remove the Extra Registry keys, you can reload your Group Policy Management and remove the policy. Or you can replace Remove with Get. This will try to get the value, but if it doesn’t exist anymore, PowerShell will present an error.
Documentation is a big deal in the world of IT. There are different levels of documentation. I want to go over in-place documentation for group policy. Comments in Group Policy are in-place documentation.
How to comment on a Group Policy
This process is not straightforward by any stretch of the imagination. The first and foremost way to add comments to a Group Policy is to use the GUI.
Open Group Policy Management Console
Select the policy you wish to comment
Right-click the policy in question and click edit
Inside the group policy management editor, right-click the policy name and click properties
Click the comment tab
Now enter your comment.
click Apply and Ok
The second way to add a comment in group policy is by using PowerShell. The Description of a policy is where the comment lives. Thus using the command Get-GPO will produce the comment. We will dig more into that later.
Get-GPO -name "Control Panel Access"
Using the Get-Member command we can pipe our Get-GPO command and see what is doable. You will be treated to a list of member types and what they are capable of. The description has a get and a set method to it. This means, you can set the description, aka comment.
(Get-GPO -name "Control Panel Access").Description = "This is my comment"
Suggestions
Here are a few suggestions for documenting the policy like this.
Use the(Get-date).ToString(“yyyy-MM-dd_hh_mm_ss”) at the beginning to setup your date time.
Then, I would add the author of the policy/comment
A quick description of the policy
Whether it’s a user or computer policy.
Any WMI filters.
More information here helps the next person or even yourself months down the road. Don’t go overboard as it can cause issues later. Using the ‘`n’ will create a new line which can be helpful as well.
Pulling Comments with PowerShell
Now that we have all the policies documented, we can pull the information from the in-place documentation. We do this by using the GPO-Get -All command. One way to do this is by using the select-object command and passing everything into a csv. I personally don’t like that, but it works.
I would like to go deeper into In-Place Documentation as it is very useful down the road. Powershell uses the #, other programs use different methods as well. If you get a chance to place in place documentation, life becomes easier when you are building out the primary documentation as you have a point of reference to look back at.
Whenever we get a new client, one of the first things we do is create a new folder on the root of C called temp. If that client has a group policy we create a policy just for that. This guide is a simple one, it’s how to create a folder with group policy. This post will build on other posts. Let’s get started.
Creating the Policy
Start Group Policy.
Expand to your Group Policy Objects
Right Click and Select new Policy.
Name the Policy. I suggest, “Folder – Temp”
Right Click the “Folder – Temp” Policy and click edit
Naviage to Computer Configuration > Preferences > Windows Settings > Folders.
Right Click in the right plane
Click New > Folder
In the Path location, enter the path you want. In this case it will be c:\temp.
Click OK.
Now we have the policy made, we need to decide who is getting the policy. We want every computer to get this policy. Closeout the edit group policy and click on the policy. Then click on the delegation tab. Here we see our delegations. Right now every user and computer will execute this policy. We want to change that.
Delegating the Policy
Click on the policy in question “Folder – Temp”
Click the delegation tab.
Click Authenticated users
Click advanced
Click autenticated users in this window.
Uncheck apply group policy.
Click the add button
Search for Domain Computers
Give Domain computers Read and Apply by checking the check box on read and apply group policy.
Click Apply
Click Ok.
Linking the policy
Now the policy will only apply to Domain Computers inside whatever OU you link it to. Now we need to link it to an OU. Since we are doing this to all computers on the domain, we can link it at the top level. We do this by right-clicking the domain and clicking the Link existing gpo object. We search for the GPO in question and click it. Then we click ok. Within the next few days, the c:\temp folder will be created.
That is how you create a folder on all computers in your domain. If you have any questions, feel free to reach out.
This one was a fun one that really threw me for a loop. DNS is an issue no matter where you go. Recently facebook showed the world how DNS can take everything down. DNS in your domain is very important to keep alive and healthy. Having items sit in your DNS is deadly to your org. That is why something called DNS Scavenging exists. This story is a story about DNS and how it directly affected group policy.
Scenario – Wrong Server!
A client called and stated that group policy wasn’t applied to a single machine. He said he couldn’t even log into the machine with new accounts, just accounts that were on there from the day before. He went as far as to say that a user that just changed his password had to use his old password. Very interesting combo of items.
Who, What, Where, When, How
Who: Anyone using this computer. Users who never signed into the machine, and users who has signed in but changed their passwords recently.
What: Login with thier current passwords, Login, Group Policy not applying.
Where: This single machine, later on discovered another.
When: One week before the issue started. (After DHCP was edited)
How: When they log in.
When I first came in, I looked at the machine in question. I ran an IPconfig /all on the machine to get basic information. I marked down the IP, subnet, mac address, DNS servers, and the DHCP server. I then ran the gpresult /r and the command errored out saying the group policy server did not respond. Hum… I pinged the DNS I noted and the ping came back. I ran NSLookup on the dns server’s IP address to get a hostname. The hostname came back as “xxx-bobsmacbook”. Well now, that’s not the DNS server. I asked the client for the DNS server information. He gladly gave it to me. I RDPed into the DNS server. The DNS server was also the DHCP server and the AD server. All the fsmo roles were on this machine. Sigh… Ok, other than that, I deep-dived into DNS because the NSLookup came back as someone’s mac book. Sure enough, there was an entry into DNS from about 2 years before for bobsmacbook at the IP address the machine believed was the DNS server. Infact, every IP address in the subnet was inside there. Most of them were years old.
I looked at the client and asked why their DNS was so full of old records. He replied with, that’s our archive. It took everything in me not to facepalm. I mean, my hand moved instinctively to my face. After explaining the importance of DNS to the client, the client agreed to enable DNS Scavenging. Wouldn’t you know it, after the first rotation, the entire company started to move much quicker. Requests to the IIS server took only seconds instead of minutes. Copying files across the network just generally did better. NSlookup worked. The computer in question group policy was updated correctly. When DNS breaks, everything suffers. In this case, DNS was a young man covered in trash bags.
How to enable DNS Scavenging
DNS Scavenging is an windows feature that finds old stale records and removes them. This ensures environments with DHCP do not detect multiple devices based on bad/multiple DNS entries for the same device. Here are the steps to enable it.
Start > Programs > Administrative tools > DNS > DNS Manager.
Right click the DNS Server
Click set Aging/Scavenging for all zones.
Check box the “Scavenge Stale Resources Records
Select the No-refresh and Refresh intervals totals combined equals to or is less than the DHCP lease. If the lease is 8 days, set the rates at 4 each.
Click Ok.
On the Server Aging/Scavenging Confirmation screen, check box the “Apply these settings to existing active directory intergrated zones.”
Click ok
(Optional) Right click the DNS server and click the “Scavenage State Resource Records” to start the process.
There you have it. The DNS records will be purged when the time comes. This allows DHCP to issue IP addresses with no problems and DNS stays clean.
As always, if you have any questions, feel free to ask.
A while back, a client called and told me he made a few new group policies, and they were not working as expected. He stated some policies applied to the wrong users, while another didn’t apply at all to any users. He stated he set the security group correctly. When I hear, “The policy didn’t apply, or the policy is applying to the wrong person, I immediately think, delegation. Let’s look at the two policies and what broke them.
Scenario – Restricted Google Chrome Policy applying to everyone.
This client had special needs to restrict google chrome. This included items like the auto-fill feature to be turned off, prohibiting Chrome extensions, and more. This was user policy. He only wanted it to Restrict to the techs computers, and not the management nor the IT department.
Who, What, Where, When, How
Who: This was effecting all the users at once.
What: A chrome policy that restricted users in google chrome.
Where: Everywhere
When: After the client applied the google chrome policy.
How: Through Group Policy.
It was clear, group policy was the issue. So, I took a gander at the delegation of the policy he called “Restricted Chrome Policy”. The policy
Immediately, I saw that the tech group was not in the policy. In fact, this was the standard policy setup. However, one thing I have learned over the years, never to assume. So, I clicked the authenticated users and clicked the advanced button at the bottom of the delegation screen.
Showing Read is checked
Showing Apply is checked
In this case, I was right in my assumption. The authenticated user are every user on the domain. This is a large group and it’s required for any group policy to work. The thing about it though, if the “Apply group policy” is checked, it applies the group policy to everyone. (Unless another policy closing to the ad object applies or enabled that overwrites the policy in question. )
This is what I did. I unchecked the “Apply Group Policy” check box. Created a security group called SG_Policy_Chrome_Tech and added all the techs inside that group. Then I add that group to the delegation. I made sure the read was checked and apply group policy was checked. Then on an end user’s computer, I ran the gpupdate /force and the policy was applied correctly.
Scenario – Group Policy wasn’t applied at all.
The second policy was harder to track down as it was a password alert policy. (Something I will cover later). The policy was to prompt a user within 14 days that their password is going to expire. It is done with a simple logon script. Very simple script, very simple policy. They called it “Password Prompt”. The client discovered it wasn’t being applied when he completed a gpresult /r on an end-user and didn’t see it. It turns out that it was only meant for users and not service accounts.
Who, What, Where, When, How
Who: Users
What: Password Prompt is not applying
Where: Main OU level
When: Always
How: Hum…
By default, group policy management opens the policy where you can see the scope. I noticed right there something was missing. The client had set the user’s group “employees” but I didn’t see authenticated users. I went to the delegation tab, and I was right. There was no authenticated users group. I went through and added the authenticated users group, and made sure the “Apply this policy” wasn’t checked, and read was checked.
The reason we do this is we want everyone to read the policy, but not apply it. How can you apply something you know nothing about? The same concept is applied here. The computer account can’t read the policy if it doesn’t know it exists. The authenticated user allows that reading. Once set, and a good old gpupdate /force was applied. The password policy showed applied.
Another way you can go about doing this is by adding the domain computers group. As it is the computer that will need to read the policy. This is thanks to the June 14 2016 security update.
The takeaway
Delegation is important. The Authenticated user’s group is required in all group policies at a minimum of read. If you set the authenticated user’s group to read-only, you use a security group with apply in order to apply a policy. The scope screen only shows you what is being applied, and thus, you may not even notice the authenticated users.
I hope this has been helpful for you. As always, if you have questions reach out to me.
Any IT professional will tell you, technology changes almost daily. Some things seem like they will never change then bam, it changes. For example the dependency on IE. In the 90s and most of the 20s it was IE. Firefox and Chrome started back then but didn’t really gain traction. Now here it is 2021, Google search no longer supports IE. Microsoft no longer supports IE. IE is a bad word in the security world. So it’s time to move away from IE. Most companies have done just that. Thousands of security-minded websites no longer develop for IE and purposely broken their sites on IE. The immortal IE was a problem this week.
Scenario – Always IE
A user called in and stated “Every time I go to ADP I get a message saying ‘Your browser isn’t supported.'” The browser was IE. ADP was a URL link on the desktop. URL links go to the default browser. The user stated that they changed the default browser to Google Chrome more than once, but it changes back after they restart the computer.
Who, What, Where, When, How
Who: The user was a standard user and located in the User OU in AD.
What: URL link is opening IE instead of google chrome.
Where: End user’s laptop.
When: Every time they reboot.
How: When they double click a url icon.
With this info gathered, I started troubleshooting. I changed the default browser to Google chrome. The user stated after a reboot it changes back. I rebooted the machine to see this behavior. Sure enough, the default app changed from Google Chrome to IE. The most common thing that changes the default apps around is Group Policy. I ran gpresult /r on the computer and saw a default app policy.
Hum…
I logged into the server and loaded the group policy. Sure enough, there was a default app policy. This policy lived at the top level of the domain as well. Default app policy lives under Computer > Policies > Administrative Templates > Windows Components > File Explorer > Default Associations Configuration File. They use an XML file on a share that can be read by everyone in the company. I looked into this file and saw .htm, .HTML, HTTP, and https were set to internet explorer.
At this point, I knew this was going to be a change request. I informed the client that this is a change request. Then I contacted the client’s leadership and acquired permission from the leadership via email. They responded with, YES PLEASE! This is my CYA that I needed. My assets were covered. Time to kick it into high gear.
Inside the default app XML file, I changed the .htm, .HTML, HTTP, and HTTPS progId to ChromeHTML and the ApplicationName to Google Chrome. This is what it looked like.
I asked the user to reboot their computer and test if the URLs opened in google chrome. The user reported that it did. I called few other users in the org and tested with them. Normally I would create a new OU and test with a test box, but this client did not have a test box. So, why not test in production! Please don’t test in production unless you have to.
In the end, the problem was a Default App Policy. Fixing that fixed more than just this single user’s issue. The leadership was happy with the change and they enjoyed using their drag and drop URL icons.
As always, if you have questions, feel free to ask.
