We found that there is no real way to predict which NIC will be named “Local Area Connection”, “Local Area Connection 2”, Local Area Connection N …” and so on. However, poking around we did find that there is one thing in common across all of our servers. Assuming the NICS were all plugged into the switch in order, we could identify them by their PCI bus, device, and function ID as shown in the screenshot below.

Well that’s all good but how can we leverage that information and automate our network configuration for new cluster nodes. First, we need to come up with a standard. We know the PCI Bus information for each NIC in the server. Once we made that map, we can specify which NIC gets which IP Address.  Once you manually create that map, you still need a way to identify which NIC has what Bus information. Enter PowerShell.

This gets a little nuts because we have to piece this together from a couple different sources. The first bit of information that we need for each NIC is something called the PnPDeviceID. You can pull this wit WMI using the win32_networkAdapter class.

So what does this buy us. It turns out this is part of the path in the registry that stores the PCI bus information. Lets assume you store the PnPDeviced id in $deviceID. You can get the PCI Bus information with the following:

Those last 3 numbers that are circled in red are the BusID, DeviceID, and FunctionID. Note that this is for 2008 and 2008 R2. All I really need is those last 3 numbers so some regex trickery along with multi-variable assignment comes in pretty handy here.

So once we have that, we can put this all together in a couple functions

And a screenshot of how to use it

IP Addresses are made up of 32 bits. Subnet masks are 32 bits as well. The subnet mask is what is used to determine where the Network ID ends and the host ID begins. Masks must have contiguous 1’s. If there is a 1 in the mask, then the corresponding bit in the IP Address is part of the Network ID. If there is 0 in the mask, the corresponding bit in the IP Address is part of the host ID.

So obviously there is going to be a lot of binary math, which any good network engineer can do. However, if you can get it for free, even better!

There is a type in .NET called System.Net.IPAddress that has several useful properties. The one I will focus on is Address.

Using the Address property and some bitwise operators in PowerShell, we can come up with a function pretty quickly. The –and and –or operators are pretty commonplace in the world of PowerShell but there is occasionally a need to do a compare of two numbers at the bit level. This is done with the –band and –bor operators. I may be off but if memory serves, using –bor and –band you can build any other bit function like xor. I won’t event think about K-maps.

So with all that, here is some code:

The Address property is the binary number that represents the IP Address. Doing a bitwise AND with a mask will tell us if they are in the same subnet. I have a default value of 255.255.255.0 for the mask, or /24 if you prefer CIDR notation, but you can specify it as a parameter if you like.

On my local machine, you can see that my listener is listening on any address it can find on my IP stack.

I’d like to set this to only listen only on a single IP V4 Address. When I first tried to change this I started looking at the value for Address under my listener but kept running into an error that reads Set-Item : Item has already been added. Key in dictionary: ‘Address’  Key being added: ‘Address’

Poking around the WSMAN provider, (which is fantastic by the way!) I found something else that looked promising. In WSMAN:\localhost\Service there are items called IPV4Filter and IPV6Filter.

Sweet!  Let’s try to set it to my local IP Address… and fail with this error

Set-Item : The WinRM client cannot process the request. The IP Filter is invalid. Ranges are specified using the syntax IP1-IP2. Multiple ranges are separated using , as delimiter. * is used to indicate that the service should listen on all available IPs on the machine. When * is used, other ranges in the filter are ignored. If filter is blank,
the service doesn’t listen on any address. For example, if service should be restricted to listen on only IPv4 addresses, IPv6 filter should be left empty.

But this is great news. The error message is actually helpful – Christmas miracle maybe?

If you want to listen on a single IP Address, you can specify a range that starts and ends at the same IP. For example,

So why would you have to enter all these crazy ranges.? Well it turns out you can specify these in a GPO. Say you have a Hyper-V Cluster that has a client access network (10.10.10.0/24), an iSCSI network (10.11.11.0/24), and a few others for things like heartbeat and live migration.  If you only wanted to have a listener on the client access network for all of your cluster nodes, you could specify the IPv4Filter to be 10.10.10.1- 10.10.10.254 and the policy would apply to all our servers and they would not be listening on the 10.11.11.0/24 iSCSI network.

To configure GPO settings, you can go to Computer Configuration\Administrative Templates\Windows Components\WinRM Service and in there you will find a setting called “Allow automatic configuration of listeners”

James Brundage has released his Windows PowerShell Pack. James and I thought we would start off with a couple examples of how to use WPK to create rich WPF based visualizations of data that is collected with PowerShell.  From there, we can go pretty much anywhere you want to.

Please leave a comment if you plan on attending. Please Register Here

Hope to see you there!

Andy

As I was thinking about this problem, there were a few tools in the toolkit I thought I could use. The first is the new cmdlet, get-hotfix. This is just a wrapper of Win32_QuickFixEngineering but its nice to have it abstracted up to the cmdlet level. The second tool I thought of using is compare-object. I have known about this cmdlet but haven’t had a real opportunity to use it much. It’s actually very powerful but it does take a bit of neuron firing to wrap your head around how it works.

The way I set this is up allows me to compare two servers.  I also have a credential parameter that is used to access servers so I can do my part in supporting the principle of Least Privilege and not be logged in with a Domain Admin account all the time.

So I pull the list of installed hotfixes from each server and select only the HotfixId property. This will make using the compare-object cmdlet a bit easier. If we do a get-member on compare-object we see that it outputs a PSObject with 2 noteproperties, a InputObject and a SideIndicator.

From the help on compare-object we find this description of the SideIndicator property:

The result of the comparison indicates whether a property value appeared only in the object from the Reference set (indicated by the <= symbol), only in the object from the Difference set (indicated by the => symbol) or, if the IncludeEqual parameter is specified, in both objects (indicated by the == symbol).

Well that does the job but frankly its output is difficult to easily interpret at first glance. The beauty of PowerShell is that if you really don’t like the way something works, you can easily work around it. In this case, I created a new array of custom objects that have three properties: KB, the name of the first server, and the name of the second server. (Lines 19 and 22)

Then I foreach’d (the new verb of the day) through the collection of compared hotfixes and switched on the “SideIndicator” property. I did this to make the output more clear so users of the script would not have to interpret all the arrows and equal signs generated by compare-object.

Here is a sample of the output:

I used Write-Host to generate some text output but I also get back an object that I can slice and dice later on.

This code is also available on the TechNet Code Gallery and up on PoshCode

First,  lets do some discovery. Whenever I am looking for cmdlets to work with something in particular, i use the get-command cmdlet with wildcards to help my search.

So from this it looks like we can get, set, enable, disable, and remove breakpoints. When we are setting breakpoints, you can specify the line and column you want to break on, but that can get really tedious. This is what the ISE does for you automatically when you toggle breakpoints. However, I find it much more useful to break when ever a variable is accessed.

Let’s use a basic function to demonstrate this.We’ll create a function foo and then set a breakpoint for the $c variable.

When we execute this code and call function foo, we get the output below. Notice that $a and $b is set, and that we break when we hit $c. One thing to note, when we specify the variable, we do not use the $ in front of the variable. This is the same as specifying the –outvariable common parameter for other cmdlets.

Last but not least, let’s take a look at how to navigate this “nested” prompt. If you type “?” or “h”, you will get the following information It is interesting that the “nested>” prompt displays this when you hit “?.” Under normal circumstances, the “?” is an alias for where-object, as we can see when we type ? at a normal prompt.

I hope this helps you with debugging your scripts.

Download it here:

https://connect.microsoft.com/windowsmanagement/Downloads

What is a PowerShell Script Club?

Script Clubs are like a hands on lab with no set topic or teacher. You bring an idea for a script, and ask your fellow PowerShell users for help getting the script written.

James Brundage, from the PowerShell at team at Microsoft, will be joining us for the evening.

About Seattle PowerShell Script Club

1. You Always Talk About Script club
2. You Always Talk About Script Club
3. If Someone asks for Help, And You Can Help, You Help
4. Two People Help One Person at One Time
5. One Module Per Person Per Night
6. All Scripts, All PowerShell
7. Scripts will be as short as they can be
8. If This is your First time at Script Club, You Have to Script

“XAML is an XML-based language for creating and initializing .NET objects. It’s used in WPF as a human-authorable way of describing the UI.” – “Programming WPF, by Chris Sells and Ian Griffiths, page 8

Expression Blend is a Microsoft product that allows designers to create UI’s in a sort of similar way that you could create WinForms using the WinForms designer in Visual Studio. It’s all drag ‘n drop. Blend is essentially a Winforms designer for WPF. It definitely takes some getting used to but the bottom line is that you don’t need to know how to code to get some basic windows, shapes, and controls up and running.

Here is a (not so) beautiful dialog box with a rectangle and a big button

Well, in Blend, if you click on XAML tab you can see the angle brackets that make up this UI.

What’s cool is that you can use this XAML that was created with Blend in PowerShell.

We can accomplish this using a [Windows.Markup.XamlReader] and call that Load static Method. Assuming we store the XAML in a here string, you just need to cast it to XML and pass it in like so

$reader = New-Object System.Xml.XmlNodeReader $xaml
$d = [Windows.Markup.XamlReader]::Load($reader)

Once you have $d you can do a bunch of things with it.

$d.ShowDialog() will display the dialog box as the script below demonstrates.

When I run this, I get the following

You may notice I tweaked the XAML a little bit. I changed the Window title on line 6. Blend also adds a class to its <Window> tag that is associated with the project in Blend. I had to remove that to get it to work in PowerShell. Other than that, we basically have a WPF editor that can create XAML that can be used in PowerShell.

My next post will deal with events. I do suppose it would be nice if clicking the button actually did something, huh.

Until next time..

Andy