Publishing Exchange 2007 OWA, Exchange ActiveSync and RPC/HTTP using the 2006 ISA Firewall (Part 4)

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

If you would like to be notified when Thomas Shinder releases the next part in this article series please sign up to the ISAServer.org Real Time Article Update newsletter.

In the first three parts of this series on publishing Exchange Web services, we went over the security implications of the solution and a discussion of the example network topology, and then we installed and configured the Hub Transport and Mailbox server. In this article we will move forward with the Exchange Server configuration by installing and configuring the Client Access Server. If you thought installing and configuring the Hub Transport and Mailbox Server was a trip, you ain’t seen nothing yet!

Discuss this article

Installing the Exchange Client Access Server

Now we are ready to install the Client Access Server. Most of the configuration steps are the same and require you to download all the prerequisite software that we downloaded when we installed the Mailbox and Hub Transport Server. The only difference is that on the Server Role Selection page you will select the Client Access Role, as seen in the figure below.


Figure 1

In the figure below you can see that installation time for the Client Access Server is quite a bit quicker than the Mailbox and Hub Transport Server. The Client Access Server only took 17 minutes compared to over 50 minutes for the Mailbox and Hub Transport Server.


Figure 2

Configuring the Client Access Server

Now we will see what steps we need to take to finalize deployment according to the Exchange Server Help. The first thing they want us to do is enter the product key. Since this is a demo version, there is no key to enter so we will not worry about that. The next thing they suggest is that we run the Exchange Best Practices Analyzer.


Figure 3

When you run the Exchange BPA, make sure you only run the test on the Client Access Server so that you do not waste time re-running the scan on the Mailbox and Hub Transport Server. Uncheck the checkbox for EXHC2007MB as seen in the figure below. Notice that there are several different checks that we can perform. In this example we will do the Health Check. Do not select the Performance Baseline (2 hours) option unless you want to wait a very long time for the baseline to complete.


Figure 4

After completing the scan, it looks like there aren’t any major issues. Since my storage driver is too old and due the fact that the Exchange Server is 32-bit, I should increase the Application log size to 16 MB at the least.


Figure 5

In the Mailbox section of the To Do list, the first thing they suggest doing is to configure the Offline Address Book for Outlook 2007 clients. Click the Configure Offline Address Book (OAB) Distribution for Outlook 2007 Clients link.


Figure 6

Click the Go to Offline Address Book Management link in Step 2 of the Help file.


Figure 7

Double click on the Default Offline Address Book entry in the Offline Address Book tab. Here you can see that the Exchange installer enabled the Enable Web-based distribution for you and also added the IIS virtual directory where the OAB can be accessed.


Figure 8

Click the OAB Virtual Directory Management link under step 3 in the Help file entry above (figure 7). Double click the OAB (Default Web Site) entry on the Offline Address Book Distribution tab. In the OAB (Default Web Site) Properties dialog box, click the URLs tab. There are two text boxes for you to enter URLs for access to the OAB: the Internal URL and the External URL.

I have to tell you that I honestly have no idea how these entries are used by the Exchange Server. However, it seems like a good idea to fill in this information just in case it actually does something. The Internal URL is the actual name of the Client Access Server on the internal network and the External URL name is the name that external clients will use to connect to the ISA Firewall to reach the Client Access Server.

In this example the Internal URL is http://exch2007cas.msfirewall.org/OAB. It represents the actual FQDN of the Client Access Server on the internal network. The External URL is https://owa.msfirewall.org/OAB, it represents the actual name that external users would use to access the OAB from external locations. However, I cannot tell you if the protocol identifier is important, since http was automatically entered for the internal URL. I entered https for the external URL since we willl be using SSL to SSL bridging in this solution. Do not bother reading the Help File on these entries, as the explanations are tautological and provide no additional information.

Click OK on the OAB (Default Web Site) Properties dialog box.


Figure 9

We now move on to the Client Access section of the Exchange guidance. The first thing we need to do is Configure SSL for your Client Access server. We will begin by clicking that link as seen in the figure below.


Figure 10

This brings up a Help file entry that explains how to use PowerShell to request a certificate. You might ask yourself why do you have to use PowerShell and not just use the easy Wizards we used with Exchange 2003. The answer is that I have no idea – but I can tell you that using PowerShell will take about 10 minutes longer to get it right and in addition, if you do it wrong, you will have no idea how to back out!

In the Help file below, step 2 provides the information on how to generate a certificate request file that can be submitted to a CA for certificate generation.


Figure 11

What should we enter in the PowerShell CLI to request the certificate? Use the following command:

New-ExchangeCertificate -GenerateRequest -SubjectName “DC=vircom(second level domain name), DC=co(top level domain name), O=Vircom(Organisation name, can be anything), CN=mail.vircom.co.uk(public name)” -DomainName mail.vircom.co.uk(1st SAN but must be the same as the public name for ISA to work with the cert), smtp.vircom.co.uk(2nd SAN for binding to SMTP service without event log warnings), autodiscover.vircom.co.uk(3rd SAN for autodiscover service), vircom.co.uk(4th SAN as domain name – still not sure why/if this is needed), vircom07.vircom.co.uk(internal FQDN), vircom07(internal host name) -FriendlyName “Microsoft Exchange 2007” -Path d:\mail.vircom.co.uk.req

Notice the information in parentheses that tells you what information to include in each section of the command. You need to remove the parentheses and the information inside them before generating the certificate request file in PowerShell. What is really odd about all the SANs (subject alternative names) on the certificate is that only Vista clients and Windows 2008 clients can make use of the SANs. In fact, I do not think that Windows 2003 supports them, so what is the point of generating all of these SANs when Windows 2003 server services cannot use them? Do not bother looking this up in the Help file, it will not tell you why you need all these SANs or what they are used for.

In our scenario, this request would look like this:

New-ExchangeCertificate -GenerateRequest -SubjectName “DC=msfirewall.org, DC=com, O=msfirewall, CN=owa.msfirewall.org” -DomainName owa.msfirewall.org, smtp.msfirewall.org, autodiscover.msfirewall.org, msfirewall.org, exch2007mb.msfirewall.org, exch2007mb -FriendlyName “Microsoft Exchange 2007” -Path c:\mailcert.req

We enter this into the PowerShell interface and press ENTER. You can see the results below.


Figure 12

Next, at the Client Access Server, you open up Internet Explorer and enter the URL to the Microsoft Certificate Server located on the domain controller on the lab network. In this example we will enter http://dc/certsrv, which brings up the certificate services Web page.

Click the Request a certificate link on the Welcome page.


Figure 13

On the Request a Certificate page, click the Advanced certificate request link.


Figure 14

On the Advanced Certificate Request page, click the Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file or submit a renewal request by using a base-64-encoded PKCS #7 file.


Figure 15

Open up the certificate request file generated by PowerShell in Notepad. Click Edit and then click Select All. Then click Edit again and click Copy.


Figure 16

Copy the certificate request information into the Saved Request text box, as seen in the figure below. Do not bother using the Browse for a file to insert because the security settings on your browser breaks this functionality.

In the Certificate Template drop down list, select the Web Server option, then click Submit.


Figure 17

Discuss this article

On the Certificate Issued page, click the Download certificate link.


Figure 18

In the File Download – Security Warning dialog box, click the Save button. Save the certificate to the root of the C:\ drive so that it is easy to find.


Figure 19

Unfortunately, we will have to return to PowerShell to get this certificate bound to the Client Access Server Web site.

Enter the command:

Import-ExchangeCertificate –path c:\certnew.cer

In the PowerShell command line and press ENTER

You will see what appears in the figure below


Figure 20

Now we need to figure out the thumbprint on the certificate we just installed. In order to do that, go into the PowerShell interface and enter the command:

Dir cert:\LocalMachine\My | fl

As seen in the figure below, the thumbprint of the certificate appears next to the Thumbprint entry. Copy that thumbprint value to the clipboard.


Figure 21

The next step is to bind this certificate to the services we want to bind it to. In the PowerShell interface enter the following command:

Enable-ExchangeCertificate -thumbprint 67DA55B9F5AB2A735E7CBD11A895F7757ACC07C4 -services “IIS,SMTP”

Note:
In reviewing this article I noticed a couple of error that I have made already. First, notice that the thumbprint on the command above is incorrect. Second, notice that the thumbprint in the following screenshots is also incorrect – I have used the footprint for the self-signed certificate instead of the owa.msfirewall.org certificate, which will not work, or at least I do not think it will work. But this makes a good point – PowerShell leads to many configuration errors that would have never been made in the easy-to-use Exchange 2003 user interface. And if I had not discovered this error when reviewing the screenshots in this article, would I ever be able to discover what I had done wrong? So, when you do this in your test bed, make sure you use the correct thumbprint! BTW – I corrected this error by re-running the commands seen below, but this time using the correct certificate. I confirmed this by looking in the IIS console and seeing that the new certificate was bound to the OWA Website.

Replace the thumbprint value with the value you received for your thumbprint. Replace the services value(s) with those service(s) that you want the certificate bound to.

As you can see in the figure below, I ran into some trouble. While I was able to bind the certificate to the IIS WWW service without any problem, I received an error when I tried to bind it to the SMTP service. The reason for that error is that the SMTP service was not installed on the Client Access Server, since SMTP is the province of Hub Transport Server. Notice that we were able to bind the certificate to the POP3 service and the IMAP4 service. However, I had to repeat the commands a couple of time since PowerShell does not recognize the actual names of the services and you have to leave out the 3 for POP3 and the 4 for IMAP 4.


Figure 22

The Exchange guidance states that the next step is to configure Exchange ActiveSync. When you click the Exchange ActiveSync link you will see the Help File entry as it appears in the figure below. We are not going to get into creating ActiveSync policies in this article, so we will bypass these configuration steps for the time being.


Figure 23

The last section on the Exchange guidance page provides information about the Hub Transport Server. Since we already configured the Hub Transport Server, we do not need to do that again.


Figure 24

Configure the OWA Directories

We need to configure the OWA directories to support Basic and Integrated Authentication. To do this, click on the Server Configuration\Client Access node in the left pane of the console. Click the Outlook Web Access tab in the middle pane. Double click the owa (Default Web Site) entry.

On the General tab enter the Internal URL and External URL names that are used to reach the site as seen in the figure below. Since we really do not know if this does anything, you can probably leave them blank. However, since I do not know what they do, I will enter the information anyhow. For the Internal URL we will enter https://exch2007cas.msfirewall.org/owa and for the External URL we will enter https://owa.msfirewall.org/owa. Maybe someday someone will be able to explain these settings.


Figure 25

Click on the Authentication tab in the owa (Default Web Site) Properties dialog box. Select the Use one or more standard authentication methods option. Put a checkmark in the Integrated Windows authentication and Basic authentication (password is sent in clear text) checkboxes. Click OK.


Figure 26

You will see a warning informing you that you will need to restart IIS for these changes to take effect. We will not restart IIS right now, as we need to make similar changes to the other OWA related directories. In addition, we will not be configuring support for remote access to file shares and SharePoint libraries this time around. I have tested it and it did not work, but that is most likely because I do not know yet how to make it work. When I figure it out, I will let you know.


Figure 27

Double click on the Exchange (Default Web Site) entry. In the Exchange (Default Web Site) Properties dialog box, click on the Authentication tab. On the Authentication tab, select the Use one or more standard authentication methods option and then put checkmarks in the Integrated Windows authentication and Basic authentication (password is sent in clear text) checkboxes. Click OK.


Figure 28

Double click on the Exchweb (Default Web Site) entry. In the Exchweb (Default Web Site) Properties dialog box, click on the Authentication tab. On the Authentication tab, select the Use one or more standard authentication methods option and then put checkmarks in the Integrated Windows authentication and Basic authentication (password is sent in clear text) checkboxes. Click OK.


Figure 29

Double click on the Public (Default Web Site) entry. On the Public (Default Web Site) Properties dialog box, click the Authentication tab. On the Authentication tab, select the Use one or more standard authentication methods option and then put checkmarks in the Integrated Windows authentication and Basic authentication (password is sent in clear text) checkboxes. Click OK.


Figure 30

Enable RPC/HTTP (Outlook Anywhere)

We need to enable the RPC/HTTP Outlook Anywhere feature in the Exchange Management console before Outlook 2003+ clients can connect using RPC/HTTP. To do this, click on the Server Configuration\Client Access node in the left pane of the console. In the right pane of the console, click on the Enable Outlook Anywhere link.


Figure 31

On the Enable Outlook Anywhere page, enter the FQDN that external users will use to reach the RPC/HTTP Web site. In our example, external users will access the RPC/HTTP proxy site using the FQDN owa.msfirewall.org, so we will enter that into the External host name text box. In the External authentication methods option set, you can select either Basic authentication or NTLM authentication. I recall reading somewhere that you get more features when using Outlook 2007 together with Exchange 2007 when you use NTLM authentication. If that is true, then we should select NTLM authentication. I do not know if it is true or not, but it cannot hurt to use NTLM authentication, so select the NTLM authentication option.

Even though we do not know if selecting NTLM makes any difference with enable feature access, at least we can demonstrate the new ISA Firewall’s ability to perform authentication protocol transition. That is to say, the external Outlook client will use basic authentication to authenticate with the ISA Firewall and the ISA Firewall will authenticate on behalf of the external Outlook client using NTLM.

Do not select the Allow secure channel (SSL) offloading. That is a low security option and you never want to select that unless you are willing to take your chances that there will never be any malicious users on your network with network analyzers in hand.

Click Enable.


Figure 32

On the Completion page you will receive information that the wizard completed successfully. Click Finish.


Figure 33

In the upper pane of the middle pane, double click on the EXCH2007CAS entry. In the EXCH2007CAS Properties dialog box, click on the Outlook Anywhere tab. If you need or want to change the authentication protocol used to authenticate with the RPC/HTTP proxy, you can make the changes here. We will not make any changes because we want to use NTLM authentication.


Figure 34

You might now be saying “Hey Tom, why did you enable RPC/HTTP in the Exchange Server configuration when you have not installed the RPC/HTTP Proxy service yet?” Unfortunately when you enable Outlook Anywhere it does not check to see if the RPC/HTTP Proxy service was installed, so you will need to install it on the CAS.

Install the RPC/HTTP Proxy

In order for RPC/HTTP connections to work, you need to install the RPC/HTTP Proxy service on the Client Access Server. You can do this from the Add/Remove Programs applet on the Client Access Server machine. Click the Add/Remove Windows Components button in the Add/Remove Programs window.

In the Windows Components dialog box, click on Networking Services (do not put a checkmark in the checkbox!) and then click the Details button. In the Network Services dialog box, put a checkmark in the RPC over HTTP Proxy checkbox and then click OK. Follow the steps in the wizard to complete the installation.


Figure 35

Discuss this article

Summary

In this fourth part in our article series on publishing Exchange 2007 Web services, we installed the Client Access Server and then configured the Client Access Server. We set the permissions on the OWA directories and installed and configured the RPC/HTTP service. We also requested a Web site certificate for the Client Access Server and installed the certificate using the PowerShell interface. An important lesson we learned in this article is that you have to be very careful with the PowerShell interface, as it is quite easy to make a mistake and not notice it. In the next article in this series we will move away from the PowerShell interface and work with the extremely well designed user interface created by the ISA Firewall Team. See you then! – Tom.

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

If you would like to be notified when Thomas Shinder releases the next part in this article series please sign up to the ISAServer.org Real Time Article Update newsletter.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top