Script Wars: The Farce Awakens (part III)


Summary: When last we saw our hero, Rey Skyworker, she was aiding her new co-worker, Tin. They managed to implement better error trapping by using the "Try Catch" statement in Windows PowerShell. The fact they could do this so easily it has tickled Tin's curiosity.

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

"Now Rey, I'm looking at this and as I see it, I could avoid the error altogether by trapping for those situations. Maybe adding in a few IF statements like this to the script."

If (($First -or $Last)) -eq '') then

{

Write-Output 'Names cannot be blank

}

Else

{

….rest of the script

}

Rey nodded. "You mean adding in some data validation?  We can definitely do that, but a much better way would be to remove the READ-HOST statements, and use parameters. We can add validation directly to the parameters."

She changed the following lines from this:

$First=Read-Host 'Enter First Name'

$Last=Read-Host 'Enter Last Name'

To this:

Param(

[String]$First,

[String]$Last

)

Tin scratched his head. "How would admins run the script? Does it prompt for the information?"

Rey shook her head. "First you would run the script in this fashion."

.\NewContosoAzureUser.ps1 -First 'John' -Last 'Smith'

"In this setup, you now do create users in bulk, by grabbing data from another source and sending it to the script from the command line."

Ben looked down. "That's a great improvement. But in the short term, we have a lot of techs trained on the manual approach. How can this be adapted to meet those needs?"

"By using validation on the parameters." Rey looked up. "In this setup, we can define that the values are permitted to be null or not, assign minimum/maximum lengths, and even specify the object type. In the example above, these objects will default as a [String] type."

Rey keyed into the PowerShell console the following line, to show how to leverage parameters in an Advanced function.

Get-Help About_Functions_Advanced_Parameters

Drilling through the content, she found a good example of what she was looking for. "Ah! Here we go. The ability to ensure the parameter cannot be empty or null."

Screenshot of PowerShell

Tin looked over. "Hang on, that seems too easy. If I just do this change to the code."

Rey nodded. "It actually is. So first, if we just want to ensure that $First is never a blank and is a required value, we would add in this."

She altered the beginning block of code from this:

Param(

[String]$First,

[String]$Last

)

 

To this:

Param(

[Parameter(Mandatory=$true)]

[ValidateNotNullOrEmpty()]

[String]$First,

[String]$Last

)

…And then re-ran his script without providing any values to see the result. They hit enter when it prompted for "First:"

Screenshot of PowerShell

Tin was jumping up and down excitedly. "This is too awesome! So if anybody makes a mistake, I can actually TRAP for it BEFORE it tries to use the bad data? Hey, wait, I think I can do the second parameter!"

Tin added the additional lines for $Last to force it to be required information.

Param(

[Parameter(Mandatory=$true)]

[ValidateNotNullOrEmpty()]

[String]$First,

[Parameter(Mandatory=$true)]

[ValidateNotNullOrEmpty()]

[String]$Last

)

"Now hang on… I just realized something. We do have the occasional account that doesn't need a last name. Ones like 'Marketing' or 'Finance.' How can we ensure there is a value, and allow that one to be not assigned by the user?"

To identify the solution, Rey scanned through the help from About_Functions_Advanced_Parameters. "Ah! Here it is. Remove the 'NotNullOrEmpty' and replace it with 'AllowEmptyString'. In this scenario, it will still prompt, but allow the value to be a blank."

Param(

[Parameter(Mandatory=$true)]

[ValidateNotNullOrEmpty()]

[String]$First,

[Parameter(Mandatory=$true)]

[AllowEmptyString()]

[String]$Last

)

They re-ran the script to see the results, supplying a value for $First when prompted, and nothing for $Last.

Screenshot of PowerShell

Ben looked over. "Looks like the pair of you will make a great team in this battle to smooth out our processes!"

Just as Ben finished talking, TB-7 decided to start chomping on Rey's shoelaces.

Return tomorrow for another exciting adventure in "Script Wars." There will be more exciting PowerShell coolness, and we hope Rey will get her shoelaces back.

Sean Kearney, Premier Field Engineer

Enterprise Services Delivery, Secure Infrastructure

 

Comments (2)

  1. Thank you for wrapping this up. That’s really impressive.
    There is a major issue with the guys “trained for manual input”. They are not trained to read logs and errors…

    1. So we, tool makers, have to implement error handling and make our scripts less “confusing”.

      Sorry for splitting up the comment.

Skip to main content