Archive

Author Archive

Transform repetitive script blocks into invocable snippets with SnippetPx

October 21, 2014 Leave a comment

The more you write code, the more you notice patterns in the code you write.  This goes for PowerShell, C#, Ruby, and any other programming or scripting language under the sun.  Patterns are opportunities.  Opportunities to generalize them and define them as design patterns.  Opportunities to isolate blocks of reusable code in such a way that they can be reused so that you can follow the DRY principle in your work.  This article is about the latter of those two.

In recent months I have been working on trying to reduce duplication in my own work by keeping my modules and functions as DRY as possible.  One challenge with keeping code DRY in PowerShell is in deciding which is the most appropriate method to do so.  There are many opportunities to keep your code DRY in PowerShell.  You can create:

  • cmdlets
  • advanced functions
  • basic functions
  • unnamed functions (aka script blocks)
  • script files
  • type extensions for the Extended Type System (ETS)
  • classes with properties and methods, either in a .NET assembly that is imported into PowerShell, or if you’re using PowerShell 5.0 or later, in PowerShell itself
    Despite each of these extension points being available to PowerShell, they don’t always fit the scenarios you need them to, perhaps because they are not appropriate for the intended purpose, because they have some limitation that you can’t work around, or perhaps for some other reason.  For example, I find myself writing all of these, and there are certain pieces of code that I want to set up for easy sharing in many of these types of extensions without being an extension point itself.  When you have logic that you might use anywhere that you could write PowerShell, how do you set that up in such a way that you can consume it in all of those locations easily regardless of the machine you are running on, without taking a dependency on physical file paths?  That last point is important, because standalone ps1 files may be one possible answer to this need, except invoking them requires knowing where they are, and when you invoke them you must decide whether to dot source them or call them with the call operator, which in turn means you must know the implications of such a decision.  Plus, when their use spans all of PowerShell (any script, any module, any function), where do you put them without having to burden the consumer with extra setup work?  And how can you create more of these while making them discoverable, and able to be added to or removed from a system with ease?
    Snippets are a great answer to these questions.  Snippet is a programming term that has been around for many years, and it generally refers to a small region of re-usable code.  They are also a lot more than a fancied-up bit of copy/paste functionality.  They have parameters, or fields, that control how they run.  They can surround text you have selected, or simply insert into the current cursor location.  Most importantly however, for me at least, is that snippets can be invocable, and that, my friends, is key because when you’re trying to maintain a DRY code base, you don’t want to inject boilerplate code blocks in many locations…you want to invoke them.

With snippets being a great solution to this problem, I decided to try to build a snippet-based solution that would allow for discoverable, invocable snippets.  I wanted this solution to be able to find snippets regardless of what computer you were running on, as long as you followed a few simple rules.  I wanted this solution to keep snippet definitions as simple as the creation of a ps1 file.  And I wanted this solution to allow for snippets to be invoked in the current scope by default, and in a child scope as an option.

Enter SnippetPx.  SnippetPx is a module that provides two very simple commands, plus a handful of snippets.  The two commands are Get-Snippet, which retrieves the snippets that are discoverable on the local computer, and Invoke-Snippet, which allows a snippet to be invoked by name, with or without parameters, in the current scope or in a child scope.  With this module, any ps1 file that is stored in a “snippets” folder inside of the current user’s Documents\WindowsPowerShell folder, the system %ProgramFiles%\WindowsPowerShell folder, or as a subfolder under the root of any module that is discoverable via PSModulePath will be discoverable as a snippet.  You can see some examples by looking in the “snippets” folder in the SnippetPx module itself, or by looking in another module that includes some snippets such as the TypePx module.  Also, any snippet that is discoverable by this module is invocable by the Invoke-Snippet cmdlet.

Since creating this module, it has quickly become a core module that my other modules take a dependency on in order to keep my code DRY.  That effort has already paid off for myself because it has allowed me to update a block of code that is defined in a snippet and only have to make that change once, while all other locations where that snippet is invoked simply run with the new code change.  I encourage you to give it a try and see if it helps you remove what might otherwise be repetitive code that is more difficult to maintain than it should be.

If you would like to give SnippetPx a try, you can download Snippet from GitHub (yes, it is open source, along with the binary module where Invoke-Snippet and Get-Snippet are implemented) or from the PowerShell Resource Gallery (aka the PowerShellGet public repository).  Feedback is more than welcome through any means by which you want to communicate with me: the Issues page for this project on GitHub, social media channels, comments on this blog, etc.  In the meantime, I will continue to identify opportunities to create more snippets that will be useful to others and push them out either as updates to SnippetPx or in the modules where those snippets are used.

One more thing: if you do decide that you want to create some snippets of your own, there are some useful details in the Notes section of the help documentation for the Get-Snippet and Invoke-Snippet cmdlets.  I strongly recommend giving that a read before you dive into creating invocable snippets, as it provides some additional detail on how snippets are discovered as well as recommendations on the naming of your snippet ps1 files.

Thanks for listening!

Kirk out.

PowerShell debugging, amplified

October 20, 2014 1 comment

This article is about the PowerShell module that I am most proud of and that I have personally found more useful than any other module I have created.  I hope that you enjoy it as much as I do.

Every programming language must be designed with debugging in mind, and PowerShell is no exception.  No matter who you are, no matter how well you know the language, you will inevitably come across something that isn’t working like it should.  What you do in these situations depends on your comfort level with programming and debugging.  For some, this means adding lines to the code that produce extra output so that they can get a handle on what is going on.  For others, this means rolling up the sleeves and stepping through the code in a debugger.  And there are others still who aren’t comfortable enough with programming or debugging, so they turn to others for assistance.  Regardless of which of these approaches you would take, I believe I have a module that can help.

DebugPx is a free, open source PowerShell module that was designed to make it easier to troubleshoot problems in PowerShell code.  It comes with two core commands: breakpoint and ifdebug.  It also includes a few helpful utility commands to control how the breakpoint command works.  The core commands are described as follows:

breakpoint The breakpoint command is used to trigger a breakpoint at the current location.  By default, the breakpoint command causes Windows PowerShell to immediately enter the debugger whenever it is invoked in an interactive session.  If it is invoked with its optional ConditionScript parameter, it will only trigger the breakpoint if the script block expression that was provided for the ConditionScript parameter evaluates to true.  It also accepts an optional string Message parameter, and it will write the message provided to this parameter to the current host whenever the breakpoint is triggered.
ifdebug

The ifdebug command is used to identify a block of PowerShell script that you only want to run in one of two scenarios: when you invoke a command with -Debug, or when the $DebugPreference variable is set to anything either than SilentlyContinue or Ignore.

Both of these commands are very powerful and they can make troubleshooting problems in PowerShell scripts a lot easier.  Let me provide some background details so that you understand the problems that these commands solve, problems that still exist in PowerShell 5.0 today.

PowerShell version 1.0 did not come with breakpoint support.  It had a debugger, and that debugger is still useful today, even though a new debugger has been in PowerShell since version 2.0.  It had a -Debug common parameter that was available on every cmdlet and, since version 2.0 of PowerShell, on every advanced function as well.  It had a $DebugPreference built-in variable.  It also had a Write-Debug cmdlet that allowed you to have some level of debugger control over your scripts.  The behaviour of the Debug common parameter, $DebugPreference and how those affect Write-Debug behaviour is quite interesting, and once you understand how those work together, you may see why their implementation leaves some opportunities on the table.

When you invoke a cmdlet or an advanced function with the -Debug common parameter, PowerShell internally sets the $DebugPreference variable value to Inquire within the scope of that command.  As far as PowerShell preference variables go, a value of Inquire means that PowerShell will prompt the user to ask if they want to continue the execution of the associated command, stop the associated command immediately, or enter a the debugger at that point, allowing the user to invoke PowerShell commands to troubleshoot the system.  This behaviour seems like it was designed to fill the void when PowerShell did not have breakpoints, because it allowed scripters to enter the debugger as long as they threw a few Write-Debug commands into their scripts.

The problem with this approach is that it tries to do too many things and mixes up several distinct needs in the process.  The ability to write debug information to the debug stream during script execution, and the ability to enter the debugger on a breakpoint at a specific location in a script are two distinct needs that are mashed together when they shouldn’t be.  Another limitation with this approach is that scripters can’t simply change the way a script is invoked in order to gather additional debug information from an environment where they aren’t able to debug with breakpoints as easily, because using -Debug meant prompting the user every time Write-Debug would be called, and often you’re trying to help a user who is having a problem in this scenario, not confuse them by asking them to continue a bunch of Write-Debug calls while telling you what is happening.  Yet another limitation with this approach is that there is no easy way to include PowerShell commands inside of an advanced function or script that will only execute when you are debugging, allowing a command or script author to include support for generating debug output but only when that command or script is invoked with -Debug.

When breakpoints were later added along with a new debugger in PowerShell 2.0, PowerShell script authors were suddenly able to set breakpoints in their scripts, either visually using PowerShell ISE or for conditional breakpoints, command breakpoints, or variable breakpoints using the Set-PSBreakpoint cmdlet.  This functionality solved the need for breakpoints, and it started the separation of the need to enter the debugger from the need to be able to write debug output; however, the -Debug common parameter behaviour didn’t change, so there still wasn’t a good vehicle for writing information to the debug stream without any requirement for user interaction during the process.  Also, while this breakpoint functionality was useful, it came with its own share of limitations.  If you were working in an environment other than PowerShell ISE that didn’t have visual support for setting PowerShell breakpoints (such as notepad++, sublime text, or some other awesome editor), you simply had no choice but to work with the Set-PSBreakpoint cmdlet, which isn’t a very friendly way to set breakpoints in PowerShell, putting it mildly.  Also, if you were debugging PowerShell code across multiple sessions, you would have to reset your breakpoints every time, either manually or using a profile or some other script, none of which is very practical.

DebugPx was designed to solve almost all of these problems with the breakpoint and ifdebug commands.  With the DebugPx module installed and discoverable via the PSModulePath environment variable, you can trigger a breakpoint at a specific location by simply invoking the breakpoint command (or the bp alias, for short).  These breakpoints are identifiable in any editor because you can see the commands in the files where they are used.  They work in unsaved files.  They even work in an interactive PowerShell prompt, or inside of a block that you run in PowerShell using copy/paste, or inside of a block that you select in ISE and run by using the Run Selection (F8) feature.  They are properly ignored if they are inside of a function that uses the System.Diagnostics.DebuggerHidden attribute.  They are conditional if you invoke them with a condition script block (which would map to the first, ConditionalScript parameter), or unconditional otherwise.  They can be globally enabled or disabled using the Enable-BreakpointCommand or Disable-BreakpointCommand commands.  They will only cause PowerShell to enter the debugger if they are encountered in an interactive session.  And if you want a message to be displayed when the breakpoint activates (for example, as a reminder why you wanted to break when that obscure scenario that you previously couldn’t catch occurs), you can pass a message to the -Message parameter and the breakpoint will output the message to the host when the breakpoint is triggered.

If you are debugging in other scenarios, where you may not be able to use the breakpoint command to enter a debugger because you are not in an interactive session (such as in background jobs, scheduled tasks, Azure Automation or Service Management Automation scripts, or perhaps in a remote customer’s environment), you can include rich debug information inside of an ifdebug command script block, and anything that is output from inside of that script block will automatically be written to the debug stream without prompting the end user.  This includes object data, text strings, or anything else you want to write to the debug stream in order to figure out what is going on when that script runs.  If the command containing ifdebug is not invoked with -Debug, PowerShell will simply skip directly over that script block, avoiding running debug logic when it is not needed, which is better for performance.

Both the breakpoint command and ifdebug can be used in the middle of a pipeline as well.  This is important because it allows for writing debug information to the debug stream or triggering a breakpoint in the middle of a pipeline during the processing of that pipeline.  If you use the breakpoint command in a pipeline and you either have the breakpoint command disabled or you are in a script block with the DebuggerHidden attribute set, or if you use the ifdebug command in a pipeline and you didn’t run the script with -Debug, both the breakpoint and the ifdebug commands will simply pass the pipeline object down to the next stage in the pipeline for additional processing.

At this point, you’re probably getting a feeling for the kind for the power that these commands provide.  Let me show you a few simple examples that demonstrate how you might use them in practice.  You can try these examples at the command prompt in the PowerShell host of your choice, or in a script file, or in functions you write, or script module files, or workflows, etc.

Enter the debugger in the middle of a series of commands

$services = Get-Service wuauserv,bits
breakpoint
Restart-Service -InputObject $services -WhatIf

Enter the debugger conditionally in the middle of a pipeline (using the bp alias)

gsv audiosrv,bits,wuauserv | bp {$_.Name -eq ‘bits’} | spsv -WhatIf

Display a message as you enter the debugger reminding you why you are doing so

Get-Process -Name Idle,PowerShell,Explorer |
   
breakpoint {$_.Id -eq 0} -Message ‘Process ID is zero???’ |
   
Format-Table

Disable the breakpoint command so that you can run without debugging

Disable-BreakpointCommand
gsv audiosrv,bits,wuauserv | breakpoint {$_.Name -eq ‘bits’} | spsv -WhatIf
‘See, the breakpoint command did not cause PowerShell to enter the debugger!’

Re-enable the breakpoint command so that it functions normally again

Enable-BreakpointCommand

Skip over breakpoints in a script block by using the DebuggerHidden attribute

& {
    [System.Diagnostics.DebuggerHidden()]
    param()
    breakpoint
    ‘The breakpoint command is effectively disabled in the current scope.’
}
‘But it still works in scopes that do not use the DebuggerHidden attribute.’
breakpoint

Create a function that generates some useful debug information

function Test-IfDebug {
    [CmdletBinding()]
    param()
    ifdebug {
        # This may be useful when debugging, but I wouldn’t want to gather
        # this information in everyday use. It is an exaggerated example of
        # what you might want to collect when debugging something.

        ‘*************** Current Operating System ***************’
        Get-WmiObject -Class Win32_OperatingSystem | Format-List *
        ‘*************** Running Services ***************’
        Get-Service | Format-List *
        ‘*************** Running Processes ***************’
        Get-Process | Format-List *
    }
    Get-Service w*
}

Invoke that function without debugging

Test-IfDebug

Invoke that function with debug output turned on

Test-IfDebug -Debug

Compare the performance of the two

Measure-Command {Test-IfDebug}
Measure-Command {Test-IfDebug –Debug}

I think those examples provide a good demonstration of how these commands work.  As I hinted at earlier in this article, I am super-excited about this module and I’m thrilled that I can share it with you now.  If you want to give it a try, install the latest version in your environment by following the instructions on the DebugPx project page on GitHub.  I have a few more features planned for this debugging toolkit, and I would be very happy to entertain your ideas as well, so please let me know what you think!  Have fun debugging!

Kirk out.

Make working with types in PowerShell easier with TypePx

October 8, 2014 Leave a comment

It is often the little things in life that make a big difference.

1.week.ago

Isn’t that a beautiful programming example? That wasn’t a heading you just read, it was a piece of code. It’s simple, it’s very expressive, it’s self-documenting, and it’s pretty hard to misunderstand the intent when you look at it.  That’s not PowerShell code though…it’s Ruby.

Over the past year or so I have taken some MOOCs offered by Coursera and edX.  After playing games that I created for my assignments in Python, I started learning more about Ruby.  Ruby is a wonderful, expressive, dynamic programming language with a vibrant community that has a lot in common with PowerShell.  It also offers more functionality than PowerShell does in some areas, and I started missing some of that expressive syntax that I was able to use in Ruby when I would switch back to working in PowerShell.

Here’s how you can accomplish the same task natively in PowerShell:

(Get-Date).AddDays(-7)

It doesn’t offer quite the same punch, does it?  Between all of the brackets, the need to call out to Get-Date, and adding negative days to be able to get a timestamp representing 1 week ago, it just isn’t quite as palatable to me.

The beauty of a more mature language like Ruby is that it’s not just about the availability of a week method for numeric classes, nor the availability of an ago method for a time span class.  It’s the availability of years, months, weeks, days, hours, minutes, seconds and milliseconds, all in singular or plural.  It’s the availability of ago to refer to a date in the past, or fromnow to refer to a date in the future.  Want UTC instead of local time?  There’s a inutc method too, as well as so many other cool things.  Small details matter.

Fortunately, like Ruby, PowerShell is also a dynamic language that has all sorts of extensibility built-in, allowing me to continue to enjoy expressive, Ruby-like syntax, even while working in PowerShell.  I know PowerShell’s extensibility quite well, and have been leveraging it since version 1.  These Ruby features inspired me to create a new PowerShell module, bringing some of the method simplicity, elegance, and usefulness from Ruby into PowerShell for the rest of the PowerShell community to enjoy.  I called it TypePx.  It’s open source, and it defines useful type extensions and simplifies type acceleration to reduce much of the typing that would otherwise be required when working with types in PowerShell.  Also, it works on PowerShell 3.0 or later, and it’s available now.

Here are examples of some of the beautiful things you can do with TypePx:

# Get a timespan in a human readable way
(10).years
(2).months
(12).hours

# Use relative dates, as mentioned above
(1).week.ago
(30).days.ago.inutc

# How about using relative dates in a practical way with event logs?
Get-EventLog -LogName System -After (2).Days.Ago
# You can use it when monitoring file age too
dir *.ps*1 | where LastWriteTime -lt (1).year.ago

# Compact (remove null values) from an array
$a = 1,$null,2,$null,3
$a.Compact()
# Return unique elements in an array
$a = 1,1,2,3,3,4,4,5,6
$a.Unique()
# Reverse an array
$a = 1,2,3,4
$a.Reverse()
# Slice an array into chunks
$a = 1,2,3,4,5,6
$a.Slice(3)[1]
# Flatten a multi-dimensional array
$a = (1,2),(3,4),(5,6)
$a.Flatten() 

These are only a few examples of what you can do with TypePx.  Have you ever worked with hashtables and noticed how annoying collection management is when it comes to hashtable values?  June Blender was looking for a solution to this the other day, and TypePx solves that problem.

$ht = @{}
$ht.Add(‘A’,’This is not a collection’)
$ht.AddArrayItem(‘B’,’This is a collection’)
$ht.AddArrayItem(‘B’,’This adds to the collection’)
$ht

By now you have probably seen the cool foreach and where “magic” methods that were added to PowerShell as part of version 4.0.  What about version 3.0 though?  TypePx solves that problem too by adding foreach and where methods to PowerShell 3.0 with all of the bells and whistles that are available in PowerShell 4.0.

Here are a handful of other problems that TypePx makes easier:

  • comparing an array to multiple search strings at the same time in a single call;
  • comparing a string to multiple search strings at the same time in a single call;
  • calculating the sum of an array or of a property on a collection of items;
  • accessing the value hidden inside of a SecureString;

TypePx isn’t just about type extensions either.  It’s also about type acceleration.  In fact, it was originally released as my old TypeAccelerator module that I had previously shared on PowerShell Magazine and posted in the PowerShell Resource Gallery, but then I renamed it and included full documentation for the *-TypeAccelerator commands as well as all of the type extension goodness I described above.  Type acceleration support is a great way to improve the quality of your PowerShell code when you are working with long type names.  Rather than explain it here though, you might want to give my article on PowerShell Magazine a read if you haven’t already since it explains what type acceleration is in more detail and gives examples that show why you might want to know more about it.

To download the latest version of TypePx, please refer to the installation instructions in the readme documentation on GitHub.

That wraps up this article.  Please let me know what you think in the comments!

Now if only PowerShell would properly recognize numeric literals as objects so that you could invoke methods and access properties on them without having to use brackets…

Kirk out.

Watch this space

October 6, 2014 Leave a comment
Categories: PowerShell Tags:

New Technical Product Manager at Provance Technologies

April 30, 2013 2 comments

Today is my first day working in my new role as Technical Product Manager at Provance Technologies.  A little while back Provance approached me to talk about this position, and it seemed like a very natural fit.  Rarely have I felt such a positive vibe from a company through the interview process, so I was really happy to accept the position of Technical Product Manager with them and I have been looking forward to starting work with them.

Now that I am working full-time with Provance, I’ll be getting up to speed as quickly as I can on the IT Asset Management Pack and the Data Management Pack products that we offer to help companies properly manage the assets they have inside their organization.  I know there is already some PowerShell support in one of the products, although I haven’t personally taken a look at it yet (but you can bet I will be soon).

For those of you who regularly follow my blog, if you happen to use either of these products in your organization, I’d love to hear about it.

Kirk out.

Categories: PowerShell, Provance Tags: ,

Hands-on Workshop at the 2013 PowerShell Summit

November 6, 2012 Leave a comment

In my last post I hinted about more news coming soon for the 2013 PowerShell Summit.  In addition to the fantastic list of sessions that attendees will be able to attend, we also have a special event lined up for the last day of the event.  On Wednesday, April 24th, for the entire afternoon attendees will be able to attend a half-day Windows PowerShell scenario walkthrough, presented by the PowerShell Team.

The event will take place on April 24 from 1pm – 5pm.  During this time the PowerShell Team will work with attendees to collectively solve a problem from the ground up using many of the new features in Windows PowerShell 3.0 and Windows Server 2012.

Starting from base Windows Server 2012 images, you will walk through:

  • Writing a PowerShell script workflow to perform Server deployments
  • Creating a constrained endpoint that hosts only the deployment workflow
  • Delegate a set of credentials for the workflow to use
  • Exposing the workflow and it’s results through a RESTful web service
  • Using Windows PowerShell Web Access to manage the workflow

This is a BYOD event, so please don’t forget to bring your own laptop to follow along!

The facilities we have for the conference can only accommodate 50 people at this event.  To give everyone a fair chance to sign up, on December 1st we will send an email from EventBrite to everyone who has already purchased their conference ticket so that they can then sign-up for this free event.  If you want to have a chance to attend this workshop, you will have a much better chance if you buy your ticket before that date!

There will also be other activities that afternoon for those who cannot attend this event due to their travel plans, or if all of the workshop tickets are all gone. If you are able to stick around though and if you can attend this workshop, this should be a fantastic way to end the conference!

Kirk out.

PowerShell Summit Community Sessions List [Updated]

November 2, 2012 9 comments

[Update: April 19, 2013] Important Note: Due to some last minute schedule changes for some of our speakers, several of the sessions below were replaced with other sessions.  To see the final list of sessions offered at the 2013 PowerShell Summit, please visit this page: http://powershell.org/wp/2013/04/19/powershell-summit-2013-conference-schedule/

After almost 100 people voted for the sessions they would like to see the most at the 2013 PowerShell Summit, the results are in!  These votes are for the sessions chosen by the community, and additional sessions from the PowerShell Team will be announced at a later date (as soon as I have them).

Below you will find the not-quite-finalized list of community sessions that will be included in the 2013 PowerShell Summit, sorted alphabetically by speaker.  It is not quite finalized because I am still awaiting final confirmation from a handful of speakers (those marked with an asterisk).  I will update this post as the final confirmations come in.

Thank you to everyone who submitted a session proposal for this conference.  There were a lot of great proposals this year, and I personally think no matter which sessions were voted for, the conference would have been fantastic.  Also thank you to anyone who took the time to vote for their favorite sessions.  Your votes really helped us a lot here, both for the upcoming 2013 conference and for conferences we’ll be planning in the future too!

If you would like to attend this conference so that you can learn from these great sessions and others that are not yet announced, and so that you can participate in the fantastic conversations that happen at such an event, you can purchase your ticket here: http://powershell.org/summit/.

Here is the list of sessions that made the final cut:

Speaker Title Description
June Blender Help for Help: A Help Authoring Deep Dive A comprehensive 400-level talk for module authors about authoring techniques for all types of Windows PowerShell Help, including About help and help for all command types, including cmdlets (and the MAML schema), scripts, functions, CIM commands, workflows (script and XAML), providers (including custom cmdlet help), and snippets. What you can and cannot do, and what’s worth doing when time and resources are short. We’ll cover online help, Updatable Help, and all the gotchas (HelpInfo XML, HelpInfoUri, HelpUri, CHMs), and I’ll share the scripts that I use to generate help files and verify the accuracy of parameters, parameter values, parameter attributes, GUIDs, and URIs.
James Brundage* The Powers of PowerShell Pipeworks Ever wanted to make PowerShell easy for others? Or realize that a simple script you have would be a great backbone of a business (if only you could charge for it)? PowerShell Pipeworks is a web platform built in PowerShell that makes is simple to build compelling web applications and software services in a snap. In this session, you will see: – How to use Pipeworks to store your data to the cloud – How to create a monitoring dashboard with Pipeworks – How to build a Facebook application with PowerShell Pipeworks – How to put a price tag on a cmdlet
Ian Davis Metaprogramming PowerShell PowerShell can be a fun and crazy language to use, but we can take it a step further with metaprogramming. By taking advantage of PowerShell’s flexible language features including dynamic scoping, modules, deferred evaluation, and ScriptBlocks, we can create simple and powerful applications applications leveraging metaprogramming idioms.
Ian Davis Automated Builds With PowerShell Automated builds are a critical part of application lifecycle management. PowerShell is very well suited for making this process easier. We have gone full circle with scripting builds and by leveraging PowerShell on the command line and building DSLs, our builds can be more robust and intuitive than ever.
Adam Driscoll Inside PowerShell: Abstract Syntax Tree Manipulation In this session we will take apart PowerShell. This session will highlight the new abstract syntax tree and node visitor API that is exposed in v3. An instrumentation profiler will be used as an example of how to traverse and manipulate PowerShell scripts from within the engine.
Adam Driscoll .NET Reverse Engineering with PowerShell In this session we will look at how to utilize ILSpy to decompile .NET assemblies and quickly access internal aspects of them using PowerShell. We will see how to easily expose private members for access and manipulation within scripts. Adam Driscoll
Jeffery Hicks Adding a GUI to PowerShell without WinForms Graphical PowerShell scripts seem all the rage these days. But most often that means using Windows Forms which can be very tedious to work with. But that is not the only game in town. Depending on your requirements there are a number of techniques you can use to add graphical elements to your PowerShell scripts. This session will explore how to create message boxes, input forms and more, all without a single Windows Form. If you are just getting started with writing PowerShell scripts, you’ll find these techniques simple to use, plus there will be plenty of sample code for all!
Don Jones Workflow Walkthrough It seems like everyone’s interested in v3’s new Workflow feature, so let’s do a quick walkthrough of building one from scratch. We’ll skip the usual “provisioning” example and go for something a bit more constrained, and perhaps real-world, where workflow’s unique features can really be put to solid use. This’ll also be an opportunity to discuss what workflow can and can’t do, and discuss some of the options and permutations of using it.
Don Jones Remoting Configuration Deep Dive What do you do when Enable-PSRemoting isn’t enough? Dig deeper. We’ll run through all of the major configuration scenarios, including how to use (and not abuse) TrustedHosts, how to set up an HTTPS listener (and use it), how to do non-domain authentication, how to enable CredSSP and configure it to be less than a major security hole, and more. Pretty much every possible Remoting config, we’ll cover. With detailed, step-by-step instructions!
Kirk Munro Creating Add-on Tools for PowerShell ISE PowerShell 3 includes a ton of improvements to the integrated scripting editor, PowerShell ISE. As great as PowerShell ISE is in this version, there is still a lot of room for improvement. Fortunately, Microsoft anticipated that they wouldn’t be able to do everything, so they extended their support for creating Add-on Tools for PowerShell ISE.In this session, the worlds first self-proclaimed Poshoholic and PowerShell MVP Kirk Munro will provide a soup to nuts demonstration of PowerShell ISE Add-on Tools, showing how you can create everything from simple menu extensions to feature rich windows that respond to ISE events and that are docked right inside of the ISE.

Technologies covered in this session include the PowerShell ISE object model, C#, WPF, eventing, Visual Studio 2012, and of course several core PowerShell features.

Kirk Munro Authoring PowerShell like a Poshoholic I’ve been using PowerShell for over 6 years. Blogging about it for over 5 years. Creating and managing products based on PowerShell for about that long as well, and writing a whole lot of scripts during the process. During this time I’ve come up with a trick or three to make that work easier. Some of these tricks are simple time savers, while others are ground breaking opportunities that just might change the way you write PowerShell.Come and join me in this session to get a bird’s eye view at some of the work I’ve been doing with PowerShell, as I talk about tips, tricks, and best practices while demonstrating some of the extensions I’ve written specifically to make authoring with PowerShell easier to do.

Topics discussed include proxy functions, WMI/CIM, Microsoft Office, DSVs, WiX, merge modules, type accelerators, and more.

Aleksandar Nikolic How to Delegate Administration and Customize PowerShell Session Configuration In this session you will learn how to customize PowerShell session configuration, and then use it to assign specific administrative tasks to the appropriate users and groups without changing the membership of local Administrators group. By using new Windows PowerShell and Windows Remote Management 3.0 capabilities we will enable dynamic creation of customized automation environments that users can access through the Windows PowerShell Web Access.
Aleksandar Nikolic Configuring Your Windows PowerShell Workflow Environment In this session you will learn how to set up your environment to run Windows PowerShell workflows. We will discuss different workflow configurations, how to prepare computers to run workflows, what is workflow session configuration and how to customize it. At the end, you will learn how to properly run your Windows PowerShell workflows.
Aleksandar Nikolic Build Your Demo Environment or a Test Lab with Windows PowerShell With Windows PowerShell 3.0 and the new Client Hyper-V available in Windows 8, it is so easy, and fun, to automate creation of your demo environment or a test lab infrastructure. You can easily convert ISO files to VHDs, deploy your VMs and configure networking and storage. Join us for this demo-heavy session to see all the steps.
Alan Renouf Creating a complex and reusable HTML reporting structure In this session I will show you the shortcuts and tricks picked up when creating a complex reporting structure with PowerShell, how a simple HTML output script grew to be a reporting structure which can adapt to give detailed, nicely formatted reports on any application or system that has a PowerShell interface, and even some that don’t!
Alan Renouf Practical PowerShell Integration from Bare Metal to the Cloud See how PowerShell can be used as the glue of the datacenter, take information from VMware, Cisco and Microsoft, Glue them all together and go from bare metal up to the cloud and beyond. Learn how PowerShell is now expanding to be the language of choice and how Microsoft and third party products can be tied together to create fantastic solutions.
Andy Schneider PowerShell and Source Control for the IT Pro Are you ever concerned about updating a script, having it break, and can’t remember what you changed. This is source control by an IT Pro for IT Pros. Come check out some best practices and lessons learned on how to incorporate source control as part of writing scripts. Learn how to have your code available via the web and easily accessed on multiple machines. We’ll take a look at using GIT to ensure your code is always up to date and you can always get back to where you were if you break something.
Andy Schneider PowerShell and Active Directory This session will provide a quick overview of different options to manage AD using PowerShell. It will quickly jump into some of the shortcomings of the MSFT provided Active Directory module and how to work around them, and even “fix” them using proxy functions and the new Default Parameter Set feature in V3.
Richard Siddaway CIM sessions The introduction of the CIM cmdlets and “cmdlets over objects” in PowerShell v3 provide new ways to work with WMI. In addition, they bring a new way to access remote systems ? CIM sessions. Analogous to PowerShell remoting sessions they provide a new flexibility when working with WMI and remote machines. This session will demonstrate:
– How to use CIM sessions against systems running PowerShell v3
– How to work with legacy installations of PowerShell v2
– How to use the available CIM session options to configure the session to meet your requirements
– Compare and contrast working with WMI, CIM and WSMAN cmdlets against remote machines to illustrate the strengths and weaknesses of each
– How to mix and match CIM sessions using WSMAN and DCOM.The key takeaways from this session will be:
– The CIM cmdlets provide a new way to access WMI
– WSMAN is required knowledge
– WSMAN and DCOM can both be used with the CIM cmdlets
– CIM sessions are easy to use and very powerful
– No more DCOM problems
Richard Siddaway PowerShell Web Access PowerShell Web Access is a new feature in Windows Server 2012 that provides a web based PowerShell console. You don’t need PowerShell on your client to administer remote machines as long as you have PWA. This session will demonstrate how to configure PWA, its strengths and weaknesses – you might even see PowerShell being accessed from a non-Windows machine! The security implications of PWA will be discussed. PWA will be compared to other ways to access remote machines through PowerShell including PS Remoting and CIM sessions.
Richard Siddaway PowerShell events The PowerShell event engine enables you to work with .NET; WMI and PowerShell engine events. What are these and how do they work? What can I do with them? Want to stop a process that shouldn’t be running? Want to start a process that’s stopped? That’s what this session will show you with PowerShell events.
Ed Wilson Write modules, not scripts Learn how to get the most from Windows PowerShell by learning a simple five-step method to transform your Windows PowerShell code into a highly reusable module. This presentation is a live demo that begins with a single line of Windows PowerShell code, transforms the code into a function, adds comment based help to the function, and converts it into a module. Next, the installation and discovery of Windows PowerShell modules is covered, as is updating the module and creating a Windows PowerShell module manifest. Ed Wilson
Ed Wilson What I learned by grading 2000 PowerShell Scripts in the 2012 Scripting Games The 2012 Scripting Games attracted both experienced and novice scripters from more than 100 countries around the world. In grading the 2000 submitted scripts, I noticed a common theme emerged. Some of the things that were consistently confused by both beginners and advanced scripters include the following: failure to return objects from functions, not creating reusable functions, spending too much duplicating capabilities of native PowerShell, using meaningless comments, omission of error handling, and an overreliance on Write-Host. In this session, I will address each of these areas of concern and show both good and bad examples from the games. A thorough discussion of each of these topics rounds out the presentation. This presentation uses live demos to illustrate the techniques that are discussed. Ed Wilson
Ed Wilson PoshMon: PowerShell does performance counters One of the cool features on Windows PowerShell 3.0 is easy consumption of WMI performance counters into Windows PowerShell. In the past, leveraging these performance counters meant writing long lines of cryptic code, calling refresher objects, and dealing with weird timestamp issues. But no more! Using a simple cmdlet, Windows PowerShell throws open the door to the treasure trove of performance counter information. But where does the oversubscribed IT pro begin? A question on my Windows NT 3.51 MCSE exam stated there are four areas for performance monitoring: disk, memory, network, and CPU. These four resources have not changed much, regardless of the application these basic areas of investigation still ring true. In this session, I talk about discovering performance counters, using performance counters, and storing information gathered from performance counters. The talk will be strengthened by live demos at each stage of the presentation.
Matt Wrock* Unit Testing PowerShell This talk will provide a walk through of Unit Testing PowerShell scripts. The OSS project Pester (https://github.com/pester/Pester) will be used to illustrate popular unit testing patterns such as ArrangeActAssert and Mocking to provide testability to PowerShell. There will be discussion on why and when to use unit testing in PowerShell as well.

Keep an eye on my blog for additional news about this conference, because more exciting news is on the way!

Thanks,

Kirk out.

Follow

Get every new post delivered to your Inbox.

Join 1,913 other followers

%d bloggers like this: