Search results for 'app:weblogs' matching tags 'Windows PowerShell', '2012 Scripting Games', and 'scripting techniques'

Scripting Games Wrap Up Part 2: Neatness Counts and Other Stuff

Anonymous — Sun, 15 Apr 2012 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, talks about the importance of formatting your Windows PowerShell code, returning objects, and other stuff.

Microsoft Scripting Guy, Ed Wilson, is here. It is Sunday in Charlotte, North Carolina. I have been busy grading scripts since early this morning. The last event, Event 10, appeared on April 13, but there is still one more week during which time contestants are turning in their final scripts. This is the time when the leaderboard will begin to dramatically shift. So I still cannot talk about issues from the last five events, but I can talk about some of the earlier events.

Neatness counts

I am not talking about being really crazy and making sure that everything lines up perfectly. I had a professor in college who used to take a ruler to the green bar paper we had to turn in, and he subtracted 1 point for each space that was not perfectly aligned. Regardless of how the code ran, it had to look perfect—in fact; it had to print out perfectly. I am NOT talking about that at all.

But, keep in mind that a fundamental concept is that you should be able to read and understand your script. If you can do that, you reduce the amount of troubleshooting by at least 50% (and no, I have not actually measured that—it is more of a guess). It is in my Windows PowerShell Best Practices book in the chapter about troubleshooting scripts.

So, what am I talking about when I talk about neatness? Here are a few quick guidelines:

Avoid making someone scroll. Keep your code to the width of your screen, so that it does not flow off of the screen. When code is hidden from view, it is easy to make mistakes.
Avoid using line continuation marks. The grave accent ( ` …I call it a backtick) is line continuation. It makes code hard to read, and is especially error prone. I have had many scripts that ran perfectly on my computer. Then when I posted them to the Hey, Scripting Guy! Blog, they no longer worked because it picked up an extra space or something. The grave accent is picky, and it is best to avoid it if possible.
Break your code at the pipe ( | ) character. Leave your pipe characters on the right, and thus avoid line continuation.
Indent subordinate clauses. Let’s say that you have an IF statement and your condition on one line. Now you have an ELSE clause. Intent the ELSE clause. How much? I generally use two spaces. The reason is that it is a visible indicator of an indent (it is easier to spot than one space), but it does not use as much space as a tab. Remember Rule 1: Keep your code narrow and avoid scrolling. If you use eight spaces for a tab, and you press tab tab tab, you just ate up 24 spaces, and you do not have much room for code after that. So I keep my indents to two spaces.
Avoid using the Tab key for your tabs. This is because an actual Tab key (ASCII 9) is different than a space (ASCII 32). Some editors allow you to substitute spaces for the Tab key, and they even allow you to specify how many spaces to insert when you do hit the Tab key. This is useful, because some mediums do not correctly interpret a tab when it shows up in code. For this reason, I avoid using the actual Tab key, and I instead use spaces.
Consider where you put the braces ({ }). This is really a personal preference. I played with putting the braces on their own lines, and lining up the opening and the closing brace. I fact, I still often do that. But at times, when the script is short, I will open the brace on the beginning line, and close it at the end of the last line; and therefore, the braces are not on their own individual lines.
Avoid in-line comments. Instead put the comments on the line ahead of the line it comments. This is because when code is moved around, edited, or whatever, an in-line comment can break the code that follows. In addition, in-line comments are not as noticeable as comments on their own individual lines.

Return an object…please

It is best if you return an object. This is because anyone who uses your code can pipe the results to other cmdlets, such as Where-Object, Sort-Object, or even Format-Table or Out-GridView. But they are not required to do so. If you spend a lot of time in your script creating your own custom formatting, the person who uses your code cannot process it further. When you send something to Format-Table, Format-List, or Format-Wide, you are done. No further processing can be done because you no longer have the original object—you have a series of formatting objects that behave completely differently than the original object. When you return an object, you permit others to use your code in the way that they want to use it. It makes the eco-system better.

Meet the requirements

If my boss asks me to write a script that does x, y, and z, and I spend two days creating a really cool script that does a, b, and c, my boss is not going to be too happy. Because although he now has a script that does a, b, and c, he still needs a script to do x, y, and z. Part of developing solutions involves first analyzing the requirements, determining the inputs and the outputs from the script, examining use case scenarios, and finally, beginning to write the code. In fact, in many projects, the actual coding time is far less than the other tasks put together.

Well, that is about all I have time for today. I have a lot of scripts to grade. Take care, and I will see you tomorrow when I will have expert solutions to Beginner and Advanced Events 1.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Simplify Your PowerShell Code by Using a Compound Where Clause

Anonymous — Sat, 14 Apr 2012 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, talks about a couple of issues he saw while grading scripts for the 2012 Windows PowerShell Scripting Games.

Microsoft Scripting Guy, Ed Wilson, is here. The Scripting Wife and I are in Atlanta for SQL Saturday #111. I will be talking about Windows PowerShell and SQL best practices. One of the great things about the Scripting Games is seeing what other people are doing. When you are the Microsoft Scripting Guy, it is good to see where people still have some confusion, and then use that information to generate ideas for blog posts. I am not alone in this endeavor. I saw a tweet the other day that said the person was generating a huge list of subjects for blog posts as a result of the 2012 Scripting Games. Today I want to look at a few things that caused me to repeat myself over and over again as I was grading scripts.

The mystery of the compound Where clause

In Windows PowerShell 3.0, we have simplified the simple Where clause. I am not going to write about that right now, but it is enough to say that when you have a single condition, it is easier to write in Windows PowerShell 3.0 than in Windows PowerShell 2.0. But there are many times when you want to use a compound Where clause. For example, Beginner Event 3 requires you to find running services that also support a Stop command. I saw lots of scripts where the person obviously did not know about using a compound Where clause. Here is one such example:

gsv -computername localhost | where {($_.status -eq "Running") -and ($_.CanStop -eq $true)}

Now, there is nothing wrong with this line of code—in fact, it meets the needs of the scenario, and it works perfectly fine. But the code can be simplified by using a compound Where clause. Simple and compound do not often go together, but they do here. Here is the way I would write the Where clause:

where { $_.status -eq 'running' -and $_.canstop }

Notice, that instead of having two separate groupings, I in fact, have no grouping at all. (The grouping is the parentheses.) The compound Where clause says where the status of the current object (the $_ represents, the current object in the pipeline) is equal to Running. It also says, AND $_.CanStop. (I will talk about this in a little bit.) Where is an alias for the Where-Object cmdlet. The question mark (?) is also an alias for the Where-Object cmdlet. But notice that in the script block of the Where-Object cmdlet, condition one is equal to Running, AND condition two exists.

What is a Boolean value, and what do I do about it?

In the get running services that also accept a Stop command event, there is a property called CanStop that exists on the System.ServiceProcess.ServiceController object. This CanStop property is shown here.

PS C:\Users\ed.IAMMRED> Get-Service | Get-Member canstop

TypeName: System.ServiceProcess.ServiceController

Name MemberType Definition

---- ---------- ----------

CanStop Property System.Boolean CanStop {get;}

Notice that under the definition, it says that the CanStop property is a System.Boolean. Boolean values are On/Off, True/False, -1/0, Enabled/Disabled, Exist/Don’t exist, and so on. One of the cool things about Windows PowerShell, is that if something exists, and it is a Boolean value, I only need to say Where plus ThePropertyOfTheObject. Let’s go back to Beginner Event 3. So, in the long version of the Where clause, the writer had the following:

where {($_.status -eq "Running") -and ($_.CanStop -eq $true)}

As I mentioned, it works. But it can be shortened by saying –and $_.CanStop. Here we are saying, “Does the CanStop property exist on the object?” If it does, this is all we want. Therefore, I can reduce this by saying, “Does it exist?” This is shown here.

where { $_.status -eq 'running' -and $_.canstop }

The nice thing is that I can negate the Boolean value. For example, if I want the running services that do NOT accept a Stop command, I have several choices. I would probably use the Not operator (!). This is shown here.

where { $_.status -eq 'running' -AND !$_.canstop }

Most of the time, I will use grouping around the Boolean value to make the code a bit clearer. This is shown here.

where { $_.status -eq 'running' -AND !($_.canstop)

If you do not like the exclamation point (!) for the Not operator, you also can use the –not operator. This is shown here.

where { $_.status -eq 'running' -AND -not $_.canstop }

Once again, I generally put grouping around the Boolean value to make the command easier to read (at least for me). This is shown here.

where { $_.status -eq 'running' -AND -not ($_.canstop) }

Not handling the default

I also saw lots of scripts that had a hardcoded value for ComputerName. Some said Server01, others said NameOfRemoteServer. I am calling this out because it is a problem. It causes someone to immediately edit the script before they can run it. I wrote a really good blog about this issue that I will refer you to: Create and Use Default Values in PowerShell Scripts.

Well, that is about it for now. There are thousands of scripts that need to be graded in the next few days. So until tomorrow, have a great day.

Ed Wilson, Microsoft Scripting Guy

2012 Scripting Games Advanced Event 9: Perform an Inventory

Anonymous — Thu, 12 Apr 2012 05:00:00 GMT

Summary: In Advanced Event 9, you are required to perform a hardware inventory and write the information to an XML file.

About this event

Division	Advanced
Date of Event	4/12/2012 12:01 AM
Due Date	4/19/2012 12:01 AM

Event scenario

You are a network manager at a medium-sized organization, and it is time to perform an inventory of computers on the network. You need to collect the following information: computer name, domain name, computer manufacturer, computer model, number of processors, number of cores, speed of processors, processor ID, MAC address of the primary network interface, operating system version (including service pack level), and the amount of physical memory that is installed (displayed in the most logical units). Your output should be stored in an XML-formatted file in the Documents special folder. The file name should be the Computername (including domain name) and the date in year, month, day format.

Design points

There are several requirements for this scenario:

Obtaining the information.

Storing the output in XML format.
Creating the file in a specific location
Creating the file name in the specific fashion, for example:
Mycomputer.mydomain.20120412.XML

Because the script will run locally on the computer, it does not need the ability to run against remote computers.
Extra points for adding error handling for missing properties

2012 Scripting Games links

2012 Scripting Games: All Links on One Page

Ed Wilson, Microsoft Scripting Guy

2012 Scripting Games Advanced Event 6: Compute Uptime for Multiple Servers

Anonymous — Mon, 09 Apr 2012 05:00:00 GMT

Summary: In Advanced Event 6, you are required to compute the uptime for multiple servers.

About this event

Division	Advanced
Date of Event	4/9/2012 12:01 AM
Due Date	4/16/2012 12:01 AM

Event scenario

You are the server lead for a medium-sized enterprise, and your boss has tasked you with computing the uptime of all servers on the network on a daily basis. This information will be stored in a Microsoft Excel spreadsheet for ease of analysis. Because of the large number of servers, the script will take some time to run; therefore, your boss has decided to compute all uptime as of 8:00 AM local time. If a server reboots after 8:00 AM, but before the report runs, the uptime is zero, and it will be factored into the report for the next day. Create a new report file each day for all the servers on the list. An acceptable output is shown in the image that follows.

Design points

Your script should be capable of running more than once per day. If it does, it should not generate an error.
Create the CSV file in the logged-on users Documents special folder.
The file name should use the year, month, and day that the report runs, with the addition of _Uptime to the file. It will appear like the following: 20120409_Uptime.csv
The column headers should appear on the first row only. The headings should be ComputerName, Days, Hours, Minutes, Seconds, and Date.

2012 Scripting Games links

2012 Scripting Games: All Links on One Page

Ed Wilson, Microsoft Scripting Guy

2012 Scripting Games Beginner Event 6: Compute Uptime for Local Computer

Anonymous — Mon, 09 Apr 2012 05:00:00 GMT

Summary: In Beginner Event 6, you are required to compute the uptime for the local computer.

About this event

Division	Beginner
Date of Event	4/9/2012 12:01 AM
Due Date	4/16/2012 12:01 AM

Event scenario

You are the main network administrator for a small company. As such, your duties consist of a variety of functions, including assisting the Help Desk when they get behind. Recently, your manager has become concerned about server uptime. He wants you to write a script that will display how long a server has been “up.” He said that he is not concerned with anything fancy—he just wants a general idea. The only real guidance he provided for the task is, “Use WMI. There is a class called Win32_OperatingSystem that should do the trick for you. Tell me the server name, and how many days, hours, and minutes the server has been up.”

The output that is shown in the image that follows meets the boss’s requirements.

Design points

Your solution only needs to run locally.
Your script should be easy to read and easy to understand.
Your script is only concerned with the uptime for the local server, calculated with the current time. Do not worry about time zones or about comparing up times with different computers.
Pay attention to the formatting of the output and the script itself.

2012 Scripting Games links

2012 Scripting Games: All Links on One Page

Ed Wilson, Microsoft Scripting Guy

Six Observations about 2012 Scripting Games Early Entries

Anonymous — Sat, 07 Apr 2012 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, discusses some of the early entries to the 2012 Windows PowerShell Scripting Games.

Microsoft Scripting Guy, Ed Wilson, is here. One of the things that is always a challenge in creating the Scripting Games is trying to come up with the right balance between challenge, practicality, and appropriateness. In some respects, it is like attempting to walk a six inch I-beam 100 stories up in the air. It looks more precarious that it really is. But like one sage told Harry Potter, “You best keep your wits about you.” And so it is with the Scripting Games—you best keep your wits about you.

Complexity is not always required

This year, I tried. I really did try to reduce complexity. One of my goals for this year’s Scripting Games is to force you into the documentation (think about using the Get-Help cmdlet on a regular basis) so that you will discover some hidden gem hidden amongst the thousands of parameters that exist for the hundreds of Windows PowerShell cmdlets. Obviously, I was not entirely successful.

The point is this: In Windows PowerShell, lots of tasks are ridiculously simple when you have figured out the secret. Of course, when a parameter exists and it is documented in Get-Help, I am not sure that it really qualifies as a secret—but hey, who am I to argue?

Some things really are easy

It has become nearly a cliché since I first wrote that there are three important cmdlets in Windows PowerShell. These three cmdlets are Get-Help, Get-Command, and Get-Member. It was really important in Windows PowerShell 1.0 when I first set this down. For beginners, in Windows PowerShell 2.0 (and especially in Windows PowerShell 3.0), I do not think that Get-Member is quite as important as the other two discovery cmdlets. This is because each new version adds new cmdlets and additional parameters that bring interesting members to the foreground, therefore make discovering obscure members less important. Even with Windows PowerShell 3.0, using Get-Member is important for the more advanced scripter. But each new version makes it easier to perform common tasks, so digging into the object model becomes less of a daily task. I think that these days, I use Select-Object and Measure-Object more often than I use Get-Member.

Scripting is not required

I know they are called the Scripting Games, but this is more a legacy artifact of the VBScript world that spawned the first Scripting Guys and consequently the first Scripting Games. Nearly all of the Beginner events in this year’s Scripting Games (and many of the Advanced events) can be completed with a one-liner. To some, these famously (or infamously) powerful commands epitomize the elegance of the Windows PowerShell language. You can save a one-liner in a .ps1 file and voila, you have a script. Of course, you can also save your one-liner in a text file if you wish. In fact, I actually do both. I have lots of .txt files that contain various one-line Windows PowerShell commands that I spent a decent amount of time creating; and therefore, I wanted a way to save the product of my brilliance.

Keep in mind that at its most basic element, a Windows PowerShell script is simply a collection of one or more Windows PowerShell commands. If I can type it in the Windows PowerShell console, I can place it in a .ps1 file, and I have a Windows PowerShell script. This is one of the great things about Windows PowerShell—it is a shell. It is also a scripting language. It is also a shell. It is also a scripting language. It is like a chocolate peanut butter cup—it is chocolate, but it is also peanut butter. When I teach a Windows PowerShell class, I generally spend the first two days working exclusively inside the Windows PowerShell console. But, I make it really clear to the students that everything we are doing applies to Windows PowerShell scripting. I love a tweet Jeffrey Hicks made when he showed dumping the commands from command history to a .ps1 file and automatically creating a script from his Windows PowerShell console command history. This is the perfect example that working interactively at the Windows PowerShell console is, in a real sense, scripting.

Now, let’s get back to my Windows PowerShell classes. Even after I finally introduce the Windows PowerShell ISE, I still end up doing many examples directly in the Windows PowerShell console. One reason is because the Windows PowerShell console has a built in transcription tool, and the Windows PowerShell ISE does not. Being able to hand out a transcript of everything that I typed in a class makes a great teaching tool. It also prevents writer’s cramp on behalf of the students.

Sometimes it seems that students are disappointed they do not do more traditional scripting in my Windows PowerShell classes. But the simple fact is that in the Windows PowerShell era, quite often scripting is not required. Many traditional tasks that required lengthy and complex scripts in the VBScript world, are simple one-liners in Windows PowerShell. Like I said, if you miss scripting, go ahead and save your one-liners as .ps1 files.

A great work ethic does not require lengthy scripts

In Windows PowerShell, often you do not need to write a big, long, complex script. In fact, I would say that on many occasions, this is true. It has quickly become the rule, rather than the exception. I can also say from experience, at times I am still too quick to fire up the Windows PowerShell ISE. After all these years of exclusively writing Windows PowerShell on nearly a daily basis, I am still surprised at how easy things can be accomplished. So what am I really saying? In Windows PowerShell, often more work goes into producing a one-liner than in creating a 15-line script. When I am making presentations to a Windows PowerShell User Group, I am often asked questions, and I will respond by firing up the Windows PowerShell ISE and dashing off a quick script to illustrate the technique I am trying to explain. At times, someone in the group will ask why I did not do XYZ. Often the answer is that I did not think of doing XYZ. Windows PowerShell is so powerful, that there is often more than one way of accomplishing the same task.

In the end, it is about getting work accomplished

In the real world, and in the real world of the 2012 Scripting Games, the end game is to accomplish work. As long as a script or a command accomplishes the task at hand, it works. Jeffrey Snover once remarked that no one learns Windows PowerShell simply to learn Windows PowerShell. Rather, they use Windows PowerShell to solve a specific problem. This is one thing I try to reflect in the Scripting Games—real-world problems seeking real-world solutions. But I do disagree with Jeffrey in one important respect. I know lots of people who have absolutely fallen in love with Windows PowerShell simply because Windows PowerShell is fun, powerful, and a great tool. Many people, including myself, find ourselves playing with Windows PowerShell and exploring the intricacies of Windows PowerShell because of this fun factor. The person who wrote Space Invaders in Windows PowerShell did not do so because his boss asked him for a Windows PowerShell port of Space Invaders. Rather he did it because Windows PowerShell is so fun to play with, and it is great that it has the ability to create fun games like Space Invaders.

Great solutions to regular problems

One reason I love the Scripting Games is that I also view myself as a learner. Whereas I write solutions to each of the tasks, I am often surprised at the sheer elegance of some of the solutions that come in from the participants. In many cases, I look at code and wonder, “Does that work?” I stare in amazement when it really does. This is one of the most exciting things about Windows PowerShell—there are many many many ways of accomplishing the same tasks. The great thing about the 2012 Scripting Games is that you work out solutions to real-world problems. I have had numerous emails from participants in prior Scripting Games where they thanked me for the games and stated that they had already had occasion to use a script at work that they wrote for the games. Cool. Learning that is fun, and useful—a great concept.

Join me tomorrow when I will continue to talk about some of the concerns I saw while grading scripts.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Troubleshoot and Repair WMI Errors

Anonymous — Thu, 29 Mar 2012 05:00:00 GMT

Summary: Learn how to use Windows PowerShell to troubleshoot and repair WMI errors.

Microsoft Scripting Guy, Ed Wilson, is here. Tomorrow is the New York City TechStravaganza. The Scripting Wife and I will be there, and we are looking forward to hanging out with Microsoft PowerShell MVPs such as Tome, Brandon, and Aleksandar. Anyway, it was late when we got to the hotel, and I was looking forward to reading a story collection by Raymond Chandler and calling it a day. I had just started on the third story in the collection, when above the constant hum of Times Square, I heard the Scripting Wife.

“Why do I always get these errors,” she exclaimed with obvious annoyance.

“Probably because you are doing something wrong,” I said not really helping the situation.

“No. In the event log. Here take a look,” she said turning her laptop to me.

The error to which she referred is shown here.

“How do you know you are always getting this error,” I asked.

“Because I always see it every time I open the Application log on my computer,” she replied.

“Well, let’s see how many times you really are getting this error,” I suggested, “Open the Windows PowerShell console, and let’s use the Get-WinEvent cmdlet to retrieve every Event 10 from Windows Management Instrumentation.”

“OK. But you are going to have to help me a bit,” she said.

“But of course. We will use a filter hash table so that we only retrieve the events from Windows Management Instrumentation that are Event 10 in the Application log. The first thing is to type the Get-WinEvent cmdlet, and call the FilterHashTable parameter. But do not press ENTER because we will build the command.”

The Scripting Wife thought for a bit, and then typed the following (she used tab expansion to complete the FilterHashTable parameter name).

Get-WinEvent -FilterHashtable

“Now we need to create the hash table for the filter. Remember that a hash table begins with the ‘at’ sign (@). Then it is the key equals the value. Each pair gets a semicolon separator,” I said.

“OK,” she said as she typed the “at” sign, and opened a pair of curly braces, “Now what?”

“The first pair is LogName equals Application. Put the word ‘application’ in quotation marks,” I said.

The following is what the Scripting wife typed.

@{logname='application'

“Now the next pair is ID equals 10. There is no need for quotation marks around the number ten. Remember, that each key value pair receives the semicolon separator.”

The Scripting Wife was all business. The she typed the following.

;id=10;

“The good thing is that the ProviderName will accept a wild card. So all you need to do is use the asterisk with the letters wmi. Make sure you also put them in quotation marks and close the curly bracket,” I said.
Here is what she typed.

providername='*wmi*'}

“Great. You are almost done. Pipe the whole thing to the Measure-Object cmdlet. You can use the alias measure for that cmdlet,” I instructed.

The following is the Scripting Wife’s completed command.

Get-WinEvent -FilterHashtable @{logname='application';id=10;providername='*wmi*'} | measure

“Cool, it works,” the Scripting Wife exclaimed, “Here take a look.”

As she turned her laptop monitor so I could see the following output in her Windows PowerShell console.

“How would I know how to do this if you were not around?” she asked.

“You could use the Get-EventLog cmdlet to do this, but you would need to pipe the results to the Where-Object cmdlet to help with the filtering. This command is more efficient. Besides, I wrote a great Hey, Scripting Guy! blog last year about using the FilterHashTable parameter. It is titled How to Improve the Performance of a PowerShell Event Log Query,” I said.

“So what does all this mean anyway?” she asked.

“What does what mean?” I asked.

“What is Event 10 from Windows Management Instrumentation, and why is it littering my Application log with meaningless events?” she asked.

“Actually it is not meaningless. It means that some permanent event does not have permission to run. That is what the error code 0x80041003 means. Why it does not have permission is another issue. Let me check with Bing to find out,” I said.

Within less than a minute, I had retrieved a support article describing the situation. Interestingly enough, this issue also has a Microsoft Fix It solution attached to it. “Cool.” I thought. Then I thought this would be a great opportunity to talk to the Scripting Wife about permanent event consumers.

“Do you remember when Trevor wrote Use a PowerShell Module to Work with WMI Permanent Events?” I asked.

“Sure. I thought it was great,” she replied.

“Well, before that blog, I talked about working with permanent events and I discussed the technology that was behind them in Use PowerShell to Monitor and Respond to Events on Your Server,” I said.

“Uh. Sure, if you say so. I don’t remember that far back,” I said.

I started to say something like she remembered Trevor’s module, but then I decided to keep my mouth shut for a change. Then I changed my mind.

“Well, this is your lucky day. Because we are going to do a refresher course,” I said.

“Oh, come on. It is late, and tomorrow is the TechStravaganza,” she whined.

The first thing I did was create a simple script that I called Get-BVTFilterandConsumer.ps1. This script is shown here. (Note: The second line uses the back tick character for line continuation. GWMI is an alias for the Get-WmiObject cmdlet. Remember, this is a quick script, and it is late at night.)

Get-BVTFilterandConsumer.ps1

gwmi __EventFilter -Namespace root\subscription -Filter "name = 'bvtfilter'"

gwmi __FilterToConsumerBinding -Namespace root\subscription `

-filter "filter = '__EventFilter.Name=""bvtFilter""'"

“Now I want you to run the script. It will retrieve instances of the __EventFilter Windows Management Instrumentation class that are named bvtFilter. It will also retrieve instances of the __FilterToConsumerBinding Windows Management Instrumentation class—but only instances that are associated with the filter named bvtFilter. It sounds complicated, but really it is not,” I said.

“If you say so. But sometimes I wonder if your idea of complicated and my idea of complicated are the same thing,” she said as she ran the script. The output from the script is shown in the image that follows.

“Now what we need to do is to delete both the bvtFilter and the filter to consumer binding. This part is really easy because all we need to do is to pipe the objects from the previous script to Remove-WmiObject,” I said.

“That is the first thing you have said that makes sense,” she said, “Shouldn’t we back up the computer first?”

“We do not need to back up the entire computer, but it does not hurt to back up system state. To do this, use the CheckPoint-Computer cmdlet,” I said.

The Scripting Wife copied the code from the Get-BVTFilterandConsumer.ps1 script, and at the end of each line she added a pipe character, and sent the objects to the Remove-WMIObject cmdlet. Then she backed up and went to the top of the script and added the Checkpoint-Computer command. The resulting script, which she named BackupComputerAndRemoveBVTFilter.ps1, is shown here.

BackupComputerAndRemoveBVTFilter.ps1

Checkpoint-Computer -Description "prior to fixing event 10 from wmi" `

-RestorePointType MODIFY_SETTINGS

gwmi __EventFilter -Namespace root\subscription -Filter "name = 'bvtfilter'" |

Remove-WmiObject

gwmi __FilterToConsumerBinding -Namespace root\subscription `

-filter "filter = '__EventFilter.Name=""bvtFilter""'" |

Remove-WmiObject

When the Scripting Wife pressed the green triangle to run the script, the dialog box shown here appeared.

Other than the dialog box, there was no output from the script.

“So how do I know that it worked?” she asked.

“For one thing, you can run my Get-BVTFilterandConsumer.ps1 script. But with no instances, it will not display any output either. Another thing you can do is to open WbemTest, change your namespace to root\subscription and open the __FilterToConsumerBinding Windows Management Instrumentation class,” I said.

The Scripting Wife typed wbemtest into the Windows PowerShell console, and when the Windows Management Instrumentation Tester opened, she set the namespace to root\subscription and opened the __FilterToConsumerBinding Windows Management Instrumentation class. She then pressed the Instances button and the following dialog box appeared.

“You might also want to look for instances of the __EventFilter Windows Management Instrumentation class,” I suggested.

The Scripting Wife closed the previous dialog box, and opened the __EventFilter class. Next she looked for instances. The results are shown here.

“OK. That’s enough. You are making my head hurt, and I need to catch up with people on Facebook,” the Scripting Wife said.

And with that, I was effectively dismissed. 2012 Scripting Games Prep Week will continue tomorrow when we will have a guest blog post from Boe Prox.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Parse an XML File and Sort the Data

Anonymous — Mon, 26 Mar 2012 05:00:00 GMT

Summary: In this blog, the Scripting Wife learns how to use Windows PowerShell to parse her books XML files and to find authors and sort titles.

Microsoft Scripting Guy, Ed Wilson, is here. Today the registration opens for the 2012 Scripting Games. You can go to the 2012 Scripting Games site on PoshCode, click Log On, choose your authentication mechanism, and fill out your user name and email address. Make sure your user name is the name you want to appear on the leaderboard, and on your 2012 Scripting Games certificate. Also, make sure your email address is correct because it is used to notify you about prizes.

Yesterday, the Scripting Wife asked me to help her with exploring an XML file. Last night, she told me that she wants me to help her look at the XML file she got by exporting her book database so that she can find titles of books and things like that. I think I will call her, and see if she is ready…

“Scripting Wife?” I call in my nicest voice.

All of a sudden I look up, and she is here.

“You don’t have to yell. You could simply have called me on my Windows 7 phone,” she replied.

“I didn’t yell—and besides, I was not sure you had your Windows 7 phone with you,” I apologized.

“I always have it with me,” she said rather curtly. “So are you going to show me how to find titles in my XML file?”

“Yep. Why don’t you sit over here next to the computer, and first read your XML file into a variable. Remember to use the [XML] symbol to make sure that you get an XML document,” I said.

The Scripting Wife thought for a minute, and then typed the following command.

[xml]$books = Get-Content C:\fso\books.xml

“Now, remember that all your book data was in the book node. So why don’t you retrieve that, pipe it to the Foreach-Object cmdlet, and then retrieve the Title property,” I said.

The Scripting Wife thought for a few seconds and began to type. Within a minute or so, she had composed the command that is shown here. (The percentage sign (%) is an alias for the Foreach-Object cmdlet.)

$books.bookinfo.booklist.book | % {$_.mainsection.title}

The two commands and the output associated with the commands are shown in the image that follows.

“That is pretty cool, but I want to be able to find out how many books I have based on subject,” she asked.

“Well, that is pretty easy. Take your book element, pipe it to the Foreach-Object cmdlet, then pipe that to the Sort-Object cmdlet, and choose the DisplayName property. Then group it by DisplayName. Use the NoElement switched parameter to keep from displaying a bunch of extra information,” I said.

She thought for a second, and then used the Up arrow to retrieve her previous command. She then modified it until the following command appeared.

$books.bookinfo.booklist.book | % {$_.subjects.subject} | sort displayname | group displayname -NoElement

She turned the monitor to me, and the output that is shown in the image that follows was the result.

“That was pretty complicated. Can’t we do something easier? For instance, I want to find all the Perry Mason novels,” she requested.

“That one really is easy. Retrieve your command that lists all the titles. Because the titles are all strings, pipe that to the Where-Object and use the Match operator to look for Mason,” I said.

This time the Scripting Wife did not hesitate. She retrieved her next to last command by pressing the Up arrow twice. Then she added a pipe character, used the question mark (?) as an alias for the Where-Object. She added the Match operator and looked for the word Mason. Her completed command is shown here.

$books.bookinfo.booklist.book | % {$_.mainsection.title} | ? { $_ -match 'mason'}

“This is more like it. Here take a look,” she said as she turned the monitor towards me.

“That is all I really wanted to see right now. I think I am going to head to the mall with a couple of my friends. You have been keeping me too busy around here, and I need a break,” she said as she jumped up and headed towards the door.

“Don’t forget…registration for the 2012 Scripting Games is open,” I said.

“I will register tomorrow,” she said.

And she was gone.

Join us tomorrow when I imagine the Scripting Wife will register for the 2012 Scripting Games.

Ed Wilson, Microsoft Scripting Guy

The Scripting Wife Learns to Use PowerShell to Work with XML

Anonymous — Sun, 25 Mar 2012 05:00:00 GMT

Summary: In this blog, the Scripting Wife learns how to use Windows PowerShell to work with an XML file.

Microsoft Scripting Guy, Ed Wilson, is here. It is only eight days until the kickoff of the 2012 Scripting Games. Tomorrow the signup for the 2012 Scripting Games goes live. I have finished all the meetings, and everything is now in readiness state for the big event. I am sitting in the kitchen sipping a cup of English Breakfast tea, and looking over the chapter that I completed last night in my Windows PowerShell 3.0 Step by Step book. I close my eyes to think about one particular sentence when all of a sudden I feel a presence come into the room.

“If you are going to sleep, then you should get up from the table,” the Scripting Wife chided.

“I am not sleeping, I am deep in thought,” I replied.

“Then I am in deep trouble,” the Scripting Wife rejoined.

“What are you doing in here? The sun is still up,” I joked.

“Very funny. In fact, it is so funny I forgot to laugh,” she said. “Actually, since you are not doing anything, I need to you tell me about XML.”

“Say what?”

“XML. I need to know how to read an XML file,” she repeated.

“You are kidding.”

“Nope. I exported my book database, and it saved as an XML file. I need to know how to read it,” the Scripting Wife explained.

“OK. That makes sense. In Windows PowerShell, it is really easy. How do you read a plain text file?” I asked.

“I use the Get-Content cmdlet,” she said.

“It is the same thing, except that you use the letters XML inside square brackets. Open up Windows PowerShell on your computer, and then use Get-Content to read the XML file.”

The Scripting Wife stores her books.xml file in the FSO directory on her C:\ drive. Therefore, her command looks like this:

[xml]$books = Get-Content C:\fso\books.xml

“Now look at what is contained in the $books variable,” I suggested.

The Scripting Wife typed the $books variable on its own line in the Windows PowerShell console. The command and its associated output are shown in the image that follows.

“Now look at the XML property,” I suggested.

The Scripting Wife typed the following command.

$books.xml

“OK. Now look at the BookInfo property.”

She typed the command that appears here.

$books.bookinfo.

The command to examine the XML property and the command to look at the BookInfo property are shown in the image that follows, along with the associated output.

“What is that booklist?” the Scripting Wife asked.

“I don’t know. Why don’t you access it and see.”

The Scripting Wife used the Up arrow to retrieve the previous command, and added BookList to the end of the command and pressed ENTER. Here is her command:

$books.bookinfo.booklist

“Well, it looks like a bunch of books,” she replied as she turned her monitor to me so I could see. The image that follows shows her Windows PowerShell console.

“Why don’t you keep going…But this time, pipe the output to More just in case you get all of your books rolling by,” I suggested.

The Scripting Wife once again used the Up arrow to retrieve her previous command, added Book to the end of the command, and piped the output to More. The command is shown here.

$books.bookinfo.booklist.book | more

Sure enough, after a few seconds, the book information began to scroll. The first little bit is shown here.

“Well that looks interesting, but how can I find more information about a book?” she asked.

“Why don’t you index into the collection? Choose the first book,” I suggested.

The Scripting Wife thought for a few seconds, and then she used the Up arrow to retrieve her previous command and then added the index operator. Her command is shown here.

$books.bookinfo.booklist.book[0]

The output from the previous command is shown here.

“You can use the same techniques to find information about the subjects of the book, and to find information about the title, plot, and other information.”

The Scripting Wife typed the commands that follow. As she examined the output from each command she continued to burrow deeper and deeper into the data structure of the first book.

$books.bookinfo.booklist.book[0].subjects

$books.bookinfo.booklist.book[0].subjects.subject

$books.bookinfo.booklist.book[0].mainsection

$books.bookinfo.booklist.book[0].mainsection.authors

$books.bookinfo.booklist.book[0].mainsection.authors.author

$books.bookinfo.booklist.book[0].mainsection.authors.author.person

Finally, she sat back and examined her handiwork. The output from these commands are shown in the image that follows.

Ed Wilson, Microsoft Scripting Guy

Learn How to Manually Create a CSV File in PowerShell

Anonymous — Sat, 24 Mar 2012 05:00:00 GMT

Summary: The Scripting Wife learns how to manually create a CSV file in this beginner Windows PowerShell blog.

Microsoft Scripting Guy, Ed Wilson, is here. Ah, it is the weekend. It seems that this week has been rather long, although I know that is a misconception because each week only has 168 hours in it. I guess it is kind of like one of the characters in One Flew Over the Cuckoo's Nest, a book I read in high school. They assumed that the staff sped up the clock when they were having fun, and slowed down the clock when they were doing things they disliked as a way of punishing them. Anyway, this morning I am in my office busily working on my new Microsoft Press book, Windows PowerShell 3.0 Step by Step.

“Hmmm…I like the new Where clause syntax in Windows PowerShell 3.0,” I said to myself.

“So what is a CSV?” said the Scripting Wife as she jolted me from my mental revelry.

“Is it a model of a car?” I facetiously queried.

“No. Not even close, Script Monkey,” she shot back, “Try again.”

“OK. It is a comma-separated value type of text file,” I said.

“Correct. Give the Script Monkey a peanut,” she said.

“So why do you want to know about CSV files?” I asked.

“Because silly, it is in the 2012 Scripting Games Study Guide, and the games start in exactly nie days,” she replied.

“OK. What do you want to know about CSV files?” I asked.

“Everything.”

“I see. Well, you could start by reading all the CSV blogs I have written on the Hey, Scripting Guy! Blog.”

“I could, but I want you to teach me. After all, you are the world famous Scripting Guy.”

Manually creating a CSV File

“What I am going to show you today is how to create CSV file manually. The first thing you need to do is to create a here string,” I said while turning my laptop screen so she could see.

“A hear string? What is this? Like a symphony or something?” she quipped.

“Try to stay with me. A here string allows you to create a string without worrying about any sort of formatting like quotation marks and commas, which are two things that CSV files really love, and that Windows PowerShell in general balks at.”

“OK. So how do I create this magical here string?” she asked with obvious signs of skepticism.

Use @” to begin and “@ to end a here string

“The first thing I do is use a variable to hold the resulting string. Then I begin the here string with the at plus quotation symbols (@”). Then I immediately press ENTER, and I add my column headings. A comma separates each heading, and then I again press ENTER. Now I add the value for each column and I use a comma to separate the values.”

“That is why it is called a comma-separated value file?” she asked.

“Exactly. When all of the rows of data are typed, press ENTER again, and I close the here string with the quotation mark plus at symbols (“@) and again press ENTER.”

“OK,” she said somewhat skeptically.

“Why don’t you give it a try,” I said as I turned the laptop over to her.

The Scripting Wife opened the Windows PowerShell console, and typed the following on the first line. In the following code, <enter> represents the ENTER or Return key (ASCII 13) (8 ).

$csv = @"<enter>

Next she added the column headings by typing the following.

"index","name"<enter>

After the columns were added, the Scripting Wife added the data. This is shown here.

1,"ed"<enter>

2,"teresa"<enter>

Finally, she closed the here string.

"@<enter>

<enter>

“Now you need to write your CSV data to a file,” I said. “When you are done, use the Import-CSV cmdlet to read it back.”

“Oh, I can use redirection to create the file,” she said.

The Scripting Wife quickly typed the following.

$csv >>c:\fso\mycsv.csv<enter>

Import-Csv C:\fso\mycsv.csv<enter>

“Very good. Now store the CSV information back into a new variable, and access the first element in the file,” I said.

“Huh? Do you mean for me to use square brackets and see the first row of information?”

“Yeah.”

“Then why don’t you just say that?” she chided.

The Scripting Wife typed the following.

$mycsv = Import-Csv C:\fso\mycsv.csv

$mycsv[0]

“Do you see that your first row of data contains two items—the index and the name?” I asked.

“Yes.”

“You can use dotted notation to access the specific column of information. These act just like properties. Why don’t you get the name from the second record?” I suggested.

The Scripting Wife typed the following.

$mycsv[1].name

“So how does all this look?” the Scripting Wife asked as she turned the monitor over so I could see.

As I looked at the screen, I beamed. “It is perfect.” The screen is shown in the image that follows.

“Cool,” she said as she jumped up and prepared to leave.

“By the way, how did you do on the new 2012 Scripting Games PowerShell Quiz?” I asked.

But by this time she was long gone. Perhaps she did not hear. Or maybe she did…

Ed Wilson, Microsoft Scripting Guy