<feed xmlns="http://www.w3.org/2005/Atom"><title>wmi</title><id>https://evotec.xyz/es/tags/wmi/index.atom.xml</id><updated>2020-06-02T15:45:54.0000000Z</updated><subtitle>Evotec Main Website</subtitle><link href="https://evotec.xyz/es/tags/wmi" /><link href="https://evotec.xyz/es/tags/wmi/index.atom.xml" rel="self" type="application/atom+xml" /><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></feed>