Friday Fun: A PowerShell Tickler

elmoI spend a lot of my day in the PowerShell console. As you might imagine, I often have a lot going on and sometimes it is a challenge to keep on top of everything. So I thought I could use PowerShell to help out. I created a PowerShell tickler system. Way back in the day a tickler system was something that would give you a reminder about an impending event or activity. What I decided I wanted was a tickler that would display whenever I started PowerShell.

This doesn’t replace my calendar and task list, but it let’s me see events I don’t want to miss right from PowerShell. As I worked through this idea I ended up with a PowerShell module, MyTickle.psm1, that has a number of functions to managing the tickle events, as I call them. From PowerShell I can get events, add, set and remove. I thought the module would make a good Friday Fun post because it certainly isn’t a high impact project but it offers some ideas on building a module and functions that I hope you’ll find useful.

The module for right now is a single file. Here’s the file and below I’ll talk about.

You should be able to copy the code from the WordPress plugin and paste it into a script file locally. You can call it whatever you want just remember to use a .psm1 file extension. The module uses some PowerShell 3.0 features like ordered hashtables but you could revise to have it run in PowerShell 2.0. Fundamentally it should work in both versions.

The events are stored in a CSV file that I reference with a module variable, $TicklePath. The default is a file called mytickler.csv which will be in your WindowsPowerShell folder under Documents. The module also defines a variable called $TickleDefaultDays, with a default value of 7. This displayed events to those that fall within that range. To use, I added these lines to my PowerShell profile.

The result, is that when I launch a new PowerShell session I see something like this (the message about help updates is from something else so disregard):

Here’s how it works.

The Show-TickleEvent function imports events from the CSV file that will happen within the next 7 days. Each object also gets an additional property that is a timespan object for how much time remains. The function then parses event information and constructs a “box” around the events.

I set a foreground color depending on how imminent the event is and then write each event to the console, wrapped in my border.

I purposely used Write-Host so that I could color code events and because I didn’t want the profile to write anything to the pipeline. Because the module is loaded at the start of my PowerShell session, I can always run Show-TickleEvent and event specify a different number of days. If I want objects, then I can use the Get-TickleEvent function which will import the csv events based on a criteria like ID or name. The function uses parameter sets and I create a filter scriptblock depending on the parameter set.

When I import the CSV file, I add types to the properties because otherwise everything would be a string, and then pipe each object to my filter.

These objects come in handy because they can be piped to Set-TickleEvent to modify values like event name, date or comment. Or I can pipe to Remove-TickleEvent to delete entries. The deletion process in essence finds all lines in the CSV file that don’t start with the correct id and creates a new file using the same name.

Finally, after accidentally wiping out event files, I added a simple backup function copies the CSV file to the same directory but with a .BAK file extension. You could specify an alternate path, but it defaults to the WindowsPowerShell folder.

Hopefully I won’t miss important events again, of course assuming I add them to my tickler file. I’ll let you play with Add-TickleEvent to see how that works or you could always modify the CSV file with Notepad.

If you actually use this, I hope you’ll let me know.

3 thoughts on “Friday Fun: A PowerShell Tickler

  1. Pingback: Microsoft Most Valuable Professional (MVP) – Best Posts of the Week around Windows Server, Exchange, SystemCenter and more – #29 - TechCenter - Blog - TechCenter – Dell Community
  2. The solution that I came up with was to leverage the All Users Startup option in Windows to launch a script that would check to see if the folder that holds the PowerShell profile scripts exists. If it exists, the script terminates and all is well. This happens on every interactive login, but takes only a second. If the folder does not exist, the will kick off a creation of the scripts based upon a preset profile definition that includes the targeting & naming of the logs, starting the transcript, and loading the SharePoint module. The profile definition can be completely customized making this a viable approach for admins of other technologies, not just SharePoint.

Comments are closed.