Just a quick shout-out to let folks know that I posted an update to our SDM Software GPMC Cmdlets on our freeware page. This is version 1.3 and primarily just fixes some bugs including an issue when you tried to get, add or remove site-based GPO links. Enjoy!
Tags:
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
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
I had a question come up today about a use case for our GPMC cmdlets and figured it was worth sharing for other's benefit. Here's the scenario. I have a GPO who's name I know. I want to find all the places that its linked and then I want disable all the links for that GPO. And I want to use PowerShell to do it because, well, I can!
So here we go. The first thing we need to do is search for all the links for a given GPO, using the get-sdmgplink cmdlet like this:
$scopes = get-sdmgplink -Name "My GPO"
In this example, I'm using the ability of this cmdlet to search for links by GPO name (using the -Name parameter). Once I've got the list of my scopes, I want to feed that into a set of commands to disable the links, like this:
$scopes = get-sdmgplink -Name "My GPO"
$gpo = get-SDMGPO "My GPO"
foreach ($scope in $scopes)
{
$links = get-sdmgplink -Scope $scope.Path -native
foreach ($link in $links)
{
if ($link.GPOID -eq $gpo.ID){$link.enabled = $false}
}
}
So, what I'm doing here is first getting the list of DNs that contain a link to the GPO called "My GPO". Then I call the get-sdmgpo cmdlet to get the GUID of the GPO to use later. Then I foreach through each scope I returned in the first call, and pass that to a call to get-sdmgplink again. Except this time, I am using the -Scope parameter to search by DN (returned as the Path property on the $scope variable). Once I get the list of links on that scope, I next foreach through them to find the one that corresponds to my GPO (by checking the GPO ID of the link compared to that of the GPO I want to search on). Once I find my GPO, I set that link's enabled property equal to false.
Note that in my 2nd call to get-sdmgplink, I pass in the optional -Native parameter, which lets me get back the actual GPMC object that has the enabled property on it. This is important because if I don't use this param, the call to .enabled will fail!
Well, hope that helps someone out there!
Tags:
Microsoft's Group Policy product team recently posted a blog announcing that they will be adding PowerShell support to Windows 7 for various Group Policy management tasks, such as those things you can do in GPMC scripts today. In addition, they are adding PowerShell support for modifying registry policy, which is a good thing, though the approach they are using is not the way I would have done it.
In any event, I think this is good news for Group Policy administrators. Of course, if you want to be able to leverage this today, you can download our free PowerShell GPMC cmdlets for today's operating systems or take a look at our GPExpert Scripting Toolkit, our commercial product that supports automation against many Group Policy areas, including registry, security, software installation and more.
Tags
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:
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!
German version:
http://download.microsoft.com/download/4/7/1/47104ec6-410d-4492-890b-2a34900c9df2/Workshops-DE.zip
English version:
http://download.microsoft.com/download/4/7/1/47104ec6-410d-4492-890b-2a34900c9df2/Workshops-EN.zip
The second link is for a video I just did for the folks as SpecOps. They have their new SpecOps Command product, which is a very cool solution for combining the power of Group Policy and PowerShell. Basically they let you use Group Policy to distribute PowerShell (and VBScript) scripts to clients on your network. In the video I created, I show how you can use SpecOps Command in conjunction with SDM Software's upcoming Get-SDMGPHealth cmdlet to retrieve Group Policy processing health across your systems.
Check out the video here!
Tags: PowerShell, Group Policy, SDM Software, SpecOps
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:
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
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:
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:
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:
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
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:
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
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
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.
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
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
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
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!
