Group Policy Trouble Shooting – Conference Call

Group Policy Trouble Shooting – Conference Call

I have been working with group policy recently and have been enjoying it. I wanted to share this knowledge with the rest of the world. I’m going to do that through a few scenarios. This first part is gathering information. More information you have, the more likely you will be successful at resolving the issue.

Scenario – User can’t hear conference call

The ticket came in as, “I can’t hear people on a conference call with XYZ company.” The help desk guy tried to figure it out. He updated the ticket with “It’s just broke.” Then he escalated the ticket to me. So, I called the person up and was blasted with an ear full of, “it ain’t working, and this be broke and that be broke, and I needed this call for a client, and and and…” The normal basically.

Who, What, Where, When, How

Here is the information I pulled. Who is the User? What computer is the user using? What is the real problem? Where is the Computer located? Where are the user and computer located in AD? When did this start happening? Finally, how can I recreate the issue?

Once I pulled that information, I discovered they were using a Website to communicate with an HR company via web conferencing. Hum… Anyways, The computer was in the standard laptop OU, and the user was inside the standard Recruiter’s OU. The problem was only noticed that week. I asked her to try another site and finally had her try google video conferencing. None of these technologies worked. I finally had her try a product She has used in the past that worked. This product was an in-house remote connect with the audio program. The in-house program worked. At this point, I knew the browser was ok. There was something else stopping it. I suspected Group Policy at this point.


To confirm group policy was doing this to her, I ran the “Group Policy Results Wizard” in the group policy management console towards the bottom. Inside the wizard, I selected the computer she was on. Then I selected her. The wizard did its wizard magic and gave me a full list of everything that was applied to her, how long each step took, and which one won over the other. Sure enough, she had a browser policy attached to her. From the wizard, I was able to see the website she was trying to use was not listed. At this point, I had some work to do.

  1. Make a change request with managements. If approved, move to the next step. If not, tell the user they are not allowed to use the conferenceing software on those sites.
  2. Add the site to the group policy
  3. then run gpupdate /force on her computer

Management did not approve the change. So, I called the user and informed them of the issue. They were not happy, but then I had the power of management behind me.

Deeper Dive

There are a few things in the Scenario to take note of.

  1. Getting the right information from the user is key.
  2. Scopes of group policies on a user and the OU they are in.
  3. The group policy management tool has some cool troubleshooting tools.
  4. Permissions from Management, AKA, cya.

Getting the right information from the user

Getting the right information is hard sometimes. Here is the conversation that went down between me and her.

  • Me: Which computer is this happening on?
  • Her: ALL OF THEM! (First Key that it’s group policy)
  • Me: let’s focus on one computer. Which computer was the first computer you noticed this issue?
  • Her: Gives me a computer name.

Once I had the computer name that it happened first. I pinged it to see if it was active or not. I also know that she has logged into the computer within the past few days as the ticket she put in was only a few days old.

AD information and Scopes

As I had a hint that this might be a group policy-related item from when she said, “It happens Everywhere” I made sure to note at the OU the computer was located in and the OU the user was located in. Then I started up group policy management and looked at her and her computer there. Her OU had the browser policy inherited from the top-level user OU. Then I used the tools inside group policy to confirm the issue.

Using built in tools to confirm

Group policy management console has a set of very useful tools that will help out to gather information. The first tool is the Group Policy Modeling tool. This tool will create a “what if” to the information you feed it. It doesn’t need access to the computer in question, just the domain. The second tool, the one I used is called Group Policy Results. This bad boy needs access to the computer. What it does is it reaches into the computer and pulls the group policy information. This one shows you what happened. It’s kind of like running gpresult /r on a computer, but on drugs. This tool confirmed the browser policy was attached.

CYA like a kid in a candy shop

Group policy has the power to change everything that is connected to it. A simple small change can have rippling effects for years to come. There is a real chance of tattooing your network as well. Tattooing is where a group policy change stays after the policy has been removed. So, best to CYA yourself. For those that don’t know CYA means to cover your assets. This is why I brought management into the picture. They get paid the big bucks and if something happens, I can point to the email I sent to the management. The manager said no, and thus the answer became no.

I hope this was helpful for you all. The one thing I want you to take away from this blog is CYA! You can be the best at your job, but if you make a change and management don’t agree, cya can save your tail.

As always, if you have questions, feel free to ask.