Automating Exchange Server 2010 Deployment

by [Published on 26 April 2012 / Last Updated on 26 April 2012]

In this article the author covers the delegation process to allow regular users to be local administrators on Exchange Server boxes using Group Policies.

Introduction

Let’s create a scenario for the sake of this article. A company’s main site is based in Porto Alegre and with an office in Toronto. The Domains Admins, Exchange Organization admins and all sort of big guys’ accounts are from Porto Alegre where the head of the IT department is located. However, the IT department wants to delegate the Exchange Deployment to a local administrator located in their branch office. The user for the branch office in Toronto is called Anderson.Toronto and at this point he is only member of the Domain Users group.

Now, that we know the scenario background and have established our goals we can start, shall we? First of all, in this kind of scenario it is good practice to use Organization Unit to delegate the user administration and service administration to a branch office. The main reason being that if we later join a server to the domain, the local guy won’t be a local administrator of the server as by default only Domain Admins group, and the local administrator would have local administrator privileges. Imagine if he needs to install an AV on that server, he has to use another set of credentials to have access to the file server and so forth and that may be too complicated.

Let’s create the Toronto OU, and within this OU create an OU for Admin, Computers, Servers, Users, while, within the Servers OU create an Exchange Server. The result of this operation is depicted in the Figure 01.


Figure 01

Now, let’s create an administration Group called TOR-Admins in the Admin OU and add our user Anderson.Toronto as member of this group. Now, we can delegate account administration at Toronto OU level to that group and the user Anderson.Toronto will be a happy camper to manage user, groups and the rest. However, we also want to improve his administration quality time and for that reason we could create a GPO to define the local administrator group, and then right-click on Servers OU, and click Greate a GPO in this domain, and link it here (Figure 02)


Figure 02

Let’s use TOR-ServerAdministration as the name for this new OU, and Edit the new GPO. Go through these folders: Computer Configuration, Policies, Windows Settings, Security Settings, Restricted Groups, then right click on the right side and click Add Group…

Type in the name of group that we want to populate, which is Administrators. In the new window that shows up click the first Add button on the right side and type in Administrator (note, that when we don’t use Domain\ we are referencing to the built-in objects of the servers that will receive this GPO) and click OK; click the Add button, and then Browse and find Domain Admins. Click OK and the final one using the same Add and Browse button is the TOR-Admins group. Note: I strongly recommend always using Browse for Active Directory groups to avoid typing in one of the groups incorrectly. Before closing our new GPO, let’s disable the user Configuration portion of this GPO since it is going to be used just for Delegated Administration of the servers. A summary of the GPO is shown in Figure 03.


Figure 03

Perfect, now that we have a Group Policy in place we just need to move the servers located in the Branch Office to the Servers or Exchange Server while, the regular account Anderson.Toronto will be able to manage them as local administrator without any issues.

Bear in mind, that after you perform the move you can be restarting or running a gpupdate /force to refresh the Group Policies. Also, don’t forget the replication time for the new GPO to show up in your branch office.

When we use GPO to delegate administration we always must be aware that the task is based on GPO, even though you go to the server and add a new local administrator, that entry will be overwritten by the GPO after a couple of hours. So, any special application, and Exchange is one of them, must be dealt with separately and that was the reason that we created an Exchange Server Organization Unit before. The reason is that Exchange adds two groups in the Local Administrator groups during the installation process which are Exchange Trusted Subsystem and Organization Management.

In order to avoid any issues, let’s open the Group Policy Management Console in a Domain Controller, expand Forest, your domain, Group Policy Objects, and then right-click on the GPO that we have just created for the regular servers (which is Toronto-ServerAdministration in this article) and click Copy. Then right click the Group Policy Objects and click Paste. In the new dialog box, just accept the default permissions and click OK. Click OK again after the copy status process dialog box finishes.

Now, let’s rename the Copy of Toronto-ServerAdministration to something more appealing, such as Toronto-ExchangeServerAdministration, edit the policy, and add the two groups that we mentioned previously which are: Exchange Trusted Subsystem and Organization Management. The policy summary should be similar to the one shown in Figure 04.


Figure 04

Finally, right click the Exchange Server OU, and select Link and Existing GPO, select the one that we have just updated and click OK. Also, as final step make sure to move your Exchange Servers to the Exchange Servers OU.

Provisioning a new server…

The easy part of this article is the Exchange one, and in order to delegate a server we must be aware of the following key points:

  • Delegation must occur after having an initial server in the organization. It cannot be the first one;
  • The user delegated that can install the server, cannot remove or add/remove features afterwards;
  • The user that is able to install the delegated Exchange Server cannot manage any server or recipient setting, just deploy the server. Although you can configure the same user to have such permissions but by default he will be able just to install the server.
  • The account that will install Exchange Server must be local administrator, we took care of this pre-requisite in an elegant way in the previous section but in case you don’t use that, you must make sure that the account has such privilege.

Now, that we are aware of the key points about this process, we can log on to an existent server using any account member of the Organization Management group and from the Exchange installation files we can use the following syntax to provision a new Exchange Server:

Setup.com /NewProvisionedServer:<Server-Name>

Bear in mind that the server specified in the cmdlet must be already in the domain before running the setup.com. In this article we are going to delegate the TOREX01 (Figure 05) to our buddy Anderson.Toronto account which by now the replication should’ve taken place, and he should be the local administrator of the TOREX01 which account was moved to Exchange Server in that OU being controlled by our Group Policy.


Figure 05

After provisioning the server, we can check that it is under Server Configuration in Exchange Management Console.The server shows up as Provisioned in the role column, as shown in Figure 06. The process also adds the computer to the Exchange Servers groups, set permissions and other requirements to allow such deployment to be prepared during the provision process.


Figure 06

The final step of this puzzle is to add the user that will be responsible for the Exchange Server deployment into the group Exchange Delegated which can be found in the Microsoft Exchange Security Groups OU, as shown in Figure 07.


Figure 07

Deploying Exchange Server in the branch office…

Here we go finally, logged on as Anderson.Toronto we can finally install the deployment. Just in case let’s check the local administrators groups and the results should be similar to the one shown in Figure 08.


Figure 08

To test the user can run net user <username> /domain and the result must contain Delegated Setup listed (Figure 09) otherwise it won’t work.


Figure 09

If all is good, then the user just needs to run set up and install the Exchange, it can be done using either the command-line (setup) or the graphical interface.

Conclusion

In this article we saw how to create a couple of OUs to support Exchange Server being installed for a regular user using the provision method. Bear in mind that the GPO and OUs were created to provide a central way to manage and keep consistency of your local administration for a branch office, but you can always do that manually in case you need it.

Featured Links