Managing mailbox features with corporate profiles (Part 1)
In this new article series, the author goes over the process of creating corporate profiles, which will be then used to manage a larger number of mailboxes from a central location.
If you would like to read the next part in this article series please go to Managing mailbox features with corporate profiles (Part 2).
If we look on the server side, Exchange Server 2013 is all about to scale out, which means if we need more horsepower to keep the business going we can add more servers to the current infrastructure and that will spread the load among more servers, improving resiliency and so forth.
Now, if we look on the operations side, the challenge is that we always have more mailboxes being added to the exchange organization and in some companies that process takes a lot of time in manual processes by the Service Desk team.
The business, as usual, wants to do more with less and that is going to be the goal for this series. We will focus on this requirement and in the first article - how we can create profiles that later on will be assigned to the mailboxes. The new profiles will enforce features and/or restrictions to the mailboxes from a central location and by doing that we can save time from the Service Desk team.
There are several ways and tools to do that, and we are going to focus on how using corporate profiles and a couple of simple PowerShell scripts will help us achieve our goals.
In order to understand this series better, we will use the following scenario: we have an Exchange Organization with 5000+ mailboxes and after having discussions with the Legal department and upper management we decided to apply certain features/restrictions based on profiles that we will defined in this first article. The ultimate goal is to reduce the work to manage several users to a simple task from a central location.
The advantage of using profiles is that the exchange administrator is able to manage from a central location a larger number of objects without the need of manual intervention.
The profile definition is key to define the future naming convention for Exchange objects and to define features/limits values for the future users that will be associate to the profile.
In order to keep consistency make sure that you create enough profiles to accommodate all your short and long term requirements, or at least plan to have enough room to support any growth on the structure down the road.
Based on my experience, what will be our worst enemy are the exceptions and for that, my recommendation is always to keep within the existent profiles instead of creating exceptions on a specific feature. In addition, if you see an expressive number of users asking the same thing, then you should start planning to change an existent profile or create a new profile to accommodate the new requirements but keep the standard in place at all costs.
The name for the profiles is also important because ideally you will name all other objects with a name that allows you to match the profile with a feature. The decision about the profile names is up to you. We can provide some definitions being used out there, such as REG (Regular), MED (Medium) and VIP; you can use army hierarchy, perhaps regions based on George Orwell’s book 1984 (Eurasia, Eastasia and Oceania). Well, we are going to keep it simple in this series, and we will be using Gold, Silver and Bronze.
In a real-world scenario, this kind of definition should be done with Security, Legal and upper-management and that usually involves creating a corporate policy informing all users before the exchange administrator can do anything on the server side.
When Legal department is involved in the process, then we have a great opportunity to apply e-mail life cycle using retention policies to archive and purge items based on the profile and this kind of exercise with different departments helps a lot.
In our scenario, after several sessions with our imaginary legal and security teams, we defined the following key features to be applied to the users and their values will vary based on the type of profile:
Some features/restrictions may use different object limits instead at the mailbox level. A good example is the maximum number of recipients where Exchange offers global limits. If the decision was to keep a lower number for all users, then our recommendation is to change the Global setting.
The same applies for Mailbox Database limits. I personally recommend using the Mailbox Database limits and keeping all mailboxes in a mailbox database that matches the profile. A good example would be one or more databases for Gold profile and only mailboxes assigned to the Gold profile would be stored in such databases.
Figure 01
A new window (Figure 02) will be displayed and any changes that we perform in the EAC (Exchange Admin Center) will be listed in this new window, but that window must be opened at all times, for now we will minimize it and go back to the EAC.
Figure 02
The next step is to use a dummy account and change a feature that is part of the policy. At this point we do not care about the value itself but we are interested in finding out the cmdlet and the attribute. In the example shown in Figure 03, we are changing the Maximum recipients to 30 for our test account. We must make sure to save the settings to have the information logged on the Show Command Logging window.
Figure 03
After completing the change on the test account, we can go back to the Show Command Logging page and all cmdlets used in the EAC will be displayed there.
Note:
The Show Command Logging will show all cmdlets of the current session, since we are changing settings our best chances to find the information is looking for verbs in our cmdlets that produce changes, such as: set, add, new and so forth.
In the Figure 04, we can see the entry Set-Mailbox and if we select and look at the bottom, we will have the entire cmdlet and the parameters used. That was the cmdlet performed in the background when we updated our dummy account. Our task is to record that in order to change the recipient limit. For any given user we need to use the Set-Mailbox cmdlet and the attribute is RecipientLimits
Figure 04
If you would like to read the next part in this article series please go to Managing mailbox features with corporate profiles (Part 2).
Introduction
When managing an Exchange Server environment with hundreds to thousands of mailboxes, the process to keep consistency among servers and mailboxes can be challenging.If we look on the server side, Exchange Server 2013 is all about to scale out, which means if we need more horsepower to keep the business going we can add more servers to the current infrastructure and that will spread the load among more servers, improving resiliency and so forth.
Now, if we look on the operations side, the challenge is that we always have more mailboxes being added to the exchange organization and in some companies that process takes a lot of time in manual processes by the Service Desk team.
The business, as usual, wants to do more with less and that is going to be the goal for this series. We will focus on this requirement and in the first article - how we can create profiles that later on will be assigned to the mailboxes. The new profiles will enforce features and/or restrictions to the mailboxes from a central location and by doing that we can save time from the Service Desk team.
There are several ways and tools to do that, and we are going to focus on how using corporate profiles and a couple of simple PowerShell scripts will help us achieve our goals.
In order to understand this series better, we will use the following scenario: we have an Exchange Organization with 5000+ mailboxes and after having discussions with the Legal department and upper management we decided to apply certain features/restrictions based on profiles that we will defined in this first article. The ultimate goal is to reduce the work to manage several users to a simple task from a central location.
Advertisement
Profile definition…
The profile definition process is critical for any company that is looking to keep consistency of settings among several mailboxes. A profile is a logic classification that will be assigned to the mailboxes and based on the profile, features and/or restrictions will be applied to mailboxes.The advantage of using profiles is that the exchange administrator is able to manage from a central location a larger number of objects without the need of manual intervention.
The profile definition is key to define the future naming convention for Exchange objects and to define features/limits values for the future users that will be associate to the profile.
In order to keep consistency make sure that you create enough profiles to accommodate all your short and long term requirements, or at least plan to have enough room to support any growth on the structure down the road.
Based on my experience, what will be our worst enemy are the exceptions and for that, my recommendation is always to keep within the existent profiles instead of creating exceptions on a specific feature. In addition, if you see an expressive number of users asking the same thing, then you should start planning to change an existent profile or create a new profile to accommodate the new requirements but keep the standard in place at all costs.
The name for the profiles is also important because ideally you will name all other objects with a name that allows you to match the profile with a feature. The decision about the profile names is up to you. We can provide some definitions being used out there, such as REG (Regular), MED (Medium) and VIP; you can use army hierarchy, perhaps regions based on George Orwell’s book 1984 (Eurasia, Eastasia and Oceania). Well, we are going to keep it simple in this series, and we will be using Gold, Silver and Bronze.
Creating the Exchange objects and some research…
Now that we have the name for the corporate profiles, we need to start defining features/restrictions for each profile.In a real-world scenario, this kind of definition should be done with Security, Legal and upper-management and that usually involves creating a corporate policy informing all users before the exchange administrator can do anything on the server side.
When Legal department is involved in the process, then we have a great opportunity to apply e-mail life cycle using retention policies to archive and purge items based on the profile and this kind of exercise with different departments helps a lot.
In our scenario, after several sessions with our imaginary legal and security teams, we defined the following key features to be applied to the users and their values will vary based on the type of profile:
- Outlook client (MAPI feature)
- Single Item Recovery
- Retention Policy
- OWA Policy
- Maximum number of recipients
Some features/restrictions may use different object limits instead at the mailbox level. A good example is the maximum number of recipients where Exchange offers global limits. If the decision was to keep a lower number for all users, then our recommendation is to change the Global setting.
The same applies for Mailbox Database limits. I personally recommend using the Mailbox Database limits and keeping all mailboxes in a mailbox database that matches the profile. A good example would be one or more databases for Gold profile and only mailboxes assigned to the Gold profile would be stored in such databases.
Finding out the information to change some attributes...
At this point, we have some research to do to find out which cmdlets and attributes are required to define the features that will be applied to the corporate profiles. Exchange Server 2013 Service Pack 1 introduced a feature called Show Command Logging (Figure 01) which will help us a lot to find out the specific settings that will be part of our future profiles.Figure 01
A new window (Figure 02) will be displayed and any changes that we perform in the EAC (Exchange Admin Center) will be listed in this new window, but that window must be opened at all times, for now we will minimize it and go back to the EAC.
Figure 02
The next step is to use a dummy account and change a feature that is part of the policy. At this point we do not care about the value itself but we are interested in finding out the cmdlet and the attribute. In the example shown in Figure 03, we are changing the Maximum recipients to 30 for our test account. We must make sure to save the settings to have the information logged on the Show Command Logging window.
Figure 03
After completing the change on the test account, we can go back to the Show Command Logging page and all cmdlets used in the EAC will be displayed there.
Note:
The Show Command Logging will show all cmdlets of the current session, since we are changing settings our best chances to find the information is looking for verbs in our cmdlets that produce changes, such as: set, add, new and so forth.
In the Figure 04, we can see the entry Set-Mailbox and if we select and look at the bottom, we will have the entire cmdlet and the parameters used. That was the cmdlet performed in the background when we updated our dummy account. Our task is to record that in order to change the recipient limit. For any given user we need to use the Set-Mailbox cmdlet and the attribute is RecipientLimits
Figure 04
Conclusion
In this first article, we defined the corporate profiles and the initial features/restrictions that will be part of those profiles. We also started the research to find out the cmdlets and attributes required for each feature listed, and that will be important when we start centralizing such changes.If you would like to read the next part in this article series please go to Managing mailbox features with corporate profiles (Part 2).
