The GPOGUY-- Group Policy Blog

Well, we've released a new version of our GPMC PowerShell cmdlets--version 1.2. This new version represents a significant updgrade to the existing cmdlets. The biggest change is that we incorporated new functionality that became available in the version of GPMC that shipped with Vista, SP1 and Windows Server 2008. As a result of those significant GPMC changes, we had to break the cmdlets into two separate download packages--one package for Vista, SP1 and Server 2008 users and the other for earlier platforms. In general, the main differences between the two downloads is that the package for Vista, SP1 and 2008 supports some features like managing "Starter GPOs" and some other new capabilities that the older version of GPMC does not support. But both packages have added some cool new features, such as better pipelining support between cmdlets and support for creating GP Settings and RSOP reports. The pipelining support is especially interesting for those of you out there looking to fully automate your GP Management tasks. In earlier versions of the cmdlets, whenever you got a reference to a GPO or created a new GPO, you could not easily pipe the output of that to another cmdlet. The reason for this is that the objects that the cmdlets emitted were COM Interop types that did not appear as useful objects to the PowerShell pipeline. As a result, we have modified the default output of many of these Get- cmdlets to emit custom objects that are more easily piped to other cmdlets. For example, now you can create a GPO and link it in one fell swoop, like this:

new-sdmGPO "Marketing Stuff" | add-sdmgplink -Scope "OU=Marketing,DC=Cpandl,DC=com" -Location -1

If you do still need access to the COM interop types, then there is now a -Native parameter on cmdlets that emit these custom objects so that you can revert to the old 1.1 behavior if needed.

The following are the rest of the release notes on the new 1.2 version. Check them out and let us know what you think!

*******************************************************************

Release Notes for SDM Software's GPMC PowerShell Cmdlets, v1.2

July 2, 2008
-------------
#Added -Native parameter to a number of the get- cmdlets, including get-SDMGPO. In version 1.1, these cmdlets emitted native GPMC COM Interop types, which could not be sent to the pipeline successfully. As a result, all of the cmdlets in this release that support the -Native parameter now, by default, emit custom object types to work better with the pipeline. If you need the native GPMC object types, then use the -Native parameter.

#Add 9 new Cmdlets, including:

Add-WMIFilterLink: Links an existing WMI filter to a GPO
Copy-SDMStarterGPO: Copies an existing Starter GPO to a new Starter GPO (Server 2008 and Vista, Sp1 only)
Get-SDMStarterGPO: Retrieves a reference to and information on a named Starter GPO (Server 2008 and Vista, Sp1 only)

Get-SDMWMIFilter: Retrieves a reference to and information on one or all WMI Filters in a domain
New-SDMStarterGPO: Creates a new Starter GPO (Server 2008 and Vista, Sp1 only)
Out-SDMGPSettingsReport: Creates an xML or HTML GPO Settings report
Out-SDMRSOPLoggingReport: Creates and XML or HTML Group Policy Results report
Remove-SDMStarterGPO: Deletes a Starter GPO (Server 2008 and Vista, Sp1 only)
Remove-SDMWMIFilterLink: Removes any WMI Filter linked to a particular GPO

#Added a Name parameter to Get-SDMGPLink. This new parameter lets you search for links by GPO name in addition to SOM. So, you can provide a GPO name and get a list of all the places its linked.

#Added a GPOID parameter to Get-SDMGPO. This new parameter lets you search for a GPO by GUID instead of by name. With this new parameter, you can use this cmdlet to effectively translate from GUID to Name and Name to GUID.

***********************************************************************

Tags:

Group Policy, PowerShell, GPMC, SDM Software

Posted by gpoguy at 02:37 PM | Permalink | Comments (0) | TrackBacks (0)

Well, despite the morbid title, this is not about dead things. Well, not quite.  And amazingly its not about Group Policy either. 

In my ever increasing thirst for PowerShell knowledge, I thought I would experiment a bit with some Active Directory-based cmdlets this time. The result is two free PowerShell Cmdlets that retrieve and reanimate AD Tombstones (for an excellent backgrounder article on Tombstone Reanimation, check out Gil Kirkpatrick's piece in TechNet Magazine from last September).

You can optionally register for and download these new AD tombstone cmdlets at www.sdmsoftware.com/freeware. Once you download and install the setup, and launch the console file that comes with it, you'll have two new cmdlets at your disposal*:

get-SDMADTombstone

restore-SDMADTombstone

The first cmdlet, most obviously retrieves a listing of all deleted objects in a given domain. You can filter the results using the -Filter parameter to search for a given text string within the DN of the deleted object. The 2nd cmdlet, which does the actual restoral work, is meant to be used with the first one. So, for example, if I have a user "Dick Evans" who was deleted, and I want to restore him, I can issue the following command:

get-SDMADTombstone -Filter Evans | restore-SDMADTombstone

The restore- cmdlet also implements the -whatif parameter, so that you can see what objects will be restored prior to pulling the trigger.

So, I encourage everyone to download and check it out and provide feedback. I look forward to hearing your input.

Have fun!

Tags:

Active Directory, PowerShell, Tombstone Reanimation

* Note: This blog post was edited after the initial posting. Thanks to feedback from Dmitry, I renamed the cmdlets to be singular, in keeping with PowerShell convention, and also changed the output format of the date fields. Otherwise, everything is the same!

Posted by gpoguy at 01:27 PM | Permalink | Comments (2) | TrackBacks (0)

German version:

http://download.microsoft.com/download/4/7/1/47104ec6-410d-4492-890b-2a34900c9df2/Workshops-DE.zip

English version:

Posted by gpoguy at 08:38 AM | Permalink | Comments (0) | TrackBacks (0)

Well, we've updated our free SDM Software GPMC PowerShell cmdlets (registration optional)! We are now up to 16 cmdlets! Cool. Here's what we've added:

• Added the –DomainName parameter to all cmdlets as appropriate to allow you to perform operations against domains other than the one the cmdlets run in
• Added  4 new cmdlets, including:

• Import-SDMgpo: provides support for the GPMC Import function that allows you to import a GPMC backup into a GPO. This is often used for migration of GPOs from test to production domains/forests.
• Get-SDMSOMSecurity: provides a list of GP-related permissions on a given SOM (Scope of Management, i.e. site, domain or OU)
• Add-SDMSOMSecurity: lets you add GP-related permissions (e.g. create GPO, link GPO, RSOP logging and planning) to a given SOM
• Remove-SDMSOMSecurity: lets you remove GP-related permissions from a given SOM

If you installed the 1.0 version, just uninstall that and install this new setup.  Note that the snap-in name has changed to SDMSoftware.PowerShell.GPMC.  

To get a full list of the GPMC cmdlets, type this at a PowerShell command prompt:

get-command *sdm* -type cmdlet

All the cmdlets also include help, so just use get-help <cmdlet name> to find out the correct syntax.

Check it out and let me know what you think.

Tags:

PowerShell, Group Policy, SDM Software, GPMC 

Posted by gpoguy at 01:58 PM | Permalink | Comments (0) | TrackBacks (0)

Well, if you've read my blog at all, you know that there are two technology areas that are especially interesting to me--Group Policy and PowerShell. Once again, I've brought the two together in the form of a new freeware cmdlet for triggering remote Group Policy refreshes. This is an update of the GPOGUY.COM rgprefresh utility that is by far the most popular download on that site. I figured it was time to PowerShell enable this sucker and so that's what I've done.

This new cmdlet, called Update-SDMgp, basically lets you specify a remote hostname to trigger a GP Refresh against, and provides the same options that RGPRefresh did for letting you specify the type of refresh and alternate credentials.

You can download the free setup (registration optional) at www.sdmsoftware.com/freeware.php.

Check it out and let me know what you think. For more information on the syntax of this new cmdlet, just type:

get-help update-sdmgp after installing the cmdlet and launching the snap-in from the installed shortcut!

Tags:

PowerShell, Group Policy, GPOGUY, SDM Software

Posted by gpoguy at 03:13 PM | Permalink | Comments (0) | TrackBacks (1)

This is the 2nd in an irregular series of discussions about using SDM Software PowerShell cmdlets for managing Group Policy. In this post, I've written a fairly simple PowerShell script that uses two of our free GPMC cmdlets to first backup a GPO, and then launch the GP Editor on that GPO. This can be a useful way to edit GPOs because it guarantees that before you make any changes to that GPO, that you have a backup copy. This script uses two of our GPMC cmdlets--namely export-sdmgpo and get-sdmgpo. The Export cmdlet backs up the gpo that you specify and then get-sdmgpo grabs the GUID for that GPO, which needs to be passed to gpedit.msc command in order to launch the GP Editor. Well, let's look at the script now. I named the script backupAndEdit.ps1 (I know, very original). When I call the script from PowerShell, I pass it 3 parameters, like this:

PS> .\backupandedit.ps1 "ADM Test" "\\sdm1\gpbackups" "Backup and Edit Test"

The first param is the name of the GPO, in this case, its called "ADM Test". The 2nd parameter is the path to my GPO backups. The 3rd param is a comment that is associated with the backup. Obviously you could get more creative here! Now here's the script:

***** 

param($GPOName,$backupLocation,$comment)
write-host "Backing up GPO: $GPOName"
trap {
'Backup Failed!'
$_
exit
}
export-sdmGPO $GPOName -Location $backupLocation -Description $comment -ea 1
write-host "Backup Completed"
write-host "Launching GP Editor"
$GPO= get-sdmGPO $GPOName
$extcmd = " /gpobject:`"LDAP://CN=" + $GPO.ID + ",CN=Policies,CN=System,DC=cpandl,DC=com`""
gpedit.msc $extcmd

*******

This script is pretty simple. I declare my parameter names at the beginning of the script. Then I set up a trap to catch for any errors during backup--I don't want to edit the GPO if the backup fails. Then I call export-SDMgpo using the params I passed in. Then assuming the backup completes and the script continues, I use get-sdmgpo to get a reference to the GPO, because from that object I can get the GPO's GUID (the ID property). Then I assign the full command I want to, including the DN of the GPO, to $extcmd. Finally, I call the external MMC tool gpedit.msc and pass it that arguments in $extcmd. Now, you'll notice that my domain name is hard-coded into the path here. I could just as easily have passed this in as a parameter as well, or used some AD code to grab my current DN. Just know that if you use this script, you'll need to modify the command for your own domain name.
Enjoy!

Tags:

Group Policy, PowerShell, GPMC

Posted by gpoguy at 12:35 PM | Permalink | Comments (0) | TrackBacks (0)

Well, I suppose I couldn't help myself. I had planned on updating our cmdlets released last week to correct an omission that Richard Siddaway had kindly pointed out, namely that I didn't have a remove-sdmgplink to go along with add-sdmgplink. So I went ahead and corrected that. I also committed a small sin by renaming one of the cmdlets, but I swear I had to. Microsoft's current naming standards for common verbs have a few gaps, as far as I'm concerned. Namely, they have a verb called export, which is supposed to encompass backups. Well, they also have a verb called import, which is the pair to export, of course. Problem is, GPMC considers imports as distinctly different from a restore of a backup. So, my use of import-sdmgpo as a way of restoring a backup would become problematic down the line, when I add support for true GPMC imports. So I opted for changing import-sdmgpo to restore-sdmgpo. Restore is supposed to be paired with "Checkpoint" but that didn't make a whole lot of sense in my case, so I chose to ignore that .

And of course, along the way I found at least 3 other cmdlets that I could add, so I did. At this point its probably worthwhile to summarize what is currently in the Snap-in. We now have 12 cmdlets, as follows:

Add-SDMgplink: Links a GPO to a particular AD container (site,domain or OU)
*Get-SDMgplink: Retrieves a list of linked GPOs from a particular AD container
*Remove-SDMgplink: Removes a GPO link from a given AD container
Export-SDMgpo: Backs up a GPO to a given folder path
Get-SDMgpo: Retrieves information about one or all GPOs in a domain
New-SDMgpo: Creates a new GPO in a domain
Remove-SDMgpo: Deletes an existing GPO from a domain
Restore-SDMgpo: Restores a GPO from backup
*Get-SDMgpoBackups: Retrieves the list of all backed-up GPOs (or a given GPO) from a given folder path
Add-SDMgpoSecurity: Adds a GP permission (ACE) for a given group to a given GPO
Get-SDMgpoSecurity: Retrieves a list of GP permissions from a given GPO
Remove-SDMgpoSecurity: Removes a particular permission for a given group from a given GPO.

* new cmdlet for this release

 Ok, so if you've already installed the first version of this, go ahead and remove that from Add/Remove Programs and reinstall the new version that's out on www.sdmsoftware.com/freeware.php . Everything should be the same except what I've noted above.

 Thanks and as always, feedback is good. Email Support (at) sdmsoftware (dot)  com if you have questions or issues.

Tags:

PowerShell, Group Policy, GPMC

Posted by gpoguy at 11:31 AM | Permalink | Comments (0) | TrackBacks (0)

Well, many of you know that we released the GPExpert Scripting Toolkit for PowerShell back at the end of July. The Toolkit lets you modify the settings within Group Policy objects using PowerShell. I also had a couple of cmdlets out on my GPOGUY.COM site that wrapped up some GPMC functionality for creating new GPOs and getting information on existing ones. More recently, I decided to flesh out that GPMC functionality even more, and I'm happy to announce that I just posted a new PowerShell snap-in for GPMC last night on our Freeware Page. The new snap-in contains 9 cmdlets, as follows:

Add-SDMgplink
Add-SDMgpoSecurity
Export-SDMgpo
Get-SDMgpo
Get-SDMgpoSecurity
Import-SDMgpo
New-SDMgpo
Remove-SDMgpo
Remove-SDMgpoSecurity

These new cmdlets let you use PowerShell to easily get at GPMC functionality such as linking GPOs to AD containers, modifying and retrieving security permissions on GPOs, backing up and restoring GPOs and creating and deleting GPOs. Give them a spin and let me know what you think!

Tags

Group Policy, PowerShell, GPMC, SDM Software

Posted by gpoguy at 09:56 AM | Permalink | Comments (0) | TrackBacks (0)

This is the first in a series of blogs postings I plan to do showing how you can use Microsoft's very cool PowerShell scripting environment and SDM Software's GPExpert Scripting Toolkit for PowerShell, to manage Group Policy settings. One of the strengths of the Scripting Toolkit is the ability to modify the settings within a local or domain GPO. But another great thing that the Toolkit can do is read settings out of GPOs. In the scenario I'm showing today, I want to feed my script a list of GPO names, and then for each GPO, I want to check whether or not a particular Admin. Template setting is enabled. If it is, then I want to report that out. I could also just as easily use this script to modify the setting if it wasn't what I wanted. I could also use the Toolkit to check other settings, like security settings. One scenario that comes to mind is a script that ensures that Password policy is set the same across all of my domains (assuming I have multiple domains), but that's an example for another day.

So, let's look at the full script and then I'll break it down:

$gpos = import-csv gpos.txt
foreach ($mygpo in $gpos)
{
  $path = "gpo://cpandl.com/" + $mygpo.Name
  $gpo = Get-SDMgpobject -gpoName $path -openbyname $true;
  $container = $gpo.getObject("Computer Configuration/Administrative Templates/System/Logon");
  $settingName = "Always wait for the network at computer startup and logon";
  $setting = $container.Settings.ItemByName($settingName);

  if ($setting.Get("State") -eq -1)
  {
    $mygpo.Name + " does not have setting configured";
  }
  else
  {
    $mygpo.Name + " has setting set to state of: " + $setting.Get("State");
  }
}

The first line simply uses the import-csv cmdlet that is provided within PSH to grab GPOs names out of a text file called gpos.txt. That file as a list of GPO names--one on each line, with a header line called Name, as follows;

Name
"My GPO"
"Wireless Test"

 I could also have included a column for domain name if I wanted to get at GPOs in multiple domains.

The foreach is going to loop through my list of GPOs so that I can read the setting I'm interested in out of each GPO. The real action starts with this line:

$gpo = Get-SDMgpobject -gpoName $path -openbyname $true;

The cmdlet get-sdmgpobject is part of the Scripting Toolkit, and lets us get a reference to a local or AD-based GPO. In this case, I'm referencing the GPO passed from the text file. Next, I want to "connect" to the path within the GPO whose setting I want to query. I do that with these 3 lines:

 $container = $gpo.getObject("Computer Configuration/Administrative Templates/System/Logon");
  $settingName = "Always wait for the network at computer startup and logon";
  $setting = $container.Settings.ItemByName($settingName);

These three lines essentially connect to the Admin. Template path of interest, and then get the particular policy setting (in this case its "Always wait for the network...")  I want to query.

Then its a simple matter of finding the state of that setting using this command:

$setting.Get("State")

Based on the value of that state, I return information about whether its Not Configured, Enabled or Disabled. Of course, if this was a policy that was more complex--i.e. it had values other than these three simple ones, I could also get those values from the script.

This is just a small example of how the Toolkit can read, as well as write values from your GPOs! Next time I'll blog on a scenario for setting policies where the Toolkit really shines.
 

Tags:

Powershell, Group Policy, GPExpert Scripting Toolkit

Posted by gpoguy at 09:18 AM | Permalink | Comments (0) | TrackBacks (0)

Jeff Hicks, scripting-guy extraordinaire at scripting solutions vendor Sapien, wrote a nice article on the Redmond Magazine website about scripting Group Policy with PowerShell. He specifically talks about our free GPOGUY PowerShell cmdlets and how you can use them to perform basic GP administratiion tasks, and then goes on to mention the GPExpert Scripting Toolkit for using PowerShell to make actual changes to Group Policy settings. Cool article! Thanks Jeff.

 Tags:

 Group Policy, PowerShell, Sapien, GPExpert Scripting Toolkit, GPOGUY

Posted by gpoguy at 04:12 PM | Permalink | Comments (0) | TrackBacks (0)

Just a quick note to let folks know that I'm going to be giving a webinar on our GPExpert™ Scripting Toolkit for PowerShell product next Wednesday, October 10th, at 8:30am Pacific Time. In this webinar, I'll go over how you can use the Scripting Toolkit and Microsoft's PowerShell scripting environment to manage the settings within a Group Policy object, such as Administrative Templates, Software Installation, Security policy, etc. I hope you can join me for this. To attend just register at: https://sdmsoftware.webex.com/sdmsoftware/j.php?ED=100098272&RG=1

 Tags:

Group Policy, Powershell, GPExpert Scripting Toolkit, SDM Software

Posted by gpoguy at 04:04 PM | Permalink | Comments (2) | TrackBacks (0)

Just a quick note that if you want to see the GPExpert Scripting Toolkit (GPST) in action, cruise on over to Adam Bell's blog. Adam's been evaluating the Toolkit and has posted some sample PowerShell commands showing how you can use the GPST to modify policy settings.

Group Policy, PowerShell Tools, GPExpert Scripting Toolkit

Posted by gpoguy at 07:32 AM | Permalink | Comments (0) | TrackBacks (0)

Well, today we announced the release of v.1 of the GPExpert Scripting Toolkit for PowerShell. As I mentioned in an earlier post, this is the culmination of something I've talked about doing for a long time--programmatic access into Group Policy settings. With the release of the Toolkit, we can now provide that for everyone...and via the new PowerShell scripting environment from Microsoft! The early feedback I've received from beta testers is that this is a great thing that willl empower them to automate GP management processes that before now were difficult to impossible to automate. If you are interested in evaluating the GPExpert Scripting Toolkit, check out our Products page for more info!

Technorati Tags

PowerShell, Group Policy, GPExpert Scripting Toolkit, SDM Software

Posted by gpoguy at 08:57 AM | Permalink | Comments (0) | TrackBacks (0)

Well, I've created a new PowerShell cmdlet to go along with my get-SDMgpo cmdlet. Its called new-SDMgpo, and its purpose in life is to let you use PowerShell to create new GPOs. As with the previous cmdlet I created, it requires GPMC to be installed where it runs since it leverages the GPMC APIs. You can get more info and download it from the Powershell page at our GPOGUY.COM site.

Technorati Tags

PowerShell,Group Policy,GPOGUY

Posted by gpoguy at 09:59 AM | Permalink | Comments (0) | TrackBacks (0)

Well, I just blogged about a little GP PowerShell cmdlet that I wrote recently to retrieve GPO information. I also mentioned that I created a Quest PowerGUI snap-in for it. Well it turns out Quest has a weekly drawing for the best cmdlet and I just won $200 for my little cmdlet. Cool! Check it out here: http://dmitrysotnikov.wordpress.com/2007/04/03/200-for-gpo-management/

 Anyway, a nice little perk

Posted by gpoguy at 04:03 PM | Permalink | Comments (0) | TrackBacks (0)

Well, I took a crack at writing a PowerShell cmdlet and of course started with a Group Policy related one. Its called get-SDMgpo and basically lets you list out one or all GPOs in an AD domain, along with some properties related to them--like GUID, DN, version and of course, Friendly Name. You can download the cmdlet from http://www.gpoguy.com/tools.htm.

Since I'm also playing around with the Quest Software PowerGUI tool, I went ahead and posted a PowerGUI snap-in for my cmdlet up on the PowerGUI site. Check it out!

Posted by gpoguy at 08:27 AM | Permalink | Comments (0) | TrackBacks (0)