Mastering GPO Troubleshooting: The Ultimate Guide for IT Admins Using GPOZaurr

We just finished a series on understanding Active Directory Group Policies and it's a complex topic. What we're going to do now is jump from that into troubleshooting. So we're going to be looking at troubleshooting these very complex group policies. I'm going to be using a PowerShell module that just does a fantastic job of walking through the fundamentals of troubleshooting group policies. We're going to be using a PowerShell module that's found in the PowerShell gallery. It is called Group Policy Eater. It's called G-P-O-Z-A-U-R-R. You can also go to the GitHub site and the gentleman who has written this module has made it fully available open source. You can take a look at everything that he has done in this module. The module is extremely common sense. And the reason I'm going to use this module for troubleshooting G-P-O-Z-A-U-R-R is because whether you use the module or not, the process, the steps, the overall concepts that he is using for this module are the very concepts and steps you do for any G-P-O-Z-A-U-R-R troubleshooting. But hopefully most of you will be able in your organization to use this G-P-O troubleshooting module and reporting tool and you'll find it extremely helpful. Now the gentleman who wrote this module, I cannot pronounce his name. He is in Poland. He has his own company. He has also done a like PowerShell module for Active Directory, which I hope to actually look at that module in troubleshooting Active Directory. Remember, everything is going to be in the video notes. So you don't have to worry about did I cover every element in this introduction because you can download the video notes. Everything will be in there. He has a company in Poland called Evotech. They have a lot of great information about material that they have available. Most of it is, again, downloadable. His material is very well worth checking out. Now, what do you need to get started? You need to have RStat installed on your administrative workstation. That is the remote administrative tools for Active Directory, which includes group policy, Active Directory users and computer sites and services, etc. So you need to have RStat installed. Then via PowerShell, go ahead and install his PowerShell module. Once you have done that, you're ready to go. Loaded our components. Let's go ahead and execute the single command and let's run the test. It runs a whole series of tests, gives us information about each of those tests, how long it runs, when it starts, when it ends. And then it's going to give us an HTML report. And now it's generating the report. So it doesn't take that long. Now, it depends on your enterprise, how complicated your bandwidth, all that will impact how fast this set of PowerShell scripts will run. Now, our HTML report starts with report was generated on what day and what time. And then we have a series of titles, broken group policies, broken policy, broken links, group policy owners, group policy permission consistencies. And we're going to walk through each and every one of them because this is how you're going to troubleshoot group policies. We're going to start with broken group policies and we're going to look at what causes the problem, how this shows us the problem, and then what steps we can take to start building our documentation and solving problems that this indicates to us. The way he has generated his HTML reports for each of these policy diagnostics and analysis titles. The method he uses in his HTML reports are just like you're going to see. Two top panes, one with information results on each of the tests, then a graph typically on the right pane. And then below is a series of rows and columns that you can then export out in Excel. You can copy, you can do a CSV, you can create a PDF. Very, very nice. So you can document the information that he discovered in this test. And then down below at the bottom actually is a step by step series of PowerShells. We can go look at this report again. Notice step two. If I go next, I can then use a series of PowerShell scripts to prepare a report. And if I go next, I then get ready to create backups. And it will actually have a series of PowerShell scripts that you can back up these GPOs and go next. Fix GPOs not available in the Active Directory. And so he gives you some PowerShell scripts that you can start fixing the problems that it discovered. This is quite amazing. And then continue on. Go next. And there's a series of PowerShell scripts. You can see I can highlight them here. There's another series here. And he gives you information on each of those. And you can use them as you feel comfortable. And then finally, go next. Fix GPOs of wrong object classes. And we'll get into that. And again, PowerShell scripts that will help you solve those problems. And then next, you create a verification report on how this set of fixes and PowerShell scripts. Did they fix the problem? Did they not fix the problem? Do you need to go back? All of that in this PowerShell module. Broken GPUs come about by basically understanding that GPUs are basically two bits of information. One, we have metadata stored in Active Directory in the domain partition. And then we have a series of files and folders that are placed in a GUID folder that's unique to every GPO. And they're stored in the SysVol folder that is also shared to the network with the name SysVol. So there's two SysVols here. Keep those straight. Every time we create a group policy, we have files and folders that are put on the SysVol folder. We also have metadata put in Active Directory. This data can get unsynced. So broken group policies can happen really easy when you have the Active Directory metadata out of sync with the files and folders on the SysVol location. What causes that? Well, a number of things can cause that. One, USN rollbacks in Active Directory can cause already deleted group policies to reappear. And yet the SysVol data is not there. So it shows up in the metadata, but it's not in the SysVol folder. Group policy deletion. If you are deleting group policies and they're across multiple domains, portions of it can be deleted in one domain but not in another domain. Permission issues can impact that deletion where the person who is deleting a group policy has rights in one domain but doesn't have it in the other domain. Or in the one domain, they don't have complete rights in the permission structure of both their Active Directory and their SysVol folder. And then, of course, replication failed. So now we have replication of the files and folders is not in sync with the Active Directory metadata. So all those things break GPOs. Now, before we go any further, make sure that you thoroughly validate that you're able to run these type of modules on your production network. That is a responsibility that every one of you have to make. I ran it on mine, but it's my production network. The module is not just read-only. It can delete, change, edit, etc. It's only been tested on English-based Active Directories. The author deliberately put in some safeguards. For example, as we get into fixing GPOs not available in Active Directory, as I showed you just a minute ago as we walked through the various steps. After you've done your backup, you can run these scripts. And notice they have a what-if statement. The what-if statement just allows you to run the commands and see how it results. It does not change anything. So if you want it to change things, you have to remove the parameter dash what-if. He also added a feature called dash limiting process and allows you to put a value there. Again, these are just safety mechanisms so that nothing is going to change or modify until you remove or add values to the limit processing or remove the dash what-if. So what-if parameter is just a safety mechanism. If you add it into a PowerShell command, it allows you to understand the potential impact of that command without actually executing it. So it will display a message describing what the command would do if it were to run without making any changes to your system of data. So he's added some safeguards into this module. So when we ran this module, one of the potential problems that can cause broken or orphan root policies is what they call object class. This is an attribute assigned to that metadata. If that object class attribute is incorrectly set or it's corrupted for any particular GPO, it can lead to identification issues within Active Directory. Active Directory may not recognize the object as a valid GPO leading to processing or replication problems. In the chart, if you see purple items in your broken orphan group policies, it's indicating that you have an object class attribute issue. In your health state of group policies that was in your rows and columns of data, you can see you have a column called object class. And it shows you for every GPO in your SysVol what object class is being assigned. So make sure you check that because that's where you're going to have to fix that problem to get that GPO to work again. Let's look at the remediation steps as we have run our first test. In my case, I have no errors to fix, but in your case, you may. But what are the steps to fix the problem in our first test module? We're going to prepare the environment. And you can run these PowerShell scripts. We're going to go next. You're going to prepare a report. Again, it's pretty much the same thing as we have right now. We'll come down here next. We're also going to make a backup copy. And over here, I have a folder that I actually ran that script. And it created a backup of all my GPOs. So I've got my SysVol folder saved on my administrative desktop. Then we're going to go next. And here's where we want to be more careful. So we're going to have three steps to fix things. One, fix GPOs not available on Active Directory. Then we're going to go next. And I'll go into each of these in detail. Fix GPOs not available on SysVol. And then last, go next, we're going to fix GPOs with the wrong object class. So let's go back and fix GPOs not available in Active Directory. I am deliberately slowing down so that we can understand what this HTML report is telling us, what these scripts want us to do. I want to solve a broken GPO. And here's my problem, is I have no data in Active Directory. But I have a GUID folder with stuff in it on the SysVol. This GPO will not work. So we have recognized that we don't have any data in Active Directory. But we have a SysVol folder that really is not having the corresponding data in AD. So we're going to get rid of this GPO that's in the SysVol folder. That's what this step is going to do. So we're going to be using this script right here. We're going to be using first this script. And we're going to leave the dash what if so that we can execute it and take a look and verify that, yeah, there are problems. If you're in a situation where you have a multi-domain scenario or you have limited domain admin credentials, you can then use this script here. We can come down here and use the same commands. And this time use limited processing. And this will allow us to, based on the value we put here, in this case, the value two, it's going to delete two of those GPUs and stop. And then we can go back and run it again, take a look and see what's happening. This just prevents a mass deletion. So if I didn't have that limiting process and I said, OK, execute this script, it's just going to mass delete all the GPOs in SysVol that don't have any data in Active Directory. You may not want to do that mass deletion. So here it's giving you that limitation by putting a two or a one or whatever you want in there. It's just going to do that many. And then you can run it again and again and again. Now, this did have a backup step, which really, keep in mind, if I have no data in Active Directory and I've got a good folder in my SysVol, there's no recovering of this GPO. So you don't have to do a backup in this. He has the steps in there to do a backup. But keep in mind, there's not going to be any restoration of data because you don't have anything in your Active Directory regarding that GUID folder. Nevertheless, you can see in below when we're actually removing that data, he does have, again, an effort to backup any GUID folder that you're going to delete. He'll give you an opportunity to back it up. So let's look at the next step, which is fixed GPOs not available on SysVol. What is this problem? This is where we have Active Directory data on that GPO, but we come over here to the SysVol folder and there's no good folder which has critical information for that GPO in Active Directory. So now we've got missing SysVol. We've got data in Active Directory. So we're going to take this step to fix that problem. Again, we're going to do the what if just to see. And when you are ready to go ahead and move forward, then you can come down here and you can limit how many of those you have to fix. If it's 10 of them, you can just put limiting process to instead of two to one and just run them one at a time over and over until you've cleaned up all your broken GPOs. Our last fix, and this is a rare situation where you have an object class attribute corruption or it's missing and your GPOs are not going to run. If you look at your spreadsheet of your GPOs and you look under the column of object class and you see that it's missing or it's corrupt or it's not correct, it's not going to run. So this script will run against your GPOs in the what if. And once you decide, OK, I've definitely identified those GPOs that have the object class issue, then I can run the script down here and limit to how many. Let's say I have two that are object class. I could leave the limiting processing at two or change it to one and do one at a time, check it, run it again. Then you can go check your overall health of your group policies now that you've made these changes. What do we mean by group policy broken links? This primarily happens when we improperly delete a GPO. When we properly delete a GPO, we remove the metadata out of Active Directory and the files in the sysvol folder and all of that is removed. Unfortunately, if anything still remains after that attempt to delete GPOs, you've got broken links. If the GPO is created and then linked within the same domain, you'll always get a clean deletion. But if a GPO is linked to another domain, this can leave a broken link. Also be aware the PowerShell cmdlet remove-gpo does not handle site link deletions. So that also can cause dead links to be stuck on a site until those are manually deleted. Just be aware if you're using PowerShell to delete GPOs, sometimes it can leave those broken links. I've ran the PowerShell module and I'm on the test called group policy broken links. You can see I have no broken links. So there's nothing in the graph. There's nothing indicated in the informational section of the HTML report. I have no data in the spreadsheet. And I have some steps I could take if I wanted to fix this problem. Again, I can come over here, prepare, look at that environment again. I can prepare a report if I need to. And then this step here where we actually remove broken links is where we're going to run a command to remove those broken links. We know that the PowerShell script or the module section that removes those broken links contains the dash what if. So you're not going to do anything but you can go look and see those broken links and you can see which ones are going to be removed. Now if you remove the dash what if, it's going to remove them. Then you can go ahead and remove the what if and execute the same command without the what if and it's going to remove those broken links. Be sure to run a report again to make sure that everything looks good. Let's take a look at another problem with GPOs and that is the ownership of those GPOs. By default, GPO creation is usually maintained by domain admins or enterprise admins. So as long as you keep that consistency, your ownership issue will not be a problem. So here I've run the group policy owner test for this PowerShell module. And you can see I have 13 group policies that are under the ownership of the domain admin but I have two that are under the built-in administrator account. Why? If we look at Active Directory users and computers, under users, notice there is a group called group policy creator owner. If I go look at membership, go to properties, look at who's a member, it's the local built-in administrator who's in there. So I have two policies that were created under the built-in administrator ownership. That's got to be fixed. Which two of my group policies are under the ownership of my built-in administrator? The two default ones. When I install server and I promote it to an Active Directory, I get two default group policies. One's called the default domain controllers policy and the default domain policy. And both of those default policies are under the built-in local administrator. All the rest of the GPOs I created under domain administrative rights. That's what we want all our GPOs under. So when I run my test, it looks at all the GPOs and looks at who owns them. And if there's any of the GPOs that are not owned by domain administrators or enterprise administrators, it highlights them. Now, is that going to break the world? No, but you probably should get them all under domain admin ownership. Here's my data. I can see all my group policies and I can see the two that were default that were actually created using the built-in local administrator. Again, the fix is pretty straightforward. I can run the PowerShell script that will actually go ahead and turn those ownership from the built-in to the ownership of the domain administrator. So let me go ahead and clear my screen. I'm going to remove the dash what if and it should go ahead and change that ownership. I'm going to go back and add the what if and see if all is clear and everything is fine now. If I run my report, so now that I've supposedly fixed the problem, I'm going to clear my screen, go ahead and run my report. And now you can see my graph is all green. There's no group policies that are under different ownership of different individuals. Everything is green in my data or my spreadsheet and I'm clean and ready to go. So here you actually saw me fix a problem highlighted by the diagnostic and cleaning it up with the PowerShell script. Now, we've looked at three of just 15 of the analysis that this PowerShell module runs. We've looked at how to solve some of those problems. But more importantly, this module is actually walking you through how to troubleshoot GPOs. We've looked at broken GPOs, broken links, ownership. And as we finish the rest of these, you'll have a clear idea of what I need to do to troubleshoot group policy objects. Feel free to put your comments in the comment section of this video. Your feedback is very, very important to us. If our channel helps you and it's the content that you're looking for, become a member. It's a great way to support the channel. It's $2.99 per month. Membership support is really appreciated. Coming up, Part 2, Group Policy Troubleshooting.