Configure iSNS Server in an iSCSI Initiator with PowerShell

This will just be a very quick post today.

Configuring an iSCSI Initiator to use an iSNS Server is fairly easy using the iSCSI configuration utility:


But lets face it, that’s no fun and it really doesn’t fit well when when we have to configure 10’s or 100’s of initiators or we’re using Server Core. Not to mention that this is something we’d really want to do with Desired State Configuration. Besides, this is a PowerShell blog.

It is easy enough to configure iSCSI Targets to register with an iSNS Server:

Set-WmiInstance -Namespace root\wmi -Class WT_iSNSServer –Arguments @{ServerName="ISNSSERVER.CONTOSO.COM"}

But unfortunately I couldn’t find any documentation on how to do this on an iSCSI Initiator. But after a little bit of digging around WMI I found the appropriate class:


So, to add the iSNS Server to the iSCSI Initiator:

Set-WmiInstance `
-Namespace root\wmi `
-Class MSiSCSIInitiator_iSNSServerClass `
-Arguments @{iSNSServerAddress="ISNSSERVER.CONTOSO.COM"}

Notice that the WMI Class argument name for the setting the iSNS Server name in an iSCSI Initiator is different (iSNSServerAddress) compared to setting it for an iSCSI Target (ServerName).

To list the currently set iSNS Servers:

Get-WmiObject `
-Class MSiSCSIInitiator_iSNSServerClass `
-Namespace root\wmi


And if you need to remove an iSNS Server from the iSCSI Initiator:

Get-WmiObject `
-Class MSiSCSIInitiator_iSNSServerClass `
-Namespace root\wmi `
-Filter "iSNSServerAddress='ISNSSERVER.CONTOSO.COM'" | Remove-WmiObject -Verbose

Pretty easy right?

In a few weeks I plan to integrate iSNS registration with my iSCSI DSC Resources (also available on PowerShell Gallery) so that the whole process of registering iSCSI Initiators and Targets with iSNS is just a little bit easier.

Thanks for reading.


Creating a Cloneable Class in WMF 5.0


You might have noticed that instances of certain types of classes are created, a method called Clone is available that will create a (shallow) copy of the object. A PowerShell Hashtable object is a classic example of a class that supports the Clone method:

$Car = [Hashtable]::New()
$NewCar = $Car.Clone()

This is nothing new to developers, but for most Ops people it might be something they’re not that familiar with. But if you are an Ops person who is implementing more advanced PowerShell modules or scripts in WMF 5.0 that require custom classes, then this might be something you need to do.

Note: you can do this in WMF 3.0 and 4.0 but it requires reflection and a lot more code, so isn’t something I’m going to cover here.

For this post, I’m assuming you have a basic knowledge of how to create classes in WMF 5.0. If you aren’t familiar with creating classes, take a look at this series for a very good primer.

If you just go and create a new class in PowerShell and try to call the clone method, an error with be thrown:


This is because by default a new class that is defined in PowerShell is based off the System.Object class which does not implement the ICloneable interface. The ICloneable interface is what gives us the Clone method on an object. So we need to tell PowerShell that we want our new class to implement the ICloneable interface.

Note: You don’t really need to know what an interface is to use it, but if you do want a better understanding of it, this is a good place to start. Details on the ICloneable Interface can be found here.

Implementing an Interface

Creating a class that implements the ICloneable interface just requires that we add the name of the interface to implement after a colon following the class name:

class Car:ICloneable {
[String] $Make
[String] $Model

However, if we try to define this class as is we’ll get an error:


The problem is that we’ve told PowerShell that the Car class implements ICloneable and should therefore have a Clone method, but we haven’t actually created the Clone method in the class.

To do this we need to add the method to our class definition:

class Car:ICloneable {
[Object] Clone () {
$NewCar = [Car]::New()
foreach ($Property in ($this | Get-Member -MemberType Property))
$NewCar.$($Property.Name) = $this.$($Property.Name)
} # foreach
return $NewCar
} # Clone
[String] $Make
[String] $Model

The above code first creates a new Car object, then gets a list of the properties on the existing ($This) object and uses a foreach loop to copy the content of each property to the new Car object ($NewCar). The $NewCar object is returned to the calling code.

Note: This performs a shallow copy of the object. If you want to perform a deep copy then you’ll need to implement code based on the child objects within the existing object.

You’ve now created an class that implements an interface. The .NET framework provides hundreds (if not thousands) of interfaces that you potentially could implement on your PowerShell classes. Of course, you could have cloned the Car object without implementing the ICloneable interface at all, but this post is intended to be a general introduction to implementing interfaces in WMF 5.0 as well as the ICloneable interface.

Thanks for reading.

PowerShell V5 New Feature: Protect/Unprotect-CmsMessage

This interesting article gives some background details on some of the problems I ran into after upgrading my DSC dev machine to WMF 5.0 10586. This is because in WMF5.0 the DSC credential encryption mechanism was converted to use Protect/Unprotect-CMSMessage. It clears up a lot of things for me and is a worthwhile read if you’re using DSC credential encryption on WMF5.0.

Keith Hill's Blog

Windows PowerShell V5, due out sometime in 2015, sports a number of new features: OneGet, PowerShell Get, enhanced DSC, ConvertFrom-String, support for authoring classes in PowerShell script, Compress/Expand-Archive, support for creating symbolic links, hard links and junctions, etc.

One of the more obscure but useful features is the support for cryptographically protecting messages as documented in the IETF standard RFC5652. This involves the creation of a certificate which I will show you how to do. You can then protect and unprotect messages using that certificate. However, where it gets interesting is when you export a public certificate from the original certificate. You can give the public certificate to anybody and they can use that to encrypt (protect) a message. That message cannot not unencrypted (unprotected) by anyone except the individual that holds the original certificate. The original certificate contains both the public and private key. It is the private…

View original post 855 more words

Building a Enum that Supports Bit Fields in PowerShell

I found this post extremely useful – definitely worth a read.

Learn Powershell | Achieve More

I was working on a project recently that required me to have an Enum that allowed bit fields as opposed to the normal fields that we might deal with in our day to day endeavors with PowerShell.

If you aren’t quite sure what I mean by this, here is a quick example that shows the difference between the two.

First, the regular Enum that we are used to:


Notice that each number matches up to a single value: 0 = Sunday, 3 = Wednesday and so on.

Now for an Enum with bit fields:


You can see here that depending on the value, you may end up for more than 1 item. This typically will follow a 1,2,4,8,16…etc… approach for the single items and then they perform a bitwise XOR to combine values for more items.

Now that we have covered this topic in a very basic form, we still…

View original post 367 more words