Managing mailbox features with corporate profiles (Part 2)

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 3)
• Managing mailbox features with corporate profiles (Part 4)

Finding out and adjusting built-in policies

In the previous article we found the value to be changed and gathered the cmdlet and attribute, and that works fine for items like Single Item Recovery, MAPI Feature and a number of recipients because they are controlled just for a specific attribute to the mailbox level.

However, we have more complex features that are found in policies within Exchange Server, such as Outlook Web App and Retention Policies.

From our corporate profile perspective, we just need to know the name of the OWA Policy that will be used to determined profile.

For Outlook Web App Policies, we will create three polices using our Profile as prefix and then –OWAPolicy, as shown in Figure 01. Afterwards, we will need to visit each one of them and define the features accordingly.

Figure 01

Now that we have the OWA Policies in place, we can go to a test account and we need to assign the new OWA Policy to check the cmdlet and attributes required. This exercise is a good example where some settings may not be in the mailbox’s properties page but are available on the right side when we select a mailbox in the EAC.

For the OWA Policy, we need to select the user from the list, and then click on View Details (Number 1 on Figure 02), then on the new page (Number 2 on Figure 02) click Browse, and finally a list of all existent OWA policies are going to be listed (Number 3 on Figure 02).

Figure 02

We will save the new OWA Profile, and using the Show Command Logging feature we will identify the cmdlet and attribute to perform that change (Figure 03). Exchange will always use more precise information (that huge number is the GUID of the object) but we can get away with using just the name, although we need to test it to make sure that everything works as planned.

Figure 03

Creating the baseline file for all features

At this point, we already defined the names of our profiles that will be assigned to the mailboxes. We listed the features/restrictions that we want to be part of the corporate profiles and researched the cmdlets and attributes to be set.

Just from the technical side we can summarize our research in a table similar to the one listed below.

Table 1

That table above is a good start and it provides all the technical details to set up the attributes, however we need to combine that with the policies defined. We can start simple by adding three columns to the previous table and then define the standard values for each profile.

Table 2

Now we are talking! We can check in a single glance all corporate settings based on profiles and the information matches with exchange internal policies (OWA and Retention Policy for example) with the Profile defined at the beginning of this series.

Configuring a Mailbox manually…

The first step before creating any script is to test the basics, we must make sure that all documentation that we created so far to change feature works fine using PowerShell.

We can start creating a test account (Andy), as shown in Figure 04.

Figure 04

After that, we will apply all changes that we documented so far based on our corporate profile (MAPI, Single Item Recovery, Retention Policy and OWA Mailbox Policy). Note that the last two are assigned to a built-in policy, and for this exercise (Figure 05), we will be using Bronze profile.

Figure 05

We need also to check if the information that we just configured was applied properly, we will do that checking only the values that we have just changed are in place (Figure 06 and Figure 07).

Figure 06

Figure 07

In theory, we can enforce that process to the Service Desk for any new account created in our exchange environment, but the goal of this series is to provide a framework where the Service Desk team do not need to make decisions but just follow the process.

PowerShell automation to the rescue…

At this point in the game, we defined our profiles (Gold, Silver, and Bronze) and all the features and restrictions of each profile and all configuration is using the profile as part of the naming convention. All that information was added to a table and we tested manually in the previous section.

Table 3

The first step is to be able to identify which profile is assigned to the mailbox and we want to keep consistency of the configuration. There are several ways to do that, for this article series for instance, we will use the CustomAttribute6 (the number 6 is because of The Prisoner TV series, but you can use any value in your organization). The new attribute will have one of the profiles defined at the beginning of this series, which are GOLD, SILVER, or BRONZE (we will use capital letters just for the sake of simplicity).

We could create a script that applies the changes from the table above and it would work just fine, however any new policy would require a change in the script and we want to avoid that. For that reason we will create a baseline file that will have the “rules” of our corporate profiles, this file will be called ex.info and it will be CSV file.

The ex.info file is shown in Figure 08, and it will be similar to the table that we already have as part of our documentation. The goal is that every time that we have a new feature/restriction we just need to update that file without worrying about scripts. The header of the file and the first line are listed below in case you want to start yours based on this article.

RuleID,RuleName,Rulecmdlet,RuleAttribute,GoldValue,SilverValue,BronzeValue

0,MAPI Feature,Set-CASMailbox,MAPIEnabled,$True,$True,$False

Figure 08

In order to check the format of the file that we created, run these following cmdlets. The entire operation is shown in Figure 09.

$vFile = Import-CSV <file>

$vFile | ft –AutoSize

Figure 09

This ex.info file should be secure to avoid regular users to change its values because that could affect your production environment, for example, if someone changes the MAPIEnabled feature to false in all profiles that would be a disaster. If you have few Domain Administrators, we could keep it on the NETLOGON folder

Creating a check.ps1 script

We will be applying changes on mailboxes in the next articles of this series. To save time performing the checks we can create a simple script to validate the changes that we are defining in our ex.info. The script will be simple and it will list the settings based on the mailbox name passed to the script (Figure 10).

Figure 10

In order to check the status of a user we can run .\check.ps1 <mailbox> (Figure 11) and the output will be all attributes that we are setting up as part of the corporate profile.

Figure 11

Bear in mind that this check.ps1 script is static and later on, we will update it to use our ex.info baseline file as well.

Conclusion

In this second article of our series, we defined the central file and completed the first draft for our ex.info file which will be the source containing all rules to our future script.

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 3)
• Managing mailbox features with corporate profiles (Part 4)