So your company doesn't want to enable PowerShell Remoting?

Wed, 21 Aug 2013 00:37:04 +0000

But I bet they’re okay with Remote Desktop Protocol, right? And all those Remote Procedure Calls?
And I bet they never even thought about why every *nix _system, ever, _has SSH enabled by default? But practically nothing else (by default)?
Hmm.

PowerShell Great Debate: What's Write-Verbose For?

Tue, 20 Aug 2013 18:07:32 +0000

This was a fascinating thing to see throughout The Scripting Games this year: _When exactly should you use Write-Verbose, and why? _The same question applies to Write-Debug.

“I use Write-Debug to provide developer-level comments in my scripts, since I can turn it on with -Debug to see variable contents.”

“I use Write-Verbose to provide developer-level comments in my scripts, since I can turn it on with -Debug to see variable contents.”

See what I mean? Some folks will suggest that Verbose is for “user-friendly status messages;” others eschew Debug entirely and prefer PSBreakpoints for that functionality.
What guidance would you offer for using Write-Verbose and Write-Debug in a script?
[boilerplate greatdebate]

PowerShell.org's Azure Journey: Part 2

Tue, 20 Aug 2013 01:10:01 +0000

I had no idea Azure gives MSDN subscribers a huge free monthly credit - $200 for the first month, and then on the Ultimate subscription level (which is what I get as an MVP) you get $175 per month thereafter. That starts to really justify the MSDN pricing. You want a lab in the cloud? Free Azure!
Given the free-ness of it, I decided to set up a PowerShell.org in the sky to see how it went. Configuring dual CentOS VMs was a bit of an all-day affair; I have less experience with RHEL (which is what CentOS is based on) and it took me a while to figure out that the built-in firewall was causing all my grief. Fixed now.
Microsoft publishes some pretty good guides for getting a LAMP stack running on CentOS in Azure. Not great guides, but good. They lack a decent guide on getting Passive FTP working - and it’s a PITA because Azure only lets you configure incoming ports on a one-at-a-time basis (not ranges), and you can only have 25. So that’s kind of a pain. But I got it working, got MySQL installed and working, and I’m presently waiting on VaultPress to smush up our latest site backup and spew it onto the Azure server. Remember: you don’t pay for bandwidth going into Azure, so I can load the backup in as many times as I want without incurring bandwidth.
This VaultPress thing is neat, if it works. It continually pulls changes from our WordPress installation and backs them up, timestamped, a la Apple Time Machine. Allegedly, if you give them the FTP info on you new server, and you have a base WordPress install working on the new server, they can “push” your whole site down to the new server. Given my fits and starts with FTP on CentOS today, we’ll see how well it works, but I’m optimistic. Dunno. It’s been saying “Testing Connection” for a long time now. Sigh.
Anyway, I’m starting both VMs in extra-small instances. Part of what I want to play with is whether or not I can upgrade those to bigger instances without breaking the universe. Depends on how CentOS behaves when it suddenly finds itself running on “new hardware.” We shall see! If it works, then it’ll truly be killer in terms of scaling. I also want to see if we get more “juice” running two load-balanced extra-small instances vs. a small instance (which is technically twice as big as an extra-small). Common logic suggests that more, smaller servers is better - a la every web farm, ever. But it’ll be fun to test.
Question: anyone have any Web site load-testing software they’re fond of? Mac or Windows is fine, or even both. I’ll enlist some folks to help with that, since I know my DSL line’s upstream side will chokepoint long before the Azure server does. Ooo, maybe we can have a PowerShell.org botnet that I could control… bwaa haa haa!
Meantime, Eric Courville, our new volunteer Webmaster, is setting up a similar Azure-based VM set with his own MSDN subscription. In addition to documenting the setup process, we’re going to try and do some load-testing and see what kind of instances we need to run in to get solid performance out of the site. PowerShell.org currently peaks at fewer than 50-60 concurrent connections (and even that day was a rare peak), so we’ll load test to that number.
Stay tuned!

PowerShell.org's Azure Journey, Part 1

Mon, 19 Aug 2013 16:19:50 +0000

When we started PowerShell.org, my company (Concentrated Tech) donated shared hosting space to get the site up and running. We knew it wouldn’t be a permanent solution, but it let us start out for free. We’re coming to the point where a move to dedicated hosting will be desirable, and we’re looking at the options. Azure and Amazon Web Services are priced roughly the same for what we need, so as a Microsoft-centric community Azure’s obviously the way to go.
Azure Technical Fellow Mark Russinovich is having someone on his team connect with me to discuss some of the models in which we could use Azure. What makes the discussion interesting is that PowerShell.org runs on a LAMP (Linux, Apache, MySQL, and PHP) stack. We’re not looking to change that; WordPress requires PHP, and the Windows builds of PHP typically lack some of the key PHP extensions we use. I’m not interested in compiling my own PHP build, either - I want off-the-shelf. WordPress more or less requires MySQL; while there’s a SQL Server adapter available, it can’t handle plugins that don’t use WordPress’ database abstraction layer, and I just don’t want to take the chance of needing such a plugin at some point and not being able to use it.
What’s neat about Azure is that it doesn’t care. I adore Microsoft for selling a service and not caring what I do with it. Azure runs Linux _just fine. _Huzzah!
So, we’ve got two basic models that could work for us. Model 1 is to just buy virtual machines in Azure. We’re planning one for the database and another for the Web site itself, so that we can scale-out the Web end if we want to in the future. We’re not going to do an availability set; that means we risk some short downtime if Azure experiences hardware problems and needs to move our VM, but we’re fine with that because right now we can’t afford better availability. We’d probably build CentOS machines using Azure’s provided base image (again, adore Microsoft for making this easy for Linux hosting and not just Windows). We know we tend to top out at 250GB of bandwidth a month, and that we need about 1GB of disk space for the Web site. 500MB of space for the database will last us a long time, but we’d probably get 1GB for that, too. It’s only like $3 a month. We could probably start with Small VM instances and upgrade later if needed. All-in, we’re probably looking at about $125/mo, less any prepay discounts.
Model 2 is to just run a _Website. _We still get to pick the kind of instance that hosts our site, so if we went with Small and a single instance, we’d be at about $110 including bandwidth and storage. That doesn’t include MySQL, though. Interestingly, Microsoft doesn’t host MySQL themselves as they do with SQL Azure. Instead, they outsource to ClearDB.com, which provides an Azure-like service for hosted MySQL. Unfortunately, the Azure price calculator doesn’t cover the resold ClearDB service. Looking at ClearDB’s own pricing, it’d probably push us to about $120-$125 a month - or about the same as having our own virtual machines. The difference is that, with Model 2, Microsoft can float our Web site to whatever virtual hosts they need to at the time to balance performance; with Model 1, they can potentially move our entire VM - although they’re unlikely to do so routinely, since it’d involve taking us offline for a brief period. A super-neat part of this model is its integration with Git: I can run a local test version of the site, and as I make changes and commit them to our GitHub repository, Azure can execute a pull and get the latest version of the site code right from Git. Awesome and automated. I love automated.
An appeal of Model 1 is that I can build out the proposed CentOS environment on my own Hyper-V server, hit it with some test traffic loads, and size the machine appropriately. I can then deploy the VHDs right to Azure, knowing that the instance size I picked will be suitable for the traffic we need to handle. It also give me an opportunity to validate the fact that a dedicated VM will be faster than our current shared hosting system, and to play around with the more advanced caching and optimization options available on a dedicated VM. I can get everything dialed in perfectly, and then deploy.
Azure has other usage models, but these are the two applicable to us. I think it’s great that we get these options, and that the pricing is more or less the same regardless. And again, I think it’s pure genius that Azure’s in the business of making money for Microsoft, and that they’re happy to do so running whatever OS I want them to.
I’ll continue this series of posts as we move through the process, just for the benefit of anyone who’s interested in seeing Azure-ification from start to finish. Let me know if you have any questions or feedback!

Two PowerShell Books 50% off TODAY ONLY

Fri, 16 Aug 2013 17:59:11 +0000

PowerShell in Depth and Learn Windows PowerShell 3 in a Month of Lunches are on half-price August 25th, 2013.
Use code dotd0825au at www.manning.com/jones2/
or
Use code dotd0825au at www.manning.com/jones3/
Tell a friend who needs to start learning PowerShell - two great books at 50% off. All print books come with a voucher for free ebook versions (MOBI, EPUB, PDF), and the ebook-only version is also 50% off.

Site Maintenance this Weekend (Aug 17-18 2013)

Fri, 16 Aug 2013 14:54:19 +0000

This weekend, we’ll be conducting maintenance on PowerShell.org. We have several goals:
**New visual theme. **We’ll be installing a new visual theme. While we hope to catch everything, you may run across something goofy-looking. Please use the Community Discussion forum to report that, so we can ask the designers to take a look.
**Performance. We’re going to continue to work on performance, with a goal of getting specified pages to have an “A” on the Page Test and YSlow tests. That’s not the entirety of performance, but it’s what we can address now without moving to a different hosting environment (which is planned). During this phase of our maintenance, the site may not function correctly, or certain features may come and go as we test different configurations.
Cleanup. **We’ll be condensing certain features of the site, rearranging menus, and so on, to provide a better visual experience across a wider variety of devices.
We appreciate your patience!

PowerShell Great Debate: Can You Have Too Much Help?

Tue, 13 Aug 2013 14:44:06 +0000

In The Scripting Games this year, more than a few folks took the time to write detailed comment-based help. Awesome. No debating it - comment-based help _is a good thing. _
But some folks felt that others took it too far. There were definitely scripts where the authors used, for example, the .NOTES section to explain their thinking and approach. Some commenters felt it was excessive, while others have pointed out, “wow, what if every programmer gave us some idea what the heck he/she was thinking at the time?” Some felt these extensive comments were just at attempt to get a better score by “convincing” the reviewer of an approach or tactic; others felt, “so what?”
So let’s leave the Games out of this debate - in a production environment, where do you come down on extensive notes in a script? When is it not enough, and when is it going too far? Where’s the value, and where’s the annoyance?
[boilerplate greatdebate]

PhillyPoSH 08/01/2013 meeting summary and presentation materials

Tue, 13 Aug 2013 04:11:24 +0000

John Mello gave a presentation on Tips and Tricks learned from the 2013 Scripting Games, a copy of his presentation and scripts can be obtained here
Various group members contributed to a Script and Tell, scripts and participant names are forthcoming.
A recording of the meeting is available on our YouTube channel, please note that the recording ends about 5 minutes before our meeting was done.

Need Desired State Configuration Modules?

Mon, 12 Aug 2013 23:59:59 +0000

You’ve probably been hearing about Desired State Configuration from a number of sources (Runas Radio, the PowerScripting Podcast, or the Channel 9 TechEd video for example). If you haven’t go check out those previously mentioned resources, I’ll wait…
Ok, now that you have a basic understanding of what Desired State Configuration (DSC) is, I have an announcement.

PowerShell.Org is building a repository of DSC modules for the community to use and contribute to.

As I’ve started working with Desired State Configuration, I began building up a repository of modules I would use in configuring my systems. I started to round them out with some basic documentation and decent logging messages and began pushing them to GitHub.
I’ve also seen several others starting to post some DSC modules on Github and elsewhere. Since we are very early in the Desired State Configuration lifecycle (it’s still not RTM yet), I would like our community to come together on a central location for our community contributions. I reached out to Don and the PowerShell.Org team and they graciously offered to host the contributions on the PowerShell.Org GitHub repository. What that means is that this effort is no longer under the control of one person (me), but owned by the community, by PowerShell.Org.
There’s not much in the repository yet, so if you’ve been experimenting with DSC and would like to share your efforts with the community, feel free to send a pull request (if you’re into the whole GitHub thing) or file an issue on the GitHub site and we’ll figure something out.
There is some basic “Getting Started With Developing DSC Modules” information at the GitHub repository as well.

Coming Soon: 55039 "PowerShell Scripting and Toolmaking" Course

Mon, 12 Aug 2013 15:23:53 +0000

Later this month, Jason Helmick will be offering a revised “PowerShell Scripting and Toolmaking” course at Interface Technical Training in Phoenix. This new course carries the Microsoft Courseware Marketplace number 55039 - that’s right, this is an official, unofficial course that will be available to all Microsoft training partners!
(Courseware Marketplace offerings are not written or endorsed by Microsoft, but they are equivalent to Official Curriculum in many ways, including being eligible for Software Assurance voucher programs. Marketplace offerings supplement Official offerings by providing courses that Microsoft doesn’t have the time or resources to generate themselves.)
This course is based directly on Learn PowerShell Toolmaking in a Month of Lunches, and incorporates much of that book’s actual text (in fact, a portion of the course’s sale price goes to the book publisher, with a portion of that going to the book authors as royalties). That’s combined with a full slide deck, some awesome brand-new labs, lab answer key, “starting points” (for lab students who fall behind), and a complete inventory of demo scripts for the instructor to use. It walks through a quick PowerShell review, and moves all the way through creating modules, advanced functions, custom views, and much more. It’s a pretty handy course, and even dives into creating “controller” scripts, such as scripts that automate processes or generate HTML reports. We provide a complete 3-VM build guide, and a simple ISO image containing all of the instructor and student files. Students are even welcome to download that ISO themselves for later reference! That URL will be provided in the student manual.
I’m especially proud of the labs, and thankful to Mike Robbins and Jason Helmick for debugging them for me. Through the main part of the course, students have three lab tracks (A, B, and C) to choose from - and overachievers can work on more than one track. Through each module, the labs gradually build from a basic command to a complete, fleshed-out “script cmdlet” packaged in a module, with a custom view and more. It’s extremely realistic, and it means much of the classroom time is spent on hands-on labs, where students will get the most value for their money.
This course is designed to complement Microsoft’s official 10961 course, which covers substantially the same material as Learn Windows PowerShell in a Month of Lunches, meaning 55039 is kind of a “sequel” course. Training centers are welcome to offer a 5-day accelerated class that combines both courses; that’s pretty much the class I teach myself. I don’t personally categorize 55039 as “advanced;” rather, it’s more of a specific application of PowerShell - building reusable tools. I do offer an advanced course of my own, and there’s a chance for that to become a packaged course in the future.
After the beta is complete, the course will be orderable in the Marketplace with a suggested price of $150 per student. It’s a full 5-day course, with multiple lab tracks per module, so I felt that was a pretty fair price, especially since students basically get the Toolmaking book “included” in their manual!
If any other trainers would like to know more about the course, they’re welcome to contact me. We will be selling it directly as well, for trainers who can’t access the Marketplace.
Download the table of contents: 55039-TOC

My PowerShell Workflow Series on TechNet Magazine

Mon, 12 Aug 2013 13:51:33 +0000

As most folks are aware, I’ve been writing the Windows PowerShell column for Microsoft’s _TechNet Magazine _for… wow, going on 7 years now. For 2013, I was doing a serialized column on PowerShell Workflow, introducing a bit of the technology at a time in each month’s article. Eagle-eyed observers will note that the series has “paused,” with no new articles in July or August.
First, I’m sorry for the interruption. Unfortunately, right now Microsoft is re-evaluating and re-positioning TechNet Magazine (perhaps in line with a larger re-considering of the TechNet brand, where they recently discontinued the subscription product), and for the time being the company is sticking with internally generated content for TechNet Magazine. I’m hopeful the company will come to a decision soon, and I’ll try and keep you posted here.
My past columns (all 77 of them) are still online and accessible, along with hundreds of other articles stretching back almost 8 years.

A Quick #PowerShell #PSHSummit Update (Europe & NA)

Thu, 08 Aug 2013 20:44:11 +0000

PowerShell Summit North America 2014, April 28-30 (special precon on April 27) is open for registration to our 2013 alumni, shareholders, and to TechLetter subscribers. The alumni block will be released on August 15, and the subscriber block on September 15th; shortly after, sales will be open to the public. If you’re a shareholder, alumni, or subscriber, and you didn’t get your registration in e-mail, drop me a line (use the Contact link in the Site Info menu). Please only contact me if you’re anxious to register right now, so I don’t get swamped.
North America will be in Bellevue, WA, adjacent to Microsoft offices up there; we will investigate a move East for the 2015 show, just to perhaps spread the love a bit. We know SEA isn’t the cheapest travel destination.
North America’s call for topics should start fairly soon, and that information will be posted here, along with information on how to submit prospective sessions. I won’t be taking the lead on that process, but some of my fellow Board members will be, so watch for their posts.
PowerShell Summit Europe 2014 is being tentatively scheduled for September or October 2014. Our city shortlist includes Munich, Milan, and Amsterdam; we’re too far out at this point to make inquiries with prospective venues (they usually work only 8-12 months out), but we’ve assembled a list to contact over the next couple of months. Venue pricing and availability (and suitability) will be a significant set of factors in the final city selection, and we’ll post details right here.
You’ll notice a “PowerShell Summit” post category here on PowerShell.org; that’s your one and official source for news and info, with our Summit Page being your one and official source for more static information on both events. You can follow @PSHSummit on Twitter, which will be a good way to receive notifications of new posts here, but which will not contain any information not available on this site. We also try to hashtag #PSHSummit on Twitter, if you’d like to watch out for that.

Is this list "Everything" in PowerShell?

Tue, 06 Aug 2013 20:11:04 +0000

Soooo…. it’s time for me to start looking at updating my various training materials (books, videos, courses, whatnot) for v4.
I’m going to, with at least some of these, take an all-versions approach. I’ll teach what’s in v2, then cover what v3 added, then cover v4, etc. It’ll be easier to maintain over the upcoming years.
For right now, I’m trying to assemble an organized topic list of “everything” the shell does. Now, I need to wrap that in an important caveat: I’m aiming at admins. Not developers. I’m not saying devs aren’t a great audience, but for this project I need to constrain my scope to just the admin audience. I’m also focused mainly on what the shell does _natively, _with only a few diversions into external or underlying technologies. Those are fixed caveats for this project - no exceptions.
Right now I"m kind of chunking the list into what I feel can be taught (by me) in 20-30 minutes, or a book chapter, or something like that. This isn’t necessarily how the material will be presented - this is just me organizing my thoughts so as to not miss important stuff.
So, given the list below, what do you feel is missing?
(Numbers are major topics; letters are basically my mental notes about what the topic might include that I might otherwise forget; like I said, this isn’t meant to be a real book outline - it’s just a topic list)
PowerShell Core

Series Introduction and Lab Setup
Windows PowerShell Introduction and Requirements
Finding and Discovering Commands
a. Importing modules and snapins
Interpreting Command Help
Running Commands
Running External Commands: Tips and Tricks
a. $Lastexitcode
Working with PSProviders and PSDrives
Variables, Strings, Hashtables, and Core Operators
a. Double quote tricks, subexpressions
b. Here-strings
c. Escapes
d. Variable types
e. Arrays
f. Math operators
Regular Expression Basics
a. Basic regex language
b. ““Match
c. Select-String
Learning the Pipeline: Exporting and Converting Data
Understanding Objects in PowerShell
Core Commands: Selecting, Sorting, Meauring, and More
How the PowerShell Pipeline Works
Formatting Command Output
Comparison Operators and Filtering
Advanced Operators
Setting Default Values for Command Parameters
Enumerating Objects in the Pipeline
a. Working with object methods
Advanced Date and String Manipulation
Soup to Nuts: Completing a New Task
PowerShell Remoting
PowerShell Remoting Basics
Persistent Remoting: PSSessions
Implicit Remoting: Using Commands on Another Computer
Advanced Remoting: Passing Data and Working with Output
Advanced Remoting: Crossing Domain Boundaries
Advanced Remoting: Custom Session Configurations
Web Remoting: PowerShell Web Access
WMI and CIM
WMI and CIM: WMI, Docs, and the Repository
WMI and CIM: Using WMI to Commands Query Data
WMI and CIM: Using CIM Commands to Query Data
WMI and CIM: Filtering and WMI Query Language
WMI and CIM: Associations
WMI and CIM: Working with CIM Sessions
WMI and CIM: Executing Instance Methods
Jobs
Background Job Basics: Local, WMI, and Remoting Jobs
Scheduled Background Jobs
Scripting in PowerShell
PowerShell Script Security
Prompting for Input, Producing Output
Creating Basic Parameterized Scripts
PowerShell Scripting: Logical Constructs
PowerShell Scripting: Looping Constructs
a. Break and Continue
PowerShell Scripting: Basic Functions, Filters, and Pipeline Functions
PowerShell Scripting: Best Practices
a. Line breaking
b. Splatting
c. Formatting
d. Source Control
e. Etc.
PowerShell Scripting: From Command to Script to Function to Module
PowerShell Scripting: Scope
PowerShell Scripting: Combining Data from Multiple Sources
a. Ordered hashtables
Advanced Functions (“Script Cmdlets”)
Advanced Functions: Adding Help
Advanced Functions: Parameter Attributes
Advanced Functions: Pipeline Input
Advanced Functions: Parameter Sets
Advanced Scripting Techniques
Creating Private Utility Functions and Preference Variables
Adding Error Capturing and Handling to a Function
Advanced Error Handling
a. Variety of error capturing options
b. Catching multiple exceptions
c. Etc.
Error Handling the Old Way: Trap
Debugging Techniques
Creating Custom Formatting Views
Creating Custom Type Extensions
Working with SQL Server (and other) Databases
Working with XML Data Files
Supporting ““WhatIf and ““Confirm in Functions
Troubleshooting and Tracing the Pipeline
Using Object Hierarchies for Complex Output
Creating a Proxy Function
PowerShell in the Field
From the Field: Enhanced HTML Reporting
From the Field: Trend Analysis Reporting
From the Field: Scraping HTML Pages
PowerShell Workflow
Introduction to PowerShell Workflow
Desired State Configuration
Desired State Configuration: The Basics
Desired State Configuration: Configuration Scripts
Desired State Configuration: Writing Resources
Globalizing a Function or Script
Discovering and Using COM Objects
Discovering and Using .NET Classes and Instances
Writing Scripts for Other People
Controller Scripts: Automating Business Processes
Controller Scripts: A Menu of Tools
Creating a GUI Tool: The GUI
Creating a GUI Tool: The Code
Creating a GUI Tool: The Output
Creating a GUI Tool: Using Data Tables
Advanced Core Techniques, Tricks, and Tips
Using Type Accelerators
a. [ADSI]
b. [XML]
c. [VOID]
d. where they”™re documented
The Big Gotchas in PowerShell
a. (from the ebook list)
Fun with Profiles
a. Profiles and hosts
b. Prompt
c. Colors
d. Get a credential
Random Tips and Tricks
a. Redirection changing pipelines
b. $$
c. $?
d. Dot sourcing

]]>

PowerShell Great Debate: Script or Function?

Tue, 06 Aug 2013 14:31:41 +0000

One of the most frequent comments in The Scripting Games this year was along the lines of, “you should have submitted this as a function, not a script.” Of course, the second-most frequent comment was something like, “you shouldn’t have submitted this as a function.”
Let’s be clear: if an assignment explicitly asks for a function, you should write one. What we’re debating are the pros and cons of a single tool being written one way or another. Read that again: _a single tool. _If you’re writing a library of tools, it’s obvious that writing them as functions for inclusion in a single file (like a script module) is beneficial.
Some argue that any tool is potentially going to be included in a function… so why not write it that way to begin with? Others argue that functions are a smidge harder to test, so why not just write a script?
This is a debate I don’t personally have a strong stake in. I mean, we’re literally talking about a _single keyword. _Take any script, add the function keyword, a function name, and a couple of curly brackets, and you’ve got a function. This really shouldn’t be a criteria when you’re looking at a contest entry… or even when you’re looking at something a colleague offered to you.
Or should it?
[boilerplate greatdebate]

PowerShell Great Debate: PowerShell Versions?

Thu, 01 Aug 2013 14:32:38 +0000

Today’s Great Debate is a bonus, offered from former team member June Blender. Take it away, June!
Like several of the excellent debates in our Great Debate series, this debate issue arose during in Scripting Games 2013 when different judges used different selection criteria to evaluate entries.
Some judges, like me, wanted to see evidence that the scripter had studied all features of the newest version of the Windows PowerShell language and selected the best approach for their solution. Other judges wanted the solutions to work on as many computers as possible.
Outside of the Scripting Games, this issue is very practical and very important. If you"™re writing a script to work on particular computers in your enterprise, you know which versions of Windows PowerShell are installed and which features you can use. But when you write a shared script or functions for a module, your scripts/functions can run in any environment.
What"™s the version best practice?
I think we can all agree that a #Requires statement should appear in any shared script.

#Requires -Version [.]In fact, maybe we need a version property of commands that can be queried by using Get-Command, like the PowerShellVersion property of modules?
But, beyond that, should you restrict yourself to features in the oldest supported version of Windows PowerShell, or the most common version, or can you use features in the newest version, even if your scripts don"™t run on all computers in all enterprises?
Sometimes, the answers are trivial. The simplified syntax in Windows PowerShell 3.0 that omits curly braces {} and “$_.” is just syntactic sugar for the original syntax. We might decide that it"™s best to avoid it unless you"™re sure that all computers are running at least 3.0.
At the other extreme are features that don"™t have any equivalent in a previous version. What if your module would benefit from using scheduled jobs, CIM commands, or workflows? Must you avoid them?
In the middle are cases where you can use a somewhat equivalent feature. Can you use Get-CimInstance, or are we forever tied to Get-WmiObject? Can you use PSCustomObject or are you committed to Add-Member? Do you need to write Types.ps1xml files when dynamic type data would suffice?

]]>

Articles from August 2013 on PowerShell.org - Welcome Automaters!

Regular Expressions are a -replace's best friend

PowerShell Great Debate: "Fixing" Output

PowerShell.org's Azure Journey, Part 4: Incoming Advice and Fun Facts

PowerShell.org's Azure Journey, Part 3: Load Testing [UPDATED]

Baseline