PowerShell 101 for Messaging Administrator and IT Pros (Part 3)

If you would like to read the other parts in this article series please go to:

Introduction

In the previous article we started by creating a script to our help desk team, and they really liked the stuff, and proposed new improvements such as: they want to get more details about the Exchange Server when they run –Server within the current results, they need to know the Server FQDN, Mailbox Roles, Server Edition and how they would retrieve that information. Using Get-ExchangeServer we can have all the information requested, and as soon as we identify the cmdlets and the format to display, we can move on and change the script (Figure 01). We are going to use | FL at the end of the script for a better visualization of the information. The Server Role column is too big and all information won’t be displayed if we don’t use | fl.


Figure 01

Since the request is when using the –Server switch only, we need to add the new cmdlet before the lines that we already have as shown in Figure 02. A new line such as Mailboxes hosted on <ServerName> was added right underneath the cmdlet to retrieve the server settings.


Figure 02

When the Help Desk uses the same switch they will have the information that they requested, as shown in Figure 03.


Figure 03

Now, the Help Desk team wants to add a switch to pass a CSV file containing users and retrieve information about them, and here we may face some challenges, such as;

  • The If statement is good for two options, if you have several options than the Switch statement is a better way to go; we can write three IF statements totally independent of each other but it creates more work and increases script flow control.
  • When using several options, just the $args[] may not be suitable because it controls only the position, and since the user can add –file or –server or even a user then we need better control of how the data is entered. The same issue is when you have several parameters and for this kind of situation using Param () is the best way to go.

A different approach to work with parameters passed to the script…

If you are developing a simple script where you can easily narrow down the parameters passed by the end-user then the previous section is more than enough, however as your script becomes more complex that solution won’t be doable and there is a better way to deal with parameters being passed to our scripts.

Let’s use the following script where we basically write in the output the first 4 parameters passed to the script (Figure 04).


Figure 04

Now, we are going to run the script twice changing the order of the parameters, but from an end-user perspective should be the same (Figure 05). Imagine if all cmdlets were created with that logic, the only way to get it right is to make sure to pass the parameters exactly as the programmer thought during development or the developer creating a lot of logic to make sure that it has all parameters in the proper order. Either way is not good from any perspective.


Figure 05

In order to solve the issue we can use Param () and specify the parameters that will be passed to our script, in Figure 06 we defined two fields called File and Server and these are the strings that must be used by the end-user to run the script. If they user –Servers (plural instead of singular) it’s not going to work, because the parameters specified must be File and Server.


Figure 06

If you run the script and change the order of the parameters we can see that the results will always be the same. This saves us a lot of work in trying to identify which parameters are being entered by the code to test all possibilities (Figure 07).


Figure 07

Now, let’s say that we require a specific parameter to start the script otherwise we cannot run the script. If that is the case we can define a specific parameter as mandatory using [parameter(mandatory=$True)] and the results of this change can be seen as the script is being executed (Figure 08) on the right side. The user hasn’t specified the –File parameter and the script requested the information before continuing.


Figure 08

Reading information from the script…

In some cases we many need to request information from the user, information that he is not expecting and he hasn’t done using parameters. A good example is a menu or a confirmation before taking action. In order to ask the information we can use Read-Host “Question string” and it is nice to use a variable to receive the content of our input otherwise we cannot use the data entered. A simple example can be seen on Figure 09. After the user types in the option, we can write it down using the write-host $vOption.

Note:
We are using Write-Host alone in some lines and that creates a single line space.


Figure 09

Thinking about multiple If Statements? Time to meet the Switch statement…

Let’s use the previous script and say instead of 3 we have 7 options, so we can display the seven options but how are we going to take action? It’s doable but not practical with 7 If Statements checking for the seven possible options If ( $vOption –eq 1) { commands }. Well, there is is a better way to do that using the Switch Statement, as shown in the following syntax:

Switch (<Variable>) {

                <value> { command-block }

                <value> { command-block }

}

The use the switch statement with the previous script is shown below (Figure 10).


Figure 10

Conclusion

In this third article of our series about PowerShell 101 for Exchange administrators we validated a better option to manage parameters being passed to our script, how to request input from the users, and how to use the Switch Statement.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top