Use PowerShell

Adding Configuration To Remoting

2010-07-17T14:38:56Z

This is a pretty brief post that will need some further elaboration, but Twitter doesn’t provide the best mechanism for longer examples.

There are two places where you can configure your remote sessions..

1) On the remote server – which is covered in a number of places and probably the most discoverable place to put configuration information.. See the help for about_Session_Configurations.

2) Locally, when you start the PSSession. This is where we will dig deeper.

One of the cool, lesser covered features in remoting is the ability to persist a remote connection to a module. After you establish a PSSession, you can use Export-PSSession to create a module that will hold the commands to create the proxies for the commands in that session, as well as the plumbing to recreate that session.

Export-PSSession will create a script module, which you can modify to work how you would like..

In the module, one of the functions generated is the Get-PSImplicitRemotingSession function. When you call one of the commands from the imported session, it will get the saved PSSession. If the session has not been established yet, the Set-PsImplicitRemotingSession function will be called, creating the session. You can add your any commands you would like after that..

For example I’m using Invoke-Command below to import a module once the session is connected. That script block can be anything you need to do to configure your remote session. (NOTE: The Set-PSImplicitRemotingSession is generated by the command, I’m only adding code after that and using the $script:PSSession object that is created.

Set-PSImplicitRemotingSession `
            -CreatedByModule $true `
            -PSSession (
            $(
                & $script:NewPSSession `
                    -ComputerName '192.168.16.150' `
                    -ApplicationName '/wsman'    -ConfigurationName 'Microsoft.PowerShell' `
                    -SessionOption (Get-PSImplicitRemotingSessionOption) `
                    -Credential ( $host.UI.PromptForCredential( 'Windows PowerShell Credential Request', 'Enter your credentials for http://192.168.16.150/wsman.', 'phoenix\steve.murawski', '192.168.16.150' ) ) `
                     `
                    -Authentication Default `
                   `
            )
            )            

          Invoke-Command {Import-Module TaskScheduler} -Session $script:PSSession

Chicago Code Camp – May 1

2010-04-28T22:00:07Z

The Chicago Code Camp is being held on Saturday, May 1st. I’ll be presenting a PowerShell Deep Dive. If you are in the Chicago area and want to get down into the guts of the PowerShell language and runtime (or many other great sessions!), come on out. There were ~~100~~ 97 tickets available last time I checked…

April Script Club – Special Guest

2010-04-14T20:11:03Z

The Greater Milwaukee Script Club will be meeting on April 20th and we will have a special guest – James Brundage (twitter | blog | blog). James is a member of the PowerShell team at Microsoft, as well as a blogger, community member, guest on the PowerScripting Podcast, and author of the PowerShellPack – part of the Windows Resource Kit.

Last month, we used the Admin Development Model to solve a particular problem one of our brave volunteers was trying to deal with in his environment.

We have planned to talk a bit about error handling, and as always, work on your scripts.

If you are a PowerShell user or need to become a PowerShell user and are in southeastern Wisconsin, come on down, all are welcome (free registration requested)!

Wisconsin Virtual SQL Server Lunch and Learn

2010-02-26T18:46:21Z

I just finished taking up 13 people’s lunch hour to talk a bit about PowerShell V2, SQL Server, and the admin development model.

I want to thank John Allman and the Wisconsin SQL Server User Group for allowing me the time to share a bit about PowerShell. I believe John will be posting the recording for those who are interested.

My slide deck is available here. The slides aren’t worth much, but the resources on the last two are where the real meat is.

Deep Fried PowerShell

2010-02-26T16:50:15Z

Back in August, I was ~~offered a chance to make a fool of myself on yet another podcast~~ tremendously honored by the opportunity to talk with Keith Elder and Chris “Woody” Woodruff on their podcast – Deep Fried Bytes – about PowerShell.

Keith and Chris are great guys, very sharp, and asked some good questions. If you pop over to take a listen to my appearance, make sure to go back and take a look through their archives. They’ve got 45 other shows, all worthwhile. (I’m a few podcast behind.. still working through show #37 – where they are talking about Windows Workflow. Jut to pull in some PowerShell, there is a PowerShell Activity in WF 4.) I’m quite looking forward to show #44 on soft skills with Brian Prince, as I don’t think we in the tech fields focus enough on these.

If you want to hear more on PowerShell related development, send Keith and Woody some feedback on the show or bother your favorite podcaster to do a show on PowerShell – maybe they’ll ask you to put your Shell where your mouth is…

Check out the show here..

Greater Milwaukee Script Club – Take 2

2010-01-27T14:25:06Z

We had a pretty good turnout for the first Greater Milwaukee Script Club and a lot of interest in keeping it going, so I’ve set up a home page for the group on Joel “Jaykul” Bennet’s PowerShellGroup.Org site, which serves as a portal page for PowerShell user groups.

Rod Gabriel (who heads up our local VMWare User Group) has an excellent review of the event. He covers why he considered attending (including why learning PowerShell was becoming a priority for him), as well as the event itself.

Registration is available for our next meeting – which will be February 16th at 6:00 PM at the Greenfield Municipal Court (details here).

More details and information to follow..

Script Injection with Set-PSBreakpoint

2010-01-12T20:30:05Z

I’ve used the integrated debugging features with PowerShell V2 since I’ve had it available, but I never really dug below the surface of setting breakpoints at certain lines.

Set-PSBreakpoint offers some additional options of which I was not aware.

Setting a breakpoint in relation to a variable (read, assigned, or both)
Setting a breakpoint when a function or command is called
Setting a breakpoint based on the column number for the referenced line
Run a scriptblock when a breakpoint is hit
Breakpoints do not need to be set on a script

Let’s dig into these in a bit more detail:

1. Setting a breakpoint in relation to a variable (read, assigned, or both)

Set-PSBreakpoint can be used to find all the occurrences of access to a variable (in the current scope). This can be very useful when attempting to find out where things might be taking an unexpected turn with your variable’s contents.

2. Setting a breakpoint when a function or command is called

This is cool. You can configure breakpoints based on when cmdlets or functions are called. Great stopping at the entry point to a particularly troublesome function, so you can drop into the debugger and check the state of parameters about to go in, as well as other state related issues.

3. Setting a breakpoint based on the column number for the referenced line

I’m not so stoked about this feature. This merely allows you to specify which column to stop execution on in a particular line of code… Moderately useful, but not really exciting.

4. Run a scriptblock when a breakpoint is hit

This is where things get interesting. You can assign an action to occur when a breakpoint is hit. This action is a scriptblock that is run in the scope where it is set. Since breakpoints can be variable assignments or calls to commands, this opens up some interesting possibilities. First off, it allows for conditional debugging. If you only want to drop into a breakpoint if a particular value is less than zero before going into a function, you could do something like

$BreakpointAction = {
    if ($MyNumber -lt 0)
    {
        break
    }
    else
    {
        continue
    }
}

This also has applications outside of debugging. Using the –Action parameter of Set-PSBreakpoint, you have the ability to run a scripblock of your choosing at any of the condition types described above – when variables are accessed, when commands are called, and at certain specific positions in the script.

5. Breakpoints do not need to be set on a script

Finally, breakpoints do not need to be set in a script, they can just be set to respond to variable access or command use. This means that you could use Set-PSBreakpoint in a profile script to configure a particular environment to respond in a certain way, perhaps prompting you before changing a critical environmental variable.

I’m definitely going to be exploring these additional features and applications of Set-PSBreakpoint as I go forward.

Additional debugging tips/info from the PowerShell Team Blog.

Please leave a comment as to how you think this functionality could be used.

I’ll be on the PowerScripting Podcast!

2010-01-11T16:39:33Z

I’ll be on the PowerScripting podcast with Jonathan Walz and Hal Rottenberg for this week’s live stream.

We’ll be talking about PowerShellCommunity.Org, the Sync Framework, and more…

I love that podcast and am really looking forward to it!

Also, they recently posted an interview with Clint Huffman, who is the author of PAL. Good stuff!

Script Club – Coming to the Greater Milwaukee Area

2009-12-08T17:41:50Z

Register here.

About PowerShell Script Club

1. You Always Talk About Script club
2. You Always Talk About Script Club
3. If Someone asks for Help, And You Can Help, You Help
4. Two People Help One Person at One Time
5. One Module Per Person Per Night
6. All Scripts, All PowerShell
7. Scripts will be as short as they can be
8. If This is your First time at Script Club, You Have to Script

The first Greater Milwaukee PowerShell Script Club is being formed.

The first meeting will be on Tuesday, January 19th at 6:00 PM at the Greenfield Law Enforcement Center (in the Municipal Court Room), 5300 W Layton Ave, Greenfield, WI 53220. Register here.

All IT Professionals (sysadmins, network admins, developers, help desk, and all others) with any level of experience are welcome. If you DO NOT KNOW POWERSHELL, but you WANT TO – This is the place.

Pizza and soda will be provided, but please bring a laptop with PowerShell installed (version 1 or 2 is fine).

What is a Script Club?

Andy Schneider describes a script club:

Script Clubs are like a hands on lab with no set topic or teacher. You bring an idea for a script, and ask your fellow PowerShell users for help getting the script written.

This is not a lecture or presentation based group (though we may have presentations from time to time). Script Club is focused on creating working scripts that will help you get your work done or just enjoy yourself.

Register here.

Using the Sync Framework from PowerShell

2010-01-21T20:30:27Z

I’ve been exploring the Sync Framework for use in a couple of projects I have going and PowerShell is my preferred exploratory environment.

It was a bit of fun, since I got to work with eventing for the first time in V2.

First, I downloaded the Sync Framework Software Development Kit. That provided me with the Sync Framework runtime as well as some documentation.

The easiest way for me to get started was to take one of the samples and convert that to PowerShell.

I’m going to walk along the MSDN Sample and provide the equivalent PowerShell, as well as any changes I made to make it feel more PowerShell-y.

Setting Synchronization Options

We are working with the File Sync Provider First up is setting the FileSyncOptions. FileSyncOptions are an enumeration (a limited list defined in code that maps to certain values) whose values are controlled by setting the appropriate bits to indicate the presence or absence of a flag. Mark Schill has a great post about how to set bitwise operations.

$options = [Microsoft.Synchronization.Files.FileSyncOptions]::ExplicitDetectChanges
$options = $options -bor [Microsoft.Synchronization.Files.FileSyncOptions]::RecycleDeletedFiles
$options = $options -bor [Microsoft.Synchronization.Files.FileSyncOptions]::RecyclePreviousFileOnUpdates
$options = $options -bor [Microsoft.Synchronization.Files.FileSyncOptions]::RecycleConflictLoserFiles

Specifying a Static Filter

With the File System provider, we can provide filters to include or exclude files and directories.

$FileNameFilter and $SubdirectoryNameFilter are parameters that take strings or string arrays.

$filter = New-Object Microsoft.Synchronization.Files.FileSyncScopeFilter
if ($FileNameFilter.count -gt 0)
{
   $FileNameFilter | ForEach-Object { $filter.FileNameExcludes.Add($_) }
}
if ($SubdirectoryNameFilter.count -gt 0)
{
   $SubdirectoryNameFilter | ForEach-Object { $filter.SubdirectoryExcludes.Add($_) }
}

Performing Change Detection

After configuring the filter, we examine the folders and files located at the paths specified. If there has not been any previous synchronization, a metadata file will be created in each location to track any changes, updates, and deletes for later synchronization.

function Get-FileSystemChange()
{
    param ($path, $filter, $options)
    try
    {
        $provider = new-object Microsoft.Synchronization.Files.FileSyncProvider -ArgumentList $path, $filter, $options
        $provider.DetectChanges()
    }
    finally
    {
        if ($provider -ne $null)
        {
            $provider.Dispose()
        }
    }
}

Get-FileSystemChange $SourcePath $filter $options
Get-FileSystemChange $DestinationPath $filter $options

Handling Conflicts

Conflict resolution in the Sync Framework happens at the at the event level. An event is merely something that happens that can trigger other actions. Using Register-ObjectEvent, we can associate one or more scriptblocks with an event.

First, I defined scriptblocks to handle the conflicts. There is an enumeration, the ConflictResolutionAction enumeration, that provides some options for dealing with conflicts. For this example, we are going to pick the source object as the winner for any conflicts.

You will also notice another type of conflict defined, and that is a Constraint conflict. That can occur when an object of the same name is added on both sides in between synchronizations. The resolution options for these conflicts can be found in the ConstraintConflictResolutionAction enumeration.

$ItemConflictAction =   {
    $event.SourceEventArgs.SetResolutionAction([Microsoft.Synchronization.ConflictResolutionAction]::SourceWins)
    [string[]]$global:FileSyncReport.Conflicted += $event.SourceEventArgs.DestinationChange.ItemId
}
$ItemConstraintAction = {
     $event.SourceEventArgs.SetResolutionAction([Microsoft.Synchronization.ConstraintConflictResolutionAction]::SourceWins)
     [string[]]$global:FileSyncReport.Constrained += $event.SourceEventArgs.DestinationChange.ItemId
}            

# Configure the events for conflicts or constraints for the source and destination providers
$destinationCallbacks = $destinationProvider.DestinationCallbacks
Register-ObjectEvent -InputObject $destinationCallbacks -EventName ItemConflicting -Action $ItemConflictAction | Out-Null
Register-ObjectEvent -InputObject $destinationCallbacks -EventName ItemConstraint -Action $ItemConstraintAction | Out-Null            

$sourceCallbacks = $SourceProvider.DestinationCallbacks
Register-ObjectEvent -InputObject $sourceCallbacks -EventName ItemConflicting -Action $ItemConflictAction | Out-Null
Register-ObjectEvent -InputObject $sourceCallbacks -EventName ItemConstraint -Action $ItemConstraintAction | Out-Null

We also see for the first time in the script blocks a variable called $event. This is an automatic variable exposed by the event and provides us information that we can use in our action.

Finally, I’m updating a variable in the global scope. There probably is a better way to handle this, but scriptblocks executed in response to events only have access to the global scope and any of the automatic variable exposed to it. Therefore, I use a variable in the global scope to gather my reporting information.

Synchronizing Two Replicas

To start to synchronize the two sides, first we set up the synchronization via a SyncOrchestrator and assign it the local and remote providers, as well as defining the direction of the synchronization. In this example (sticking with the format from MSDN, we will do an Upload, which is in the SyncDirectionOrder enumeration (other options are Download, DownloadAndUpload, and UploadAndDownload).

# Create the agent that will perform the file sync
$agent = New-Object  Microsoft.Synchronization.SyncOrchestrator
$agent.LocalProvider = $sourceProvider
$agent.RemoteProvider = $destinationProvider            

# Upload changes from the source to the destination.
$agent.Direction = [Microsoft.Synchronization.SyncDirectionOrder]::Upload            

Write-Host "Synchronizing changes from $($sourceProvider.RootDirectoryPath) to replica: $($destinationProvider.RootDirectoryPath)"
$agent.Synchronize();

To achieve two way synchronization, we will do the upload twice, reversing the order of the providers.

Invoke-OneWayFileSync -SourcePath $SourcePath -DestinationPath $DestinationPath -Filter $null -Options $options
Invoke-OneWayFileSync -SourcePath $DestinationPath -DestinationPath $SourcePath -Filter $null -Options $options

Full Example

I modified the example to write out a custom object (and the logging is in the variable in the global scope as noted in the Handling Conflicts section) with the results of the synchronization (rather than logging it to the console).

In all, my translation is pretty similar to the example code, but there are some differences.

# Requires -Version 2
# Also depends on having the Microsoft Sync Framework 2.0 SDK or Runtime
# --SDK--
# http://www.microsoft.com/downloads/details.aspx?FamilyID=89adbb1e-53ff-41b5-ba17-8e43a2e66254&displaylang=en
# --Runtime--
# http://www.microsoft.com/downloads/details.aspx?FamilyId=109DB36E-CDD0-4514-9FB5-B77D9CEA37F6&displaylang=en
#
#            

[CmdletBinding(SupportsShouldProcess=$true)]
param (
    [Parameter(Position=1, Mandatory=$true, ValueFromPipelineByPropertyName=$true)]
    [Alias('FullName', 'Path')]
    [string]$SourcePath
    , [Parameter(Position=2, Mandatory=$true)]
    [string]$DestinationPath
    , [Parameter(Position=3)]
    [string[]]$FileNameFilter
    , [Parameter(Position=4)]
    [string[]]$SubdirectoryNameFilter
)
<#
    .Synopsis
        Synchronizes to directory trees
    .Description
        Examines two directory structures (SourcePath and DestinationPath) and uses the Microsoft Sync Framework
        File System Provider to synchronize them.
    .Example
        An example of using the command
#>
begin
{
    [reflection.assembly]::LoadWithPartialName('Microsoft.Synchronization') | Out-Null
    [reflection.assembly]::LoadWithPartialName('Microsoft.Synchronization.Files') | Out-Null            

    function Get-FileSystemChange()
    {
        param ($path, $filter, $options)
        try
        {
            $provider = new-object Microsoft.Synchronization.Files.FileSyncProvider -ArgumentList $path, $filter, $options
            $provider.DetectChanges()
        }
        finally
        {
            if ($provider -ne $null)
            {
                $provider.Dispose()
            }
        }
    }            

    function Invoke-OneWayFileSync()
    {
        param ($SourcePath, $DestinationPath,
                    $Filter, $Options)
        $ApplyChangeJobs = @()
        $AppliedChangeJobs = @()
        try
        {
            # Scriptblocks to handle the events raised during synchronization
            $AppliedChangeAction = {
                $argument = $event.SourceEventArgs
                switch ($argument.ChangeType)
                {
                    { $argument.ChangeType -eq [Microsoft.Synchronization.Files.ChangeType]::Create } {[string[]]$global:FileSyncReport.Created += $argument.NewFilePath}
                    { $argument.ChangeType -eq [Microsoft.Synchronization.Files.ChangeType]::Delete } {[string[]]$global:FileSyncReport.Deleted += $argument.OldFilePath}
                    { $argument.ChangeType -eq [Microsoft.Synchronization.Files.ChangeType]::Update } {[string[]]$global:FileSyncReport.Updated += $argument.OldFilePath}
                    { $argument.ChangeType -eq [Microsoft.Synchronization.Files.ChangeType]::Rename } {[string[]]$global:FileSyncReport.Renamed += $argument.OldFilePath}
                }
            }            

            $SkippedChangeAction = {
                [string[]]$global:FileSyncReport.Skipped += $event.SourceEventArgs.CurrentFilePath            

                if ($event.SourceEventArgs.Exception -ne $null)
                {
                    Write-Error '[' + "$($event.SourceEventArgs.Exception.Message)" +']'
                }
            }            

            # Create source provider and register change events for it            

            $sourceProvider = New-Object Microsoft.Synchronization.Files.FileSyncProvider -ArgumentList $SourcePath, $filter, $options
            $AppliedChangeJobs += Register-ObjectEvent -InputObject $SourceProvider -EventName AppliedChange -Action $AppliedChangeAction
            $AppliedChangeJobs += Register-ObjectEvent -InputObject $SourceProvider -EventName SkippedChange -Action $SkippedChangeAction             

            $ApplyChangeJobs += $SourceApplyChangeJob            

            # Create destination provider and register change events for it
            $destinationProvider = New-Object Microsoft.Synchronization.Files.FileSyncProvider -ArgumentList $DestinationPath, $filter, $options
            $AppliedChangeJobs += Register-ObjectEvent -InputObject $destinationProvider -EventName AppliedChange -Action $AppliedChangeAction
            $AppliedChangeJobs += Register-ObjectEvent -InputObject $destinationProvider -EventName SkippedChange -Action $SkippedChangeAction            

            $ApplyChangeJobs += $DestApplyChangeJob            

            # Use scriptblocks for the SyncCallbacks for conflicting items.
            $ItemConflictAction =   {
                $event.SourceEventArgs.SetResolutionAction([Microsoft.Synchronization.ConflictResolutionAction]::SourceWins)
                [string[]]$global:FileSyncReport.Conflicted += $event.SourceEventArgs.DestinationChange.ItemId
            }
            $ItemConstraintAction = {
                $event.SourceEventArgs.SetResolutionAction([Microsoft.Synchronization.ConstraintConflictResolutionAction]::SourceWins)
                [string[]]$global:FileSyncReport.Constrained += $event.SourceEventArgs.DestinationChange.ItemId
            }            

            #Configure the events for conflicts or constraints for the source and destination providers
            $destinationCallbacks = $destinationProvider.DestinationCallbacks
            $AppliedChangeJobs += Register-ObjectEvent -InputObject $destinationCallbacks -EventName ItemConflicting -Action $ItemConflictAction
            $AppliedChangeJobs += Register-ObjectEvent -InputObject $destinationCallbacks -EventName ItemConstraint -Action $ItemConstraintAction             

            $sourceCallbacks = $SourceProvider.DestinationCallbacks
            $AppliedChangeJobs += Register-ObjectEvent -InputObject $sourceCallbacks -EventName ItemConflicting -Action $ItemConflictAction
            $AppliedChangeJobs += Register-ObjectEvent -InputObject $sourceCallbacks -EventName ItemConstraint -Action $ItemConstraintAction             

            # Create the agent that will perform the file sync
            $agent = New-Object  Microsoft.Synchronization.SyncOrchestrator
            $agent.LocalProvider = $sourceProvider
            $agent.RemoteProvider = $destinationProvider            

            # Upload changes from the source to the destination.
            $agent.Direction = [Microsoft.Synchronization.SyncDirectionOrder]::Upload            

            Write-Host "Synchronizing changes from $($sourceProvider.RootDirectoryPath) to replica: $($destinationProvider.RootDirectoryPath)"
            $agent.Synchronize();
        }
        finally
        {
            # Release resources.
            if ($sourceProvider -ne $null) {$sourceProvider.Dispose()}
            if ($destinationProvider -ne $null) {$destinationProvider.Dispose()}
        }
    }            

    # Set options for the synchronization session. In this case, options specify
    # that the application will explicitly call FileSyncProvider.DetectChanges, and
    # that items should be moved to the Recycle Bin instead of being permanently deleted.            

    $options = [Microsoft.Synchronization.Files.FileSyncOptions]::ExplicitDetectChanges
    $options = $options -bor [Microsoft.Synchronization.Files.FileSyncOptions]::RecycleDeletedFiles
    $options = $options -bor [Microsoft.Synchronization.Files.FileSyncOptions]::RecyclePreviousFileOnUpdates
    $options = $options -bor [Microsoft.Synchronization.Files.FileSyncOptions]::RecycleConflictLoserFiles
}
process
{
    $filter = New-Object Microsoft.Synchronization.Files.FileSyncScopeFilter
    if ($FileNameFilter.count -gt 0)
    {
       $FileNameFilter | ForEach-Object { $filter.FileNameExcludes.Add($_) }
    }
    if ($SubdirectoryNameFilter.count -gt 0)
    {
       $SubdirectoryNameFilter | ForEach-Object { $filter.SubdirectoryExcludes.Add($_) }
    }            

    # Perform the detect changes operation on the two file locations
    Get-FileSystemChange $SourcePath $filter $options
    Get-FileSystemChange $DestinationPath $filter $options            

    # Reporting Object - using the global scope so that it can be updated by the event scriptblocks.
    $global:FileSyncReport = New-Object PSObject |
        Select-Object SourceStats, DestinationStats, Created, Deleted, Overwritten, Renamed, Skipped, Conflicted, Constrained            

    # We don't need to pass any filters here, since we are using the file detection that was previously completed.
    # this will only 
    $global:FileSyncReport.SourceStats = Invoke-OneWayFileSync -SourcePath $SourcePath -DestinationPath $DestinationPath -Filter $null -Options $options
    $global:FileSyncReport.DestinationStats = Invoke-OneWayFileSync -SourcePath $DestinationPath -DestinationPath $SourcePath -Filter $null -Options $options            

    # Write result to pipeline
    Write-Output $global:FileSyncReport
}

Download Invoke-SyncFrameworkSample.zip

So Easy, I Could Kick Myself

2010-01-07T22:18:29Z

I’m updating Crystal Reports and trying to determine which reports might have been affected by some schema changes or functional changes in how the data was being stored.

The problem I’ve had is that when there are a large number of reports, it is very time consuming to open each one, look at it, and see if it contains any affected tables or views.

I’ve had to deal with this in my previous role as well. After feeling the pain a few times, I turned my intern loose on the problem and shelved the problem as “just another pain in dealing with Crystal Reports”.

Now, I’m back dealing with Crystal Reports more frequently and in the position to have to possibly update around 30 or 40 reports that were written before I started.

I’ve recently had a bit of exposure to the object model for the .NET API for Crystal Reports and thought maybe I could leverage that through PowerShell and whip together a quick script to help me list out the tables in each report.

It turned out to be painfully easy…

[reflection.assembly]::LoadWithPartialName('CrystalDecisions.Shared')
[reflection.assembly]::LoadWithPartialName('CrystalDecisions.CrystalReports.Engine')
$report = New-Object CrystalDecisions.CrystalReports.Engine.ReportDocument
$report.load($pathToScript)
$report.Database.Tables | Select-Object -expand Name
$report.Dispose()

After I got the basics, I poked around and updated the script further (and posted it on PoshCode).

The full script also accesses the first level of subreports and retrieves their tables as well.

NOTE: Requires either the Crystal Report Runtime (Visual Studio 2008) or Visual Studio to be installed.

DOWNLOAD UPDATED SCRIPT

All Sorts of New

2009-11-12T13:00:00Z

A lot has happened since I last had the opportunity to post.

Quick recap:

PowerShell v2 is now out and available for XP, Server 2003, Vista, Server 2008, and installed and on by default for Windows 7 and Server 2008 R2
SharePoint 2010 has an insane number (492)
There is an open source cmdlet and help designer
Try PowerShell is a great way to explore
The PowershellPack provides some great modules that get you jump started with V2.
Azure has cmdlets for management
There is introductory PowerShell material in the Server 2008 R2 Developer Training Kit
There are some PowerShell for Developers training videos on Channel 9
James Kovacs released psake V2.00
PsTFS has hit V1 – which is great for me now..
I’m sure I’ve missed a ton of other cool PowerShell stuff that is happening too..

And that leads me to what I’m doing now.

In August, I left my job as a IT Specialist for a municipal police department and took a job heading up research and development for ProPhoenix, which is a software development company that make software for public safety agencies (police, fire, corrections, municipal courts).

I now live in a more software development focused world and will get to spend more time focusing on using PowerShell to automate my current activities, explore new frameworks, and to build a management API for our applications. I can’t wait to make PowerShell a requirement for our server products installation so I can get our support staff to start leveraging the capabilities PowerShell brings to the table.

PowerShell in Azure

2009-07-21T16:53:34Z

The July CTP release of the Windows Azure SDK contains a new sample project called PowerShellRole which demonstrates that PowerShell is available in the cloud!

Previous versions of the CTP have come with a sample Provider which you could use to access Azure storage (blobs, queues, and tables), but this actually provides demonstration of creating runspaces and executing pipelines in the cloud.

Now to see what version is running in the cloud!

Deep Dive: Error Handling – Error Types (part 1)

2009-11-20T19:12:55Z

I started looking a little deeper at error handling in PowerShell after this StackOverflow question.

PowerShell has two kinds of errors – terminating errors and non-terminating errors.

Terminating errors are the errors that can stop command execution cold. Non-terminating errors provided an additional challenge, as you need to be notified of failed operations and continue with pipeline operations. To deal with this issue and to provide additional output options, PowerShell employs the concept of streams. There are three additional streams (other than the primary pipeline stream) available in PowerShell – Verbose, Warning, and Error (and . We’ll be concerning ourselves with the output from the Error stream.

There are some automatic variables in the shell that deal with errors as well. $ErrorActionPreference is a variable that describes how PowerShell will treat non-terminating errors. $ErrorActionPreference has four options: “Continue” (the default), “SilentlyContinue”, “Inquire”, and “Stop”. $error is an array of all the errors that have occurred in the current session up to the number specified in $MaximumErrorCount. $? is a boolean value that is $true if the previous operation succeeded and $false if it did not.

PowerShell does have some built in flexibility to turn non-terminating errors into terminating errors. Based on our setting of $ErrorActionPreference, PowerShell will treat a non-terminating error differently. If $ErrorActionPreference is set to ‘”Stop”, PowerShell will treat the errors from that scope and all sub scopes (unless explicitly overridden) as terminating errors. If “Inquire” is chosen as the $ErrorActionPreference, then PowerShell will prompt the user at the console upon each error to ask whether it should continue (treat as non-terminating) or halt (treat as terminating), as well as providing an option to drop into a nested prompt.

$ErrorActionPreference is a global preference that can be set, but the PowerShell runtime also allows more granular control by providing common parameters for -ErrorAction and -ErrorVariable (shorthand -EA and –EV) which allow you to determine per cmdlet (and in V2 per advanced function) how errors should be handled. The –ErrorAction parameter takes the same options as $ErrorActionPreference.

So what happens when you encounter an error?

If you hit a terminating error, your script, function, or command will stop. The error will be logged to the $error variable and written to the error stream. The $? will be set to false. You can use the trap construct (or the try/catch/finally construct in V2) to deal with terminating errors and we’ll cover that further in the fourth post in this series.

If you hit a non-terminating error, the result will depend on the $ErrorActionPreference in the scope or the –ErrorAction parameter. If the $ErrorActionPreference or –ErrorAction parameter is set to ‘Continue’, the error will be written to the error stream, added to the $error array, and the $? will be set to $false. ‘SilentlyContinue’ will not write an error to the Error stream, but $error and $? are updated. Finally, ‘Inquire’ provides you an option at each error as to whether to treat it as terminating or non-terminating. If treated as a non-terminating error, the error will be treated like the $ErrorActionPreference or –ErrorAction parameter is ‘Continue’.

Now, I’ve mentioned that some terminating and non-terminating errors both write to the Error stream, so where does that actually get reported back to the user? If an error has been written to the error stream, it will be written to the output stream (which may surface differently based on the PowerShell host) separately from the pipeline output unless it is redirected. This means that the exception objects, which are how the errors are represented, are not saved to a variable if you are assigning the pipeline output to a variable.

For example:

$results = Get-WMIObject Win32_Bios –ComputerName localhost, ComputerThatDoesNotExist
Get-WmiObject : The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
At line:1 char:22
+ $results = Get-WmiObject <<<< Win32_Bios -ComputerName localhost, ComputerThatDoesNotExist

creates this output to the screen, but $results will only hold the results of the successful WMI query. This is where the –ErrorVariable comes in. You can specify a variable to hold the exceptions generated by a particular cmdlet (or in V2 advanced function). Specifying a variable does not remove an item from being written to the error stream and displayed as output.

In a console session, you can redirect the error stream with the redirection operators ( 2> or 2>>) or you can merge the error stream with the output stream (2>&1) and write the output to a file, the pipeline, or assign it to a variable.

Up next:

Error Objects
Tracing Errors
Trapping Errors
Reporting Errors

Other great PowerShell Error Handling posts:

Exploring the .NET Framework with PowerShell – Garbage Collection (Part 6)

2009-07-07T12:00:00Z

Garbage collection is a process that the .NET Framework (upon which the PowerShell runtime works) uses to manage memory. The garbage collection (for applications – services are handled a bit differently) process basically covers X steps:

Identify objects that won’t be used
Delete them from memory
Compact the space to make room for new objects

The first step is the critical point for PowerShell users. You may have noticed how the memory used in a PowerShell session can steadily climb (or suddenly climb if you’re dealing with a large number of objects). I talked about that in this tip. The .NET garbage collector looks for objects that are still in use or could possibly be in use in the near future (this is a gross oversimplification – if you are really interested in a detailed explanation of how garbage collection works in the .NET Framework, check out this article.)

What this means to scripters who are running into memory pressure issues is that the garbage collector will not reclaim any objects you have actively referenced (meaning that you’ve assigned them to a variable) in your current or higher scope.

Since this can sound a bit convoluted let’s look at an example.

I read a large file to parse it and leave the contents of the original stored in a variable

PS> $MyLargeFile = Get-Content MyLargeFile.txt
PS> Foreach ($line in $MyLargeFile) {
DoSomething $line | Out-File NewUpdatedLargeFile.txt
}

One of the problems with the above pattern is that the original file remains saved in memory and doesn’t get released unless you explicitly remove the reference, either by using Remove-Variable or Remove-Item or by changing what $MyLargeFile points to by assigning another value to it.

This isn’t VBScript where you have to set values to “Nothing”, but you should be aware of what larger object sets you are retaining in memory.