If you missed the first part in this article series please read:
Following the previous articles we should have improved our environment, as we now have all mailboxes created in the Resource Forest using the Linked Mailbox feature. In this article we will work on the client-side. This means that we will set up the environment to support client access, such as OWA, Outlook 2007 and Outlook 2003. Just to refresh our memories, the environment after two articles should be as in Figure 01 below:
Figure 01:
Account Forests and Exchange Server 2007 Resource Forest with all mailboxes
Adjusting the DNS settings
In this article we will set up our clients, such as OWA, Outlook 2007 and Outlook 2003 to work in a Resource Forest environment. Before starting to deploy the certificates and Active Directory changes, we should create the following records in the msexchange.local zone in the Resource Forest:
- Autodiscover.msexchange.local pointing to the CAS Server
- Mail.msexchange.local pointing to the CAS Server
Creating a certificate in the Resource Forest
First of all, we should create a certificate for our environment. We have some options, such as: get a valid certificate or use a certificate built in an internal CA (Certification Authority). We have to choose if this certificate will be by service or if it will use Subject Alternative names, where we can group some names in the same certificate. In this article we are going to create an internal certificate using Subject Alternative names, after which we will request a certificate using the following syntax:
New-ExchangeCertificate –GenerateRequest –Path <path> -Subjectname <Subject-Name-of-the-certificate> -DomainName <Subject Alternative Names for the certificate>
Figure 02: Generating the request through the Exchange Management Shell using Subject Alternative Names
Now open the recently created file and copy the content using Ctrl+C. Open the web browser and type in the following address http://<CA-Server-Name>/certsrv, click on Request Certificate link, click on Advanced certificate request, click on the second option that starts with Submit a certificate request using a base 64-encoded CMC. On the new page, paste the memory content using Ctrl+V in the first box, and then click on Submit. The next screen will be a page informing you that the certificated was issued, then click on Download Certificate, and store it on the disk. Let’s go back to the Exchange Management Shell, and run the following cmdlet Import-ExchangeCertificate –Path <path-of-the-saved-certificate> as shown in Figure 03.
Figure 03: Importing the certificate using Exchange Management Shell
To enable the exchange certificate for OWA type:
Enable-ExchangeCertificate <ThumbPrint> -Service IIS
Now, we have a new certificate that accepts some names, such as: mail.msexchange.local and autodiscover.msexchange.local.
Configure the Trust Root Validation in the Account Forests
We have just set up a new certificate for the Resource Forest, but if the Account Forest clients try to access OWA or WebServices in the Resource Forest, they will receive a pop up window warning that the certificate is not valid. To resolve this issue, we can add the Resource Forest Certificate Authority in the Trusted Root Certification Authorities into the Account Forests.
We have to repeat these steps in each account forest. From the Account forest access the Resource Forest Certification Authority website, typing http://<servername>/certsrv , click on Download a CA Certificate, certificate chain, or CRL.
Figure 04: Downloading the CA Certificate Chain from the Resource Forest
On the next page, click on Download Certificate CA Chain and save the file on disk. Now we have to publish this Certificate Chain for our clients. Logged in a Domain Controller click on Start, Programs, Administrative Tools, and then click on Domain Security Policy.
Expand Computer Configuration, Windows Settings, Security Settings, Public Key Policies. Right-Click on Trusted Root Certification Authorities, and then click on Import… as shown in Figure 05.
Figure 05: Publishing the Certificate Chain from the Resource Forest into Account Forest
A new wizard will appear, click on Next, in the second part locate the Certificate Chain file which we have just downloaded in the previous step, and click Next, on the third screen click Next again, and then click on Finish.
Now all the Account Forest workstations will know the Certification Authority of the Certificates used by OWA in the Resource Forest. They will be able to access the webservices without security warnings.
User Experience using OWA
Now, let’s access OWA from a workstation that belongs to the APatricio’s Account Forest, accessing https://mail.msexchange.local/owa of the server located in the Resource Forest. In OWA we should use our domain and user in the format DOMAIN\User and type in the Account Forest password. Then, click on Log on, as shown in Figure 06.
Figure 06: Log in the OWA located in the Resource Forest
After our log on, we can create a new message and click on the To: field and we will see our mailbox from our Forest and also from the other Account Forest in the same GAL (Global Address List), because all the mailboxes are located in the same exchange organization, as shown in Figure 07.
Figure 07: The Resource Forest GAL has mailboxes from both Account Forests
Changing the user’s attributes in the account forest
Ok, now the concern is to improve the infrastructure to enable Outlook 2007 and Outlook 2003 to connect easily in the Resource Forest. To accomplish this goal, let’s set up the infrastructure
Outlook 2007 uses the Autodiscover service to automatically configure clients’ settings, but we need to change some settings in a Resource Forest scenario to allow this feature to work. First of all, all the users who have a mailbox in the Resource Forest should have the attribute mail in the Active Directory filled out with the correct Resource Forest address (smtp address).
We have three options to accomplish that: manually input the e-mail information for each user, create a script to change this value, or use Windows PowerShell to change the Exchange 2007 style. Of course, we prefer a PowerShell solution. Then, let us go download the ActiveRoles Management Shell tool from Quest Software (www.quest.com) and install an administrative machine which must have PowerShell installed. Then let’s change the mail attribute of all users to their correct e-mail address using the following cmdlets:
Get-QADUser | ForEach-Object { Set-QADuser $_.Name -ObjectAttributes @{mail = $_.Name + ‘msexchange.local’ } }
Now, we can see the mail attribute in the Account Forest users with the correct settings, as shown in Figure 08.
Figure 08: The attribute mail that was changed recently by PowerShell Tool
But why do we need to do this? Because the first screen of Outlook 2007 checks the user and mail attribute in the Active Directory, after that the Outlook 2007 will use the autodiscover services.
Setting up the Outlook 2007
We have just set up the Certificates and the mail attribute in the users, now we can run Outlook 2007 to validate our changes in the infrastructure.
We just have to start Outlook 2007 in an Account forest workstation, making sure that this workstation is the domain and can access the autodiscover.msexchange.local. The First wizard screen will be filled out with the user name and mail attribute which we have just changed using Power Shell, as shown in Figure 09.
Figure 09: The information is automatically filled in, enhancing the user experience
After that, Outlook 2007 will contact the autodiscover service and will get all the information that it needs to set up the client. The expected result is shown in Figure 10.
Figure 10: Outlook 2007 setup without user intervention to fill out any information
Now, just to see behind the scenes, let’s access the Virtual Directory IIS log files where Autodiscover is located and validate the log entry from our client.
Figure 11: Validating the Autodiscover access from the Account Forest
Finally, we can open the Outlook 2007 client and glance at the GAL with users from all Account Forests, as shown in figure 12.
figure 12: The GAL, seeing all the Account Forests users
Setting up Outlook 2003
The easy part of the article I left to the end, i.e. Outlook 2003 configuration, as it is easier than Outlook 2007. We just need to set up the server name in the profile configuration pointing to the resource forest Exchange Server, as shown in Figure 13.
Figure 13: Setting up Outlook 2003 to Exchange Server 2007 in the resource forest
Conclusion
In this last article we have just seen how to set up the resource forest so that it would be useful for the client side, such as OWA, Outlook 2007 using AutoDiscover service and Outlook 2003.
More information:
Configuring Public Key Group Policy
If you missed the first part in this article series please read:
