This post will explain how to splat in Powershell. Splatting is basically using an array or a hash table as the attributes of a command.
As with most things in Powershell, its best demonstrated by an example or two.
Example 1
In my day job I have an ESXi build script, part of that is to call a function to create a VMK adapter. I can call that function in one of 3 ways.
1, badly
Deploy-VMKAdapter -Host "10.10.10.10" -VMKIP "10.10.20.10" -VMKMask "255.255.255.0" -DSwitch "DataSwitch" -PortGroup "ISCSI01" -MTU 9000
Although there is nothing wrong this the code, it can be difficult to follow. In a build script with many other function calls like this it will be very difficult to modify the script to build a different host as the same attribute would need to be changed on multiple function calls. One will always get missed.
2, badly but slightly better
$vmk3IP = "192.168.10.15"
$vmk3Mask = 24
$vmk3GW = "" # some helpful information
$vmk3MTU = 9000 # some helpful information
$vmk3DSwitch = "DataSwitch"
$vmk3PG = "ISCSI01"
$vmk3Stack = ""
Deploy-VMKAdapter -Host "10.10.10.10" -VMKIP $vmk3IP -VMKMask $vmk3Mask -DSwitch $vmk3DSwitch -PortGroup $vmk3PG -MTU $vmk3MTU
Now this is better, The options are now much clearer and with comments to explain things further helps. but if I want to copy and paste this to create another VMK adapter then I will need to make sure I rename all the variables. Very bad things will happen if I miss one.
3, Splatting
$VMK3 = @{
IP = "192.168.10.15";
Mask = 24 ;
GW = "" ; # some helpful information
MTU = 9000 ; # some helpful information
DSwitch = "DataSwitch" ;
PG = "ISCSI01" ;
Stack = "" ;
}
Deploy-VMKAdapter -Host "10.10.10.10" @VMK3
if ($VMK4){Deploy-VMKAdapter -Host "10.10.10.10" @VMK4)
Here the attributes are collected in a hash table and the hash table is “fed” to the function. If a hash table key matches a command/function attribute name, then that value is used. In the example above the hash table has a key of IP, The value of IP is fed to the function as it also has an attribute called IP.
This means that the config part of the script is now much more human friendly as config data (VMKs in this case) can be “grouped” in to a hash tables.
Also, I may or may not need a VMK4 adapter. Not a problem I check for $VMK4s existence before calling the function to create VMK4. I can copy/paste $VMK3 to $VMK4 if I need to and re configure it. No need to edit code, just create or delete hash tables.
Example 2
Here is a snip-it of a script that will loop through a CSV of domains and then a CSV of users. Ultimately adding all the users to all of the domains.
The section below just shows how the user config hash table is used (splatted) with the New-ADUser command.
# user details and password
Add-Type -AssemblyName System.Web
$Password = [System.Web.Security.Membership]::GeneratePassword(10,4)
$FName = "Bob"
$SName = "McBobface"
$FullName = $FName + "." + $SName
# get user details, now build the hash table
$UserConfig = @{
AccountPassword = (ConvertTo-SecureString $Password -AsPlainText -Force);
DisplayName = $FullName;
Enabled = $true;
GivenName = $FName;
Name = $FullName;
Path = "ou=Admins, ou=Users, ou=CustA, dc=domain, dc=local";
SamAccountName = $FullName;
Surname = $SName;
UserPrincipalName = ($FullName +"@domain.local");
}
# create the user account
New-ADUser @UserConfig
Splatting can be slightly more difficult to debug as you can not easily see what command attributes are being used. But for me the benefits in the clarity of defining groups of variables to be passed to functions more then outweighs this.