Managing mailbox features with corporate profiles (Part 3)

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

• Managing mailbox features with corporate profiles (Part 1)
• Managing mailbox features with corporate profiles (Part 2)
• Managing mailbox features with corporate profiles (Part 4)

When creating a script we first develop the functionalities and as soon as we get that working, then we can start validations and so forth. In the current article, we will make sure that the script works and in subsequent sections we will explain the validation and debug options of the script and in the next article we will provide the full script.

The goal is to develop a script where the service desk runs the following command and it will get everything done automatically. The script should have only two parameters: mailbox and profile. Therefore, to make sure that we are on the same page we will be calling our script Assign-Profile.ps1 and the syntax should look like this:

Assign-Profile.ps1 MailboxName ProfileName

In order to improve our understanding of the evolution of the script we will start simple and we will increase the script as we go. Every time that we have a piece of new code we will place that in bold to give you a hint what is being added and it will be explained in the previous sentence. All code in regular text means that was already there, and we hope that it will help us to track down the progress of the logic behind of the script.

Now that we are on the same page, we can start writing the script. The first block of commands is to retrieve the information ($vMailbox and $vProfile variables), and the third line we will be getting the information from our ex.info file that contains all the rules to apply on any given mailbox based on the profile.

Note:
The $vProfile changes all information received through the script to Capital Letters (that is the reason of the .ToUpper())

We have the mailbox, profile to be assigned and the file with all the rules. Our next logical step is to execute each one of the lines of our ex.info (that is defined in the ForEach ($tFile in $vFile) {} statement) and for each line we will reset the variable $tValid to $false.

Note:
The $tValid was already added but at this point is not doing anything on the script, it will make sense when we start validating data.

Now we will evaluate the second piece of information provided to the script by the Service Desk which is stored in the variable $vProfile (second line) and we start a Switch statement that will compare the value of the variable $vProfile with the possible options that are GOLD, SILVER and BRONZE.

If there is a match we will get the value of the correspondent column to the variable $tValue, in the Figure 01 we show the GoldValue column and its values for all lines. Finally since that is a valid profile we define the variable $tValid as $True.

Note:
We are inside of the ForEach statement and that means that each line will be read as part of the loop until the end of the file.

Figure 01

Now the last portion of the script is to check first if the $tValid is true and that only happens if the user who initiated the script gave us a valid profile based on our definitions (gold, silver or bronze), otherwise it will skip and nothing will happen.

If the profile is valid, then we are going to use the Invoke-Expression() using the parameters from our ex.info file. Let’s say that the script is processing the first line and the profile is GOLD, then based on the Figure 02, the invoke command will be Set-CASMailbox MailboxName –MAPIEnabled $True.

Figure 02

Bear in mind that $tValue was filled out on the previous section when we evaluated the $vProfile variable and the information is coming from the same table. The reason that we use $tValue is to get the profile out of the way at the beginning of the script instead of creating a new Invoke-Expression line for each profile (more work that we don’t want to).

Finally, the last step is to configure the CustomAttribute6 to the value of the profile.

Note:
We are setting the CustomAttribute6 several times for the same user, we can improve that by moving that line out of the ForEach statement and that would improve performance.

Time to test it, we can save the current script as xx2.ps1 (at least that was the name that we used during the creation of this article). Just to make sure that we are testing the right things, first run the .\check.ps1 tor38 against a test account (in our case TOR38) and that will serve as basis for our test. Then run .\xx2.ps1 tor38 silver and that will configure it to the silver profile, finally run again.\check.ps1 tor38 and we should see all the silver values defined for the account. The entire process is shown in Figure 03.

Figure 03

Validation Time…

So far, our script is working however all the variables must be perfectly aligned to work properly. If we get any wrong location of the ex.info file inexistent mailbox we will get an error and our script would fail.

We need to focus our attention to first block where we get the information from the user (Figure 04). It is too simple and we need to add validation for that information.

Figure 04

Unfortunately, validation sometimes take more code than the actual script especially if the script is being created by an IT Pro which is the current case. We will add all tests bellow between the first three lines and the rest of the script.

The first test that we perform is to check our file if the ex.info file is accessible and we use the Test-Path to validate and if it is not then the script will terminate.

The second validation is about the number of parameters passed through the command line, we must force that the first and second parameters are being entered otherwise the end-user will receive an error message.

The third validation is to check if the mailbox is valid, after all we do not want to process the script to find out that there is no such mailbox, right?

The fourth validation is about the profiles, if the end-user enters a non-existent profile, then we will provide an error message.

We created the conditions to force a failure (removed the file ex.info for the first attempt), inexistent mailbox, inexistent profile and the validation worked on the vast majority of the tests (Figure 05). We found an error on the validation when the user adds only 1 attribute and that validation should be one of the first things of the script to avoid the error message (that was caused because the value was $null and we were trying to run .ToUpper()).

We always can improve the validation process but I think we have a good start for our script.

Figure 05

Conclusion

In this third article of our series, we worked on the script that reads the information from a central file and then applied those changes based on the profile of the mailbox.

The logic behind this script is the CustomAttribute6 which defines the corporate profile and from that point on the script takes over and configures the mailbox with all parameters pre-defined by the corporate policy.

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

• Managing mailbox features with corporate profiles (Part 1)
• Managing mailbox features with corporate profiles (Part 2)
• Managing mailbox features with corporate profiles (Part 4)