PowerShell speaks WPF and that means you can build a XAML-based GUI for your PowerShell script. It's easy to do - here's a small demo:
Blog
Admit it. Be honest now. We've all done it. We've run a command against a batch of users and forgot to limit the scope to the ones we were really targeting.
Some environments have multiple domains in a single Active Directory forest. Working with Powershell in the same domain as your user account is easy, but what do you do when you need to run Powershell commands in one of the other domains? Change context. Powershell can traverse AD as a file system, and this allows an easy way to change the context for your script. Keep in mind, that to be able to load the AD Powershell module, you need to install the RSAT tools on the workstation that you are using to run your commands.
I've been writing a lot of custom applications lately, many using Powershell and then packaged using Sapien's Powershell Studio. Something that I've had to do a few times lately is provide applications to allow a non-privileged user to manipulate a user account in a different domain. There are a few pieces that go into this, including mounting AD: as a provider and then "cd" to that "drive". To make all of this context changing work, it requires embedding the RunAs command into the executable to allow the script to run as an admin account from the domain being affected. The problem with that Powershell can not read the current true username from $env:username. Since it is important to log who is actually making changes to another persons account, this is a problem.