RSS Subscription 168 Posts and 2,769 Comments

Archive for August, 2008

Configuring Exchange 2007 Autodiscover Site Affinity

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.

There are two methods we can do to achieve Autodiscover Site Affinity.

Method 1

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 depending on Netmask Ordering option in DNS talked about below.

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. With Windows 2000 DNS, if both netmask ordering and round robin are enabled, only netmask ordering is utilized and the addresses are provided in the same order.  If Windows 2003 is utilized, Netmask ordering is utilized but the addresses will still be prioritized.  Netmask ordering in Windows 2000+ utilizes a matching Class C address as a local IP.  If you have Windows 2000 and Windows 2003 DNS servers in your environment, your results to clients may be inconsistent.

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, the DNS server will utilize Netmask ordering and find all the records which return 192.168.119.0 network.  If more than one DNS record for affinity.shudnow.net are returned for the 192.168.119.0 Network ID, the records will load balanced through round robin if a Windows 2003 DNS server responds.

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” -AutodiscoverSiteScope “US-California”,”US-Chicago”,”US-Florida”

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

Set-ClientAccessServer -Identity “US-Florida-CAS” -AutodiscoverServiceInternalURI “https://affinityUS.shudnow.net/autodiscover/autodiscover.xml” -AutodiscoverSiteScope “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 either the 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” -AutodiscoverSiteScope DE-Hamburg“,”DE-Frankfurt“,”DE-Leipzig

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

Set-ClientAccessServer -Identity “DE-Leipzig-CAS” -AutodiscoverServiceInternalURI “https://affinityDE.shudnow.net/autodiscover/autodiscover.xml” -AutodiscoverSiteScope “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” -AutodiscoverSiteScope “CN-Shanghai“,”CN-HongKong“,”CN-Chengdu

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

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

Method 2

Method 2 is short and simple but wanted to add it last so you understand the concept of Autodiscover Site Affinity from reading about Method 1.

All your sites can utilize the FQDN that exists on their self-signed certificate.  This self-signed certificate contains the NetBIOS name and the FQDN of the server.  So instead of using a common name such as affinityCN.shudnow.net, you very well could just utilize the existing self-sigend certificate and use the FQDN of the server.  Or you can make sure that the PKI certificates you deploy contain the FQDN of the server and utilize the FQDN for the AutodiscoverInternalURI and set the SiteScope. This is the simplest way and most likely the most common way.

Share

How Anonymous Relay works in Exchange 2007

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 now be able to relay off of Exchange (even though you can configure SharePoint to authenticate, but still just giving an example).

Share

Secure SMTP between Edge Transport and Hub Transport

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 accept StartTLS from a Receive Connector due to the Send Connector using the defined parameter IgnoreSTARTTLS which is set to false by default which means the Send Connector will accept StartTLS and utilize TLS for encryption for SMTP.  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 Connectors 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-EdgeSynchronization

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.

When you go to renew your Hub Transport certificates, a simple Start-EdgeSynhcronization will take the Hub Transport certificates and place them into ADAM so the Edge Transport Servers will trust your Hub Transport Servers.

Share

Office Communications Server 2007 Enterprise Deployment – Part 5

Welcome to Part 5 of this article series. So far in this article series, we have deployed an Enterprise Pool, configured our Pool, set up DNS, tested connectivity with Communicator 2007, configured our ISA box, and prepared our Edge Servers.

In this Part, I will go through the part of the configuration of our Consolidated OCS Edge Server using a separate NIC for each Edge Role.

Part 1

Part 2

Part 3

Part 4

Part 5

Consolidated Edge OCS 2007 Server Installation

When installing an OCS Consolidated Edge Server, you would perform the following steps:

Note: Edge Server should not be joined to your Corporate Active Directory.

  1. Install Files for Edge Server
  2. Activate Edge Server
  3. Configure Edge Server
  4. Configure Certificates for Edge Server
  5. Start Services
  6. Validate Edge Server

Install Files for Edge Server (Step 1)

To begin the Edge Server installation process, we can insert our OCS CD (Standard can be used for Edge).  There are some prerequisites for installing OCS such as .Net Framework 2.0, but this is all taken care of during the installation.

Insert the CD and let’s begin the installation process.  You will be asked to install the Microsoft Visual C++ 2005 SP1 Redistributable. Click Yes to Continue.

You will then be asked to install the Microsoft .NET Framework 2.0. Click Yes to Continue.

Once Microsoft .NET Framework 2.0 is installed, you will be presented with the Deployment Wizard.  We will want to deploy our Edge Server in a Consolidated fashion..  Click Deploy Other Server Roles > Deploy Edge Server to Continue.

We are now on Step 1 which is to Install Files for Edge Server. Click Install for Install Files for Edge Server to Continue after meeting the Prerequisites (being a local Administrator).

On the Welcome Screen, Click Next to Continue. After fully reading the License Agreement, if you agree, Select “I accept the terms in the license agreement .”  Click Next to Continue.

You will be asked for Customer Information such as Product Key, Name, and your Organization Name.  Enter them appropriately. Click Next to Continue.

Enter the location you want your files to be installed.  I chose the default location. Click Next to Continue.

You are now ready to start the Installation.

Once you completed the File Installation, you should see the Installation Interface update the Step 1 Status showing as Completed.

Activate Edge Server (Step 2)

Click Run for Active Edge Server to Continue.

On the Welcome Screen, Click Next to Continue.

The next screen asks us what Edge Roles we want to install.  Because we are installing a single Consolidated Edge Server, we will choose all three Edge Roles; Access, Web Conferencing, and Audio/Video. Select Activate Access Edge Server, Web Conferencing Edge Server, A/V Edge Server.  Click Next to Continue.

Note: If you are going to be load balancing, you can only have the Access Edge and Web Conferencing Edge roles together on a server.  You will need to have two separate Audio/Video Servers.  So you will need a minimum of four servers if you plan on load balancing all three Edge Roles.

You will now be prompted to specify passwords for your Service Accounts.  I recommend to use long secure passwords.  You can view this and this site which assist in choosing strong passwords.  You will have to do this for several Service Account: RTCProxyService

Once you have set a password, Click Next to Continue.

You are now ready to Activate your Edge Server.  Review your Current Settings.  After satisfied, Click Next to Continue.

When the Activation is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.

Once you completed the Activation, you should see the Installation Interface update the Step 2 Status showing as Completed.

Configure Edge Server (Step 3)

Click Run for Confingure Edge Server to Continue.

On the Welcome Screen, Click Next to Continue.

The next screen asks us if we have a Configuration File to use.  This file is great to use if we are deploying multiple Edge Servers that will be load balanced.  For example, it would be useful if I was going to be deploying two Access Edge/Web Conferenicng Edge Servers behind a Hardware Load Balancer.  I would configure my first Edge Server, and at the end of the configuration, it would ask me to export the configuration so I can import it on my second Edge Server.  Nifty!

Because this is our first and only Edge Server, Click Next to Continue.

We must choose the Internal IP of our Edge Server as well as its’ FQDN.  We are presented with the following options.

You may be wondering which IP to choose.  Remember back in Part 4 we configured four NICs.  One of these NICs was the Internal NIC which we configured as follows. We also configured a dedicated NIC and IP for each Edge Role.  Here is a list of NIC Names, their associated Edge Role, and IPs associated with them

Note: Please don’t forget that in a production environment, or even a real test environment where you will have internet/internal connectivity, the A/V Edge NIC requires a publicly routable IP Address.  This does not mean it is directly exposed to the internet.  You should need to have your firewall route a public IP directly to your A/V Edge Server.

So in our Edge Configuration, we will want to choose 192.168.119.160 for our Internal NIC.  We will also want to set the FQDN as  ocs-ocs2.shudnow.net (computername.domain.com).  Because our server is not a domain member, we will need to manually add the DNS record in our Active Directory DNS due to the nature of Active Directory Secure DNS Zones only allowing domain members to add records to our zone. Click Next to Continue.

We now must configure the IPs and FQDNs for all three Edge Roles.  You can refer to the Excel List above to determine what IPs are associated with which role.

When a client connects to the Access Edge Server, the Access Server will return the URLs needed for the client to successfully communicate with services in the OCS organization.  For example, we will configure our Web Conferencing Edge Server to use webconf.exchange.shudnow.net.  Exchange.shudnow.net is our Internet DNS Zone.  So when a Live Meeting Client tries to connect to a web conference, our Access Edge will communicate with the client telling it the FQDN for the web conferencing edge.  The same applies for the A/V Edge Server.

Enter in the IP Configuration and FQDN accordingly.  Click Next to Continue.

We will want to use this Edge Server to allow anonymous users to join meetings as well as enable federation.  If you plan on allowing your users to talk with public IM providers such as AOL, MSN, and Yahoo, select those features as you see fit.

Now let me explain why Allow remote users to communicate with federated contacts is greyed out.  It is possible to set up two Edge Servers and use one Access Edge for Remote User Access and another for Federation and Public IM connectivity.  If you decide to do this, one one Access Edge you’ll disable Federation which will light up the currently greyed out option.  On the second Access Edge, you’ll disable Remote User Access and enable Federation.  Now keep in mind this is optional.  Because we will be utilizing one Consolidated Edge Server, we can choose the options as follows which will enable Remote User Access, Federation, and Public IM Connectivity through our Consolidated Edge. Click Next to Continue.

We want our Edge Server to be able to talk to the internal OCS Servers.  We have a few options.  If we are using a Standard Server as our next hop, we would enter the Standard Pool FQDN which would be the server’s FQDN.  If we deployed a Director, we would enter the Director (or FQDN of hardware load balancer). Because we deployed an Enterprise Pool, we will use the FQDN of the Enterprise Pool. Enter the Enterprise Pool FQDN OCSPool.shudnow.net. Click Next to Continue.

Because our SIP Domain will be exchange.shudnow.net, that is what we will choose when specifying what our Authorized Internal SIP Domains are.  Click Next to Continue.

We will then want to enter our internal OCS Pool Name for Authorized Internal Servers.  If you have more than one Pool or Standard Edition Server, enter them here.  Click Next to Continue.

You are now ready to Apply your Edge Server Configuration.  Review your Current Settings.  After satisfied, Click Next to Continue.

You are now ready to apply your configuration.  Review your Current Settings.  After satisfied, Click Next to Continue.

When the Configuration is finished, Click Finish.  You will be given the option to view the log which I advise you to do to ensure everything went OK.  This is also where you’ll have the change to export your configuration if you’re deploying a second Edge Server for Hardware Load Balancing.

Once you completed the Configuration, you should see the Installation Interface update the Step 3 Status showing as Completed.

Configure Certificates for Edge Server (Step 4)

Click Run for Configure Certificates for the Edge Server to Continue.

On the Welcome Screen, Click Next to Continue.

I’m going to skip through a lot of this section as it consists of how to obtian a Certificate which I already went through in Part 4 when we discussed configuring our ISA Server.

I will be obtaining three certificates.  One is for our Internal NIC that consists of the FQDN of our Server (ocs-ocs2.shudnow.net).  The second certificate will consist of  the names of our Access/Web external edge roles. The third certificate will be our A/V Authentication certificate.

Now you may be thinking, well, can’t I just use two certificates?  One for internal and A/V edge.  Well in our case, probably.  If you have multiple servers, no.  This is because each certificate for the internal interface will be unique due to the name of every server being different.  The A/V Authentication name will be the same and exported/imported on multiple servers.  Also, Microsoft considers it to be insecure by using the same certificate for both the Internal and A/V Authentication services.

Certificate One (Internal Interface):

CN = ocs-ocs2.shudnow.net

Certificate Two (Access/Web Server Roles):

CN = sip.exchange.shudnow.net

SAN = sip.exchange.shudnow.net

SAN = webconf.exchange.shudnow.net

Certificate Three (A/V Authentication)

SAN = av.exchange.shudnow.net

Now keep in mind the reason the namespaces our different is because the internal NIC is connected to our internal infrastructure and will be utilized internally only.  Because of that, we will be using our internal namespace that is also used as our default SIP routing domain.  Our edge servers will be contacted using the external DNS namespace.  If you are using split-DNS where your internal namespace is hosted on external DNS, you can use either namespace.

For purposes of this lab, I will obtain all certificates from our internal CA.  Because our Edge Server is not a domain member, you have to ensure it contains the Root Certificate from our Internal CA.  You will also have to submit the request, approve it, and submit the .cer file manually and import it manually due to our Edge server not being a domain member.

Note: In a production environment, you will be requesting your Access/Web Conferencing Certificates from a Third Party Vendor.  Both your A/V Authentication and Internal Interface NICs will be provided by your Internal CA.  The A/V Edge role doesn’t need an Internet Facing Certificate.

We will first choose to Create a new Certificate.  One you have done this, you will want to make sure you select only your Edge Server Private Interface.  Click Next to Continue.

You will want to go through the rest of the configuration which includes entering your Organization Name, Company Name, Etc…  As I said, when you are at the screen which consists of what FQDN to use, you will use the CN of ocs-ocs2.shudnow.net.

Once you are finished preparing the request, you will see the Step being partially finished.  Click Run again to Continue.

You will now want to go through the motions of taking the .Cer file you obtained from your Certificate Authority and binding it to your request.

Follow this procedure with the remaining certificates.  Refer to the certificate CN/SAN names above as to what entries should be on your certificate.

Your Access/Web Conferencing Edge Certificate request will look like:

Your A/V Certificate request will look like:

Once you completed the Certificate Configuration, you should see the Installation Interface update the Step 4 Status showing as Completed.

Remaining Steps

I will not be going through the remaining steps.  It consists of Starting Services and Validating your Configuration.

The only remaining steps are to enable users, configure federation, and enable your Front End Servers to talk with your Edge Servers.  All this information is out of the scope of this article.  If you are interested in doing this (and you will have to connect your Front End Servers to your Edge Servers), visit this site here.

Summary

Well folks, that is all for not just Part 5, but the entire article series. Hopefully these articles have helped you understand more on how the deployment of OCS works.  There is a lot more to the configuration of OCS and especially the deployment when you get into load balancing.  Much more than what I went into.  But hopefully the article gave you enough knowledge to know where to look and how the overall deployment process works.

Share

Communicator Web Access (CWA) requires Server 2003+ Enterprise Edition CA

Now looking at my title, many of you may be thinking, ok so what… we have an Enterprise Issuing CA.  Now here’s where a lot of people get confused with Enterprise CA vs Windows Enterprise.  An Enterprise CA means that your server is an issuing CA and stores/retrieves information directly from Active Directory while a Standard CA does not.  Another difference is that an Enterprise CA issues certificates based on templates while a Standard CA issues certificates based on Enhanced Key Usage (EKU).  EKU is essentially a certificate that defines if a certificate can be used for Server Authentication, Client Authentication, All, Etc…  An Enterprise CA will issue certificate with templates such as Web Server, Encrypting File System, Domain Controller, Etc.  Each of these templates will be based on a number of factors such as what EKUs will be assigned to that template.

Now everything I have wrote above explains the difference between a Standard CA and an Enterprise CA.  What about which version of Windows we use?  Well, there is a difference between Windows 2003 Standard and Enterprise when it comes to your Certificate Authority.  There is something called Certificate Version Templates which are known as Version 1 and Version 2 Templates.  Don’t get this confused with the actual version of a certificate X.509 Version 3 is what has been used in Windows for years.  A Windows 2003 Standard Edition Server that hosts your Certificate Authority that will be issuing certificates will be able to issue Version 1 Certificate Templates only.  So if you ever need to create a custom template based off of an already existing template, you will not be able to.  This is because when you create a custom template, it becomes a Version 2 Certificate Template.

Now Office Communications Server documentation recommends that you have an Enterprise CA.  This means that the certificate information will be stored in Active Directory and when you deploy your Standard Pool Servers or Enterprise Front End Servers, you can just search for an Enterprise CA and automatically request and approve a certificate due to the machines being domain members. OCS Front End Servers or OCS Edge Servers do not require you to use Version 2 Certificate Templates.  So from a perspective of Standard Pool Servers, Front End Servers, and your Internal NIC for your Edge Server, you can use Version 1 Certificate Templates.  But with CWA, this is not the case.

Now this is where Communicator Web Access (CWA) is different.  If you look at the planning guide for CWA, there is a section on certificates.  You can view this planning information here.  If you look through the document, you will see the table that describes the certificate requirements.

As you can see, the certificate requirements state that the Web Server template needs to be duplicated.  This is both for the Mutual Transport Layer Security (MTLS) Certificate as well as the Secure Sockets Layer (SSL) Certificate.  So if you are going to be deploying OCS and CWA and are planning to deploy a Certificate Authority, I would suggest that you deploy your Certificate Authority on at least a Server 2003 Enterprise Edition Operating System.  Server 2008 Enterprise Edition introduces Version 3 Certificates Templates, Online Responder, Network Device AutoEntrollment Service, and Native Support for Qualified Certificates.  So if you are going to be deploying a CA, it may be worth your time to deploy Server 2008 to be more “future proof.”  To enable the new features of a Server 2008 CA, you will need to update your schema.

Note:  I explained this earlier but I will go into it a little more. Some of you may be thinking you need a Server 2008 CA then since the table states you need a Version 3 certificate and Server 2008 CA can do Version 3 Certificate Templates.  Version 3 (X.509 Version 3) certificates are not the same as Version 3 Certificate Templates.  Version 3 certificates have been around since 1996 and enable functionaly such as Authority Key Identifier, Subject Alternative Names, Enhanced Key Usage, Etc…  All these pieces of functionality have been in all Editions of Windows for quite some time.  So Version 3 Certificates are not the same thing as Version 3 Templates.

If you did deploy Windows 2003 Standard Edition on the server which contains your Certificate Authority, you can thankfully upgrade to Windows 2003 Enterprise Edition or even Windows 2008 Enterprise Edition.  If you deployed a Standalone CA and want to upgrade it to an Enterprise CA, you can follow the instructions here.

Update 1: According to Tom Pacyk, you can use the OCS Admin Tools to request a certificate that’ll provide the correct type of certificate needed for CWA. Read his comments below for further instructions.

Share

Migrating clients to Exchange 2007 and Outlook Profile Updates

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.

Now prior to Exchange 2003 SP2, if a client’s profile got moved to another Exchange Server, as long as it was in the same Administrative Group, DSProxy would automatically refer the Outlook client to the other Exchange server.  The Outlook client would then update its’ profile.  Now in SP2, DSProxy was changed so it can refer users to an Exchange server in a different Administrative Group.  This is essential since Exchange 2007 gets installed into its’ own dedicated Administrative Group where all Exchange 2007 servers live.  This Administrative Group is called FYDIBOHF23SPDLT.

So what had to happen prior to Exchange 2003 SP2 to allow you to move a client across an Administrative Group?  You would use a tool called The Exchange Profile Update Tool (ExProfRe).  This tool can be run in a logon script, group policy, or manually.  You can download this tool from here.  And a tip.  The documentation for ExProfRe is in the self-extracting .EXE so don’t go searching Google for hours trying to find the commands to use for ExProfRe.

Now let’s say you’re migrating to Exchange 2007.  Typically, after the last user has been migrated, you want to leave your Exchange 2003 Back End Servers that hosted mailboxes up for a period of time to ensure you have provided your users enough time to be referred automatically.  For the stragglers (people on vacation, out on maternity leave, etc.), you can either manually update their profile or use ExProfRe to get their Outlook profiles updated.  What I typically do or at least recommend is to leave your Back End up for a week or two and then shut it down for a few days to ensure no unknown dependencies were missed.  You can then bring it back up if all goes well and decomission it.

Another option is to update their profile with a PRF file.  For Outlook 2003, you can create a custom PRF file using the Custom Installation Wizard.  This PRF file allows you to create a new profile or manage existing profiles. For more information on how to do this for Outlook 2003, go here.  For Outlook 2007, the procedure is the same as Outlook 2003 except you use the Office Customization Toolkit instead.  For more information on how to do this for Outlook 2007, go here.  There are scripts out there that you can run via login scripts that allow clients to apply a PRF file once (sets a registry key when run) and the next time it runs it checks for a registry key and halts PRF execution.

I feel that in the situation that you want your client to only be re-directed to another server due to the source server having been decommissioned, ExProfRe would be the fastest and easiest method to accomplishing what you need.

Share