Normally when you think of Windows Registry, you’re normally worried about the two sections: HKEY_LOCAL_MACHINE (HKLM) and HKEY_CURRENT_USER (HKCU). It’s fairly obvious that settings under each area apply to either the PC itself (machine) or just to the currently logged in user. This is usually fine, but there are scenarios where there’s a setting that will only apply to a machine due to how the program is written, but you actually want to turn it on or off based on the logged on user. With Group Policy Preferences (GPP) which was introduced with Windows Server 2008, this is much easier to do. Before this, you would have need to have written complex logon scripts using 3rd party tools to perform lookup commands, create variables and then adjust the registry accordingly, while providing administrator credentials. GPP lets you apply registry settings rather easily. One of the main benefits of GPP is how flexible and granular you can be with the settings you apply. This is how I would normally use to deploy a setting, but have it easily managable: Have two settings for the registry, one setting it on and the other off (normally done by a 1 for on, 0 for off but it depends on the setting). The targeting for having the setting on or off is based by user membership to an Active Directory (AD) group, but the setting is not applied in the user context meaning it’s applied by ‘System’ which will have full access to the HKLM registry. This will then mean the HKLM setting changes from 0 to 1 and back based on which user logs in! I prefer this than just applying particular users individually to the item because it will reduce processing time having a single check...

It’s a common question asked of IT – “Can you give me a list of who’s in Marketing?” or “How many accounts do we actually have?” Before PowerShell, this was a lot harder to do. There were companies like Quest Software who provided several handy tools (and still do) , or long complicated visual basic scripts. So, how do you get a list of users? All of this is being done from the Active Directory Module for Windows PowerShell which will install as part of the Windows Server 2012 Feature – Role Administration Tools > AD DS and AD LDS Tools > Active Directory Module for Windows PowerShell. The ‘Get-ADUser’ command is what we’ll use to demonstrate what you can do. For starters, ‘Get-ADUser -filter*’ will get you a list of all users, and they’ll output in this format one after the other: A lot of information. You can specify a single user with: Get-ADUser -identity username which will just show you the one result. As you may be aware, there are a lot more fields a user has than just the ones shown. You can tell PowerShell to show you all the properties by modifying the command like this: Get-ADUser -identity username -properties * Note that in PowerShell v4 if you get the error “get-aduser : One or more properties are invalid.” then there may be an issue with your schema. Check out this post for more information. If there’s just one extra property you need, there’s no point getting everything, so if you needed to see a field such as “Department” for all users then adjust the command like this: Get-ADUser -filter * -properties Department Now, this gives the results for every single user in your Active Directory environment. You can narrow this down to a particular...