There are a few things that are inevitable in this world. You always hear people say it is death and taxes. I think it is a little different than that though, I think it is Change, and that something will break at the worst possible time. Murphy’s law and all that. In either case, you need to know how to change it or fix it. It works that way for Group Policy too. Someone will either change something and you need to update the policies, or something will break and you will need to fix them.

Let’s get ahead of the curve and take a look at how we can troubleshoot issues with the group policy.

To troubleshoot, we really need to have an understanding on how and why things work the way they do. We have already looked at what Group Policy is and how to create them. so let just recap a few key points here.

• Group Policy lives on the domain controller. The thing to remember here is, you need to be able to talk to the domain controller. Sounds simple right? Well, I cannot count the number of times that I have gotten calls from people working from home with no VPN saying something does not work. Why have my share drives not connected? I need those! This is where the domain controller comes in, if you can not reach the domain controller you cannot get the GPO that would map these drives. Also, if you cannot talk to the file server…you probably will not get access to those drives.
• DNS DNS DNS!!! I cannot say this enough. People always tend to forget about this little gem of the IT world. DNS makes things work, and when it breaks or you are not using. Things do not work like you expect. Often times you will find that someone has “helped” a user by changing their DNS over to google or something and forgot to change it back. This would help with some issues, and in a home network would be fine. However, in a domain environment like you have at the office. This creates a problem. You would be setting custom DNS records on the domain controller usually. So if you are not getting DNS from the DC, then how would you get those records?

Pro Tip: Domain controllers should have DNS set to look at each other. Root hints should be used if you need to use an external DNS for lookups.

• Know where your GPO’s are being applied. There are very very few GPO that should be applied at the top level. such as only the default domain policy. The reason for this is that anything you apply at the top level would apply to everything on the domain. Why would you want to apply a GPO to every machine ever? I know it sounds like something you would want to do, but do you want that policy to be applied to server? to admin accounts? Most likely you would not. I always have an OU that is named for the company and everything goes inside that one. This allows me to create test OU’s outside of the company policies and apply test OU’s to the test environment only.
• Why does my computer hang for 5 minutes when I logon? You forget a logon script, didn’t you? It’s ok I won’t tell anyone. We all do this from time to time. The default time out for a script is 5 minutes. Check to make sure you do not have something trying to run that is having an issue.
• Enforced GPO’s vs inheritance. Sometimes we want to apply something to anything that touches the domain. An example of this would be a remote access agent. in that case you would be able to set it enforced and it would still apply even if you blocked inheritance to an OU. In either case, it can cause big headaches as you track down problems. So it’s best to avoid both options when you can
• Group Policy and security groups, sounds like a winner right? Not exactly, You can not apply a GPO to a group. You can use the security filtering to have it apply to the members of the group. Remember to take out authenticated users though. If you miss this step it can apply the GPO to users or computers that are not intended.
• Disabled GPO’s are something I always suggest against. If you do not need the GPO anymore, then just unlink the GPO. Leaving it linked and setting it to disabled can cause a lot of confusion.
• Security permissions can be set on a GPO, but it is usually not needed. Only set custom security permissions as a last resort.

Keeping those common things in mind, let’s look at how we troubleshoot. With GPO’s this is really all about making sure the machine or user has the GPO applied to it. If you build the GPO correctly, it will work once it is applied. How do we know it is applied?

My first thought is to go with command prompt and use gpresult. This lets me see if the policy is being applied yet. That can save you a lot of time troubleshooting something that is not even applied.

gpresult /s ComputerName /user Domain\UserName /r

Lists summary of applied GPOs when the specified user is logged onto the specified computer. This can be useful if you are running this command from the back end or as the administrator.

gpresult /s ComputerName /user Domain\UserName /r /scope user

The /scope user will let you narrow the results to only show user GPO’s

gpresult /s ComputerName /user Domain\UserName /h gpreport.html

The /h filename.html will generate an HTML report that is a bit easier to read.

gpresult /s ComputerName /user Domain\UserName /z

Adding a /z will generate a verbose report of user and computer policy settings.

Remember you can always save these to a text file by using > c:\folder\filename.txt

If you have issues with the default policies, they can be reset. This should ALWAYS be a last resort.

NOTE: Doing this will remove any changes you have made to them.

To reset your Default Domain Policy and/or Default Domain Controllers Policy GPO to their default settings, perform the following steps:

1. Log on as a Domain Administrator to a Domain Controller.

2. Open an elevated command prompt.

3. Enter the parameter to reset:

dcgpofix /target:Domain 

To reset the Domain GPO.

dcgpofix /target:DC 

To reset the Default DC GPO.

dcgpofix /target:both 

To reset both the Domain and Default DC GPOs.

4. After you enter the appropriate command in Step 3, enter Y to both prompts.

5. Close the command window.

If you think someone has made changes to the local security policy on a computer, that too can be reset. It is not as common but there is a command to do that.

1. Log into an account with local administrative rights on the machine in question.

2. Click Start, Run, then enter “cmd” in the prompt, then <Enter> to start a command session.

secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose

To reset Local Security Policy.