Elan Shudnow’s Blog

Autodiscover site Affinity is used in environments where you do not have good connectivity between all your sites and you would like Outlook 2007 clients to utilize Autodiscover services on a Client Access Server (CAS) to which the client would have good connectivity with.  Or even if you have good or decent connectivity between your sites, you may still prefer for Outlook 2007 clients to utilize Autodiscover services on a Client Access Server in a site that is local to that client.

In our example, our company is dispersed across three countries; USA, China, and Germany.  Our Active Directory (AD) infrastructure consists of many sites.  All sites in the USA are connected via high-speed reliable dedicated fiber lines.  All sites in China are connected via high-speed fiber lines.  All sites in Germany are also connected via high speed reliable dedicated fiber lines. Every country is connected to each other via a much slower link.  Because of this, you would like all Outlook 2007 clients to use their Autodiscover services within their own country regardless of which site they are in.

In the United States, we have 3 sites:

• US-California
• US-Chicago
• US-Florida

In Germany, we have 3 sites:

• DE-Hamburg
• DE-Frankfurt
• DE-Leipzig

In China, we have 3 sites:

• CN-Shanghai
• CN-HongKong
• CN-Chengdu

All sites within the the United States are configured with T3 links in which each site can talk to each other.  All sites within Germany are configured with E3 links in which each site can talk to each other.  All sites within China are configured with links that are similar in speed to a T3/E3 in which each site can talk to each other.  Each country talks to each other via links comparable to the speed of a T1.  As you can see, intra-country communication is occurring over a much faster link than inter-country communications.  So how can we restrict clients to utilize Autodiscover services from Client Access Servers within their own country?

This can be achieved by using Autodiscover Site Affinity.  To understand Autodiscover Site Affinity, we must first understand how the Autodiscover Service works internally within the organization for domain joined Outlook 2007 clients.

Internal Clients who are domain joined will first try to contact Active Directory for Service Connection Point (SCP) information.  Each time a CAS is installed into your Forest, that CAS will create an SCP in AD which provides a mean for Outlook 2007 clients to figure out the URL it should access Autodiscover.  This SCP is created in the following location:

CN=Autodiscover,CN=Protocols,CN=<CASServer>,CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services

To manually configure the SCP, you can run the following command:

Set-ClientAccessServer -Identity CASServer -AutoDiscoverServiceInternalUri https://affinityUS.shudnow.net/Autodiscover/Autodiscover.xml

By default, the SCP is configured with the following URL (Uses NetBIOS instead of FQDN):

https://CASServer/Autodiscover/Autodiscover.xml

When your organization is set up in a single-site fashion or you don’t care about Site Affinity, this is really easy to set up.  Just pick one common URL and set all your Client Access Servers to use that URL.  Or you can leave the URL at its default which uses its’ servername instead of an FQDN.  The use between using a common FQDN or leaving it at the default NetBIOS name is significant.  I will go into this later on though.

When we use Site Affinity, we have to be more careful with what our FQDNs as we want Outlook 2007 clients in their respective countries to obtain an FQDN that belongs to a Client Access Server within their own country.

So we will create a custom DNS record for each country that will Round Robin your client requests to the CAS Servers in their respective countries.  The following FQDNs will be:

• United States - https://affinityUS.shudnow.net/Autodiscover/Autodiscover.xml
• Germany - https://affinityDE.shudnow.net/Autodiscover/Autodiscover.xml
• China - https://affinityCN.shudnow.net/Autodiscover/Autodiscover.xml

Create three host records for each country (9 total).  Three host records for affinityUS that round robin requests between CAS Servers in each site in USA, three host records for affinityDE that round robin requests between CAS Servers in each site in Germany, and three host records for affinityCN that round robin requests between CAS Servers in each site in China.

If you recall, I stated that when any CAS is installed, it creates an SCP that contains the FQDN for the Autodiscover Service.  We now have to modify this SCP so it contains a Site Scope. Outlook 2007 by default will select an SCP at random to use.  Now this is very important.  If you left the default FQDNs for each CAS to their NetBIOS name, your autodiscover requests will be all over the place but your requests will be balanced between your CAS Servers due to every FQDN being set using the CAS Servers NetBIOS name.  If you set the FQDN for every SCP in your environment to use a common FQDN, the server that FQDN is set to will be getting hammered with all the Autodiscover requests.

One thing to keep in mind is that WIndows DNS Servers provide an option called Netmask ordering which is enabled by default.  This is essentially a subnet prioritization feature that works before round robin. So let’s say your Network ID for US-Chicago is 192.168.119.0 and your client obtains the SCP record, finds out the FQDN is https://affinity.shudnow.net/Autodiscover/Autodiscover.xml, when that client tries to communicate with that FQDN, hits the DNS Server, that DNS server will return an IP local to that subnet prior to attempting round robin.   For this, you would have to create the A record for each Client Access Server. There would also have to be a CAS with an IP that matches the NetworkID of the client initiating the DNS request for this to work.

By default Outlook 2007 queries AD to locate the Autodiscover SCP’s and chooses one at random. But if you chose a common FQDN, it wouldn’t matter that it’s random because the FQDN would be the same and the same CAS would be hammered.  This is why we are using round robin for each country.   We now want to set our Site Scope for each Country.  We will do this for the United States.

Let’s say we have 1 CAS in each United States Site:

• US-California-CAS
• US-Chicago-CAS
• US-Florida-CAS

We would run three commands:

Set-ClientAccessServer -Identity “US-California-CAS” -AutodiscoverServiceInternalURI “https://affinityUS.shudnow.net/autodiscover/autodiscover.xml” -AutodiscoverServiceSiteScope “US-California”,”US-Chicago”,”US-Florida”

Set-ClientAccessServer -Identity “US-Chicago-CAS” -AutodiscoverServiceInternalURI “https://affinityUS.shudnow.net/autodiscover/autodiscover.xml” -AutodiscoverServiceSiteScope “US-California”,”US-Chicago”,”US-Florida”

Set-ClientAccessServer -Identity “US-Florida-CAS” -AutodiscoverServiceInternalURI “https://affinityUS.shudnow.net/autodiscover/autodiscover.xml” -AutodiscoverServiceSiteScope “US-California”,”US-Chicago”,”US-Florida”

Do you see what we did here?  We set every CAS in the United States to use the same FQDN.  We then said, for every client that belongs to eithe rthe US-California, US-Chicago, or US-Florida Site, they should use any one of these three SCPs instead of choosing an SCP at random.  But because we created 3 host records for affinityUS, these requests are still load balanced between all your Client Access Servers.  You now are forcing your US clients to use US Servers for Autodiscover Services and load balancing that traffic through round robin DNS at the same time.

You can use the same steps above for your Germany Sites and China sites.  All you have to do is substitute the site names, the FQDN, and the name of the Client Access Servers.

Let’s say we have 1 CAS in each Germany Site:

• DE-Hamburg-CAS
• DE-Frankfurt-CAS
• DE-Leipzig-CAS

We would run three commands:

Set-ClientAccessServer -Identity “DE-Hamburg-CAS” -AutodiscoverServiceInternalURI “https://affinityDE.shudnow.net/autodiscover/autodiscover.xml” -AutodiscoverServiceSiteScope “DE-Hamburg“,”DE-Frankfurt“,”DE-Leipzig“

Set-ClientAccessServer -Identity “DE-Frankfurt-CAS” -AutodiscoverServiceInternalURI “https://affinityDE.shudnow.net/autodiscover/autodiscover.xml” -AutodiscoverServiceSiteScope “DE-Hamburg“,”DE-Frankfurt“,”DE-Leipzig“

Set-ClientAccessServer -Identity “DE-Leipzig-CAS” -AutodiscoverServiceInternalURI “https://affinityDE.shudnow.net/autodiscover/autodiscover.xml” -AutodiscoverServiceSiteScope “DE-Hamburg“,”DE-Frankfurt“,”DE-Leipzig“

Let’s say we have 1 CAS in each China Site:

• CN-Shanghai-CAS
• CN-HongKong-CAS
• CN-Chengdu-CAS

We would run three commands:

Set-ClientAccessServer -Identity “CN-Shanghai-CAS” -AutodiscoverServiceInternalURI “https://affinityCN.shudnow.net/autodiscover/autodiscover.xml” -AutodiscoverServiceSiteScope “CN-Shanghai“,”CN-HongKong“,”CN-Chengdu“

Set-ClientAccessServer -Identity “CN-HongKong-CAS” -AutodiscoverServiceInternalURI “https://affinityCN.shudnow.net/autodiscover/autodiscover.xml” -AutodiscoverServiceSiteScope “CN-Shanghai“,”CN-HongKong“,”CN-Chengdu“

Set-ClientAccessServer -Identity “CN-Chengdu-CAS” -AutodiscoverServiceInternalURI “https://affinityCN.shudnow.net/autodiscover/autodiscover.xml” -AutodiscoverServiceSiteScope “CN-Shanghai“,”CN-HongKong“,”CN-Chengdu“

Elan Shudnow :: Aug.24.2008 :: Exchange :: 2 Comments »

Yes there are many blogs out there that talk about how to enable anonymous relaying in Exchange 2007.  One of the most popular of these is the official Microsoft Exchange Team Blog.  That specific article is located here. Out of the articles I have read, I haven’t seen any that really explain how/why relaying isn’t enabled when you enable Anonymous users.  I’ll explain exactly what permissions are given to the anonymous group and why enabling anonymous doesn’t allow relay.

I previously wrote a blog article entitled, “Client to Server Secure SMTP Connectivity in Exchange Server 2007.”  I explained in this article that on your Default Receive Connector, the Exchange Users group is enabled to use that connector by default.

This Exchange Users group is allowed the following permissions to that connector:

• Ms-Exch-SMTP-Submit
• Ms-Exch-SMTP-Accept-Any-Recipient
• Ms-Exch-Bypass-Anti-Spam
• Ms-Exch-Accept-Headers-Routing

The Ms-Exch-SMTP-Accept-Any-Recipient is the permission that allows a user to relay off of that connector.

So what really happens when you place a check mark in the Anonymous users group in the above screenshot?  A lot of people are afraid to place a checkmark in that box in fear that anonymous users will be able to relay off your Exchange Server.  This is NOT the case.

When you place a checkmark in that box, the following permissions are given to the Anonymous Logon group:

• Ms-Exch-SMTP-Submit
  
• Ms-Exch-SMTP-Accept-Any-Sender
  
• Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
  
• Ms-Exch-Accept-Headers-Routing

So, as you can see, there is no Ms-Exch-SMTP-Accept-Any-Recipient permission added by default.  Because of this, users will NOT be able to relay off your Exchange Server by default.  In order to allow for this, you should do the following as outlined in my previous article:

1. Create a new Receive Connector with the Custom Usage Group
2. For Remote Network Settings, remove 0.0.0.0-255.255.255.255, and then add the IP Address of the remote server that requires relaying permissions
3. Once the new Custom Receive Connector is created, go into the properties of this connector, go to the Permission Groups Tab > Add Anonymous Users

To activate Anonymous users to use this connector for relaying, you must issue the following command:
Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

The command should be easy enough to read, but what it essentially does is retrieve the receive connector that you created, add a permission into Active Directory for the Anonymous Logon group, and assign that group the Ms-Exch-SMTP-Accept-Any-Recipient permission for that group on that connector.

Now you may be thinking, why should I create this new connector?  Well, Exchange will always look to see how specific you are on a connector.  So let’s say we have a SharePoint Server at 192.168.119.150.  We would create a relay connector and allow ONLY 192.168.119.150 to relay.  So when Exchange receives SMTP from an address of 192.168.119.150, it will see there are a few connectors.  One being the Default Receive Connector and one being the Relay Connector.  The Default Receive Connector allows connections from any IP Address while the Relay Connector only allows connections from 192.168.119.150.  Because you explicitly set the address on your Relay Connector, that is given higher preference in serving that SMTP connection from SharePoint and your SharePoint Server will not be able to relay off of Exchange (even though you can configure SharePoint to authenticate, but still just giving an example).

Elan Shudnow :: Aug.21.2008 :: Exchange :: 1 Comment »

There seems to be some confusion as to how TLS connectivity between a Hub Transport and Edge Transport works. A large reason for this is due to the Exchange 2007 Edge Transport Server not being a part of your Corporate Active Directory.  Because of this, people may think, that by default, Hub SMTP communication between a Hub Transport and Edge Transport is not encrypted and are asking, “How to secure SMTP communication between a Hub Transport and Edge Transport is encrypted.” Well the answer is, it already is…. Let me explain.

One of the steps in connecting your Edge Transport Server is to export an Edge Subscription XML file once all your Edge Transport prerequisites are done.  An explanation of these prerequisites is out of the scope of this article.  There are many things that occur during XML export process and import process.

To export an XML, you would run the following command:

New-EdgeSubscription -FileName “C:\Edge.XML”

As stated, there are many things that happen during the export.  Before running the above command, you want to ensure you have a certificate on your Edge Transport Server that is enabled for SMTP use.  To check this, you can run the following command:

Get-ExchangeCertificate

You should see that your server has a self-signed certificate that lasts for one year and is enabled for SMTP.

When exporting our XML file, the private key is stored in the local computer store and the public key is written to the Edge Subscription file.  Because of this, when you submit the XML file to the Hub Transport for importing, the Hub Transport will store a copy of this public key in Active directory. The Hub Transport will then use Active Directory as a Trusted Storage mechanism to validate the Edge Transport’s certificate. Vice Versa, when your Hub Transport and Edge Transport are now connected with each other, the Hub Transport will send a copy of its’ public key for an Edge Server to store in ADAM. It is because of this, both servers are allowed to take advantage of TLS communications for the secure transport of SMTP.

You don’t have to use a self-signed certificate.  If you don’t want your certificate to expire in one year and have to mess with it, you can use your own PKI cert or even a certificate from a 3rd party vendor.

Now what happens when you are approaching your certificate expiration date.  Well, even if your certificate expires, mail will still flow.  This is because our Transport servers use something called Opportunistic TLS. If you look at the Authentication Tab of your Connector, only Transport Layer Security will be selected. This is called Opportunistic TLS which means that TLS will be accepted and is the preferred method for communication, but TLS will not be required.  So even if your certificate expires, all that means is that mail will still flow, but less secure since TLS will not be able to be used.

As you can see, Transport Layer Security is selected.  Opportunistic TLS means that any time a sending server attempts to issue a StartTLS, our Exchange server will accept TLS communications and encrypt the communications.  By default, an Exchange 2007 Send Connector will attempt to issue StartTLS using the defined parameter IgnoreSTARTTLS which is set to 0 by default.  In order to see the setting on your Exchange Servers, you can type the following command:

Get-SendConnector “SendConnectorName” | fl

If you look on your Hub Transport, you may think that you see a Send Connector there going to your Edge.  This won’t be the case. A configuration object in Active Directory has a Site Association for an Edge Subscription.  Because of this, mail flowing from a Hub Transport to an Edge Transport utilizes the hidden Intra-Organization Send Connectors.

You will however, see the connectors that live on the Edge Transport Server. In reality, these Send Connectorsf or the Edge Server were created on our Hub Transport and live in Active Directory.  These Send Connectors get pushed out to the Edge Server via Edgesync replication.  To force this replication, you can type the following command:

Start-EdgeSyncronization

You should then see your Send Connectors on your Edge Transport Server.

Now you can launch the Exchange Management Shell and run the Get-SendConnector command above on the connector which points to our Hub Transport Servers; which is the connector I highlighted.  Run the following command:

Get-SendConnector “edgesync - inbound to default-first-site-name” | fl

As you can see, IgnoreSTARTTLS is set to false which means our Send Connector will allow Mutual TLS to take place if the Receive Connector advertises StartTLS; which it does by default.  So as long as your IgnoreSTARTTLS settings are False, Opportunistic TLS is enabled, and your certificate is valid, Secure SMTP using TLS will work between your Hub Transport and Edge Transport Servers.

Now what happens when our certificate expires?  Well, we can renew our certificate on our Server.  There are some good instructions here.  One difference you’ll want to do is instead of enabling the certificate for IIS, you’ll want to enable the certificate for SMTP.

Now don’t forget that earlier in this article, I talked about how the Edge Transport and Hub Transport trust each other’s certificates.  Because we have a new certificate, we’ll have to re-subscribe our Edge Servers to our Hub Transport Servers.  This way, our Hub Transport can receive our new certificate and store it in Active Directory for a Direct Trust.

If you ever introduce new Hub Transport servers, they’ll be able to send and receive mail securely due to the Intra-Org Send Connector and using Active Directory as a Trusted Storage Mechanism, but these new Hub Transport Servers will not be able to participate in Edgesync replication.  In order to allow for this, your Edge Transport Servers will need to be re-subscribed, especially if you want the Edge Transport to be able to send mail securely to this new Hub Transport.  That is because, as I stated before, part of the initial process of subscribing an Edge Transport is the Hub Transport placing its’ certificate into ADAM.

Elan Shudnow :: Aug.20.2008 :: Exchange :: No Comments »

I have seen a lot of questions on what will happen to Outlook profiles when you migrate a user to Exchange 2007.  First, let me say, that in order for you to migrate to Exchange 2007, you have to upgrade your previous version of Exchange (2000 or 2003) to the latest service pack.  That is part of the puzzle as the latest service pack enables the functionality for an Outlook client to automatically updates its’ profile.

So, let’s take a look at the release notes for Exchange 2003 SP2 which you can find here.  The part we are interested in is:

Changes to how DSProxy Referral Mechanism Works

In Exchange Server 2003 SP2, the DSProxy referral process now tries to provide an Outlook client that has a global catalog that belongs to the same domain as the mailbox-enabled user by using a new algorithm. The new algorithm examines all global catalog servers that are directly connected to the Exchange server Active Directory site and provides the client with a global catalog that resides in the same domain as the mail recipient, if possible. This means that Exchange can now refer clients to out-of-site global catalog servers if there are no mailbox home domain global catalogs available in the Exchange server Active Directory site. For detailed information about DSProxy in SP2, see Microsoft Exchange Server 2003 Technical Reference Guide.

Elan Shudnow :: Aug.04.2008 :: Exchange :: 1 Comment »

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.

Elan Shudnow :: Jun.24.2008 :: Exchange, ISA, Symantec :: No Comments »

Overview

The Messaging API is a COM-like API that provides access to the contents of messaging stores. CDO 1.2.1 (Collaboration Data Objects, version 1.2.1) is a package providing access to Outlook-compatible objects through a COM-based API. Using either CDO or MAPI, a program can connect to a MAPI store, and then perform operations against that store. Starting with Exchange 2007, Microsoft will distribute the MAPI client libraries and CDO 1.2.1 as a Web download.

System Requirements

This download is available here.

Elan Shudnow :: Jun.02.2008 :: Exchange :: 2 Comments »

I wanted to share some of my findings with running Exchange 2007 SP1 on Server 2008. I’ve noticed and heard of several issues and information that I believe people should be cognizant about.

Here are the issues and general information I have heard of and experienced so far that seems to be valuable to share. If you disagree with anything I am sharing, have found it works in a different way for you, and/or want to include your findings and any tidbits of information you may have, please feel free to comment.

• Hub Transport Server Role fails when IPv6 is disabled on that server
  • If IPv6 is disabled prior to the installation of Exchange Server 2007, when installing the Hub Transport Server role, your Hub Transport Server role will fail to install
  • If IPv6 is disabled after the installation of Exchange Server 2007, you may experience some Exchange services failing to start

• Outlook Anywhere is broken under certain conditions
  • Outlook Anywhere is not working for Outlook 2007 with IPv6 enabled (More information can be found from the following URLs: http://blog.aaronmarks.com/?p=65 and http://www.buit.org/2008/01/04/outlook-anywhere-is-broken-on-ipv6-in-windows-server-2008). I’m not sure if this also happens with previous versions of Outlook. The first link refers to Outlook 2007 while the second link refers to Outlook. I would figure this would be for all Outlook versions since RPC over HTTP proxy is not Outlook version specific. I can’t think of anything that would cause this to fail via Outlook 2007 and not previous versions of Outlook. But from what I’ve heard, this is definitely happening with Outlook 2007. More information below.
  • This bug consists of the fact that IPv6 is not listening on the loopback port 6004 (RPC/HTTP Proxy Service). This is causing Outlook Anywhere to fail with Outlook 2007. Not sure if this happens with previous versions of Outlook. The reason for this is because Server 2008 prefers communication using IPv6 over IPv4. Since IPv6 is not listening on port 6004, Outlook Anywhere will fail.

  TCP 0.0.0.0:6001 0.0.0.0:0 LISTENING
  TCP 0.0.0.0:6002 0.0.0.0:0 LISTENING
  TCP 0.0.0.0:6004 0.0.0.0:0 LISTENING
  TCP [::]:6001 [::]:0 LISTENING
  TCP [::]:6002 [::]:0 LISTENING

  • People have been disabling IPv6 within the registry to ensure that IPv6 is not active at all so Outlook Anywhere will use IPv6 which is listening on IPv6. The problem with disabling IPv6, is if the CAS is also on the HTS, HTS will fail. So in this case, there are several options. The first being deal with the bug. The second being separate the CAS and the HTS so you can disable IPv6 on the CAS and leave IPv6 on the HTS on. The third option is presented in the second URL above which includes making some modifications to your host file.
  • Microsoft has stated this has been added to the QFE list for SP2

• NTLM seems to be very buggy with Outlook Anywhere. There are lots of reports of Outlook Anywhere NTLM Authentication not being functional when using Server 2008. More information can be found from the following URL: http://blog.aaronmarks.com/?p=65.

• There is an HP Document (http://h71028.www7.hp.com/ERC/downloads/4AA1-5675ENW.pdf) which goes over some testing with varying network latencies using CCR over an OC3 link with a network latency simulator. I wanted to give an overall summary of their findings.
  • 20 ms latency – All the log files were shipped over properly and all CCR databases auto-mounted properly
  • 30-40 ms latency – Some manual mounting will be required to mount all your databases as the latency will prevent all logs to be shipped over fast enough for automatic mounting
  • 50+ ms latency – Log shipping mechanism was out of control

• In regards to SCR and the network latency topic. SCR is a manual failover mechanism. Because of this, CCR is a lot more dependent on network latency due to its automatic failover mechanism. Microsoft does provide recommendations on how to tune SCR for latency on the Exchange Technet Library which can be found here. The problem here is the article is geared for Server 2003 Networking. As for real world SCR scenarios, I have been told that a mailbox server that contains ~6,000 mailboxes has been successfully failed over to an SCR target across the world over a 200 ms link.

Update 1: There has been an update in regards to NTLM Authentication issues from the Microsoft Exchange Team Blog here.

Sid quoted the following:

As promised, here’s an update on the reprompting issue that many of you have encountered.

The gist of the issue is that IIS7 uses kernel mode windows
authentication by default. Turning this off will fix reprompting. I
will post a detailed update once I dig through some more and talk to
the IIS PD, but for now I wanted to provide this update so you can give
it a shot and let me know if (no, “that”) it works for you

Here’s the command that needs to be run on the CAS boxes ->

%Windows%\inetsrv\appcmd.exe set config /section:system.webServ

er/security/authentication/windowsAuthentication /useKernelMode:false

Elan Shudnow :: May.22.2008 :: Exchange, Server 2008, Windows :: 1 Comment »