Wednesday, November 23, 2011

Exchange 2010 Management Shell into Existing Exchange 2007 Servers

By default Exchange 2010 Management Shell (EMS 2010) cannot manage/access information stored on the Exchange 2007 servers such as IIS configuration in the example below. When attempting to get information from an Exchange 2007 server in an Exchange 2010 management shell you will receive the following error:

An IIS directory entry couldn't be created. The error message is Access is denied.
. HResult = -2147024891
+ CategoryInfo : NotInstalled: (PER-EXCHMBX\Exchange (Default Web Site):ADObjectId) [Get-OwaVirtualDirecory], IISGeneralCOMException
+ FullyQualifiedErrorId : EBEB5204,Microsoft.Exchange.Management.SystemConfigurationTasks.GetOwaVirtualDirectory


For example here we have an Exchange 2010 shell and an Exchange 2007 shell. We can see the Exchange 2010 shell cannot access the Exchange 2007 servers... where the Exchange 2007 shell is fine.



To allow the Exchange 2010 shell to connect to the Exchange 2007 servers you must add "Microsoft Exchange Security Groups\ Exchange Trusted Subsystem" as a local admin to all Exchange 2007 servers.

Tuesday, November 22, 2011

Windows RPC/HTTP and Outlook Anywhere

Prior to Windows Vista SP1, the Windows RPC/HTTP client-side component required that the Subject Name (aka Common Name) on the certificate match the "Certificate Principal Name" configured for the Outlook Anywhere connection in the Outlook profile. Therefore, as a best practice, you should ensure that your certificate common name is configured as the name Outlook Anywhere references which can be achieved by using the Set-OutlookProvider cmdlet with the -EXPR parameter.

To understand how to configure the EXPR parameter please view this blog post:

http://clintboessen.blogspot.com/2009/06/configuring-outlook-anywhere-settings.html

As many people still use Windows XP, I recomend always configuring the the EXPR parameter to use the certificate common name.

Monday, November 21, 2011

Where are Exchange 2003 relay restrictions stored?

I was asked by a client where Exchange 2003 Relay Restrictions are stored? The SMTP Virtual Server in Exchange 2003 is actually apart of IIS and as a result its configuration is not stored in Active Directory (for the most part). This means if you recover an Exchange 2003 server using the Disaster Recovery switch you will need to re-enter this configuration.

drive:\Setup\I386\Setup.exe /DisasterRecovery

See Recovering a failed Exchange 2003 server:

http://www.msexchange.org/tutorials/Recovering-Failed-Exchange-2003-Member-Server-Using-Disaster-Recovery-Switch.html

The relay restrictions are stored under a series of REG_DWORD and REG_MULTI_SZ values under the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Service\MSExchangeIMC\Parameters

For more information please see the following Microsoft KB article:

http://support.microsoft.com/kb/193922

Thursday, November 17, 2011

Load Balance SMTP with F5 BIG-IP

The F5 BIG-IP has a template for Exchange 2010 which assists administrators with configuring load balancing for Outlook Anywhere, Active Sync and Outlook Web App. This template does not configure SMTP load balancing. There are many circumstances where you may want an SMTP endpoint IP address to be highly available and load balanced between multiple hub transport servers.

In this post I will go through and show you how to configure the BIG-IP LTM for load balancing the SMTP protocol and the challenges associated with this. This article was written using the F5 BIG-IP LTM VE version 10.2.3.

Create a Health Monitor

Create a health monitor which monitors the Exchange 2010 SMTP service on our Exchange 2010 servers. The heath monitor will send SMTP HELO requests on a regular basis to ensure the SMTP servers are healthy.

Expand Local Traffic and click Add next to Monitors.



I called the monitor SMTP_Monitor. Set the Type to SMTP. Provided an interval of 120 seconds meaning the monitor will send an SMTP HELO every 2 minutes to the Ex2010 servers to see if they are still online. Configured the Alias service port to 25.



Create a Pool for the SMTP Servers

A load balancing pool is a logical set of devices, in our case SMTP servers, that you group together to receive and process traffic. To create a new pool under Pool List click Add.



I called the pool smtp_pool. Select the SMTP_Monitor we created earlier. Select the load balancing method as Round Robin. Add the SMTP servers to our pool in which we wish to distribute inbound SMTP connections to.



Create an SMTP Virtual Server

Create an SMTP Virtual Server on the F5 BIG-IP which will allow the BIG-IP system to listen on TCP25 to load balance incoming SMTP sessions. To do this under Virtual Servers --> Virtual Server List click add.



I called the SMTP Virtual Server SMTP_VS. Under Destination I specified 172.16.51.174. This is the Virtual IP the BIG-IP will listen on for incoming SMTP traffic. Select a service port of 25 and place the device in an enabled state.

Under configuration set SNAT Pool to Auto Map (I have explained what Auto Map is below).



Scroll down further and under resources set the Default Pool to smtp_pool along with the default persistence profile to source_addr.



Test our BIG-IP SMTP Virtual Server

The F5 BIG-IP device should now be configured to load balance SMTP requests between the two Exchange 2010 servers. In your Virtual Server List the SMTP_VS should come up green.



From a command prompt verify you can telnet our SMTP virtual server on 172.16.51.174 on port 25.



We can see that it successfully connected to one of the SMTP servers in our load balancing pool "smtp_pool"



At this point your F5 BIG-IP is successfully load balancing SMTP.

The Problem...

When building an email solution it is absolutely critical to avoid becoming an open SMTP relay. Most organisations implement relay restrictions by locking anonymous relay down to certain source IP addresses on their internal network such as applications and printers. Source IP is generally the preferred method as Administrators do not have to deal with SMTP authentication methods. The list of IP addresses who are allowed relay anonymously are usually configured on the Exchange SMTP receive connectors. However when dealing with load balancers such as a F5 BIG-IP Local Traffic Manager this becomes a difficult task.

Why?

Whilst load balancing connections the F5 BIGIP uses SNAT to re-write the source IP address on the SMTP packets to one of its "Self IP" addresses or "Virtual IP" addresses. This means the Exchange servers will see all requests coming from the same IP address making it impossible to determine which request belongs to what client. This is illustrated in the following diagram:



However I have a workaround for you. If we setup two SNAT addresses on the F5 BIG-IP for example 172.16.51.174 and 172.16.51.175 we can configure our BIG-IP to say any source IP addresses that need to be an anonymous open relay hit our Exchange 2010 servers from 172.16.51.174 ELSE hit our Exchange 2010 servers from 172.16.51.175. This solution means we need to configure our list of allowed IP addresses for SMTP relay on our F5 BIG-IP instead of our Exchange SMTP Receive Connectors.

Create a Data Group List

First we must create a list of IP addresses we want to allow anonymous relay for on our F5 BIG-IP. These are the IP addresses we would normally configure on our Exchange receive connectors. To do this we need to create a new data group list.

Add a new data group list by expanding iRules --> Data Group List and clicking the add button.



I called my Data Group List smtp_relay_allowed and specified the IP address 172.16.51.21. You can add as many IP addresses as you want for anonymous relay.



Create a new iRule

An iRule is a powerful and flexible feature of BIG-IP devices which provide you with unprecedented control to directly manipulate and manage any IP application traffic. By creating an iRule we can instruct the BIG-IP to return a different SNAT address based on on the condition. We want to instruct our BIG-IP to perform the following:

IF a clients source IP is on our Data Group List THEN use an SNAT address of 172.16.51.174 ELSE use the SNAT address of 172.16.51.175.

To create the iRule under Local Traffic Select iRule --> iRule List and click the add button.



I called my iRule smtp_irule and created the following code to perform my required conditions as mentioned above.



A copy of the code:

when CLIENT_ACCEPTED {
set accepted_snat "172.16.51.174"

if { [ class exists smtp_relay_allowed ] }
{
if { [class match [IP::client_addr] equals $::smtp_relay_allowed] }
{
snat $accepted_snat
} else {
snat automap
}
} else {
snat automap
}
}


Automap is a feature of the BIGIP where it automatically selects a Self IP at random to use for the SNAT translation. A Self IP is an IP you have assigned to the BIGIP manually under your network configuration. This is different to a Virtual IP address which is created when you setup a virtual server. I only have one Self IP on my BIG IP set to 172.16.51.175 and one virtual IP set to 172.16.51.174 used by all my F5 virtual servers on different TCP ports. As a result automap will ONLY select 172.16.51.175.

Why would you want multiple source SNAT IP addresses?

For each connection made from the BIG-IP to your load balanced servers a TCP source port needs to be opened for the communication. TCP only has 65535 ports for source and destination traffic so if the number of connections exceeded the number of available ports, the BIG-IP would not be able to take new connections. In this event you could add an additional Self IP and rely on the Automap feature or create an SNAT pool which is a predefined list of IP addresses the BIG-IP is allowed to use for SNAT.

I recommend reading the chapter on SNAT configuration from the F5 website:

http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_snat.html

How do I configure Exchange 2010:

On your Exchange 2010 servers create your two receive connectors as normal. Create one receive connector configured for your anonymous relay and setup yoru default receive connector for all other SMTP traffic. Both receive connectors must listen on port 25. Do this on all Exchange servers in your pool.

For information on how to configure your application receive connector for anonymous relay follow this blog post:

http://clintboessen.blogspot.com/2009/07/allow-network-applications-to-relay.html

Apply my new iRule to the SMTP Virtual Server

Next we need to attach the iRule to the SMTP virtual server in the F5 configuration screen. To do this go to your Virtual Servers --> Click Virtual Server List then select our SMTP_VS created earlier.



Select Resources then under iRules click Manage.



Select our smtp_irule out of the list available then click finish.



Testing our Configuration

So time to test the configuration to ensure it works as configured. Lets telnet my BIG-IP SMTP Virtual Server from the host we allowed 172.16.51.23 by running the following command:

telnet 172.16.51.174 25

I then wrote some random comments in the telnet session so we can identify our server 172.16.51.23 in our SMTP logs.



I then repeated the procedure from another server which is not in our Data Group List created above.



In our SMTP logs on our Exchange 2010 server as expected the 172.16.51.23 server came from 172.16.51.174 and the non trusted IP came from 172.16.51.175.

Tuesday, November 8, 2011

VBS Get the OU distinguishedName of the OU containing a User Account

I had an interesting task which I needed to achieve. I had another peice of code grabbing a bunch of user distinguishedName's in Active Directory. For each distinguishedName I needed to grab the OU/container the user account resides in. For example:

"CN=Clint Boessen,OU=Microsoft MVPs,OU=Engineers,OU=IT Professionals,DC=4Logic,DC=local"

We need to cut the "CN=Clint Boessen" of this string in order to determine the organisational unit so we get:

"OU=Microsoft MVPs,OU=Engineers,OU=IT Professionals,DC=4Logic,DC=local"

However sometimes the user accounts are in a container not an OU so we need code smart enough to deal with this.. for example:

"CN=Clint Boessen,CN=Users,DC=4Logic,DC=local"

To be come:

"CN=Users,DC=4Logic,DC=local"

The VB Script below will take care of this... as long as you store the distinguishedName within the strOU attribute.

For example:

strOU = "CN=Clint Boessen,OU=Microsoft MVPs,OU=Engineers,OU=IT Professionals,DC=4Logic,DC=local"

If instr(lcase(strDN),"cn=users") = 0 then
strOU = right(strDN,len(strDN) - instr(lcase(strDN),",ou="))
Else
strOU = right(strDN,len(strDN) - instr(lcase(strDN),",cn=users"))
End If

Thursday, November 3, 2011

Exchange 2003 PFDavAdmin Error

When trying to connect to an Exchange 2003 Server using PFDavAdmin I received the following error:

An error occur ed while trying to establish a connection to the Exchange server. Be sure that port 443 (for SSL) or port 80 (for non-SSL) can be reached. If you are connecting to public folders, be sure that the public folder store is mounted. If you are connecting to mailboxes and the progress bar shows a particular mailbox, be sure that user has at least one email address.

Exception: Failed to connect using secure URL: https://domain.local/ExAdmin/Admin/domain.local/public%20folders/ with error: The underlying connection was closed: Unable to connect to the remote server.. Failed to connect using unsecure URL http://domain.local/ExAdmin/Admin/domain.local/public%20folders/ with error: The remote server returned an error: (503) Server Unavailable.




This error gets generated if you have a proxy server configured in Internet Options. What caught me out however is PFDavAdmin only detects proxy settings on application lauch... not on connection. If you remove your proxy settings from Internet Options, then attempt to connect again using PFDavAdmin the same error will be reproduced as PFDavAdmin will continue trying to use your proxy settings.

You must:

1. Disable your proxy server or add an exclusion.
2. Close PFDavAdmin
3. Relaunch the PFDavAdmin application.

Wednesday, November 2, 2011

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

When Running Test-ActiveSyncConnectivity on Exchange 2010 you will probably experience the following error.

[System.Net.WebException]: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. Inner error [System.Security.Authentication.AuthenticationException]: The remote certificate is invalid according to the validation procedure.



There is generally three causes for this problem:

1) Name mismatch - make sure the site name matches exactly as it is in the cert. If there is a "Subject Alternative Name" (SAN) on the details tab, then make sure the name is in that list (note: subject name must also be included in the SAN). Some applications don't supports SANs, but most do. Also note that site1 and site1.domain.com are not the same - this is the most common mistake.

2) Untrusted - you need to install the root certificate into the trusted root certificate store. If this app uses the Microsoft root store, you can check Certificates MMC to see if it shows up. If not, view the details of the certificate from the error box, go to the certification path tab and double click the topmost certificate, go to details tab and Copy to File button to export it, then from your saved copy you can import it to the trusted root store.

3) Expired or not yet valid - usually from the cert expiring - renew it. Can also happen if the time/time zone/date/year is off in the client OS - if this is ok, try also checking the same in BIOS.


Name mismatch is generally the one that catches people out. If you simply run Test-ActiveSyncConnectivity the Exchange 2010 server will not use a trusted URL on your SAN certificate. Make sure you specify the URL on the Test command for example:

Test-ActiveSyncConnectivity -URL "https://mail.contoso.com/Microsoft-Server-ActiveSync"