RSS Subscription 167 Posts and 2,643 Comments

Exchange 2010 RTM High Availability Load Balancing Options

With Exchange 2010 comes many advantages in the HA realm.  One of them is the ability to connect to the Client Access Server for RPC.  This means, when a Mailbox Server does a *over (failover or a switchover), the user is still connected to their RPC Endpoint.  You can also create a Client Access Array which load balances your RPC Endpoint on your CAS Servers.  Lots of information on the RPC Client Access Server here and here.  So what options are available for load balancing this new RPC Client Access Array and at the same time, load balancing all our other services?  And what are the pros/cons of each method?  If you want to know, read on…

Exchange Load Balancing Options

In Exchange 2007, if you wanted any type of HA, you needed at least four servers.  2 for CCR Nodes and 2 for HUB/CAS Nodes.  The reason why you cannot have 2 nodes altogether is that CCR Nodes were limited to the Mailbox role only.  For an Exchange Site, you need to always have at least the  HUB/CAS/MBX Role  for that site to be operational.  In Exchange 2010, more options are now available.  You now have something called Database Availability Groups (DAGs).  These DAG members can contain all Exchange roles (HUB/CAS/MBX/UM) but still may not contain the Edge Transport role.

There is a problem though.  There is a Windows limitation that allows you to install Windows Network Load Balancing on a server that also contains Failover Clustering Services. So while we can now have 2 Exchange 2010 Servers, we need a way to load balance the CAS role to provide High Availability for the following CAS Services:

  • Outlook Web App (formerly Outlook Web Access) (HTTP Traffic)
  • Exchange Control Panel (HTTP Traffic)
  • Exchange Web Services (HTTP Traffic)
  • Exchange ActiveSync (HTTP Traffic)
  • Autodiscover (HTTP Traffic)
  • Offline Address Book (HTTP Traffic)
  • Outlook Anywhere (HTTP Traffic)
  • RPC Client Access (RPC  Traffic)

There are a few options for load balancing.  The first is the ability to use ISA.  The problem here, is that ISA can only load balance HTTP-based traffic.  If you take a look at the bulleted list above, you can see that RPC Client Access Service is RPC Traffic which means that ISA cannot load balance this traffic.  We have a few load balancing options then:

  1. 2 Multi-Role DAG Members and Hardware Load Balancers – Utilize 2 Multi-Role DAG Members (MBX/HUB/CAS).  Use a hardware load balancer to load balance all of the bulleted items above including the RPC Client Access Service using an RPC Client Access Array which load balances port 135 for the RPC Endpoint Mapper and 1024-65535 ports.  Typically, since you are using High Availability, this means that you would most likely want to have 2 hardware load balancers.
  2. 2 DAG Members, 2 HUB/CAS Servers, and Windows Network Load Balancing - Utilize 2 DAG Members (MBX).  Use 2 HUB/CAS Servers with Windows Network Load Balancing.  Windows Network Load Balancing will load balance all of the bulleted items above including the RPC Client Access Service using an RPC Client Access Array which load balances port 135 for the RPC Endpoint Mapper and 1024-65535 ports.
  3. 2 DAG Members and DNS Round Robin - Use 2 Multi-Role DAG Members (MBX/HUB/CAS).  Use DNS Round Robin to achieve a “poor man’s solution” type of load balancing.  With this scenario, you will not have automatic failover for the RPC Client Access Service.  You will essentially create two A Record for the RPC Client Access Array; one pointing to the first multi-role DAG Member and one pointing to the second multi-role DAG Member.  You will most likely want to lower the TTL values of these DNS records to 5 minutes so if a failure does happen, you can remove one of the A records and the clients will flush their DNS cache within 5 minutes time.
  4. 2 DAG Members, ISA/TMG/UAG, and either Hardware Load Balancing or DNS Round Robin - Use 2 Multi-Role DAG Members (MBX/HUB/CAS).  Use ISA/TMG/UAB to load balance all HTTP items from the bulleted list above. The issue here is that now with Exchange 2010, for mailbox access, users connect to the Client Access Server for their RPC Endpoint.  To make this redundant, we create an RPC Client Access Array.  This RPC Client Access Array can be load balanced through a hardware load balancer, DNS Round Robin, or Windows Network Load Balancing.  ISA/TMG/UAG cannot load balance non-HTTP Traffic.  So if you have ISA/TMG/UAG, you can still use it to load balance all HTTP Traffic but you would still need to use a Hardware Load Balancer, DNS Round Robin, or Windows Network Load Balance to load balance the RPC Client Access Array.  The example picture below will show the use of UAG with a Hardware Load Balance mix.

Exchange Load Balancing Options and their benefits

Taking a look at the above list of options, we can use several different options including Windows Network Load Balancing, Hardware Load Balancing, and DNS Round Robin. Each has their pros and cons in terms of cost and functionality.

Hardware Load Balancing

Hardware Load Balancers can have the most capacity in terms of user connections.  But for SMBs, you won’t have to worry about load.  The load is more for very large organizations.  In fact, Microsoft recommends that if you are going to require over 7 HUB/CAS Servers in a load balanced farm, to use Hardware Load Balancers instead of Windows Network Load Balancing.  Hardware Load Balancers are also the most expensive option.

Hardware Load Balancers do have the best functionality from a perspective of Client to Server Affinity depending on the vendor used.  For example, we can use multiple affinities and have fallbacks to a specific affinity of our preferred affinity fails.  For example, we can set up up our hardware load balancers to use the following affinity in terms of preference:

  • Existing Browser-Based Cookie
  • Hardware Load Balanced created cookie
  • SSL Session ID
  • Source IP

The goal here is to make sure that every user is load balanced evenly and that automatic failover can occur quickly and smoothly.

Windows Network Load Balancers

Windows Network Load Balancers do not achieve as much capacity in terms of user connections as a Hardware Load Balancer, but they can still handle a lot of connections.  Windows Network Load Balanced farms can use as many as 8 CAS Servers without suffering a performance degradation.  In order to have the need for 8+ CAS Servers, you’ll need to have many users (tens of thousands). Windows Network Load Balancing is built into Windows Server and therefore, it’s a large cost savings in comparison to purchasing hardware load balancers.

Windows Network Load Balancers do not have as good of functionality of Hardware Load Balancers from a perspective of Client to Server Affinity.  For example, we only have one affinity method.  That method is Source IP.  The downside to using Source IP is if you have a lot of connections coming from a NAT’d Source IP. This means that all of these connections will end up hitting the same Client Access Server as again, the only Affinity Method a Windows Network Load Balancer has is Source IP.

Most likely, if you don’t have the need for more than 8 CAS Servers, Windows Network Load Balancing will suffice for you needs.  It’s cheap, comes with Windows, and does its job.

ISA Server, TMG, or UAG

ISA/TMG/UAG Servers to have more capabilities than Windows Network Load Balancers.  The one downside to them is that they cannot load balance RPC Traffic.  Because of that, you can still use ISA/TMG/UAG to load balance your HTTP traffic, but you’ll still need a Hardware Load Balancer or a Windows Network Load Balancer to load balance your RPC Client Access Array.

ISA/TMG/UAG do scale better than Windows Network Load Balancing but not as well as a Hardware Load Balancer.  ISA/TMG/UAG does not cost as much as a Hardware Load Balancer but is more expensive than Windows Network Load Balancing.  ISA/TMG/UAG also has the capability to do Load Balanced created cookies as well as Source IP Affinity depending on the protocol ISA/TMG/UAG is publishing.

Another upside to using ISA/TMG/UAG is that they can do pre-authentication.  This means that if a server goes down in which a client has affinity to, ISA/TMG/UAG still contains the authentication context of the user and automatically re-authenticates to the new Client Access Server.

DNS Round Robin

DNS Round Robin scales just as high as Hardware Load Balancers because the connections will just go directly to the Client Access Servers.  If anything, it has the highest scale as you don’t have anything in the middle doing anything with the connections.  It’s also free to use!  But in this case, free is not necessarily good because you lose a lot of functionality.  Hardware Load Balancers, Windows Network Load Balancers, and ISA/TMG/UAG all have the capability to detect server failures and automatically stop sending to the server and direct all traffic to a server that is operational.

DNS Round Robin has no automatic server failure detection.  If a host goes down, an Administrator will need to realize it, remove the DNS A/HOST Record for the server that went down, and then clients will have to wait for the TTL value on the old DNS record to expire.  When that happens, the client will begin connecting to the proper server. So you save a lot of money going with this option, but you lose all automation and gain downtime instead.

  1. 2 DAG Members and DNS Round Robin - Use 2 Multi-Role DAG Members (MBX/HUB/CAS).  Use ISA to load balance all HTTP items from the bulleted list above. Use DNS Round Robin to achieve a “poor man’s solution” type of load balancing.  With this scenario, you will not have automatic failover for the RPC Client Access Service.  You will essentially create two A Record for the RPC Client Access Array; one pointing to the first multi-role DAG Member and one pointing to the second multi-role DAG Member.  You will most likely want to lower the TTL values of these DNS records to 5 minutes so if a failure does happen, you can remove one of the A records and the clients will flush their DNS cache within 5 minutes time.
Share

Publishing Exchange 2007 Autodisover in ISA 2006 – Part 2

Since writing the first part of this article here,  I’ve seen a lot of questions about how you really publish things like the Autodiscover as there have been many articles out there where they keep the Autodiscover in the Outlook Anywhere rule and others where they separate it out.  I wrote the first part of this  article  a while back when Autodiscover was quite unknown and I was a bit new to ISA and figuring things out.  Since then, I have done quite a bit with Autodiscover and written several articles about it as well as done a lot with ISA itself.  Because of that, I wanted to create a part 2 and really detail on the different methods which you can use in regards to authentication and how it really ties together.

One thing needs to be taken into consideration. Integrated Authentication in IIS uses NTLM or Kerberos.  These protocols were designed to prevent man in the middle attacks.  What this means is that when you create an ISA rule, you cannot typically have your rule’s authentication delegation using Integrated Authentication as this will mean that ISA is attempting to do a man in the middle attack.  There are two ways to make this work.  One is by using Kerberos Constrained Delegation in which you use a separate listener which listens on NTLM and then use Kerberos Constrained Delegation to talk to Exchange.  This way, you enable Outlook Anywhere for NTLM, then allow ISA to request Kerberos tickets and pass that right to Exchange.  The other  method is to set the rule to not require the client to authentication to ISA but the client can authenticate directly to Exchange.  This prevents ISA from delegating NTLM and then allows the client to NTLM auth directly to Exchange.  This way you can have 1 listener because when you configure the bypass, it’ll trump the requirement to authenticate to the listener.  And because Autodiscover uses Integrated Auth, you can have Autodiscover on the same rule.

An important thing to note is that if you do decide to go with Kerberos Constrained Delegation, both the ISA and CAS computer accounts need to be on the same domain.  It is because of this, the KCD method will not work when ISA is joined as a workstation.

So the existing ways to publish Exchange with Autodiscover are the following:

  1. Outlook Anywhere NTLM
    1. Two Configurations
      i.      Increased Security and added complexity – Utilize a separate listener just for your OA rule that utilizes NTLM and then configure Kerberos Constrained Delegation as the Authentication Delegation mechanism within the OA rule to authenticate to IIS on the Exchange CAS RPC Proxy Server
      ii.      Reduced Security and less complexity – Utilize the same listener for all Exchange Services including OA and take ISA Pre-Authentication out of the mix and allow the client to authenticate directly to the Exchange Server.  Because ISA Pre-Authentication is taken out of the mix, NTLM will work and the user will not be prompted since there’s nothing in the middle preventing a man in the middle attack.
    2. Because you’ll be using NTLM with OA, you can use Autodiscover on the same rule
  2. Outlook Anywhere Basic
    1. Use the same listener for all Exchange Services.
    2. Set listener to forms based authentication since the listener will fall back to Basic Authentication since OA does not support Forms.
    3. Configure each rule with the appropriate authentication delegation mechanism so each service in the /path/* for that rule contains the same authentication within IIS.  So for example, if I have OAB and EWS on that same rule and Basic Authentication delegation is configured for that rule, IIS for both OAB and EWS will need to contain Basic Authentication

So let’s take a look at Outlook Anywhere with NTLM.  Because we’re using NTLM, we’ll need to either create a new listener and have that use NTLM and then use Kerberos Constrained Delegation.  This way, a client on the internet can use NTLM and then the ISA machine needs to be able to request Kerberos tickets on behalf of the authenticated user and then pass this service ticket to the Exchange Server.  This gets around the man in the middle attack.  But because of this, you’ll need the NTLM listener and then a different listener for things such as OWA/EAS/Etc..  With this method, you’ll have 2 listeners. Because you’re using NTLM, you can have your Autodiscover path (which passes NTLM to Exchange) on the same rule as Outlook Anywhere.

Now with Kerberos Constrained Delegation, that’s the only time you’ll have a 2nd listener.  Any other situation you’ll have just a single listener.  You can still use Outlook Anywhere with NTLM, but in this case, you’ll have to configure your rule to not require authenetication from ISA and to just allow the client to authenticate directly.  This way, you’re bypassing Pre-Authentication.  But even with bypassing pre-authentication, you’re still being authenticated.

Now with any of the above 2 configurations, you can have Autodiscover on the Oulook Anywhere rule because you’re essentially allowing the client to use NTLM (first method uses NTLM on listener and KCD to authenticate to the Exchange Server and second one bypasses ISA pre-authentication and lets client authenticate directly to Exchange in which NTLM will work.)

Now if you’re using Basic Authentication for Outlook Anywhere, you can just have 1 listener that just does Forms Based Authentication.  This is because if the service authenticating to the listener does not support FBA, ISA 2006 (not ISA 2004) has the capability to fallback to basic authentication.  It’s this reason you can use a single listener.  Then for all the services, you’ll need to make sure the rule’s authentication delegation is set approproiately.  Authentication Delegation is always only set on a rule and the delegation type has to match what is set in IIS on Exchange.  So if you authenticate to ISA’s listener via FBA, ISA will then look at the rule’s authentication delegation and then use that authentication type to authenticate back to Exchange.  It knows which rule to use by looking at the /path/* in the rule.

When you use this method, I will typically put Autodiscover in its own rule and set that to bypass pre-auth while all other services are not bypassing pre-auth.  I don’t leave the /autodiscover/ path  in the Outlook Anywhere rule because they will now be using different authentication types.  And I don’t want to be authenticated by Autodiscover and Outlook Anywhere (if using basic) so I let Autodiscover bypass pre-auth but still require Outlook Anywhere to authenticate.

One thing to keep in mind here, is with ISA 2006, if you configure a rule to bypass pre-auth, it’ll trump the listener and the client won’t need to satisfy the listener authentication and the authentication will pass through in which Exchange will then perform the necessary authentication.

Share

Exchange 2007 OWA via ISA RSA – Authentication Delegation

When utilizing ISA (in this case, ISA 2006) to publish Outlook Web Access (OWA), there are various options you can choose from in order to authenticate a user.  One listener authentication mechanism that is often used is Forms Based Authentication.  By default, your ISA form when publishing OWA will look like the following:

As you can see, by default, it asks you for Domain\User name.  By going into the listener authentication options, you can specify the default domain that should be specified if the user does not specify a domain.  Without specifying this, if the user were to only enter their user name, authentication would fail as it is not passing the domain back to Exchange. By going into the properties of your OWA listener, you will see an Authentication tab.

Because we will be utilizing RSA, we will choose RSA as the method of Authentication utilizing Forms Based.  Because Exchange isn’t set to also authenticate to RSA (only ISA), we will need to collect additional information in the form.  This allows a user to also enter their AD credentials so after ISA authenticates a user, ISA can still pass back the AD credentials back to Exchange as the Authentication Delegation mechanism using Basic.  Selecting to Collect dditional delegation credentials in the form allows you to utilize either Basic, NTLM, or Negotiate as an Authentication Delegation mechanism.

By clicking on Advanced, we can see the section in which we can configure the domain to automatically pass back to Exchange during the Authentication Delegation.  Again, a user authenticates from a browser to a web listener and from there, ISA then takes certain information about the user and passes that back to Exchange which is the Authentication Delegation piece.

But, as you can see, the Domain name piece is greyed out.  But if you look at the authentication form for ISA when RSA is enabled, you can see it doesn’t ask for the Domain Name.

Now because of this, if a user doesn’t specify to use a different user name which does allow you to enter a domain\username, the authentication delegation piece will fail as the basic authentication mechanism that you will set on Exchange will want a domain\username passed back.  So if we can’t set this in ISA, how do we set it?  Well, we can actually configure IIS to automatically assume a specific domain to be used if no domain is specified.  While IIS6 and IIS7 are very much different, you can actually utilize the Exchange Management Console to set this option which will stamp IIS appropriately (both IIS6 and IIS7.)

The default authentication option for OWA on a CAS is to use Forms Based Authentication and require a user to specify their domain.

If you specify the following option, choose your domain, and click Apply, it will stamp IIS to assume the specified domain name.  A user can still specify their domain or not specify it and both will work when authenticating.  This should hopefully make you realize that if ISA relays authentication back to IIS on the CAS, that it won’t matter anymore if the domain is specified or not.

But because our ISA Authentication Delegation for our OWA rule will utilize Basic Authentication, we now want to specify Basic Authentication within Exchange for OWA.  But don’t worry, even if you change it from the previous setting of Forms Based Authentication with the assumed domain, IIS will still stay stamped properly. So go ahead and choose Basic.  You will be prompted to do an IISReset -Noforce.  Go ahead and do it after choosing Basic.

So back over to ISA, if we go into our Outlook Rule, we can see the Authentication Delegation set to Basic which it will need to be since that’s what the Authentication option is set to for OWA on our CAS.

So taking everything into account what we did above, what happens is the user authenticates to ISA utilizing a form and specifies their username without the domain, RSA key, and password for their username.  When they click Log On to authenticate, ISA will authenticate the user with RSA, and when that passes, ISA will utilize basic authentication due to the authentication delegation being set to basic to pass the username and password they specified (with no domain) back to OWA. Because IIS is stamped to automatically utilize the domain even if it wasn’t specified, authentication will work and the user will be logged into OWA.

Share

Default Gateways and Multihomed Edge Boxes

I seem to encounter this issue quite often and felt this topic warrants a dedicated blog post.  The basic point of this post is to explain that you cannot have more than one default gateway on separate NICS on a multihomed server!  Well, technically you actually can, but things won’t work correctly. Now I am not saying that you cannot have multiple Default Gateways on a specific NIC as this is quite possible as Windows will assign metrics so one Default Gateway is given priority over another which provides redundancy.  What I am saying is that you cannot have a Default Gateway on one NIC and then assign a Default Gateway on another NIC.

Any time I have seen Multihomed Servers (OCS Edge, Exchange Edge, ISA, Etc.) malfunctioning, the first thing I’ll do is a  ROUTE PRINT. Quite often, I’ll see several lines that display:

0.0.0.0

0.0.0.0

0.0.0.0

0.0.0.0

That instantly tells me that multiple Default Gateways are assigned.  You should only be seeing one line with 0.0.0.0. The entire point of a Default Gateway is it’s the last resort on where to send a packet.  Now with that in mind, does it make any sense to have multiple last resorts?  No!

So please, put the Default Gateway on only one NIC.  For OCS, I typically put it on the Access Edge NIC.  For Exchange Edge/ISA, I put it on the Internet Facing NIC.  Ok, so you may be thinking, well my external router doesn’t allow RDP traffic…  How am I going to manage my box from the inside since the RDP packets will be blocked at the external firewall?  What I always do on an Edge Server (and you should also be doing this on any multi-homes DMZ/Edge Server including ISA), is create static routes so any internal traffic will go to your internal network from your internal NIC.  It’s essentially creating a fake Default Gateway for only specific subnets (your internal subnets) set on your Internal NIC.

So let’s say you’re setting up an OCS Edge Server and it has 4 NICs:

Access Edge – 10.10.10.100 (DMZ Subnet) – Default Gateway Assigned here

Web Conferencing Edge – 10.10.10.101/24 (DMZ Subnet)

Audio / Video Edge – 10.10.10.102/24 (DMZ Subnet)

Internal NIC – 192.168.200.100/24 (Internal Network)

So how can we get all internal traffic to go out directly through the Internal NIC even though the Default Gateway is assigned to the Access Edge?  As stated before, we’ll create a static route.  So let’s say your internal router is 192.168.200.1, we’ll create a static route using the following syntax

route add 192.168.200.0 mask 255.255.255.0 192.168.200.1 -p

So for anything destined to the 192.168.200.x network (due to mask being 255.255.255.0 it will route to the default gateway of 192.168.200.1.  And Windows is smart enough to see that 192.168.200.1 is on the same subnet as your 192.168.200.100 NIC and assign that as the interface it should send it out of.  Problem solved!

Now what if you have a bunch of internal subnets that have similar address ranges?  Simple!  Supernet your internal networks!

route add 192.168.0.0 mask 255.255.0.0 192.168.200.1 -p

This supernet basically says anything that’s 192.168.x.x (only uses 1st 2 octets since you’re using a mask of 255.255.0.0 otherwise known as /16), send it to the 192.168.200.1 gateway.  And again, Windows is smart enough to see that 192.168.200.1 is on the same subnet as your 192.168.200.100 NIC and assign that as the interface it should send out of.  So if you have a 192.168.200.x, a 192.168.199.x, or a 192.168.198.x network, all those packets will route to the 192.168.200.1 router which will then send the packet to the appropriate subnet. Problem solved!

And the -p stands for persistent.  It means that the static route will survive a reboot.

All the above applies to ISA as well.  Let’s say you’re doing LDAPS authentication which uses port 636.  Your external router may not allow 636.  So by creating the static route to your internal network, the LDAPS traffic won’t be going through your external router and be blocked. It instead will go through your internal router which would most likely be allowing it as Internal Routers are more relaxed in their restrictions.

One thing to take into consideration is that if you are in an environment where the Default Gateways are assigned to all NICs and you modify your server to be properly configured with a Default Gateway on one NIC, make sure that any services such as remote backup on your server are allowed to access over the internet over the ports required for these services or things such as remote backup will start failing.

Share

Publishing Symantec Enterprise Vault in ISA 2006

I have seen many people encounter issues with publishing Symantec Enterprise Vault behind ISA 2006.  For our scenario, OWA users go through ISA both internally as well as externally.  Why do we do this?  Well, when you are publishing OWA 2007 behind ISA 2006, one of the requirements is to go onto your Exchange 2007 Client Access Server (CAS) and disable Forms Based Authentication and enable Basic Authentication instead. This is because ISA 2006 will be using Forms Based Authentication. Switching OWA on Exchange 2007 to use Basic Authentication instead of Forms Based Authentication allows us to avoid being prompted twice for authentication (once by ISA and then once by Exchange).  Basic Authentication on the CAS allows ISA to pass the authentication through to Exchange without being prompted a second time.

So why do we point both internal and external users through ISA?  That is because we want users to get the same OWA experience both internally and externally.  We don’t want internal users pointed directly to Exchange and get a Basic Authentication prompt while external users get Forms Based Authentication when outside the corporate network.  By pointing internal and external users directly through ISA, they will get the same experience internally and externally.

As you can see in the following image, in Symantec Enterprise Vault, IIS contains several directories which include a directory called EnterpriseVault:

Prerequisite

Properly configure IIS on your Client Access Server (CAS) to host the certificate(s) needed for external and internal access. The certificate recommended for this configuration is a Unified Communications (UC) certificate. You can read more about these different configurations here.

Note: For this article, we will be using a UC certificate that contains 4 Subject Alternative Names (SANs). Our requested certificate’s CN was webmail.shudnow.net. The first SAN name requested was also webmail.shudnow.net. Our request was created using the following EMS command:

New-Exchangecertificate -domainname webmail.shudnow.net, autodiscover.shudnow.net, casserver.shudnow.net, casserver -Friendlyname Shudnow -generaterequest:$true -keysize 1024 -path c:\certrequest.req -privatekeyexportable:$true -subjectname “c=US, o=Shudnow Inc, CN=webmail.shudnow.net”

  1. NetBIOS name of CAS (casserver)- used if there is a need/want to connect to services such as OWA using the NetBIOS name of the CAS while connected to the internal network.
  2. FQDN name of CAS (casserver.shudnow.net)- used so we can publish Autodiscover internal URLs to point directly to the CAS.  This name is required if your Exchange Server will be hosting the Unified Messaging rule and you plan on integrating  Unified Messaging into your Office Communications Server 2007 Enterprise Voice envirnment.  If you have an internal PKI, I would recommend leaving this FQDN out and requesting a certificate with this FQDN to avoid exposing your servername to the public.
  3. Autodiscover.shudnow.net – used so external clients can retrieve external URLs to connect to web distributed services.
  4. Intuitivname.shudnow.net – used for services such as Outlook Web Access, Outlook Anywhere, Exchange ActiveSync, web service distribution (OAB, OOF, and Availability). Common FQDNs used are exchange.domain.com, owa.domain.com, mail.domain.com, webmail.domain.com, etc. This article will use the example FQDN: webmail.shudnow.net.

Note: For purposes of this article, the only name in your certificate that is essential for publishing Symantec Enterprise Vault is #4 (Intuitivename.shudnow.net). But since you are requesting a certificate, I would advise you to properly create a certificate with any other names that are required which include #1-4.

You will also want to do the following:

  1. At the minimum, the ISA 2006 Supportability Update is required which is located here.  I would recommend using SP1 instead which is located here.
  2. Create an Exchange Web Listener

ISA 2006 Configuration

You must ensure that you go onto the CAS and export the certificate with its private key and import that into ISA 2006 (Please make sure you have the licenses needed for installing a certificate on multiple servers if required by your certificate vendor). A guide on how to do this is out of the scope of this blog. Once the certificate has been imported on the ISA 2006, ISA configuration can begin. Start by publishing each Exchange 2007 role as needed. For purposes of this article, we will only show how to publish your Enterprise Vault rule and steps needed to configure your OWA publishing rule to get Enterprise Vault to work through OWA.

Enterprise Vault Publishing Rule

For our Enterprise Vault publishing rule, we will go to Servername > Firewall Policy > New > Website Publishing Rule.

Give your Website Publishing Rule a name. Click Next to Continue.

Select Allow. Click Next to Continue.

Since we will be publishing a single Enterprise Vault Server, choose “Publish a single Web site or load balancer.” Click Next to Continue.

If you have installed a certificate for your Enterprise Vault Server, choose “Use SSL to connect to the published Web server or server farm.”  If you have not installed a certificate for your Enterprise Vault Server, choose “Use non-secured connections to connect the published Web server or server farm.”  We did install a certificate on our Enterprise Vault Server, so we will choose the first option. Click Next to Continue.

Enter the Internal Site name of your Enterprise Vault Server.  Then enter the IP Address of your Enterprise Vault Server. Click Next to Continue.

Because the IIS directory name on your Enterprise Vault Server is called EnterpriseVault, you must enter that name in the Path (Optional) field as is displayed in the following screenshot. Click Next to Continue.

Because we will be accessing Enterprise Vault through OWA, we will want to make to enter our OWA URL name in the Public Name field.  For purposes of this lab, our OWA URL will be webmail.shudnow.net. Click Next to Continue.

You will want to select the Listener you created for your Exchange environment. Click Next to Continue.

Select Basic Authentication. Click Next to Continue.

Leave the setting to All Authenticated Users. Click Next and then Finish.

Once you have finished the creating the publishing rule, go into the properties of your Enterprise Vault publishing rule and go to the Paths tab.  Ensure your paths display as follows (which they should if you followed the above correctly). Click OK to Finish.

OWA Publishing Rule

Typically, you create your OWA publishing rule using the Firewall Policy, “Exchange Web Client Access publishing Rule.”  There is a bug that prevents you from setting up Link Translation rules that are needed to get Enterprise Vault to work.  Because of this, make sure you write down all your settings for OWA because we will need to re-create the OWA publishing rule using a regular, “Web Site Publishing Rule.”  We will not go through the entire steps of creating the OWA publishing rule, but will rather go through the modification of this rule to ensure Symantec Enterprise Vault works.

So now we have our two publishing rules:

Open your Exchange OWA publishing rule and go to the Link Translation tab and select “Apply link translation to this rule.”  Click Next to Continue.

We will now want to make some Link Translation Mappings

These mappings include:

How does this work?

A user connects to OWA using webmail.shudnow.net.  They will attempt to access Enterprise Vault.  Because they are connected to OWA, you want them using the webmail.shudnow.net name.  ISA will create a link translation rule so when the user tries to access the Enterprise Vault rule, they will use the webmail.shudnow.net name instead.  But because ISA has the Enterprise Vault publishing rule, ISA knows how to proxy those requests to Enterprise Vault.  The reason we created the Public Name as webmail.shudnow.net for the Enterprise Vault rule is because this rule uses the listener for Exchange which contains a certificate that does not include the certificate that contains the entvault.shudnow.net name.  It does contain the webmail.shudnow.net name though.

Share

Want to test drive Exchange 2007 and/or other products?

This isn’t anything really new, but something I figured I would post. Microsoft has been making products readily available for evaluation purposes on VHD files for some time now. VHD files are the virtualization files for Virtual Server and Virtual PC. If you are looking to test drive Exchange, ISA, Office, Vista, Server 2008, or some other Microsoft product, I would visit the following URL:

http://www.microsoft.com/technet/try/vhd/default.mspx

Share

Publishing Exchange 2007 Autodisover in ISA 2006

Edit: I have went into pretty good detail on the different methods you can use to publish Exchange Services including Autodiscover here.

In Exchange versions previous to Exchange 2007, users would store data inside a public folder. This data included free/busy information, Out of Office messages, Offline Address Book, etc. Beginning with Exchange 2007, this information is stored in Internet Information Services (IIS). The process of distributing these services in Exchange 2007 is known as web distribution. Keep in mind that you will need to have Outlook 2007 clients to support web distribution. If you are running clients previous to Outlook 2007, you will still need to use public folders.

As you can see in the following image, in Exchange 2007, IIS contains several new directories than its predecessor, Exchange 2003:

The Autodiscover directory is used by the Autodiscover service to provide automatic profile configuration for Outlook 2007 clients as well as compatible mobile devices, such as Windows Mobile 6. In addition to automatic profile configuration, it provides the external URLs necessary to connect to web distributed services. Another directory is the EWS directory which provides access to web distributed services. These web distributed services include the Availability service, Out of Office (OOF) messages, etc. The Availability service grants users on-demand access to free-busy information. For more information regarding the Availability service, please visit the following site: http://msexchangeteam.com/archive/2006/10/23/429296.aspx. The OAB directory is used to store the Offline Address Book (OAB) which provides an offline copy of the Global Adress List (GAL). The file distribution service copies the OAB files from the OAB generation server to the CAS server for web distribution. To learn more about OAB web distribution, please visit the following site: http://msexchangeteam.com/archive/2006/11/15/431502.aspx.

Prerequisite

Properly configure IIS on your Client Access Server (CAS) to host the certificate(s) needed for external and internal access. The certificate recommended for this configuration is a Unified Communications (UC) certificate. You can read more about these different configurations here.

Note: For this article, we will be using a UC certificate that contains 4 Subject Alternative Names (SANs). Our requested certificate’s CN was webmail.shudnow.net. The first SAN name requested was also webmail.shudnow.net. Our request was created using the following EMS command:

New-Exchangecertificate -domainname webmail.shudnow.net, autodiscover.shudnow.net, casserver.shudnow.net, casserver -Friendlyname Shudnow -generaterequest:$true -keysize 1024 -path c:\certrequest.req -privatekeyexportable:$true -subjectname “c=US, o=Shudnow Inc, CN=webmail.shudnow.net”

  1. NetBIOS name of CAS (casserver)- used if there is a need/want to connect to services such as OWA using the NetBIOS name of the CAS while connected to the internal network.
  2. FQDN name of CAS (casserver.shudnow.net)- used so we can publish Autodiscover internal URLs to point directly to the CAS.
  3. Autodiscover.shudnow.net – used so external clients can retrieve external URLs to connect to web distributed services.
  4. Intuitivname.shudnow.net – used for services such as Outlook Web Access, Outlook Anywhere, Exchange ActiveSync, web service distribution (OAB, OOF, and Availability). Common FQDNs used are exchange.domain.com, owa.domain.com, mail.domain.com, webmail.domain.com, etc. This article will use the example FQDN: webmail.shudnow.net.

ISA 2006 RTM Configuration

Update1 (08/18/2008) – It’s been over a year since this article was released.  Things have changed.  Below I explain to create a new rule for Autodiscover, set All users for authentication, etc..  ISA 2006 SP1 is now out and supports SAN certs.  As of now, when I configure ISA 2006 SP1, I leave autodiscover in the Outlook Anywhere Rule, leave Authenticated Users on, and add the autodiscover FQDN to the Public Name Tab as I do below.  So please keep these things in mind due to the remaining section of ISA 2006 is based off of RTM and not SP1.

You must ensure that you go onto the CAS and export the certificate with its private key and import that into ISA 2006 (Please make sure you have the licenses needed for installing a certificate on multiple servers if required by your certificate vendor). A guide on how to do this is out of the scope of this blog. Once the certificate has been imported on the ISA 2006, ISA configuration can begin. Start by publishing each Exchange 2007 role as needed. In ISA 2006, each rule will need to be published by itself. You can see this by looking at the following screen:

The Outlook Anywhere rule contains several /paths/ as can be seen by the following screenshot:

Because Outlook 2007 will contact the Autodiscover service by using https://autodiscover.shudnow.net/Autodiscover/Autodiscover.xml, we will need to remove the /Autodiscover/ Path from the Outlook Anywhere rule and create a dedicated rule just for the Autodiscover.

There are also several other /paths/ that are new to publishing Exchange 2007. As you recall from the previous IIS screenshot from the CAS, there is an /EWS/ and /OAB/ path that allow us to publish the OAB and EWS web distributed folders. In the Exchange ActiveSync (EAS) rule, there is a /Microsoft-Server-Activesync/ path that is used to publish Exchange Active Sync. Because the Public Name for these rules are configured to webmail.shudnow.net, we will need to publish the external URLs on the CAS server to distribute these services to external clients via https://webmail.shudnow.net.

Autodiscover Rule

With the Autodiscover rule created, there are a few configuration settings that need to be modified. The first is done by opening the Autodiscover Rule and navigating to the To: Tab. We need to ensure the, “This rule applies to the published site:” equates to the Common Name of the internal certificate. Since we are using the same certificate on both the CAS and ISA, the common name will be the same on both certificates. Using a separate certificate on your CAS and ISA is out of the scope of this article. The IP Address must be the IP address of the CAS server.

The next tab you will need to modify is the Public Name tab. Because this rule will be listening for a request to Autodiscover.shudnow.net, we will need to ensure this rule accepts requests that are destined to Autodiscover.shudnow.net

You will see an error on the Listener tab that states there is an issue with certificates. Disregard this error as it doesn’t affect us. ISA does not see the certificate contains subject alternative names and will work even though the Public Name is set to something other than the Common Name of the certificate.

Note: Microsoft has stated that ISA 2006 SP1 will support SAN certificates (which means all SAN names in a SAN Certificate).  SP1 is due out late summer at earliest.

The final change to the Autodiscover rule that is needed is to modify authentication. Click on the Users tab and remove All Authenticated Users. Add the All Users group. There is currently a bug in Exchange 2007 that does not allow ISA 2006 to publish the Exchange 2007 Autodiscover when All Registered Users is selected. Look out for a fix in Exchange 2007 SP1.

Configuring Autodiscover on CAS

In order to allow a smooth connection to web distributed folders, we need to configure internal and external URLs. Internal URLs are provided to domain-joined clients who have direct connectivity to Active Directory. Because they have direct connectivity to AD, they will be able to pull authoritative internal web distribution URLs directly from the Service Connection Point (SCP). The SCP is an object that gets installed in Active Directory when a CAS is installed. The SCP contains an authoritative list of all Autodiscover service URLs in the forest where Exchange 2007 is installed.

Because we created an Autodiscover rule that listens for connections on Autodiscover.shudnow.net, an Outlook 2007 client as well as a compatible mobile client connecting from a remote network will be able to contact the Autodiscover service to have their profile automatically be configured as well as find the external URLs for web distributed services. Because ISA is publishing these web distributed folders via webmail.shudnow.net, we need to configure the external URLs to use https://webmail.shudnow.net/ServiceAddress. This way when a client connects from the outside network, they will see these external URLs are configured using https://webmail.shudnow.net/OAB and https://webmail.shudnow.net/EWS.

When using a UC certificate with the 4 URLs specified earlier in this article, we can allow an internal client to connect directly to the CAS bypassing ISA. If you are not using the UC certificate, you will most likely be using the same internal and external URL. This is because when not using the UC certificate, you will be need to separate your IIS websites to accommodate multiple certificates. One blank default web site for your self-signed certificate, one site for all your web distributed services, OWA, and Outlook Anywhere that will contain your webmail.shudnow.net certificate, and finally an Autodiscover website for your Autodiscover.shudnow.net certificate. Because you will be only using 3 certificates, you will not have the FQDN of the CAS server defined in your certificates. Because of this, you will need to point both the internal and external URL to webmail.shudnow.net. Because the UC certificate contains both the FQDN of our CAS and the FQDN webmail.shudnow.net, we can point the internal URL to the FQDN of the CAS server and the external URL to the webmail.shudnow.net FQDN for which we configured ISA to accommodate. As stated in the prerequisite section, you can read about these two different types of certificate configurations here.

As of late September, Microsoft has added a new method to make the Autodiscover service accessible from the outside with a single certificate. This is through the use of SRV records. You can read more about this new type of configuration here.

EWS Configuration

In order to see what internal and external URLs are set for the EWS folder, we can run the Get-WebServicesVirtualDirectory cmdlet in the EMS. When a client is on the external network, they will need to go through the published rule in ISA. This is why we configure the external URL to go through https://webmail.shudnow.net. The EWS /path/ is configured in the Outlook Anywhere rule which accepts connections from webmail.shudnow.net (Remember the public name tab is configured to accept connections from webmail.shudnow.net). We will configure the internal URL to go directly to the CAS server bypassing ISA since the FQDN of the CAS server is defined as one of the subject alternative names in our Unified Communications Certificate.

In order to configure the Internal and External URL, we need to use the following commands:

Set-WebServicesVirtualDirectory -Identity “CASServer\EWS (Default Web Site)” -InternalURL https://casserver.shudnow.net/EWS/Exchange.asmx -ExternalURL https://webmail.shudnow.net/EWS/Exchange.asmx -BasicAuthentication:$true

Note: You must ensure that you enable Basic Authentication on the EWS folder in IIS due to the Outlook Anywhere rule using Basic Authentication Delegation.

OAB Configuration

In order to see what internal and external URLs are set for the OAB folder, we can run the Get-OABVirtualDirectory | FL cmdlet in the EMS. When a client is on the external network, they will need to go through the published rule in ISA. This is why we configure the External URL to go through https://webmail.shudnow.net. The OAB /path/ is configured in the Outlook Anywhere rule which accepts connections from webmail.shudnow.net (Remember the public name tab is configured to accept connections from webmail.shudnow.net). We will configure the internal URL to go directly to the CAS server bypassing ISA since the FQDN of the CAS server is defined as one of the subject alternative names in our Unified Communications Certificate.

In order to configure the Internal and External URL, we need to use the following commands:

Set-OABVirtualDirectory -Identity “CASServer\OAB (Default Web Site)” -InternalURL https://casserver.shudnow.net/OAB -ExternalURL https://webmail.shudnow.net/OAB -RequireSSL:$true

Note: You must ensure that you enable SSL on the OAB directory in IIS which is not on by default. The same goes for Basic Authentication on the OAB directory. The above command will only enable SSL, but will not ensure 128-bit SSL is required.

Outlook Anywhere Configuration

Currently, in Exchange 2007, Outlook anywhere only works using Basic Authentication. To enable Outlook anywhere and configure it to use the webmail.shudnow.net with basic authentication, use the following command:

Enable-OutlookAnywhere -Server CASServer -ExternalHostname “webmail.shudnow.net” -ExternalAuthenticationMethod “Basic” -SSLOffloading:$False

Note: The above Enable-OutlookAnywhere command works on RTM. For SP1, substitute -ExternalAuthenticationMethod with ClientAuthenticationMethod.

Exchange ActiveSync

In order to see what external URLs are set for the Microsoft-Server-Activesync folder, we can run the Get-ActiveSyncVirtualDirectory cmdlet in the EMS. When a client is on the external network, they will need to go through the published rule in ISA. This is why we configure the External URL to go through https://webmail.shudnow.net. The Microsoft-Server-Activesync /path/ is configured in its own ActiveSync rule which accepts connections from webmail.shudnow.net (Remember the public name and the To: tab should both be configured to accept connections from webmail.shudnow.net)

In order to configure the External URL, we need to use the following commands:

Set-ActiveSyncVirtualDirectory -Identity “CASServer\Microsoft-Server-ActiveSync (Default Web Site)” -ExternalURL https://webmail.shudnow.net/Microsoft-Server-Activesync

Unified Messaging Configuration

In order to see what internal and external URLs are set for the UnifiedMessaging folder, we can run the Get-UMVirtualDirectory cmdlet in the EMS. When a client is on the external network, they will need to go through the published rule in ISA. This is why we configure the External URL to go through https://webmail.shudnow.net. The unifiedmessaging /path/ is configured in the Outlook Anywhere rule which accepts connections from webmail.shudnow.net (Remember the public name tab is configured to accept connections from webmail.shudnow.net). We will configure the internal URL to go directly to the CAS server bypassing ISA since the FQDN of the CAS server is defined as one of the subject alternative names in our Unified Communications Certificate.

In order to configure the Internal and External URL, we need to use the following commands:

Set-UMVirtualDirectory -Identity “CASServer\UnifiedMessaging (Default Web Site)” -InternalURL https://casserver.shudnow.net/UnifiedMessaging/Service.asmx -ExternalURL https://webmail.shudnow.net/UnifiedMessaging/Service.asmx -BasicAuthentication:$true

Note: You must ensure that you enable Basic Authentication on the UnifiedMessaging folder in IIS due to the Outlook Anywhere rule using Basic Authentication Delegation.

Share