Scriptimus Ex Machina

Testings results with a test matrix

My Rename-Computer script is in production and I’ve made some major changes to it so it’s time for some major testing.  It’s important when testing your scripts to understand and document what your expected outcomes are. You should then run through each scenario and ensure that you get the desired results.

I’m running my script with its new changes on my technicians PC. Remember, I’ve neutralised the script and added debug lines. For reference, here’s the code again.

Param (
 [String]$Name = $TSEnv:OSDComputername,
 [String]$WorkGroupName
)

Begin{
$DebugPreference="Continue"
Import-Module ZTIUtility
}
Process{
If ($Name) {
 # Rename the Computer using WMI
 # (Get-WmiObject win32_computersystem).rename($Name)
 Write-Debug "RUN COMMAND - Computer was renamed to $Name"
 }
# If the WorkGroupName variable has no value passed to the script.
 If (!($WorkGroupName)) {
 Write-Debug "WorkGroupName variable has no value passed to the script."
# If the Task Sequence variable JoinWorkgroup has a value.
 If ($TSEnv:JoinWorkgroup) {
 Write-Debug "Task Sequence variable JoinWorkgroup has a value."
 [String]$WorkGroupName = $TSEnv:JoinWorkgroup
 }
 }

 # Join a Workgroup
 # If the WorkGroupName variable has a value.
 If ($WorkGroupName) {
 Write-Debug "WorkGroupName variable has a value."
 # Add-Computer -WorkGroupName $WorkGroupName -WarningAction SilentlyContinue
 Write-Debug "RUN COMMAND - Joined the Workgroup $WorkGroupName"
 }
}
End{}

Below I’ve put together a simple testing matrix with the expected/desired results. Below which I’ve shown screenshots of the actual results.

Test 1 – Supply computer name Scriptimus to the command line
Expected results: Computer should be renamed.

Test 2 – Supply computer name Scriptimus and workgroup name ExMachina to the command line
Expected results: Computer and should be renamed and new workgroup joined.

Test 3 – Set Task Sequence Variable OSDComputername to CON-LAB1 and run script without supplying parameters
Expected results: Computer should be renamed.

Test 4 – Set Task Sequence Variables OSDComputername to CON-LAB1 and JoinWorkGroup to Continuum then run script without supplying parameters
Expected results: Computer and should be renamed and new workgroup joined.

Test 5 – Remove all variables and test script without parameters.
Expected results: No changes should be made.

Remove debug lines and reactivate script.

There’s a lot of debugging lines in this script that need to be removed. Sounds like a lot of work, right? No. Just comment out the line $DebugPreference=”Continue” and all the Write-Debug lines will be ignored as they are now run with the default “SilentlyContinue”.

The Import-Module ZTIUtility line can be left in as it will do nothing when run in production. In fact Microsoft suggest that this function will have helpful code in future MDT releases so they recommend that you keep the line in.

Finally the actual code needs to be re-enabled so remove the comment lines (#’s) from the 2 actual code lines and your script is now ready to return to production.

Param (
 [String]$Name = $TSEnv:OSDComputername,
 [String]$WorkGroupName
)

Begin{
# $DebugPreference="Continue"
Import-Module ZTIUtility
}
Process{
If ($Name) {
 # Rename the Computer using WMI
 (Get-WmiObject win32_computersystem).rename($Name)
 Write-Debug "RUN COMMAND - Computer was renamed to $Name"
 }
# If the WorkGroupName variable has no value passed to the script.
 If (!($WorkGroupName)) {
 Write-Debug "WorkGroupName variable has no value passed to the script."
# If the Task Sequence variable JoinWorkgroup has a value.
 If ($TSEnv:JoinWorkgroup) {
 Write-Debug "Task Sequence variable JoinWorkgroup has a value."
 [String]$WorkGroupName = $TSEnv:JoinWorkgroup
 }
 }

 # Join a Workgroup
 # If the WorkGroupName variable has a value.
 If ($WorkGroupName) {
 Write-Debug "WorkGroupName variable has a value."
 Add-Computer -WorkGroupName $WorkGroupName -WarningAction SilentlyContinue
 Write-Debug "RUN COMMAND - Joined the Workgroup $WorkGroupName"
 }
}
End{}

Testing variables with the ZTIUtility module

My Rename-Computer script worked great on a computer in a workgroup environment. But now, I have a new server that I want to rename before I join it to a domain. I’ve worked out that I’ll need the script to have the following functions:

• Rename the Computer only if a parameter is passed to the script or if a value exists in the task sequence variable OSDComputername. If neither is true then do nothing.
• Join a new Workgroup only if a parameter is passed to the script or if a value exists in the task sequence variable JoinWorkgroup. If neither is true then do nothing.

The first thing I need to do is create task sequence variables for testing outside of MDT. For this I will need the PowerShell drives TSEnv and TSEnvlist. Fortunately, there’s a module that can create these this for me. After which I can create the test variables manually.

To set this up, first copy the folders Microsoft.BDD.TaskSequenceModule and ZTIUtility from your deployment share \tools\modules folder to your Powershell modules folder.

Now you can add the line Import-Module ZTIUtility to your script and it will create your PSDrives for you.

In my case, I want to test that my script works with the OSDComputername set to CON-LAB1. From a PowerShell console I import the ZTIUtility module and set the variable. These 2 lines will do the trick.

Import-Module ZTIUtility
$TSEnv:OSDcomputername="CON-LAB1"

I can add/change a variable by using this example.

$TSEnv:OSDcomputername =”CON-LAB1″

I can call/test the variable in a number of ways. For example, by typing $TSEnv:OSDcomputername 

Next, after a moment in the script editor I’ve add my script changes, this is how my script looks now.

Param (
 [String]$Name = $TSEnv:OSDComputername,
 [String]$WorkGroupName
)

Begin{
$DebugPreference="Continue"
Import-Module ZTIUtility
}
Process{
If ($Name) {
 # Rename the Computer using WMI
 # (Get-WmiObject win32_computersystem).rename($Name)
 Write-Debug "RUN COMMAND - Computer was renamed to $Name"
 }
# If the WorkGroupName variable has no value passed to the script.
 If (!($WorkGroupName)) {
 Write-Debug "WorkGroupName variable has no value passed to the script."
# If the Task Sequence variable JoinWorkgroup has a value.
 If ($TSEnv:JoinWorkgroup) {
 Write-Debug "Task Sequence variable JoinWorkgroup has a value."
 [String]$WorkGroupName = $TSEnv:JoinWorkgroup
 }
 }

 # Join a Workgroup
 # If the WorkGroupName variable has a value.
 If ($WorkGroupName) {
 Write-Debug "WorkGroupName variable has a value."
 # Add-Computer -WorkGroupName $WorkGroupName -WarningAction SilentlyContinue
 Write-Debug "RUN COMMAND - Joined the Workgroup $WorkGroupName"
 }
}
End{}

In my next post, I walk through a testing matrix.

Adding new functions and features to a perfectly good script is common practice. One example is my evolving Rename-Computer script. I want to modify the way it works (again) but I don’t want to rename my computer and join a workgroup every time I test the script.

Using Write-Debug lines

One method I use when testing such a script is to neutralise it by replacing code with debug lines. I can then run the script and simulate the outcome. Here’s an example

Param (
 [String]$Name = $TSEnv:OSDComputername,
 [String]$WorkGroupName = $TSEnv:JoinWorkgroup
)
Begin{
$DebugPreference="Continue"
}
Process{
 # Rename the Computer using WMI
 # (Get-WmiObject win32_computersystem).rename($Name)
 Write-Debug "RUN COMMAND - Computer was renamed to $Name"
# Add the computer to a new workgroup
# Add-Computer -WorkGroupName $WorkGroupName -WarningAction SilentlyContinue
 Write-Debug "RUN COMMAND - Joined the Workgroup $WorkGroupName"
}
End{}

I’ve commented out the active commands and added Write-Debug commands below them. I’ve also activated the DebugPreference feature by adding the line $DebugPreference=”Continue” to the start of the script.

With this technique, I can test the logic of my code in a harmless environment while saving myself hours in reboots.