We also need to grab the constants from the GPMC object and create a variable
that can be passed into our COM functions; the code at callout B accomplishes
this task. In addition, we need to use the DNS names from the sample .csv file
to obtain the domain object GPMDomain via a call to the GetDomain GPMC API;
the code at callout C accomplishes this task.
Next, we need to call the GPMC API to select the appropriate GPO, as the code
at callout D does. Notice that this line of code uses a new operand (i.e., $_.)
and specifies the column name of the .csv file we created earlier. The $_ operand
lets us access sets of data within each column, stored by PowerShell as .NET
objects.
The last line in our GPMC API calls, which callout E shows, is the final call
to actually do the backup. In this example, I hard-coded the backup location
to C:\backup. This location can be passed in or be part of the columns in the
passed-in .csv file. The PowerShell command is
$Result = $GPO.Backup ("C:\\backup", $_
.Description)
Note that when you pass in a directory name to a COM-based function call, you
need to use two backslashes because single backslashes are interpreted as escape
characters. Make sure the directory C:\backup exists before you call the PowerShell
script.
Finally, we add a single line of code at the beginning to name our filter
and put the code we've written so far in a block to allow objects to be
passed in as a filter. Functions are typically created with parameters that
are passed in. In our case, the whole .csv file is passed in and we're dynamically
accessing all the objects within the file. Using functions doesn't make sense
because we aren't specifying static parameters. Filters just take whatever is
passed in—the code inside the filter handles and makes assumptions about
the data to use.
If we wanted to get more advanced, we could add error checks to make sure the
$GPMResult variable is valid and that no exceptions have been thrown, to determine
the script's success or failure. However, I wanted to keep the example simple.
Step 4: execute the Backup Filter
Now we get to see PowerShell's magic and flexibility. First, start PowerShell
and change the PowerShell policy to allow execution of scripts. To do so, enter
PS C:\> Set-ExecutionPolicy
-executionPolicy Unrestricted
Next, load the PowerShell code from Listing
1 by "dot-sourcing" the PowerShell file. This action essentially loads the
filter we've created into the current PowerShell runspace.
As I already explained, passing a .csv file as a parameter only passes the
reference to the .csv file in a function. You then have to write code in the
function to manually parse the contents of the .csv file. Passing the .csv file
in as a filter lets us access all of the file's data elements as .NET objects
inside the filter.
Enter
PS C:\> . C:\PSDemo\BackupGPOs.ps1
Then, import the .csv file and pass it into the Do-GPOBackup filter we wrote.
Enter
PS C:\> import-csv C:\PSDemo\GPOList.csv
| Do-GPOBackup
Figure 2 shows the output.
The PowerShell script that we created can take as input any .csv file for performing
operations on GPOs. We can also add a parameter check to operate only on GPOs
that match a certain domain name. For example, for the domain Americas, enter
PS C:\> import-cvs C:\PSDemo\GPOList.csv
| {where $_.Domain = "Americas"} | DoGPOBackup
Another option is to take the result and pipe it to a graph to identify the
GPOs that were backed up, time them to see which ones are taking the longest
to back up, and pinpoint which ones are creating the greatest performance problems.
The possibilities are now endless. We could modify the PowerShell script so
that instead of performing backups, we could perform periodic restores of critical
GPOs by scheduling them via Task Scheduler. In addition, simply changing the
spreadsheet contents would dynamically change the list of GPOs being operated
on, backed up, or restored.
