In the last post, I discussed some of the reasons why you might want to write your own PowerShell hosting app. I realized later that I didn’t define what that meant. In general, there are 2 ways to include PowerShell technology in an application. Use the PowerShell objects (in the System.Management.Automation.* namespaces) to execute scripts, …
I’ve mentioned before that I use a homegrown PowerShell host in my work. I have been more than pleasantly surprised at how easy and how rewarding this is. In the last few weeks, I’ve seen a few articles that have gotten me thinking about writing a series of blog posts about how to get started. …
When preparing a PowerShell training class for a group of DBAs, I realized that there were some parallels between basic SQL and basic PowerShell commands. A (very) basic SQL statement has the form: SELECT <COLUMNS> FROM <TABLE> WHERE <CONDITION> ORDER BY <EXPRESSION> I noticed that a very common idiom for PowerShell pipelines* was: <data source …
In a recent post , I showed how to get a list of Scheduled Tasks as objects using PowerShell and Import-CSV. In that, I included the following line of code:
In this post, I’ll try to explain why I did that.
There are a few approaches to manipulating scheduled tasks in PowerShell.
* WMI – Useful if you are only going to manipulate them via script. The tasks will not be visible in the control panel applet.
* SCHTASKS.EXE – Works ok, but has a somewhat arcane syntax, and is a text-only tool.
* Task Scheduler API -Best of both worlds, but only on Vista (not XP).
Why am I writing a blog about PowerShell? The answer is simple. I haven’t been as excited about a technology since I first learned SQL. PowerShell allows me to do my job in a much more consistent, flexible, and scalable way.
What is it about PowerShell that has me so fascinated?