01.17.09
Posted in PowerShell at 5:22 pm by Administrator
I previously blogged about how Microsoft is going to deliver some PowerShell cmdlets in Windows 7 for Group Policy. Now that Windows 7 beta is out, information is starting to flow about what these will look like. A recent blog post by the GP product team at Microsoft introduces the first of these new cmdlets — New-GPO, which, as the name implies, lets you create a new GPO from scratch or from a Starter GPO. This is equivalent to our New-SDMGPO cmdlet in our GPMC cmdlets, about which there was a nice nod at the end of the Microsoft posting. I’ve started to play around with the new Win 7 GP cmdlets and will be posting some information about them as I find out more. The good news is that, as of the current beta, Microsoft is shipping some 25 cmdlets, ranging from creating and linking GPOs to modifying GPO permissions to a set of 6 cmdlets for managing registry policy and GP Preferences Registry policy. More later as I get familiar with these new cmdlets.
Tags
Group Policy, PowerShell, Windows 7
Permalink
01.09.09
Posted in PowerShell at 10:03 am by Administrator
In a previous post, I mentioned that the Group Policy Health Cmdlet was now a free download at www.sdmsoftware.com/freeware. The Health Cmdlet is a PowerShell utility for collecting Group Policy processing health against one or more remote systems. The cmdlet returns a "health object" that contains a number of properties related to the target systems’ Group Policy processing, as shown here:
What you notice is that some properties are pretty straightforward, like the domain name, hostname, loopback status, etc. However, some properties are more complicated. For example, the ComputerGPOsProcessed property is actually a collection of objects that define the GPOs processed by the computer. Those GPO objects each have their own set of properties. So, how can you quickly get to one of these property collections if you just want to know that information. Well, PowerShell provides the select-object cmdlet (aka "select") that you can use to select a property and expand it out in one step for example, if I wanted to see a list of GPOs processed by the computer on my target system called sdm2, I can simply type:
Get-SDMGPHealth -ComputerName sdm2 | select -expand ComputerGPOsProcessed |fl
which will just list out the GPOs processed by the computer, like this:
DisplayName : Local Group Policy
GPLink : Local
Version : GPT Version: 0000, GPC Version: 0000
DisplayName : Default Domain Policy
GPLink : DC=cpandl,DC=com
Version : GPT Version: 003A, GPC Version: 003A
DisplayName : Desktop Policy Manager: Marketing User Lockdown – {C0D4FBAE-3952-
4A3E-89BF-90AC4AFC3FFF}
GPLink : DC=cpandl,DC=com
Version : GPT Version: FFFF, GPC Version: 0000
DisplayName : Desktop Policy Manager: Sales Users Lockdown – {C30783C6-A0D9-4B9
C-B2A3-A21FA0BADC5E}
GPLink : DC=cpandl,DC=com
Version : GPT Version: FFFF, GPC Version: 0000
DisplayName : Desktop Policy Manager: Engineering Department Lockdown – {1D9875
10-9ADB-4102-BFAC-B3027518D0F6}
GPLink : DC=cpandl,DC=com
Version : GPT Version: FFFF, GPC Version: 0000
DisplayName : Restricted Groups AD test
GPLink : OU=Domain Controllers,DC=cpandl,DC=com
Version : GPT Version: FFFF, GPC Version: 0005
DisplayName : Default Domain Controllers Policy
GPLink : OU=Domain Controllers,DC=cpandl,DC=com
Version : GPT Version: 004E, GPC Version: 004E
The other main property collections on the Health object are the ComputerCSEsProcessed and UserCSEsProcessed. These objects are a bit more complicated because they actually contain a collection of collections. Namely, these properties list each Client Side Extension that ran for the computer or user, and then within each of those, it lists the GPOs that were called by that CSE. Each of those GPO objects contains properties that include the GPO name, the last time the CSE ran for that GPO and where the GPO was linked.
So, let’s say we want to find out all the GPOs that processed security policy for the computer. That can be done in a single PowerShell command by using the following syntax:
Get-SDMGPHealth -ComputerName sdm2 | select -expand ComputerCSEsProcessed |
where {$_.ExtensionName -contains "Security"} | select -expand GPObyCSE |fl
When I issue this command, I get the following output:
DisplayName : Default Domain Policy
GPLink : LDAP://DC=cpandl,DC=com
LastProcessingTime : 1/9/2009 2:31:00 PM
CseStatus : The operation completed successfully
DisplayName : Default Domain Controllers Policy
GPLink : LDAP://OU=Domain Controllers,DC=cpandl,DC=com
LastProcessingTime : 1/9/2009 2:31:00 PM
CseStatus : The operation completed successfully
Which tells me that the Security CSE ran two GPOs and that they both ran successfully at the times given above. If they had not run successfully, the actual error message returned by the CSE would be shown here.
Hope this helps folks get more value out of the cmdlet (and thanks to PowerShell MVP Brandon Shell for helping me work through the syntax!)
Darren
Tags
PowerShell, Group Policy, Group Policy Health, SDM Software
Permalink
01.06.09
Posted in General Stuff at 10:09 am by Administrator
Someone today on our GPTalk Group Policy Mailing List asked a simple question for which there is a fairly long, complicated answer, "Could you please explain Group Policy Loopback Processing ? I’m finding this very difficult to understand"
One would think that this question should be easy to answer, but in fact, loopback processing confounds a lot of folks. I took some time to try and answer the question using examples, and so I figured it was worth re-posting here. Hopefully this helps others understand this powerful, yet often confusing feature of Group Policy:
Its a complex topic for many (including me!) so I will try to attack it from a solution perspective. Essentially loopback is designed to help answer the following challenge, “How do I control user policy on a particular computer or set of computers such that, no matter who logs onto those computers, they always get the same user policy?”. As you know, GP is processed by computers and users and the policy that a computer or user gets is determined by where the computer and user account resides in AD, where the GPO is linked, and whether its filtered or not. Loopback is a special mode of GP processing that you set on a per-computer basis. When a computer has loopback enabled, any user that logs onto that computer can be given a set of per-user policies that is different than the ones they would normally receive by virtue of where their user account is. The simplest example is a Terminal Server environment. A common configuration is to create an OU called “Terminal Servers”. In that OU, you place computer accounts that are your Terminal Server machines. Now, linked to that OU, you create a GPO called “TS Loopback Policy”. In that GPO, you enable loopback under Computer Configuration\Administrative Templates\System\Group Policy\User Group Policy Loopback Processing Mode. When you enable the policy, you have two options—merge or replace. Merge says, “first apply the user’s normal user policies (as if they were logging into their normal workstation) then apply the loopback user settings”. Replace says, “Just apply the loopback user settings”. I generally tell people to choose “replace” mode unless you have a specific requirement for merging.
So, now that loopback is enabled, on that same TS GPO (assuming the simplest case) under User Configuration, you can set all of the loopback user settings that you want to apply to users logging into these TS boxes. When the user logs on, these user settings are applied instead of their “home” ones.
Hope that helps!
Darren
Tags:
Group Policy, Loopback Processing, GPTalk
Permalink
01.02.09
Posted in General Stuff at 11:20 am by Administrator
Well, I received the always welcome email yesterday indicating that my Group Policy MVP status has been renewed. Its an honor to receive this status, though I have to admit that it was touch and go as yesterday dragged on with no notification, until I realized that the renewal email was trapped in my spam folder! One day spam filters will really work, and I look forward to that with much anticipation.
In any case, it is definitely a wecome piece of news that recognizes contributions we make to the community. The best perk for me is the annual MVP Summit– this year happening in early March. Its at the Summit where we get to spend quality time with the Group Policy product group, hearing about what is in store for the new releases and providing input into future versions of Group Policy. If you have ideas or feedback about what things you’d like to see improved or fixed in GP, feel free to comment on this blog or contact me through either SDM Software or GPOGUY.COM, and I will make sure I feed those into the product group meetings.
And before I forget, Happy New Year to everyone. 2008 was challenging on many levels and so I’m hopeful that 2009 will to be not as "interesting" as some are predicting, or at least, that we have seen the worst and that we are on the uphill slope!
Tags:
Group Policy, Microsoft MVP, SDM Software, GPOGUY
Permalink
