Learn about Windows PowerShell
Summary: Microsoft Scripting Guy, Ed Wilson, talks about using the Windows Powershell transcript tool to keep track of commands that are run in a session.
Microsoft Scripting Guy, Ed Wilson, is here. I am busting out all over and I hardly know where to begin. Suffice it to say that TechReady 15 in Seattle was awesome. I especially loved the Ask the Experts session on Wednesday night. I always love the Ask the Experts sessions—the one at TechEd in Orlando this year was awesome, as was the one in Atlanta the year before.
Of course, I thought my session, Using Windows PowerShell 3.0 to Manage the Remote Windows 8 Desktop was really cool (and well received)—so I am going to present a version of it at PowerShell Saturday in Charlotte, North Carolina on September 15, 2012. The registration for this high-profile event opens tomorrow, July 30, 2012. The PowerShell Saturday event in Columbus, Ohio sold out in 13 days, and I expect the one in Charlotte to be no different. Therefore, if you want to attend, you need to begin queuing up at your keyboard around midnight Pacific Time in preparation for the 200 tickets to go on sale.
Recently, JRV posted on one of my blog posts (he does that a lot), and he stated that I must have access to some secret inside vault of information (my words, not his) because of all the cool stuff I come up with in my postings (again, my words, not his). This brings up an interesting story…
When Microsoft hired me eleven years ago, one of the things I was really looking forward to was getting to see “all the secret stuff.” After a month, I emailed my friend Bill (Mell, not Gates), and I told him, “Dude, there is no secret stuff.” Obviously, when products are in development, we need to guard our secrets. But after it ships, there is no secret vault of information (at least not where I am concerned).
One of the really neat features of Windows PowerShell is that it is self-describing. This means that I use Windows PowerShell to learn stuff about Windows PowerShell. There are three powerful tools for doing this: Get-Help, Get-Member, and Get-Command. Learning how to use each of these cmdlets to their maximum potential is essential to becoming a Windows PowerShell guru. I will add two additional cmdlets to this list: Start-Transcript, and for Windows PowerShell 3.0, Show-Command.
Note The first thing you want to do in Windows PowerShell 3.0 is open Windows PowerShell as an administrator and run the Update-Help –module * -Force command. This will ensure that you have the latest Help information. For Windows PowerShell 2.0, you use Get-Help cmdletname –online to see the most up-to-date help.
Start-Transcript? You may ask, “What’s up with that?” Well, by using the Start-Transcript cmdlet, I record the commands and the output from my explorations. In fact, I find the cmdlet so useful that it is in my Windows PowerShell console profile. Unfortunately, it does not work in the Windows PowerShell ISE, although I did write a function that includes some of the capability in my post, Create a Transcript of Commands from the Windows PowerShell ISE.
Therefore, if I find a really cool thing I can do in Windows PowerShell, I already have a record of that cool thing. There is only one problem with this approach: it quickly becomes unruly. With no management of the transcripts, it does not take long to fill up the Documents folder as shown here on my Windows 8 laptop.
With opening and closing the Windows PowerShell console several times a day, it does not take very long until the folder is filled with transcript files. One thing that can help in finding commands is to use the desktop Search tool. (I always ensure that I do a full text index for text files in addition to all of the Windows PowerShell type of files). With the Content view of files, you can easily see an idea of what is inside of a particular transcript file. This is shown in the image that follows.
On the other hand, I like to have something a bit more permanent than a simple search result. To this end, I wrote a Windows PowerShell script that parses a folder full of Windows PowerShell transcript files, and it pulls out all of the Windows PowerShell commands (those that work and those that did not work, so keep that in mind) and it puts them into a new text file. The script is rather cumbersome, and it is one that I wrote nearly four years ago. But a great thing about Windows PowerShell is that the team is committed to saving your investment—in terms of learning Windows PowerShell and in terms of writing Windows PowerShell scripts. So nearly all of the stuff I did on Windows PowerShell 1.0 (and to some extent, even during the beta of Windows PowerShell 1.0) still work today.
I copy the transcript files to a transcript folder (not in my Documents folder), and then I open the ParseTranscriptPullOutCommands.ps1 script in the Windows PowerShell ISE, and I edit the Path parameter to point to my new transcript folder location. When I run the script, it parses all of the transcript files in the folder, and it pulls out all the commands. It works great. The image that follows is the text file that is produced by running the script.
I uploaded it to the Scripting Guys Script Repository: Pull PowerShell commands from transcript file.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
right! Transscripts are very useful, if you want to habe a look at what happened during the session.
It is probably a little bit unknown and seldom used in general, but it sure is worth to keep in mind!
Extracting the commands with your script is quite straight forward and easy to understand.
Using the wildcard "PS C*" is a bit "optimistic" because we restrict it to the "C drive" which might not
be apropriate in each case. ( even the prompt could be quite different ... but let's put that aside :-)
@K_Schulte Hey, I wrote that script more than 4 years ago ... if I wrote it again today, I would write it completely differently ... but the cool thing about Windows PowerShell is that we are on our third version (PowerShell 3.0) and a script I wrote back for PowerShell 1.0 still works just fine. So because it works (for me) there is no need to waste time re-writing it.