<feed xmlns="http://www.w3.org/2005/Atom"><title>gpo</title><id>https://evotec.xyz/es/tags/gpo/index.atom.xml</id><updated>2021-01-24T17:15:04.0000000Z</updated><subtitle>Evotec Main Website</subtitle><link href="https://evotec.xyz/es/tags/gpo" /><link href="https://evotec.xyz/es/tags/gpo/index.atom.xml" rel="self" type="application/atom+xml" /><entry><title>The only command you will ever need to understand and fix your Group Policies (GPO)</title><id>https://evotec.xyz/es/blog/the-only-command-you-will-ever-need-to-understand-and-fix-your-group-policies-gpo</id><link href="https://evotec.xyz/es/blog/the-only-command-you-will-ever-need-to-understand-and-fix-your-group-policies-gpo" /><updated>2021-01-24T17:15:04.0000000Z</updated><summary>I’ve been working on cleaning up Group Policies for a couple of months. While it may seem trivial, things get complicated when you’re tasked with managing 5000 GPOs created over 15 years by multiple teams without any best practices in mind. While working on GPOZaurr (my new PowerShell module), I’ve noticed that the more code I wrote to manage those GPOs, the more I knew passing this knowledge to admins who will be executing this on a weekly/monthly basis is going to be a challenge. That’s why I’ve decided to follow a similar approach as my other Active Directory testing module called Testimo. I’ve created a single command that analyses Group Policies using different methods and shows views from different angles to deliver the full picture. On top of that, it provides a solution (or it tries to) so that it’s fairly easy to fix – as long as you agree with what it proposes.</summary><category term="active directory" /><category term="gpo" /><category term="group policy" /><category term="powershell" /></entry><entry><title>Using Win32_UserAccount WMI filter in PowerShell/Group Policies and what to avoid</title><id>https://evotec.xyz/es/blog/using-win32_useraccount-wmi-filter-in-powershell-group-policies-and-what-to-avoid</id><link href="https://evotec.xyz/es/blog/using-win32_useraccount-wmi-filter-in-powershell-group-policies-and-what-to-avoid" /><updated>2020-06-02T15:45:54.0000000Z</updated><summary>Some months ago, I created PowerShell Script to create local administrative users on workstations – Create a local user or administrator account in Windows using PowerShell. It’s a bit overcomplicated, but the goal was it should work for Windows 7 and up, and that means supporting PowerShell 2.0. As part of that exercise, I’ve been using Win32_UserAccount WMI based query to find local users and manage them to an extent. While Get-LocalUser exists, it’s not suitable for the PowerShell 2.0 scenario. I also use the same query in GPO for WMI filtering. You can say it’s been a good friend of mine.</summary><category term="active directory" /><category term="ad" /><category term="gpo" /><category term="powershell" /><category term="wmi" /></entry><entry><title>Active Directory DFS Health Check with PowerShell</title><id>https://evotec.xyz/es/blog/active-directory-dfs-health-check-with-powershell</id><link href="https://evotec.xyz/es/blog/active-directory-dfs-health-check-with-powershell" /><updated>2020-02-20T20:29:20.0000000Z</updated><summary>One of the critical parts of Active Directory is DFS. It allows you to share same NETLOGON/SYSVOL folders across all Domain Controllers in your Forest. Its health is vital to the functionality of your Active Directory. If it’s broken, a lot of things may not work, and it’s not that easy to tell the status of it. At first sight, everything may seem to work correctly, but if you take a closer look – not so much. It’s great if you find it out by yourself, but not fun if suddenly GPO’s don’t apply to some users, computers, and you find out a year later.</summary><category term="active directory" /><category term="adessentials" /><category term="dfs" /><category term="gpo" /><category term="PowerShell" /><category term="testimo" /></entry><entry><title>Finding GPOs missing permissions that may prevent GPOs from working correctly</title><id>https://evotec.xyz/es/blog/finding-gpos-missing-permissions-that-may-prevent-gpos-from-working-correctly</id><link href="https://evotec.xyz/es/blog/finding-gpos-missing-permissions-that-may-prevent-gpos-from-working-correctly" /><updated>2020-02-19T21:08:35.0000000Z</updated><summary>I’ve been in IT for a longer time now. I’ve made my fair share of mistakes and misconfigurations. One of those misconfigurations was removing Authenticated Users from Security filtering in Group Policy Objects. While it worked fine at some point Microsoft rolled out a Hotfix MS16-07 on June 14th 2016.</summary><category term="active directory" /><category term="adessentials" /><category term="gpo" /><category term="powershell" /></entry><entry><title>Create a local user or administrator account in Windows using PowerShell</title><id>https://evotec.xyz/es/blog/create-a-local-user-or-administrator-account-in-windows-using-powershell</id><link href="https://evotec.xyz/es/blog/create-a-local-user-or-administrator-account-in-windows-using-powershell" /><updated>2019-10-30T13:44:27.0000000Z</updated><summary>Recently I got a simple task to implement LAPS for the newly created local user instead of using the built-in local administrator account. It seemed easy at first. Go to Group Policies, create a new user, add it to an administrators group, and then follow standard steps to implement LAPS. That is until you find out it’s actually not possible anymore due to password encryption key being available in the wild, which made Microsoft block that Group Policy Preference. While that road is blocked, I still need to get my user-created somehow. Let’s do it with PowerShell. It’s quite simple – use New-LocalUser a few parameters, some random password that I don’t need to save as LAPS will overwrite it. Except it’s not available on PowerShell 2.0, which is the default for Windows 7 that I have to support. Things get even more complicated if you consider that Administrators group is called differently in different countries. While I stopped supporting anything below PowerShell 5.1, I can’t say if it’s the project requirement.</summary><category term="administrator" /><category term="gpo" /><category term="powershell" /><category term="Windows" /></entry><entry><title>Prepare Windows 10 Start Menu for all computers in Active Directory</title><id>https://evotec.xyz/es/blog/prepare-windows-10-start-menu-computers-active-directory</id><link href="https://evotec.xyz/es/blog/prepare-windows-10-start-menu-computers-active-directory" /><updated>2018-01-26T14:08:44.0000000Z</updated><summary>Windows 10 in my humble opinion is very good system. It has it’s pros and cons but so does each…</summary><category term="1703" /><category term="1709" /><category term="Active Directory" /><category term="gpo" /><category term="gpresult" /><category term="gpupdate" /><category term="group policy" /><category term="powershell" /><category term="powershell editor" /><category term="powershell ise" /><category term="start menu" /><category term="Windows" /><category term="windows 10" /><category term="windows 10 1703" /><category term="windows 10 1709" /></entry></feed>