• Native support for the PowerShell 2.0 debugger, including command-line management of breakpoints using Disable-PSBreakpoint, Enable-PSBreakpoint, Get-PSBreakpoint, Remove-PSBreakpoint and Set-PSBreakpoint;
• Advanced breakpoint support such as command and variable breakpoints through the PSBreakpoint cmdlets;
• $MyInvocation support in scripts that you are debugging (this has been an issue we have wanted to fix for a long time)
• Start-Job and Invoke-Command support in scripts that you are debugging (this was another issue that had to be worked around that is fixed by the new debugger);

This is the first public beta that we have had in a while, so I want to make sure everyone interested knows how the beta works.  It’s a pretty straightforward process, as follows:

1. If you are interested in trying out the beta, go to the beta download page and follow the instructions to download and install the beta.  If you are using PowerGUI 2.1.1, it will automatically be upgraded when you install the beta.
2. Use the beta just like you would use the previous version of PowerGUI.
3. If you run into any issues, please notify us on the PowerGUI 2.2 public beta forum.

That’s pretty much it.  I should also note that auto-update from the beta version of PowerGUI 2.2 to the RTM version of PowerGUI 2.2 will be supported.

We’re looking forward to your feedback, so please download the beta and let us know what you think!

Kirk out.

Share this post:

…select all of my files and open them at one time; or

…turn on line/word wrap?

How about if it would allow you to…

…view white space characters (tabs and spaces); or

…move the cursor through the whitespace outside of a document while you edit the same column in multiple lines in your script; or

…zoom in or out using Ctrl+Add or Ctrl+Subtract so that you can adjust the font as necessary during presentations?

Some of these features were requested by members of our community, and others are features that I have wished for at one point or another.  As of today you can get all of these features in the PowerGUI Script Editor by simply downloading and installing the Script Editor Essentials Add-on!

How do I do that you ask?  Simply visit the Script Editor Essentials Add-on page and follow the installation instructions.  It shouldn’t take more than a few minutes to set up.  Once you have it set up, you can start using the new features right away.  For example, to enable the new features that affect your open documents, take a look at the new menu items in the Edit | Advanced menu:

That menu allows you to enable the view white space, word wrap, or virtual white space features.  If you enable view white space, you’ll see tabs appear as arrows and spaces appear as dots, like in this screenshot:

You can also turn on word wrap, which is great when working with documents that contain long lines of PowerShell script (unless you like scrolling back and forth horizontally when reading script lines).  It even shows a small arrow at the end of any lines that are wrapped, making it easier to distinguish between lines that wrap and lines that don’t:

All of these features can be turned on at the same time, allowing you to customize your experience for your needs, and the configuration is saved so that it persists between sessions.  Here’s another screenshot showing the virtual white space feature, which allows you to place the cursor anywhere on any line (normally you cannot place the cursor beyond the end of a line):

This feature can come in quite handy when you are modifying script on multiple lines in a similar column position, and when those lines aren’t necessarily adjacent to one another (I’ve had this experience which made me wish for this feature myself).

Do you ever show PowerShell to others, either via the web using desktop sharing or LiveMeeting or perhaps during presentations?  Being able to zoom in and zoom out on the fly can be useful if you do, so you may like these new menu items:

They will increase or decrease the font size in the open documents as well as in the embedded PowerShell console by 1.  You can do this without this Add-on today by using Ctrl while moving your mouse wheel, but it is can be very difficult to control depending on your mouse sensitivity and it increases or decreases the font size by 10% instead of by a fixed value, plus it sets all fonts to the same font, which may not give you the results you are looking for (if you use the Blue Console Add-on, it applies a different font to the embedded console window).  The keyboard shortcuts for these menu items are very useful to learn if you ever show PowerShell to anyone while using the PowerGUI Script Editor.

And last, but not least, I have wanted to have multi-select support in the File Open dialog for a long time.  That support is now available, and while I was adding it I also flushed out the list of file extensions to include all PowerShell file extensions plus other extensions commonly used with PowerShell.  Here’s what that looks like once this Add-on is installed (you can click on the image to see it full size):

I would really appreciate any feedback that you would like to share on this (or any other) Script Editor Add-on.  I’ve called this Script Editor Essentials because it contains a variety of general editor features that I think are essential for anyone using the PowerGUI Script Editor without being tied to a specific need.  That doesn’t mean it contains everything that is essential though, and there are a lot of other Script Editor Add-ons available that you should take a look at to see the other options available to you to enhance your script editing experience.  What features would you consider essential to you as you work with PowerShell files in the Script Editor that are not yet available in the core product or as an Add-on?  Let me know in the comments or on the PowerGUI Forums so that we can make sure we’re meeting your needs.

Also, I would be remiss if I didn’t point out that this Add-on, as well as all other Add-ons, are created using PowerShell modules.  There’s even an Add-on Authoring Toolkit that makes it easier to create Script Editor Add-ons, along with a tutorial showing you how you can create your own Add-ons!  Creating an Add-on can be pretty easy to do, so don’t be afraid to give it a try and use the PowerGUI Forums to ask questions as needed.

Hopefully this will be a useful and welcome addition to your PowerGUI experience.  Enjoy!

Kirk out.

Share this post:

]]> http://poshoholic.com/2010/07/29/powergui-script-editor-essentials/feed/ 0 Poshoholic ScriptEditorEssentials.EditAdvancedMenuExtensions.png ScriptEditorEssentials.ViewWhiteSpace.png ScriptEditorEssentials.WordWrap.png ScriptEditorEssentials.VirtualWhiteSpace.png ScriptEditorEssentials.ViewMenu.png ScriptEditorEssentials.FileOpen http://poshoholic.com/2010/07/15/vmware-infrastructure-management-powerpack-now-with-visio-2010-support/ http://poshoholic.com/2010/07/15/vmware-infrastructure-management-powerpack-now-with-visio-2010-support/#comments Fri, 16 Jul 2010 02:57:30 +0000 Kirk Munro https://kirkmunro.wordpress.com/2010/07/15/vmware-infrastructure-management-powerpack-now-with-visio-2010-support/ ]]> Tonight I have published a new version of the VMware Infrastructure Management PowerPack.  This release (version 2.4.0) is the first release that provides near 100% feature parity between both PowerGUI and the Virtualization EcoShell.  I say near 100% feature parity because PowerGUI supports displaying progress dialogs during calls to Write-Progress but the Virtualization EcoShell does not, so PowerGUI users have a minor leg up over the Virtualization EcoShell experience.  Depending on what environment you are coming from, you will notice some of the following improvements to this PowerPack:

• Visio 2010 support for vDiagram functionality
• Charts for virtual machines, datastores, and resource configuration data
• Progress bars during the rendering of diagrams created with the vDiagram functionality
• Improved layout in the nodes in the tree
• Simplified connection logic, making it easier for you to reuse scripts generated by the PowerPack
• Additional minor bug fixes

Note that version 4.1 of the VMware PowerCLI is not supported with this release at this time, due to a number of issues.  For now the only supported version of the VMware PowerCLI is version 4.0 U1.

If you are an existing user of this PowerPack, you will automatically get notified about the new version.  If you haven’t looked at this PowerPack yet and you manage VMware vSphere, Virtual Center, ESX, or ESXi hosts, I strongly encourage you to give this PowerPack a try.  You can download it here.  It provides an excellent management experience over those VMware hosts, and it’s free!

As usual, many of the enhancements we add in these releases are based on customer feedback on the PowerGUI Forums.  If you’d like to see more improvements to this PowerPack, please speak up and let us know on the forums.  We’re always listening!

Kirk out.

Share this post:

With version 4.1 of the PowerCLI, the VMware team has changed the namespaces used in the object model behind the PowerCLI.  The objects themselves have stayed the same, but the namespaces have changed.  This change has a number of impacts once PowerCLI 4.1 is installed, including but not limited to the following:

• Any PowerShell function that uses strongly typed parameter names with the VMware PowerCLI 4.0 or earlier type names will no longer function properly without an update.
• Any PowerShell script that uses the is or as operators with the VMware PowerCLI 4.0 or earlier type names type names will no longer function properly without an update.
• Any PowerGUI extensions (read: PowerPacks) written for PowerCLI 4.0 or earlier will no longer function properly without an update.
• Any PowerShell scripts that use the VMware PowerCLI 4.0 or earlier type names inside of Add-Type calls will no longer function properly.

In general, any code or script written that is dependent on these type names will have issues once you upgrade to PowerCLI 4.1.  It also means that once these items that don’t work with 4.1 are updated, they may no longer work with PowerCLI 4.0 and earlier.  Also note that these are just PowerShell-related impacts.  If you’re using other languages to manage or automate VMware you need to be aware of the impacts for those languages as well.

Here are a few PowerShell-specific examples of the impact of these breaking changes:

1. The PowerCLI Community Extensions won’t work with PowerCLI 4.1 until they have been updated, and once they have been updated they will not work with PowerCLI 4.0 and earlier as long as they continue to use strongly typed parameter names (which they should).
2. Scripts on PoshCode like this one and this one will suffer the same fate since they use strongly typed parameters in the advanced functions.
3. Blog posts like this one from Glenn Sizemore and this one by Maish Saidel-Keesing will only work with PowerCLI 4.0 and earlier unless they are updated.
4. The VMware Infrastructure PowerPack for PowerGUI and the Virtualization EcoShell will return data from the nodes, however actions will not appear and icons and charts will not show up in the grid.
5. The VMware Community PowerPack for PowerGUI and the Virtualization EcoShell will return data from the nodes, however actions will not appear and icons and charts will not show up in the grid.
6. Any blog posts that mentions PowerCLI object types will now be out of date.
7. Books like this one will contain examples that are now broken.

As you can see, the PowerCLI 4.1 release comes with changes that are pretty far reaching, and they are definitely going to cause confusion in the community.  Unfortunately, since these changes are now in the wild, we’re at a fork in the road where some community contributions will only support 4.0 and earlier for a while and others, as they start supporting 4.1 and later, may only support 4.1 and later depending on how they add that support.  Changes like this are never fun, so please be aware of these changes when considering when to upgrade PowerCLI in your environment.

As far as the PowerPack issues go, we will add support for the PowerCLI 4.1 release to the VMware Infrastructure PowerPack soon, but it will take a little while for us to work out the details and do the appropriate testing.  Until then, please don’t upgrade the PowerCLI on your systems where you use the VMware Infrastructure PowerPack.

Thanks,

Kirk out.

Share this post:

A recording of the webinar is now available, so if you missed catching it live you can go here and watch it at your leisure.  You won’t be able to ask questions during the presentation of course, but that’s what the comments on this blog and the PowerGUI Forums are for.

Enjoy!

Kirk out.

Share this post:

For example, let’s take a look at how you might use Get-Member to see what you can do with Win32_BIOS objects, like this:

Get-WmiObject Win32_BIOS | Get-Member

That command yields the following results:

   TypeName: System.Management.ManagementObject#root\cimv2\Win32_BIOS

Name                  MemberType   Definition
—-                  ———-   ———-
BiosCharacteristics   Property     System.UInt16[] BiosCharacteristics {get;set;}
BIOSVersion           Property     System.String[] BIOSVersion {get;set;}
BuildNumber           Property     System.String BuildNumber {get;set;}
Caption               Property     System.String Caption {get;set;}
CodeSet               Property     System.String CodeSet {get;set;}
CurrentLanguage       Property     System.String CurrentLanguage {get;set;}
Description           Property     System.String Description {get;set;}
IdentificationCode    Property     System.String IdentificationCode {get;set;}
InstallableLanguages  Property     System.UInt16 InstallableLanguages {get;set;}
InstallDate           Property     System.String InstallDate {get;set;}
LanguageEdition       Property     System.String LanguageEdition {get;set;}
ListOfLanguages       Property     System.String[] ListOfLanguages {get;set;}
Manufacturer          Property     System.String Manufacturer {get;set;}
Name                  Property     System.String Name {get;set;}
OtherTargetOS         Property     System.String OtherTargetOS {get;set;}
PrimaryBIOS           Property     System.Boolean PrimaryBIOS {get;set;}
ReleaseDate           Property     System.String ReleaseDate {get;set;}
SerialNumber          Property     System.String SerialNumber {get;set;}
SMBIOSBIOSVersion     Property     System.String SMBIOSBIOSVersion {get;set;}
SMBIOSMajorVersion    Property     System.UInt16 SMBIOSMajorVersion {get;set;}
SMBIOSMinorVersion    Property     System.UInt16 SMBIOSMinorVersion {get;set;}
SMBIOSPresent         Property     System.Boolean SMBIOSPresent {get;set;}
SoftwareElementID     Property     System.String SoftwareElementID {get;set;}
SoftwareElementState  Property     System.UInt16 SoftwareElementState {get;set;}
Status                Property     System.String Status {get;set;}
TargetOperatingSystem Property     System.UInt16 TargetOperatingSystem {get;set;}
Version               Property     System.String Version {get;set;}
__CLASS               Property     System.String __CLASS {get;set;}
__DERIVATION          Property     System.String[] __DERIVATION {get;set;}
__DYNASTY             Property     System.String __DYNASTY {get;set;}
__GENUS               Property     System.Int32 __GENUS {get;set;}
__NAMESPACE           Property     System.String __NAMESPACE {get;set;}
__PATH                Property     System.String __PATH {get;set;}
__PROPERTY_COUNT      Property     System.Int32 __PROPERTY_COUNT {get;set;}
__RELPATH             Property     System.String __RELPATH {get;set;}
__SERVER              Property     System.String __SERVER {get;set;}
__SUPERCLASS          Property     System.String __SUPERCLASS {get;set;}
PSStatus              PropertySet  PSStatus {Status, Name, Caption, SMBIOSPresent}
ConvertFromDateTime   ScriptMethod System.Object ConvertFromDateTime();
ConvertToDateTime     ScriptMethod System.Object ConvertToDateTime();

That’s a pretty good list of 40 members, but there are actually many more that you might like to see as well.  For example, it can be useful to see the different member sets available on an object as well as any get_ and set_ methods that object has.  You can see that information by using the –Force parameter with Get-Member.  It can also be useful to see any hidden members that an object has, whether they come from the base member set, extended member set, or adapted member set.  To see all of these hidden members, you can use the –View parameter and specify you want to see members from All views.  When you put the –Force and –View parameters together, you end up with the following command:

Get-WmiObject Win32_BIOS | Get-Member -Force -View All

Running that command yields the following results:

   TypeName: System.Management.ManagementObject#root\cimv2\Win32_BIOS

Name                      MemberType            Definition
—-                      ———-            ———-
pstypenames               CodeProperty          System.Collections.ObjectModel.Collection`1[[System.String, mscorlib...
Disposed                  Event                 System.EventHandler Disposed(System.Object, System.EventArgs)
psadapted                 MemberSet             psadapted {__GENUS, __CLASS, __SUPERCLASS, __DYNASTY, __RELPATH, __P...
psbase                    MemberSet             psbase {Scope, Path, Options, ClassPath, Properties, SystemPropertie...
psextended                MemberSet             psextended {ConvertToDateTime, ConvertFromDateTime, PSStatus}
psobject                  MemberSet             psobject {Members, Properties, Methods, ImmediateBaseObject, BaseObj...
PSStandardMembers         MemberSet             PSStandardMembers {DefaultDisplayPropertySet}
add_Disposed              Method                System.Void add_Disposed(System.EventHandler value)
Clone                     Method                System.Object Clone()
CompareTo                 Method                bool CompareTo(System.Management.ManagementBaseObject otherObject, S...
CopyTo                    Method                System.Management.ManagementPath CopyTo(System.Management.Management...
CreateObjRef              Method                System.Runtime.Remoting.ObjRef CreateObjRef(type requestedType)
Delete                    Method                System.Void Delete(), System.Void Delete(System.Management.DeleteOpt...
Dispose                   Method                System.Void Dispose()
Equals                    Method                bool Equals(System.Object obj)
Get                       Method                System.Void Get(), System.Void Get(System.Management.ManagementOpera...
GetHashCode               Method                int GetHashCode()
GetLifetimeService        Method                System.Object GetLifetimeService()
GetMethodParameters       Method                System.Management.ManagementBaseObject GetMethodParameters(string me...
GetPropertyQualifierValue Method                System.Object GetPropertyQualifierValue(string propertyName, string ...
GetPropertyValue          Method                System.Object GetPropertyValue(string propertyName)
GetQualifierValue         Method                System.Object GetQualifierValue(string qualifierName)
GetRelated                Method                System.Management.ManagementObjectCollection GetRelated(), System.Ma...
GetRelationships          Method                System.Management.ManagementObjectCollection GetRelationships(), Sys...
GetText                   Method                string GetText(System.Management.TextFormat format)
GetType                   Method                type GetType()
get_ClassPath             Method                System.Management.ManagementPath get_ClassPath()
get_Container             Method                System.ComponentModel.IContainer get_Container()
get_Item                  Method                System.Object get_Item(string propertyName)
get_Options               Method                System.Management.ObjectGetOptions get_Options()
get_Path                  Method                System.Management.ManagementPath get_Path()
get_Properties            Method                System.Management.PropertyDataCollection get_Properties()
get_Qualifiers            Method                System.Management.QualifierDataCollection get_Qualifiers()
get_Scope                 Method                System.Management.ManagementScope get_Scope()
get_Site                  Method                System.ComponentModel.ISite get_Site()
get_SystemProperties      Method                System.Management.PropertyDataCollection get_SystemProperties()
InitializeLifetimeService Method                System.Object InitializeLifetimeService()
InvokeMethod              Method                System.Object InvokeMethod(string methodName, System.Object[] args),…
Put                       Method                System.Management.ManagementPath Put(), System.Management.Management…
remove_Disposed           Method                System.Void remove_Disposed(System.EventHandler value)
SetPropertyQualifierValue Method                System.Void SetPropertyQualifierValue(string propertyName, string qu…
SetPropertyValue          Method                System.Void SetPropertyValue(string propertyName, System.Object prop…
SetQualifierValue         Method                System.Void SetQualifierValue(string qualifierName, System.Object qu…
set_Item                  Method                System.Void set_Item(string propertyName, System.Object value)
set_Options               Method                System.Void set_Options(System.Management.ObjectGetOptions value)
set_Path                  Method                System.Void set_Path(System.Management.ManagementPath value)
set_Scope                 Method                System.Void set_Scope(System.Management.ManagementScope value)
set_Site                  Method                System.Void set_Site(System.ComponentModel.ISite value)
ToString                  Method                string ToString()
Item                      ParameterizedProperty System.Object Item(string propertyName) {get;set;}
BiosCharacteristics       Property              System.UInt16[] BiosCharacteristics {get;set;}
BIOSVersion               Property              System.String[] BIOSVersion {get;set;}
BuildNumber               Property              System.String BuildNumber {get;set;}
Caption                   Property              System.String Caption {get;set;}
ClassPath                 Property              System.Management.ManagementPath ClassPath {get;}
CodeSet                   Property              System.String CodeSet {get;set;}
Container                 Property              System.ComponentModel.IContainer Container {get;}
CurrentLanguage           Property              System.String CurrentLanguage {get;set;}
Description               Property              System.String Description {get;set;}
IdentificationCode        Property              System.String IdentificationCode {get;set;}
InstallableLanguages      Property              System.UInt16 InstallableLanguages {get;set;}
InstallDate               Property              System.String InstallDate {get;set;}
LanguageEdition           Property              System.String LanguageEdition {get;set;}
ListOfLanguages           Property              System.String[] ListOfLanguages {get;set;}
Manufacturer              Property              System.String Manufacturer {get;set;}
Name                      Property              System.String Name {get;set;}
Options                   Property              System.Management.ObjectGetOptions Options {get;set;}
OtherTargetOS             Property              System.String OtherTargetOS {get;set;}
Path                      Property              System.Management.ManagementPath Path {get;set;}
PrimaryBIOS               Property              System.Boolean PrimaryBIOS {get;set;}
Properties                Property              System.Management.PropertyDataCollection Properties {get;}
Qualifiers                Property              System.Management.QualifierDataCollection Qualifiers {get;}
ReleaseDate               Property              System.String ReleaseDate {get;set;}
Scope                     Property              System.Management.ManagementScope Scope {get;set;}
SerialNumber              Property              System.String SerialNumber {get;set;}
Site                      Property              System.ComponentModel.ISite Site {get;set;}
SMBIOSBIOSVersion         Property              System.String SMBIOSBIOSVersion {get;set;}
SMBIOSMajorVersion        Property              System.UInt16 SMBIOSMajorVersion {get;set;}
SMBIOSMinorVersion        Property              System.UInt16 SMBIOSMinorVersion {get;set;}
SMBIOSPresent             Property              System.Boolean SMBIOSPresent {get;set;}
SoftwareElementID         Property              System.String SoftwareElementID {get;set;}
SoftwareElementState      Property              System.UInt16 SoftwareElementState {get;set;}
Status                    Property              System.String Status {get;set;}
SystemProperties          Property              System.Management.PropertyDataCollection SystemProperties {get;}
TargetOperatingSystem     Property              System.UInt16 TargetOperatingSystem {get;set;}
Version                   Property              System.String Version {get;set;}
__CLASS                   Property              System.String __CLASS {get;set;}
__DERIVATION              Property              System.String[] __DERIVATION {get;set;}
__DYNASTY                 Property              System.String __DYNASTY {get;set;}
__GENUS                   Property              System.Int32 __GENUS {get;set;}
__NAMESPACE               Property              System.String __NAMESPACE {get;set;}
__PATH                    Property              System.String __PATH {get;set;}
__PROPERTY_COUNT          Property              System.Int32 __PROPERTY_COUNT {get;set;}
__RELPATH                 Property              System.String __RELPATH {get;set;}
__SERVER                  Property              System.String __SERVER {get;set;}
__SUPERCLASS              Property              System.String __SUPERCLASS {get;set;}
PSStatus                  PropertySet           PSStatus {Status, Name, Caption, SMBIOSPresent}
ConvertFromDateTime       ScriptMethod          System.Object ConvertFromDateTime();
ConvertToDateTime         ScriptMethod          System.Object ConvertToDateTime();

That result set shows 99 members, which is a lot more than the 40 members you get to see by default!

As you can see, there is a lot more to these objects than meets the eye.  Using Get-Member with –Force and –View All is a great way to get all of the information you need about objects so that you really know what your objects contain and are capable of.

Kirk out.

Share this post :

Due to popular demand, Adam Driscoll has just released Beta 1 of his PowerGUI Visual Studio (aka PowerGUI VSX) project!

If you missed my blog about this last week and don’t know what this product is, it’s an extension for Visual Studio that adds PowerGUI’s editor with Intellisense, syntax highlighting and snippets for PowerShell script files to Visual Studio!  This can make it much easier to create PowerShell scripts or modules if you’re already working inside Visual Studio.

You can learn all about this great project and download the beta release by going to the PowerGUI VSX page on CodePlex now!

This project requires that the following prerequisites be installed first:

• Visual Studio 2010
• PowerGUI

Please share any feedback you have for this release in the comments on this blog, on the CodePlex site itself, or on the PowerGUI forums.

Enjoy!

Kirk out.

Share this post:

Here’s something really cool for all the developer types out there.  Adam Driscoll, one of the developers here at Quest Software, is working on an extension for Visual Studio 2010 that integrates PowerGUI Script Editor functionality into the Visual Studio 2010 IDE!  It’s not released yet, but you can learn more about it on the PowerGUI VSX site on CodePlex.  Here’s a teaser screenshot to whet your tastebuds:

I’d love to hear your feedback on this, so please leave comments and let me know if this is of interest to you or not.

Thanks,

Kirk out.

Share this post:

Aside from the great performance improvements that were made in the Script Editor, not to mention the Charts and custom HTML support in the administrative console, there’s one particular feature that really grabbed my attention in this release: we now have a documented and supported SDK for the PowerGUI Script Editor!  This is great news because up to this point the only extensions that were possible were in the administrative console where you could create PowerPacks.  Now with 2.1 available anyone can create extensions for the Script Editor that add really cool functionality to it as well!

The screenshots I was blogging about a few weeks ago showed some of the Add-ons that I have been working on, and I just started publishing some of those Add-ons in the Script Editor Add-on category on PowerGUI.org.  These Add-ons are just PowerShell modules so you can see exactly how they work by opening the module files in the Script Editor.  With Add-ons, not only do you get the features that were implemented in the core product, you now get to pick and choose additional features that you want as they become available by installing Add-ons.

What sort of things can you do with Add-ons?  Well, for starters you can sign your script files:

publish scripts online:

or change your embedded PowerShell Console to blue:

If that inspires you, you can also try creating your own Add-on:

And if you want to learn more about how you can create an Add-on, there’s even a tutorial available to help get you started.

There are some other useful Add-ons available right now, and more are in development so check the Script Editor Add-on category often to see what has been recently published.

If there are Add-ons you would like to see developed but you aren’t comfortable creating them yourself, share the ideas on our forums so that others can step up and help you out (or maybe even create the Add-on for you).

The Script Editor SDK that was added to this release is brand new to the PowerGUI product and we would love to hear your feedback on it.  Please speak up and let us know what you think about the SDK, the Add-ons we have made available so far, or anything else related to PowerGUI.  We’re always listening.

Thanks and happy scripting!

Kirk out.

Share this post:

That’s not the only features that I’ll be talking about though…here’s another teaser screenshot showing you something else you’ll be able to do in the PowerGUI Script Editor really, really soon: Script Signing!

If you’d like to hear more about PowerGUI and what we’ve been up to, come by the 30 minute Q&A session on Monday.  Or, if you can’t make that session track down myself or Dmitry or head over to the Quest booth in the partner expo and ask for a demo of PowerGUI at any time.  I’d love to hear how you’re using PowerShell and PowerGUI and show you some of the new features that I haven’t shared here yet.

See you in New Orleans!

Kirk out.

P.S. I’m not literally taking the train down to New Orleans (although that would be really fun), but I am bringing PowerGUI with me on my laptop.  Maybe after the PowerShell market grows a little more I’ll be able to convince Quest to have a locomotive built for PowerGUI that we can use when travelling to events like Tech·Ed!

P.P.S. If you’re not going to Tech·Ed but you want to share how you’re using PowerShell and PowerGUI with me anyway, drop me a line anytime and tell me about it, or just share it on our forums!

Share this post :

And if you missed the cool Rock-Paper-Scissors support as well, go check out Tuesday’s blog post!

More to come!

Kirk out.

Share this post:

I’ve been really quiet lately while I’ve been focused on a bunch of fun projects that I’ve been working on for the next release of PowerGUI.  That release isn’t available just yet (soon though – watch this space!), but I can start sharing a few teasers to whet your appetites in the meantime.  Here’s a screenshot to share a little bit of what I’ve been working on recently:

That’s right, it’s Rock-Paper-Scissors for Windows PowerShell!  No, no, that’s not it…look at the cool blue console with the transparent effect applied to it.

Some neat things like this and more are coming your way soon in PowerGUI!

Kirk out.

Share this post:

PowerGUI has gone Pro!

You’re favorite PowerShell engine is now available in a cool new package.  PowerGUI Pro has all of the same great features that you know and love from PowerGUI Freeware plus it allows you to:

• Use PowerShell from your favorite mobile device with MobileShell!
• Protect your scripts using integrated version control!

All that and you get full commercial support from Quest Software to boot!

If you hurry you can buy it for only $99/user for the first 60 days.  After that, it will return to the regular price of $199/user.

Want to learn more?  You can read all about it here:

http://www.quest.com/PowerGUIPro

If you have any questions or want to learn more, feel free to leave a comment or post your question on our forums.

Thanks,

Kirk out.

Share this post:

Is strong typing important to you when you write your scripts?

If that question is confusing to you, then you likely aren’t really writing any scripts complex enough that you need to know how to create generics just yet, or maybe you are and there are bugs in your scripts that you just don’t know about.  Regardless, you likely haven’t developed a really strong need for them yet.  But, if you know what strong typing is and the advantages it provides in terms of script readability and in terms of easier script troubleshooting / debugging due to automatic type checking then it would be worthwhile for you to understand how generics can benefit you as well.

An example may help illustrate the benefits you’ll get when using generics.  For this example, keep in mind it may not be that realistic, but I have seen people do similar things and scratch their head wondering what was going on when it didn’t work the way they thought it would.  For this example lets say you wanted a table of something, we’ll use modules, where you could look them up quickly by name.  Maybe you’ve heard of hash tables / associative arrays, so you try something like this:

PS C:\> $moduleTable = @{}
PS C:\> Get-Module -ListAvailable | ForEach-Object {$moduleTable[$_] = $_}

No errors were returned, so you want to check if it worked.  You try to show the module table you built using PowerShell:

PS C:\> $moduleTable
Name                           Value
—-                           —–
PSDiagnostics                  PSDiagnostics
CmdletDesigner                 CmdletDesigner
TroubleshootingPack            TroubleshootingPack
AppLocker                      AppLocker
BitsTransfer                   BitsTransfer
WebAdministration              WebAdministration
AdminConsole                   AdminConsole
Class                          Class

That looks right, sort of, so you then try accessing one of the module table values:

PS C:\> $moduleTable.WebAdministration
PS C:\> $moduleTable['WebAdministration']
PS C:\>

That’s no good, something isn’t working right at all.  If you’ve learned at some point that hash tables can contain any type of value as their key you might have an idea what the problem is here, but if not this can be really puzzling and it’s time to revisit hash tables 101.  A hash table is a dictionary that associates an object of any type to an object of any other type.  In the case of a hash table though, both types are generic objects (*not* to be confused with generics), so you can mix key types and value types as you wish, like this:

PS C:\> [System.Reflection.Assembly]::LoadWithPartialName(‘System.Drawing’)
PS C:\> $mixedUpMotherGoose = @{}
PS C:\> $mixedUpMotherGoose[1] = ‘One’
PS C:\> $mixedUpMotherGoose['Two'] = 2
PS C:\> $mixedUpMotherGoose['Red'] = [System.Drawing.Color]::Red
PS C:\> $mixedUpMotherGoose[[System.Drawing.Color]::Blue] = ‘Blue’
PS C:\> $mixedUpMotherGoose
Name                           Value
—-                           —–
Color [Blue]                   Blue
Red                            Color [Red]
Two                            2
1                              One

Accessing values in tables like this can be challenging, as can be shown here:

PS C:\> $mixedUpMotherGoose.$([int]1)
One
PS C:\> $mixedUpMotherGoose.Two
2
PS C:\> $mixedUpMotherGoose.Red
R             : 255
G             : 0
B             : 0
A             : 255
IsKnownColor  : True
IsEmpty       : False
IsNamedColor  : True
IsSystemColor : False
Name          : Red
PS C:\> $mixedUpMotherGoose.$([System.Drawing.Color]::Blue)
Blue

In many cases though, when you are creating a hash table you know the type of association (or rather, the types you want to associate) ahead of time.  You can use the generic hash table (again, this is generic in terms of the objects used inside the hash table and is not to be confused with generics) and many times this will be sufficient for what you want to do.  But if you know the type of association ahead of time, wouldn’t it be great if you could ask PowerShell to watch your back and make sure that the objects you place into your hash table are of the correct type, and to let you know via an error if ever they are not so that you will have one less thing to worry about when you are debugging your script?  Or wouldn’t it be great if you could define your collection with strong typing in mind so that later someone else who works with the same scripts you do doesn’t come along and put other associations of different types into your collection, which may break the logic in your script?  Enter generics.

Generics are collections that have strong type associations enforced by the language itself (in this case, PowerShell).  Depending on your perspective, you may think of them as type-specific collections (or “specifics” as Hal Rottenberg jokingly refers to them) instead of as generics because they enforce strong typing on any items added to the collection once they are created.  System.Collections.Generic.Dictionary is a generic collection that allows you to create strongly typed System.Collections.HashTable’s.  System.Collections.Generic.List is a generic collection that allows you to create strongly typed System.Collections.ArrayList’s.  These collections are generic in the sense that they can be applied generically to any object type resulting in the ability to create strongly-typed collections.  This allows you get all the advantages that strong typing provides in your collections just like you do when you create strongly-typed variables (script readability and easier troubleshooting/debugging, remember?).

Let’s see what this means for PowerShell and the example that we looked at earlier.  To create a table of modules where we can easily look up any module with its string representation (which is its name), we can define a generic dictionary that associates System.String to System.Management.Automation.PSModuleInfo.  We need to be careful and make sure we set the lookup comparison to case insensitive when we create it if we want it to work just like hash tables do in PowerShell.  The command to do that looks like this:

PS C:\> $moduleTable = New-Object -TypeName ‘System.Collections.Generic.Dictionary[System.String,System.Management.Automation.PSModuleInfo]‘ -ArgumentList @([System.StringComparer]::CurrentCultureIgnoreCase)

It is important to note the syntax of this command.  The single-quotes that enclose the type name are required when working with generics.  There is definitely room for improvement in how this sort of thing could be done in the future (or today if you don’t want to wait and you want to create a type accelerator called Dictionary using the Accelerator module that Joel Bennett created), but for now knowing this is the format for generic dictionaries and knowing that you can use any type names inside the dictionary definition should be sufficient.  Also as mentioned you need to make sure you don’t forget to set the generic collection up to be case insensitive when you are working with PowerShell and you don’t want to worry about case by passing in the appropriate static property of the StringComparer class.  By default string comparisons are done case sensitive in .NET, so if you leave the ArgumentList parameter out your dictionary keys will be case sensitive.

Once you have that collection, watch what happens when you try to build the contents of the table using the same command you used before.

PS C:\> Get-Module -ListAvailable | ForEach-Object {$moduleTable[$_] = $_}

You get a bunch of errors that look something like this:

Array assignment to [WebAdministration] failed: The value “WebAdministration” is not of type “System.String” and cannot be used in this generic collection.
Parameter name: key.
At line:1 char:58
+ Get-Module -ListAvailable | ForEach-Object {$moduleTable[ <<<< $_] = $_}
    + CategoryInfo          : InvalidOperation: (WebAdministration:PSModuleInfo) [], RuntimeException
    + FullyQualifiedErrorId : ArrayAssignmentFailed

The important details here are in the errors themselves, and they are what you get when using strongly typed collections with incorrect types.  They inform you that the value you are assigning to the “key” parameter is not of type System.String.  In my opinion, when working with scripts that are even a little bit complicated, it is better to get this error that points you to a problem in your script than no error at all.  That’s one of the ways generics add value.

The other way they add value is in the assignment of the collection itself.  The command above that created the generic dictionary associating strings to PSModuleInfo objects tells you what types of objects you are associating, which can go a long way towards helping someone else other than you when they are looking at your script and trying to understand what you’re doing.  Of course they would have to understand generics, but you must be realizing by now that they aren’t all that hard, right?

To eliminate the logic error you were facing in your original hash table experience and properly create your module table, you can do this instead:

PS C:\> Get-Module -ListAvailable | ForEach-Object {$moduleTable.Item($_) = $_}

Now when you try to access a module in the module table using the name, you get the results you were originally after:

PS C:\> $moduleTable.WebAdministration
ModuleType Name                      ExportedCommands
———- —-                      —————-
Manifest   WebAdministration         {}

I should note that when using generic dictionaries, it is easier to use the Item parameterized property by name than it is to use the square brackets identifying the Item parameterized property when populating the dictionary.  The reason for this is because the named Iteme parameterized property takes care of all of the typecasting for you, but assignment when using the square brackets identifying the Item parameterized property does not.  For example, if I were to try populating my dictionary using a syntax similar to my original syntax, the only way I can get that to work in PowerShell 2.0 without errors is as follows:

PS C:\> Get-Module -ListAvailable | ForEach-Object {$moduleTable[[string]$_] = [System.Management.Automation.PSModuleInfo]$_}

This is another area where there is room for improvement in PowerShell when working with generics.  Both methods give you strong typing and therefore raise errors if there are any unexpected types, but the syntax when using the Add method is obviously much easier to type and read afterwards.

Anyhow, that about covers it.  If after reading all of this you still don’t care about generics, even though it’s very likely you use them in PowerShell without realizing it, then you can simply come back here later if you find yourself in a position where you start to care about them.

I hope this helps!

Kirk out.

Share this post:

Here’s all you need to do:

1.  Bookmark the PowerPack section of the wiki.  I published a big update to our wiki earlier this week and it should be able to answer a lot of questions you might have.  Don’t read the whole thing right now though, that might take too long and what you really want to do right now is explained in the next step.

2.  Watch this screencast (also shown below on YouTube) that shows how I created a cool Windows Server Roles and Features PowerPack from scratch earlier today and published it to the PowerPack Library in only 10 minutes.  The PowerPack even has dynamic nodes generated from 4 script nodes, which used to be quite a lot of work but thanks to the AdminConsole module they are much, much easier now.  In fact, if you pay close attention to the screencast, you’ll see that all of the functionality in the PowerPack itself is done with only 7 lines of PowerShell script plus one basic node and two basic actions — that’s pretty amazing.  The entire screencast is longer than 10 minutes because I needed to explain a few things before and after the demonstration, but the creation and publishing of the PowerPack itself is done in only 10 minutes during the screencast.

Now that I’ve armed you with the wiki documentation and the screencast demo, I’ll be looking forward to seeing your PowerPacks in the PowerPack Library after your lunch or afternoon break!

Good luck with your PowerPacks!

Kirk out.

Share this post:

]]> http://poshoholic.com/2009/11/13/powergui-quick-tip-create-a-powerpack-from-start-to-finish-in-10-minutes/feed/ 3 Poshoholic http://poshoholic.com/2009/09/18/powershell-3-0-why-wait-importing-typed-objects-with-typed-properties-from-a-csv-file/ http://poshoholic.com/2009/09/18/powershell-3-0-why-wait-importing-typed-objects-with-typed-properties-from-a-csv-file/#comments Fri, 18 Sep 2009 14:48:06 +0000 Kirk Munro http://kirkmunro.wordpress.com/2009/09/18/powershell-3-0-why-wait-importing-typed-objects-with-typed-properties-from-a-csv-file/ ]]> After working exclusively with PowerShell in my career for over two years now, it has become quite clear to me that the single most valuable feature in Microsoft Windows PowerShell, in my opinion anyway, is its extensibility.  In particular, it’s how easily it can be extended in PowerShell itself through a combination of PowerShell scripts and XML files, without the need of a compiler.  There are some features that are a very close second to that (consistency and discoverability), but the extensibility that PowerShell provides is truly second to none.

Version 1.0 of PowerShell was extendible from within PowerShell via combinations of PowerShell functions, the .NET Framework, WMI, ADSI, Add-Member and external ps1xml files that define type extensions and formats, not to mention snapins.  Using these features in PowerShell 1.0, I found them more than capable to allow me to create some really creative workarounds to some challenging issues that were identified in that version.  Not everything can be worked around, of course; some bugs can really only be fixed by the PowerShell team, and that will always be the case.  Those bugs aside though, PowerShell 1.0 really did a great job of providing a ton of functionality and enabling people like you and me to add even more.

Still, the solutions I could come up with in PowerShell 1.0 didn’t function quite the same as a regular PowerShell cmdlet.  There were some subtle differences and limitations in what you could do in that release.  Version 2.0 of PowerShell addresses some of those limitations, bringing even more extendibility options to the table with advanced functions, classes (using Add-Type), modules, and proxy functions.  These new options are a welcome addition to the PowerShell ecosystem and they allow me to ask the question “Why wait for PowerShell 3.0?”, a question I can now try to answer with creative solutions to problems in PowerShell and with creative ways to extend PowerShell so that you don’t necessarily have to wait for the next release to get new features or functionality that you might be looking for.  This article is the first in what I hope becomes a series of solutions that allow you to get some functionality you might find in PowerShell 3.0 without having to wait for it.

First on my list of areas needing improvement comes from a recent question that came up on a mailing list I follow:

I’m using Import-CSV to import a two-"column" CSV file and return a custom object with two additional properties. But I want the first property to be an Int and the second to be a DateTime. How do I do that? (I’ve tried several strategies, including explicit casting of the types in an array, but they come out as strings.

Import-Csv is a really, really handy cmdlet.  It allows you to import the contents of a csv (character-separated value) file as a collection of objects so that you can then do things with them.  It is commonly used in bulk provisioning or modification scenarios, where administrators can work with the data in the csv first if necessary and then write a script to do the required work according to the data from each entry in the csv file.

It has certain limitations, though, and those limitations can cause you to have to include additional complexity in your scripts to work around the limitations.  When you import data using Import-Csv, every property on the objects that are created are all of type string.  If you are trying to work with some properties containing dates (System.Datetime) or others containing numeric values or other types, complicated pipelines with manual conversion using ForEach-Object or Select-Object is required.  That’s fine for one-off scenarios, but this has come up before, and it makes sense for Import-Csv to allow users to set the types for the properties on the objects they are importing — that’s one problem to solve.

Another limitation is that objects imported from Import-Csv don’t necessarily have an appropriate type name associated with them.  If the file was created manually or by another program, the objects will be generic PSObjects.  If the file was created by exporting data from PowerShell using Export-Csv, a type may be included in the csv file but most csv files I work with come from sources other than PowerShell.  You can customize the object type name however you like (and this is recommended if you are doing something like Importing data from a csv file into the PowerGUI Admin Console so that you can then associate relevant actions with that object type), but again this isn’t something you would want to do each time you import csv data because it’s just that much more work.

It sounds to me like this user would have preferred being able to call Import-Csv using a syntax something like this:

Import-Csv C:\birthdays.csv -Type String,Int,Date

or, with a slightly more powerful example, perhaps like this:

Import-Csv C:\birthdays.csv -TypeMap @{Age='Int';Birthday=[System.DateTime]} -As 'BirthdayRecord' -UseETS -Overwrite

We could simply put in a feature request to the PowerShell Connect site (something I recommend you do whenever you come across something you feel is missing or incorrect), but that won’t do anything to help us today.  How can we solve those two problems now and bring Import-Csv into a level of functionality we might like to think we’ll get in PowerShell 3.0, like what is shown above, in such a way that getting typed objects with properly typed properties is as simple as importing data from a csv file using nothing but an Import-Csv command?  The answer to that comes from one of my new best friends in PowerShell: proxy functions.  The proxy function feature in PowerShell allows you to create an advanced function with the same name as a cmdlet that internally calls that cmdlet.  Since functions have a higher precedence that cmdlets in the command precedence order, you’ll always get the proxy function if it’s loaded when you are using the basic (that is to say, non-qualified) cmdlet name.

Creating a proxy function is easy.  All you have to do is execute a static .NET method called Create on the System.Management.Automation.ProxyCommand class and pass in a new System.Management.Automation.CommandMetaData object created by using the result of calling Get-Command for the cmdlet you want to proxy to get the internal script that will be the body of the proxy function, then wrap that in a function with the same name as the cmdlet you are proxying and then, to add that function to your current script file, output it to another file and then copy it over using an editor.  Huh?  That sure sounds complicated.  Well, since it’s not all wrapped up in a cmdlet for you, it is more complicated than it needs to be.

Let’s try that again.

Creating a proxy function is easy.  All you have to do is follow a few steps to get the command you need to run that generates the proxy function body, and then work within your favorite editor to copy that command body into your function in the file you are working on.  My favorite editor is PowerGUI, so I’ll use that in my example.  First, make sure you have installed PowerGUI with the new PowerShell 2.0 snippets (you can read more about those here) and then open up your PowerGUI Script Editor and follow these steps:

1. Select Edit | Insert Snippet.
2. Scroll down the list of snippets until you find a folder called “PowerShell v2” and double-click on it.
3. Scroll down the list of PowerShell v2 snippets until you find one called “function (proxy)” and double-click on it to insert that snippet.
4. In the snippet Name field, type in the name of the cmdlet you want to create a proxy for and hit enter.

If you like to learn by watching others, you can watch a demonstration of this (and other snippets) in a screencast that is posted on YouTube.  If you’re a keep-your-fingers-on-the-keyboard junkie like me, you can use shortcuts and type in the snippet folder and name and get this done very quickly.  When you’re done, you’ll have a function that looks something like this:

<#
    For more information about proxy functions, see the following article on the
    Microsoft PowerShell Team blog:

http://blogs.msdn.com/powershell/archive/2009/01/04/extending-and-or-modifing-commands-with-proxies.aspx

#>

function Import-Csv {
    <#
        To create a proxy function for the Import-Csv cmdlet, paste the results of the following command into the body of this function and then remove this comment:
        [Management.Automation.ProxyCommand]::Create((New-Object Management.Automation.CommandMetaData (Get-Command Import-Csv)))
    #>
}

That’s not exactly a proxy function yet.  There’s one more step you need to take, as described in the comment inside the proxy function.  That comment indicates you need to run the command inside it and paste the results of that command over the comment itself.  Copy the command as described in that comment and paste it in the embedded PowerShell Console window that is docked in your PowerGUI Script Editor, and once you have it pasted there, run it by pressing enter.  The result of that command is string output that will become the main body of your proxy function.  If you did this for Import-Csv like I did, it will look like this:

[CmdletBinding(DefaultParameterSetName='Delimiter')]
param(
    [Parameter(ParameterSetName='Delimiter', Position=1)]
    [ValidateNotNull()]
    [System.Char]
    ${Delimiter},

    [Parameter(Mandatory=$true, Position=0, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)]
    [Alias('PSPath')]
    [System.String[]]
    ${Path},

    [Parameter(ParameterSetName='UseCulture', Mandatory=$true)]
    [ValidateNotNull()]
    [Switch]
    ${UseCulture},

    [ValidateNotNullOrEmpty()]
    [System.String[]]
    ${Header})

begin
{
    try {
        $outBuffer = $null
        if ($PSBoundParameters.TryGetValue('OutBuffer', [ref]$outBuffer))
        {
            $PSBoundParameters['OutBuffer'] = 1
        }
        $wrappedCmd = $ExecutionContext.InvokeCommand.GetCommand('Import-Csv', [System.Management.Automation.CommandTypes]::Cmdlet)
        $scriptCmd = {& $wrappedCmd @PSBoundParameters }
        $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin)
        $steppablePipeline.Begin($PSCmdlet)
    } catch {
        throw
    }
}

process
{
    try {
        $steppablePipeline.Process($_)
    } catch {
        throw
    }
}

end
{
    try {
        $steppablePipeline.End()
    } catch {
        throw
    }
}
<#

.ForwardHelpTargetName Import-Csv
.ForwardHelpCategory Cmdlet

#>

Select all of that text that was output in your docked PowerShell Console window and copy it to your clipboard.  Then paste it over the original comment that told you to do this.  Now you have a proxy function.  It doesn’t do anything different than the cmdlet you are proxying yet, but when it is loaded in your PowerShell session it will proxy that cmdlet properly.

So now you might be saying to yourself: “That’s great (although the process could be a little more streamlined…), but now what do I do?”.  Now you can add your own parameters that you wish were on the original cmdlet in the first place, making the proxy function much more powerful.  For our example with Import-Csv that I showed earlier, I would like to be able to specify the type of the properties in the csv file, either as an array when I want to specify all property types or as a hash table when I only want to specify a type for a few named properties, knowing that the rest will default to string.  I’ll accomplish that by adding a Type and a TypeMap parameter to my Import-Csv proxy function.  I’d also like to be able to specify the type of the object that is imported using Import-Csv, and I’d like to be able to define whether my type name should be treated as an Extended Type Name extension as well as whether or not the current type hierarchy should be overwritten or not.  I’ll accomplish that by adding As, UseExtendedTypeSystem (alias UseETS), and OverwriteTypeHierarchy parameters.

Those changes will allow me to use the syntax I proposed above without waiting for someone else to give it to me.  By taking the time to create the proxy function that supports these parameters I’ll save myself and others time and complexity in the scripts they write by moving all of the extra pipeline complexity that would otherwise be necessary directly inside the proxy function.  It is worth noting that a proxy command isn’t as efficient as it would be if the added functionality were included in the cmdlet itself, but that’s not the point.  The point is that you can extend cmdlets when they leave you wanting more today rather than waiting to see if PowerShell 3.0 includes the extensions you want or not tomorrow (or three years from now, who knows when it will be released).

The resulting proxy function is a pretty good sized function, but we’ve added quite a few features to it as well, and those features need to have some logic to support them.  I’m including my version of the Import-Csv proxy function at the bottom of this post in its entirety so that you can give it a try yourself and see if it helps you out.  With the exception of the parameter definitions I added to the param statement, all logic supporting the new parameters I have added is enclosed in collapsible regions so that you can see the specific locations where I inserted my logic.  That should make it a little easier for you to see how logic can be added within a proxy function, enabling you to experiment a little and create your own PowerShell 3.0 flavors of your favorite cmdlets.  If you prefer to download the ps1 file containing the proxy command directly, I have also shared that on my SkyDrive, here.

There are several other important things I should mention about proxy functions, as follows:

1. You can add parameters, modify parameters, remove parameters, or leave parameters unchanged in proxy functions.
2. If you add parameters, you need to remove them from the parameter collection ($PSBoundParameters) before you create your wrapped command so that those parameters are not passed to the cmdlet you are proxying.  You may also have to do this if you modify parameters, depending on the modifications you make.
3. If you find you are adding pipelines to certain commands you call on a regular basis, it is likely a sign that the cmdlet itself needs improvement.  Consider creating proxy functions in these situations so that you don’t have to do as much typing in the long run.
4. If you create and use proxy functions, share them with the community so that the PowerShell team can see where cmdlets could be improved.  You can’t influence what goes in PowerShell 3.0 if you’re not sharing.

Here’s the final version of my Import-Csv proxy function:

#Requires -Version 2.0

function Import-Csv {
    <#

    .ForwardHelpTargetName Import-Csv
    .ForwardHelpCategory Cmdlet

    #>

    [CmdletBinding(DefaultParameterSetName='Delimiter')]
    param(
        [Parameter(ParameterSetName='Delimiter', Position=1)]
        [ValidateNotNull()]
        [System.Char]
        ${Delimiter},

        [Parameter(Mandatory=$true, Position=0, ValueFromPipeline=$true, ValueFromPipelineByPropertyName=$true)]
        [Alias('PSPath')]
        [System.String[]]
        ${Path},

        [Parameter(ParameterSetName='UseCulture', Mandatory=$true)]
        [ValidateNotNull()]
        [Switch]
        ${UseCulture},

        [ValidateNotNullOrEmpty()]
        [System.String[]]
        ${Header},

        [ValidateNotNullOrEmpty()]
        [System.String[]]
        ${Type},

        [ValidateNotNullOrEmpty()]
        [System.Collections.Hashtable]
        ${TypeMap},

        [ValidateNotNullOrEmpty()]
        [System.String]
        ${As},

        [Alias('UseETS')]
        [ValidateNotNull()]
        [Switch]
        ${UseExtendedTypeSystem},

        [ValidateNotNull()]
        [Switch]
        ${OverwriteTypeHierarchy}
    )

    begin {
        try {
            $outBuffer = $null
            if ($PSBoundParameters.TryGetValue('OutBuffer', [ref]$outBuffer)) {
                $PSBoundParameters['OutBuffer'] = 1
            }
            $wrappedCmd = $ExecutionContext.InvokeCommand.GetCommand('Import-Csv', [System.Management.Automation.CommandTypes]::Cmdlet)

            #region Initialize helper variables used in the processing of the additional parameters.
            $scriptCmdPipeline = ''
            #endregion

            #region Process and remove the Type parameter if it is present, modifying the pipelined command appropriately.
            if ($Type) {
                $PSBoundParameters.Remove('Type') | Out-Null
                $scriptCmdPipeline += @'
 | ForEach-Object {
    for ($index = 0; ($index -lt @($_.PSObject.Properties).Count) -and ($index -lt @($Type).Count); $index++) {
        $typeObject = [System.Type](@($Type)[$index])
        $propertyName = @($_.PSObject.Properties)[$index].Name
        $_.$propertyName = & $ExecutionContext.InvokeCommand.NewScriptBlock("[$($typeObject.FullName)]`$_.`$propertyName")
    }
    $_
}
'@
            }
            #endregion

            #region Process and remove the TypeMap parameter if it is present, modifying the pipelined command appropriately.
            if ($TypeMap) {
                $PSBoundParameters.Remove('TypeMap') | Out-Null
                $scriptCmdPipeline += @'
 | ForEach-Object {
     foreach ($key in $TypeMap.keys) {
        if ($TypeMap[$key] -is [System.Type]) {
            $typeObject = $TypeMap[$key]
        } else {
            $typeObject = [System.Type]($TypeMap[$key])
        }
        $_.$key = & $ExecutionContext.InvokeCommand.NewScriptBlock("[$($typeObject.FullName)]`$_.`$key")
    }
    $_
}
'@
            }
            #endregion

            #region Process and remove the As, UseExtendedTypeSystem and OverwriteTypeHierarchy parameters if they are present, modifying the pipelined command appropriately.
            if ($As) {
                $PSBoundParameters.Remove('As') | Out-Null
                $customTypeName = $As
                if ($UseExtendedTypeSystem) {
                    $PSBoundParameters.Remove('UseExtendedTypeSystem') | Out-Null
                    $customTypeName = '$($_.PSObject.TypeNames[0] -replace ''#.*$'','''')#$As'
                }
                if ($OverwriteTypeHierarchy) {
                    $PSBoundParameters.Remove('OverwriteTypeHierarchy') | Out-Null
                    $scriptCmdPipeline += @"
 | ForEach-Object {
     `$typeName = "$customTypeName"
     `$_.PSObject.TypeNames.Clear()
    `$_.PSObject.TypeNames.Insert(0,`$typeName)
    `$_
}
"@
                } else {
                    $scriptCmdPipeline += @"
 | ForEach-Object {
     `$typeName = "$customTypeName"
    `$_.PSObject.TypeNames.Insert(0,`$typeName)
    `$_
}
"@
                }
            } else {
                if ($UseExtendedTypeSystem) {
                    $PSBoundParameters.Remove('UseExtendedTypeSystem') | Out-Null
                }
                if ($OverwriteTypeHierarchy) {
                    $PSBoundParameters.Remove('OverwriteTypeHierarchy') | Out-Null
                }
            }
            #endregion

            $scriptCmd = {& $wrappedCmd @PSBoundParameters}

            #region Append our pipeline command to the end of the wrapped command script block.
            $scriptCmd = $ExecutionContext.InvokeCommand.NewScriptBlock(([string]$scriptCmd + $scriptCmdPipeline))
            #endregion

            $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin)
            $steppablePipeline.Begin($PSCmdlet)
        }
        catch {
            throw
        }
    }

    process {
        try {
            $steppablePipeline.Process($_)
        }
        catch {
            throw
        }
    }

    end {
        try {
            $steppablePipeline.End()
        }
        catch {
            throw
        }
    }
}

Are you still with me?  Whew, if you stuck with me this far, thanks!  There’s a lot of information here, and while it’s definitely not something for a beginner, if you’re comfortable experimenting in PowerShell I encourage you to give proxy functions a try and see what solutions you can come up with.  Or, if you don’t mind taking the time to leave me a note, let me know what your biggest pains are with cmdlets today that you think could be solved with proxy functions and I’ll see what I can do to help create solutions for those.  The feedback system really works, so don’t be shy, participate by either sharing solutions or letting others like me know what your problems are so that we can continue to help evolve PowerShell into the best scripting environment out there!

Thanks for listening!

Kirk out.

Share this:

Once you have the snippets installed, watch the screencast that demonstrates how you can learn more about some PowerShell v2 features by using the v2 code snippets.  You can watch it in flash format with a table of contents, or you can watch the YouTube version below.

Want to see more snippets?  Let me know which areas of PowerShell you would like to see covered in snippets by leaving me a note in the comments.

Enjoy!

Kirk out.

Share this post:

As Jackson Shaw suggested on his blog about a week ago, PowerGUI provides an admin console that allows you to create your own management UI that is layered on top of PowerShell.  This admin console can be extended with PowerPacks, which are essentially add-ins that provide additional user interface elements in PowerGUI that invoke PowerShell script when clicked.  All you need to do is add the user interface elements you want and then provide the scripts to power those elements, managing the Active Directory Recycle Bin objects or anything else you need to manage.  Or alternatively you can check to see if someone on the PowerGUI Community like myself has already created a PowerPack with the functionality you are looking for.

In the case of the Active Directory Recycle Bin, you’re in luck.  I just finished creating the first release of a new PowerPack that is designed to allow you to manage any objects in your recycle bin.  You can find the Active Directory Recycle Bin PowerPack by following the hyperlink here or by going directly to http://www.powergui.org and browsing into the Active Directory subcategory in the PowerPack Library.  This PowerPack includes the following features:

• View the contents of the recycle bin, including hierarchies
• Restore individual items in the recycle bin (recursively or not) to their original location
• Restore individual items in the recycle bin (recursively or not) to a specified location
• Permanently delete objects in the recycle bin (recursively or not)
• Empty the contents of the recycle bin
• Modify the number of days that the recycle bin is configured to retain objects and the number of days that objects are to be kept in a tombstone state before permanent deletion

If you would like to see a demo of the Active Directory Recycle Bin PowerPack, watch this screencast:

If you prefer watching a high resolution version of the screencast, you can watch it in flash format here or on YouTube directly in HD format here.

This is the initial release of this PowerPack and it contains a good amount of new functionality.  If you are experimenting with the Active Directory Recycle Bin feature, please take a look at this PowerPack and provide any feedback you have so that we can continue to provide improvements that are valuable to you and others in future releases.

Thanks for listening!

Kirk out.

Share this post:

Recently there have been several posts on the forums where the problem has been a lack of understanding of the operator and enclosure precedence in PowerShell.  That’s not too surprising because the precedence order used by the PowerShell interpreter doesn’t seem to be documented at this time.  You can find the precedence order of arithmetic operators through the about_arithmetic_operators help file, you can find out some precedence details for specific operators in various operator help files, and you can find out the precedence of command types through the about_command_precedence help file, but that’s about it.  There is no single help file that documents the overall operator and enclosure precedence.  It doesn’t seem to be listed in any of the PowerShell books I have read either. 

Fortunately through some ad hoc experimentation and through some reading of the help documentation that does exist it is possible to figure out how all of this works.  I’ve gone through that exercise recently and the resulting table of operator and enclosure precedence is below.  Before getting to the table though there are a few important things I should mention, as follows: 

1. Any items that share the same row in the table have the same precedence and are evaluated from left to right when adjacent within an expression unless otherwise indicated.
2. The intent of this table is to identify a precedence that can be used to create or troubleshoot more complicated expressions without a lot of guesswork.  It is not intended to explain what each of the operators are and how you can use them (although to help understand expressions you might have to deal with I do mention a few details about some operators that function differently than the majority of operators in PowerShell).
3. If you want to learn about the individual operators and see examples showing how they can be used I recommend you consult the about_operators help file and all of its related files.

With that out of the way, here is the operator and enclosure precedence table for PowerShell:

Since this table is created through experimentation and through snippets of information about precedence that I was able to find in the help files, it may not be entirely accurate.  If you find any problems with the precedence information provided here, please let me know and I’ll update this table accordingly. 

[Update 09-July-2009: Fixed table formatting, added an index operator, added all case-sensitive and case-insensitive variants and adjusted the precedence for the property dereference and static member operators.] 

Thanks, 

Kirk out. 

Share this post:

$collection = Import-Csv C:\newusers.csv

Commands like this will work forever as long as you have a csv file in the appropriate location.  Occasionally though you may find that a script containing this command just stops working.  It might not make sense to you at the time because the script hasn’t changed, so what’s the problem?

The problem is that in the above command there is no guarantee that $collection will actually store an array of objects because there is no guarantee that Import-Csv will return more than one object.  In fact, there is no guarantee that Import-Csv will return any objects at all.  If the C:\newusers.csv file is generated by some other tool, it is possible that it might contain 0, 1 or more entries.  When it contains 0 or 1 entries, the $collection variable will either be $null or it will contain one object representing the single entry in the C:\newusers.csv file, respectively.  If further down in your script you’re always treating $collection as if it is an array and using indices to access elements in the array, your script will suddenly start failing with errors.

Fortunately there is a way to ensure that the results of any command are stored in an array.  All you need to do is wrap the command that returns the object(s) in array enclosures, like this:

$collection = @(Import-Csv C:\newusers.csv)

If you take this approach in your script and then later when you run your script C:\newusers.csv only contains one entry or perhaps doesn’t contain any entries at all, your $collection variable will still be an array so that you can check the size using the Count property ($collection.Count), access individual values using indices (e.g. $collection[0]), etc.  This is a much safer practice to take when writing your scripts so that you can make sure that you have an array when you store an array.

Of course if you are dealing with very large collections of objects that aren’t already loaded in memory an even better practice is to avoid storing the entire collection in memory altogether by using pipelines and cmdlets like ForEach-Object to process the items in the collection, but I wanted to make sure you were aware of how you should properly handle and store arrays in variables in your scripts so that you’re not facing a script long after it has been written and asking yourself why it suddenly stopped working.  There are plenty of other reasons why a script could stop working at some point but at least now you’re armed with the knowledge required to avoid one of those possibilities.

Kirk out.

Share this post:

1. Dynamically create an org chart from users in Active Directory using title, department, office, address, and other properties.
2. Generate a Visio Org Chart from PowerGUI for the any branch of an organization.
3. Create statistical reports for the employees in your organization to see breakdowns of employees by office, department, management, etc.
4. Dynamically generate Office Directory reports in HTML when using it in conjunction with the Advanced Reporting PowerPack.

Note: The Org Chart PowerPack uses the Quest AD cmdlets to retrieve information from AD so you will need to install those first before you can use the PowerPack.

If you would like to see how this PowerPack can be of benefit to you, check out this screencast:

This screencast was recorded in HD format so you can click on the HD button once you start watching it to enable high definition video.  Alternatively, if you would prefer to watch a high resolution flash version with a table of contents you can watch the screencast here.  I decided to try widescreen format this time since that is my format preference…let me know if this is a problem for you.

This is the first release of this PowerPack and I’m anxious to hear what you think so please give it a look and share your feedback so that I can improve it with another update in the future.

Thanks for listening!

Kirk out.

Share this post:

Still, even with that knowledge in hand people often trip over the ScriptBlock parameter syntax when using a parameter that takes a hash table (aka an associative array) as input.  The most common example I can think of where this is encountered is in the Quest AD cmdlets.

Many of the Quest AD cmdlets have a parameter called ObjectAttributes.  This parameter serves two purposes: in Get cmdlets it is used to define the values you want to filter on; in Set and New cmdlets it is used to define the values you want to assign to specific attributes.  Not consistent, I know, but that’s a whole other discussion.  In both cases the ObjectAttributes parameter is a hash table and to use it you simply need to define a hash table that matches attribute names with values.  Here’s an example showing how users trip over the syntax without realizing it:

Get-QADComputer Comp1 `
    | Set-QADObject -ObjectAttributes ` 
        @{userAccountControl=$_.userAccountControl -bxor 2}

This one liner was designed to enable or disable a computer object in AD.  It will run without raising an error, and it will even enable or disable the computer object, but it will not work like you might expect.  After running this command the userAccountControl attribute (which contains many flags, not just a flag for enabled/disabled state) will not be properly configured.  Why?  It looks like it is properly using a ScriptBlock parameter, but it is not so the $_.userAccountControl value will either evaluate to 0 if the $_ variable is null or if it does not have a userAccountControl property, or it will contain the userAccountControl value from whatever object the $_ variable contained before you called Get-QADComputer in the first stage of this pipeline.  Nothing in this command instructs PowerShell to treat the ObjectAttributes parameter as a ScriptBlock parameter.  So what’s missing?

The most important thing to remember about ScriptBlock parameters is that they always must be surrounded by script block enclosures (“{“ and “}”).  Otherwise they are not script blocks.  In our example above it looks like the parameter is surrounded by the proper enclosures, but that’s not true.  It’s surrounded by hash table enclosures (“@{“ and “}”), and this is what trips people up when working with this syntax.  To make this be properly treated as a ScriptBlock parameter, we need to surround the hash table with curly braces, like this:

Get-QADComputer Comp1 `
    | Set-QADObject -ObjectAttributes ` 
        {@{userAccountControl=$_.userAccountControl -bxor 2}}

That makes PowerShell recognize that we have a ScriptBlock parameter and the $_ variable within it properly evaluates to the object that just came down the pipeline.  No ForEach-Object or temporary variables required.  It seems simple enough when explaining it but you’d be surprised how many people get tripped up on this syntax.

If you want to see some forum discussions where this has been an issue for others, you can go here or here.

Kirk out.

Share this post:

]]> http://poshoholic.com/2009/06/23/powershell-quick-tip-setting-ad-object-attributes-with-scriptblock-parameters/feed/ 0 Poshoholic http://poshoholic.com/2009/06/20/just-released-advanced-reporting-powerpack/ http://poshoholic.com/2009/06/20/just-released-advanced-reporting-powerpack/#comments Sat, 20 Jun 2009 09:40:27 +0000 Kirk Munro http://kirkmunro.wordpress.com/2009/06/20/just-released-advanced-reporting-powerpack/ ]]> I just published a brand new PowerPack to the PowerPack Library called the Advanced Reporting PowerPack.  If you’ve been keeping your eyes on the Virtualization EcoShell project as well as PowerGUI, you may have already come across this PowerPack because I released it there first.

The Advanced Reporting PowerPack allows you to generate HTML reports with collapsible nested groups for any set of data in PowerGUI.  Think VMs, Snapshots, AD Users or Groups…you name it.  If you can get the data into a grid in PowerGUI, you can generate a nice HTML report using this PowerPack.  The only UI element this PowerPack adds to PowerGUI is a common action called “Create report…”.  This action does all of the heavy lifting to generate a cool HTML report for the items you have selected.

Want to see what how to get started using this PowerPack?  Watch this screencast:

If you would prefer to watch a higher resolution version, you can watch the screencast in flash format here.

This is only the first release of advanced reporting functionality in PowerGUI and already it’s really powerful.  Still, there is room for improvement so if you have any feedback, please share it with me in my comments or on the PowerGUI Forums so that I can consider it for the next release!

Thanks and enjoy!

Kirk out.

Share this post:

Hal’s an IT pro, and while I work with IT pros a lot these days I have a developer background, so we were able to speak to both sides of the fence and talk about why you should pay attention to PowerShell whether you’re a software developer or an IT pro.

That recording is now live, so if you want to hear it head over to Hanselminutes Show #162: PowerShell 2.0, and let me know what you think afterwards.

Kirk out.

Share this post:

I have the latest verions of the Quest AD cmdlets, PowerGUI and the Active Directory PowerPack.  Can I use PowerGUI to search for old computer accounts?  For example: computer accounts that haven’t had their machine account password reset for over three months?

The timing of this question is perfect because the update of the Active Directory PowerPack that I posted two weeks ago allows you to do this without having to write any scripts yourself.  For those of you who want to try this but don’t have the most recent versions of PowerGUI, the Quest AD cmdlets and the Active Directory PowerPack installed, follow those links and download and install those before continuing.  Installation instructions are on the appropriate web pages where necessary.

Once you all of the necessary software installed, here’s what you need to do.

Step 1: Add the attributes you need to the list of attributes retrieved from Active Directory.

There are In the PowerGUI Admin Console, expand the “Active Directory” node and click on “Configuration”.  This will show you the current domain that PowerGUI will gather data from.  You can change this if you like, however you don’t need to unless you want to use alternate credentials or connect to another domain.  With the configuration showing in the grid, click on the “Manage default attributes” link.  That will present you with a view something like this:

This shows you the current list of attributes that are retrieved for each individual Active Directory object.  This will be initially configured with the default attributes as defined by the Quest AD cmdlets plus a few attributes that are required for the Active Directory PowerPack.  You can add whatever attributes you want to gather here for any of the object types.  To help solve our immediate problem and be able to get a list of computer accounts that have not had their machine account password reset for over three months, we need to add the pwdLastSet attribute for computer objects.  To do this, simply click on the “Add attribute…” action, provide the name of the pwdLastSet attribute in the “Attribute name” field and set the “Retrieve attribute for computer objects” value to True.  When you click on OK, that attribute configuration will be saved and any computer objects retrieved using the Quest AD cmdlets will have that attribute retrieved with them.

Step 2: Retrieve the objects you want from Active Directory and optionally show the attributes you want to filter on.

Once you have configured PowerGUI so that it will retrieve the pwdLastSet attribute for computer objects, you need to get your computers.  You can do this by simply clicking on the “Computers” child node under the “Active Directory” node.  This will present you with a list of computer accounts, showing their Name, Type and DN by default.

With the list of computer objects showing, you can optionally add the pwdLastSet attribute to the view by right-clicking in the column headers and selecting “More…” from the menu that appears.  With the list of all attributes that can be added showing, scroll down until you find the pwdLastSet attribute and check the checkbox beside it.  Then click on OK to save that change and your pwdLastSet attribute will be retrieved with your computer objects from the Computers node.

Step 3: Create a client-side filter to filter out the objects you don’t care about.

With the list of all of your computer objects showing, you can create a filter to reduce the number of objects to those that you need to see.  To do this, click on the Filters button above the column headers.  This will make the filter panel visible.

You can use this panel to filter any collection based on the properties of the objects in that collection.  For our particular problem, we want to see computer objects whose password has not been changed in the last 3 months.  We can get that by selecting “pwdLastSet” in the “Property” field, “Less or equal” in the “Operator” field, and selecting the calendar date three months ago in the “Value” field using the calendar control.  Once that is set, click on the “Apply” button to apply the filter and your list of computer objects will be filtered to only show those whose machine passwords haven’t changed in the last 3 months.

Step 4: Make the newly filtered data set available in its own node.

Now that you have the data you’re looking after, your “Computers” node is now configured to always show you the filtered list because PowerGUI remembers the filters you apply to nodes.  You might not like this configuration, preferring to have a separate node to view the data that you want.  Fortunately, PowerGUI lets you do create that easily too, and you still don’t have to do any scripting.  To create a separate node that lets you get the same data set, simply click on the “Save As…” button in the filter panel.  This will allow you to save the script from the Computers node with the filter you have created automatically applied as a client-side filter for that script.  Simply give the new script node a name (something intuitive like “Computers with old passwords” will do), and click on OK to save the new child node.  Then you can click on the “Clear All” button in the filter panel for your “Computers” node because that filter will no longer be needed.  Now click on your new node and you’ll get the list of computers you are after, and it will look something like the screenshot below.

Step 5: Make your work reusable at any time by taking it one step further.

At this point you have successfully created a new node that gets specifically the data you were looking for and you didn’t have to do any scripting to get it, which is great!  You can make it a little better still though.  For our specific problem that we’re trying to solve, we created a new node that reports any computer object with a machine account password that hasn’t been changed within 3 months from today.  But tomorrow that will be come 3 months and 1 day.  The next day that will become 3 months and 2 days.  What if you want to customize the node so that it reports computers whose machine accounts have not had their passwords changed in the last 3 months, no matter what day you click on it?  For that to work you will have to do a minor script modification.

Right-click on your new “Computers with old passwords” node and select properties.  This will show you the script used to retrieve your computers and filter the list.  At the very end of that script, you will see something like the following:

func_Computers | Where-Object {
    $_.'pwdlastset' -le [System.DateTime]"2009-02-08"
}

The Where-Object cmdlet contains the filter that is excluding any computers whose pwdLastSet attribute is greater than 3 months from the day we did this (for me that that’s February 8, 2009 since I created the node on May 8, 2009).  To change that filter so that it always works using a date 3 months earlier than now, you simply need to replace [System.DateTime]”2009-02-08” with (Get-Date).AddMonths(-3).  That changes the end of our script to this:

func_Computers | Where-Object {
    $_.'pwdlastset' -le (Get-Date).AddMonths(-3)
}

That’s it!  A simple replacement of the filter condition and you’re off and running with a brand new node designed to meet your specific needs with PowerGUI, the Quest AD cmdlets and the Active Directory PowerPack!

In a future article I’ll show you just how simple it is for you to take a collection of extensions to PowerPacks that you have created like this and package them up in a PowerPack so that you can share them with other users in the Community as well!

Enjoy!

Kirk out.

Share this post: