Microsoft Exchange and Remote Desktop Services Specialists

SEMblog

Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

Community Event Follow Up

On the 21st June 2007 a UK based Exchange User group called MMMUG (http://www.mmmug.co.uk/) held a community event hosted by Microsoft. This was also attended by some of the other UK user groups.

I attended and assisted with a the breakout sessions for Exchange 2007 along with Nathan Winters of the MMMUG.

During and after the breakout presentations I was asked the same couple of questions more than once. In case you were there and didn't get to ask me those questions, here they are along with the answers.


Q: Where can I get SSL certificates for US$30?
A: This was in relation to the section of our presentation about the SSL issues with Exchange 2007 (discussed elsewhere on this blog: http://blog.sembee.co.uk/archive/2007/01/21/34.aspx).

There are two main sources that I suggest.
1. Go Daddy. http://www.certificatesforexchange.com/
Their certificates are US$20 a year and are compatible with Windows Mobile 5 with the MSFP update and later.
However their certificates are a little more complex to install server side, but it isn't that bad. They also aren't good for .co.uk domains as their authorisation process seems to fail.


2. RapidSSL. http://www.rapidssl.com/
Their certificates are US$60 a year, but if you look around for their resellers you can find them as low as US$30.
RapidSSL also do 30 day trial certificates, which are good to get to grips with the process. If you have a trial certificate and then upgrade you get a discount.
Good for co.uk domains.
However their certificates are not trusted by Windows Mobile, so you have to import the root certificate yourself (http://www.amset.info/pocketpc/certificates.asp).


Q: I would like to test Unified Messaging with Exchange 2007.
A: If you would like to use actual hardware then you need to get a cheap gateway device.
Last year Microsoft ran a trial kit with some partners (http://msexchangeteam.com/archive/2006/09/25/428984.aspx)
The device that they used is readily available - if you can get someone to sell it to you without expensive consultancy.
The device is you need is an AudioCodes MediaPack 114 FXO VoIP gateway. It is an analogue device, so you can plug it in to a standard telephone line. http://www.audiocodes.com/

Q: What is your blog address?
A: In case you are reading this elsewhere, it is http://blog.sembee.co.uk/
I also author content on my company web site at http://www.amset.info/

Q: Can we hire you?
A: Yes of course. Email contact  @  amset.co.uk

Windows Mobile 6.0 Emulator Images

Kudos to Jason Langridge for this one.

Windows Mobile 6 emulator images are available for download from Microsoft. You will need the emulator installed on your machine, with the various networking components etc.
Unlike the previous SDK images, these work in the standalone emulator.

The emulator is ideal if you are looking at Exchange 2007 as you can see the extra features of Windows Mobile 6 when used with Exchange 2007 and test the auto discover functionality that Windows Mobile 6 provides.

You need version 2.0 of the emulator for these images.

185mb for the Professional version emulator. Watch you get the correct language.

Emulator 2.0 download:

http://www.microsoft.com/downloads/details.aspx?FamilyID=dd567053-f231-4a64-a648-fea5e7061303&DisplayLang=en

Windows Mobile 6 images:

http://www.microsoft.com/downloads/details.aspx?FamilyID=38c46aa8-1dd7-426f-a913-4f370a65a582&DisplayLang=en

Source: http://blogs.msdn.com/jasonlan/archive/2007/05/15/windows-mobile-6-stand-alone-and-localised-device-emulator-images.aspx

Problems with Email Delivery to Hotmail/MSN?

There have been increasing number of posts on forums about problems with email delivery to Hotmail/MSN domains in the last few weeks.

As the numbers seemed to be higher than usual, I made some enquiries and received a response which I will summarise here.

Apparently they changed something at the beginning of April, that has caused problems for "small senders" (their words, not mine).

The suggestions are as follows:

  1. Submit a support web form for assistance:
    http://support.msn.com/eform.aspx?productKey=edfsmsbl&page=support_home_options_form_byemail&ct=eformts
  2. Apply for Smart Network Data Services http://postmaster.live.com/Services.aspx#SNDS

There is more information on the email services from Microsoft on their postmaster site at:

http://www.microsoft.com/postmaster

Blog Gone

You may well have noticed that this blog disappeared yesterday (8th March).
The web server it was hosted on suffered a hard disk failure - the second in eight months (see here for last time: http://blog.sembee.co.uk/archive/2006/08/26/13.aspx).

The disk was replaced, but everything had to be reinstalled. Setting Community Server to how I prefer takes a little while, but here it is.

I am slowly repopulating the articles. If you read this site by RSS, then I apologise for a lot of "new" articles appearing as I put them back.

However due to the nature of Community Server, I cannot get the URLs to be identical to what they were before. Therefore I have adjusted one of the error pages which will send you to be root of the blog, where you can find the article that you are looking for. They will all return - eventually.

Routing Groups and SMTP Virtual Server Issues

When you are carrying out many installations and migrations, it is too easy to presume that a site is setup in the same way as the others, particularly when a specific technique works every time. When you get a site where it doesn't work in the same way, it throws you off a little bit.

I have recently carried out an installation for a client where a number of a factors caused some problems that caught me out.

Background

Client has two sites, about 150 miles apart, connected by a dedicated 2mb line.
500 users, roughly 60/40 split.
Three domains, parent and two child domains, with a child for each site. The root domain does not have any resources in it.
Single Exchange 2003 server, with all users on the same server.
The server wheezed badly, it wasn't configured correctly to begin with

Requirements

The requirements that the client required were very simple 

  • improve performance of email for all users
  • improve performance of email for the users in the "other" site
  • provide enough capacity for growth of the company
  • increase the mailbox limits
  • carry out tasks to comply with regulatory requirements (the client is in the financial services industry)
  • simplify management of the Exchange servers.

Nothing unusual there.

Deployed Solution

The solution I proposed and the client went for was to move to four servers - a single back end and front-end server in each site.
Both sites would be able to receive email from the internet, so if one site was down the other site received their own email and queued the email for the other.

The initial deployment was for all four servers on the same LAN as the original server. This made the data migration smooth and almost transparent to the user community.

The Problem

When separating Exchange servers with a limited bandwidth connection, using routing groups gives you control over how the email is routed out to the internet. As both sites had high speed Internet connections, we wanted the traffic to go straight out, rather than over the WAN link connection to the other server and then out to the internet.
However on this site, whenever the servers were split in to two routing groups, email from the second routing group to servers in the first routing simply queued, although email to the internet was fine. Moving the servers back in to the single routing group allowed email to flow correctly.

The routing groups were failing with a DNS related error message, which seemed odd as the servers could all talk to each other using IP address, NETBIOS name and the fully qualified domain name.

The problem was resolved very quickly when it was worked out what was wrong.

What went wrong?

It was agreed with the client that the best practises should be followed with the server naming conventions on the internet.
Furthermore the client wanted to limit the amount of internal information in the SMTP headers.
I therefore adjusted the properties of FQDN on the SMTP Virtual Server to reflect the server's real name on the internet, and the client arranged for reverse DNS to be configured for the relevant IP addresses.

However, one of my other techniques was not implemented by the client at the time the servers were initially deployed, due to the issues with their internal network.
When I deploy Exchange, I always configure a split DNS system. This allows the external name of the server to resolve internally as well, and resolve to the internal IP address of the server. (More info on split DNS: http://www.amset.info/netadmin/split-dns.asp).

What I had forgotten was that the routing group information uses the FQDN on the SMTP server in the configuration of the routing group connector.
Therefore the servers were finding the FQDN of the other server, but it was being resolved to an external IP address, instead of the internal IP. The firewall was blocking the traffic (as most firewalls do).

The Solution

There are actually two solutions to this problem, both were deployed to ensure that it doesn't cause a problem again.

  1. Setup the split DNS system. This allowed the names to be resolved correctly and for email to flow. 
  2. Change the SMTP virtual server configuration.
    If you change the IP address setting on the SMTP virtual server from "All Unassigned" to the specific IP address of the server then that also fixes the problem. The server doing the sending then doesn't have to do a name resolution for the other end of the routing group as the IP address information is enough.

What did I learn?

If you don't learn from incidents like this, then you don't gain anything, and I take something from every deployment that I do.
Don't presume that the clients network will work like most other networks. If the network has had a history of things not working correctly then this is particularly the case. 

  • Setup everything that you need before you start. 
  • I have also adjusted by own procedures and will now change the IP address settings from "All Unassigned" to a specific IP address, unless there is a reason not to for that specific client. This setting change shouldn't cause a problem with the vast majority of deployments and will avoid issues like this, particularly if there is a possibility that routing groups may be used in the future.