Microsoft Exchange and Blackberry Server Specialists

SEMblog

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

Odd SBS 2011 Receiving Email Issue

 

Recently deployed an SBS 2011 server for a client down in the New Forest. Shortly after going live with this server, we experienced one of the oddest issues I have experienced. The fix was very simple, but the symptoms left us scratching our head. 

The server was intermittently receiving email. I could send it messages, but other accounts could not. Sometimes email from Google Mail would come through, other times they wouldn't. Same for Hotmail and other services. 

As it was intermittent, I was confidently ruling out the Exchange part as I said I could send it email. It was responding to telnet commands quite happily. 

Therefore we started to consider issues such as the router (it was something odd), the ISP as it was one that I hadn't used before and wasn't quite the same as others in the UK. Things were changed around and still the problem continued. 

The major symptom was the "Service Unavailable" was received by the clients, but it was on a 4.x.x error code, so email wasn't failing immediately. That error message usually means the anti-spam filtering it blocking the email. As the anti-spam agents are installed by default on SBS 2011, they were removed, no change. We had also installed AV on to the server, so that was checked and removed to ensure it wasn't affecting anything. 

This went on for a few days.

Then clutching at straws I started to go through the entire setup comparing it to my reference SBS 2011 server here in my home office. This reference server is basically an SBS 2011 installation that has had the wizards run, is kept patched, but isn't used or touched in any other way. It is an out of the box install. No third party software installed, and it isn't exposed to the internet. I have them for all three versions of SBS (2003, 2007 and 2011) that I work with. 

When I got to the Receive Connectors, I immediately noticed something was wrong, and I had overlooked something. 

This is a screenshot of the Receive Connector as I saw:

 
The key bit is at the bottom. 
It appears that the SBS setup wizards configure the receive connector to not receive email from the internal subnet. However for some reason the third line to allow IP addresses above 192.168.x.x had not been written. 
 
This is a screenshot of the correctly configured connector:

 

What this meant was that any email server with an IP address of below 192.168 was able to send email to the server, but anything above that couldn't. It would appear that some of the major email providers like Google Mail are routing their email out through high number IP addresses!

Furthermore, this wasn't being corrected by the fix my network wizard, which I had run a number of times to ensure that I hadn't missed something. 

As soon as I corrected the setting and restarted the Microsoft Exchange Transport Service for good measure, the email started to flood in. 

 

Relocation

 

The blog has been very quiet for a few months, and even my forum posting level has dropped, and that is because I have moved house. 

I am now located in the Thames Valley, midway between Newbury (home of Vodafone) and Reading (home of Microsoft UK). It took me a little while to settle in, as I moved from a very small one bedroom flat (apartment) in to a three bedroom detached house. Although oddly my stuff appears to have grown to fill the space!

I now have a real office instead of the corner of the lounge, a real kitchen instead of the corner of the lounge and a lounge without a kitchen and my office in it. I also have a garden, which is somewhat of a shock as I am so not green fingered. 

Anyway all good fun and I am now back up to speed with client work. 

 

Introduction of a New CAS Server Causes Certificate Prompts

An increasing issue appears to be a certificate prompt being seen by Outlook 2007 and higher clients following the introduction of additional CAS servers, or new multiple role servers holding the CAS role. 

While this has been an issue for some time and well known to those running a multiple server environment, the increasing number of postings on forums about this problem has probably occurred as single Exchange 2007 servers start to get to end of life and people migrate to Exchange 2010. 

The cause of this is usually autodiscover. 

What is Happening

CAS Servers have a value called "AutoDiscoverServiceInternalUri". This is published in to the domain as a Service Connection Point (SCP) and is queried by Outlook 2007 and higher as part of the internal autodiscover process. It tells the client where to connect to for the account information. 

If you have multiple CAS servers then they will all be publishing this information to the domain, in effect overwriting each other. 

This command will show you the name and the value set on all Client Access Servers in the org:

Get-ClientAccessServer |select name,AutoDiscoverServiceInternalUri

The Resolution

There are two resolutions to this issue, depending on your setup, and future plans. 

 

  1. The simple fix is to bring forward the introduction of the trusted SSL certificate and get it installed on to the new server. The value for "AutoDiscoverServiceInternalUri" should match one of the host names on the SSL certificate. Remember that most SSL providers will not allow multiple certificates with the same names on them to be issued, so you may have to get a new certificate issued to cover all servers with the CAS role. 
  2. Set the value for AutoDiscoverServiceInternalUri to be the same on all CAS Servers. If this is a specific server name, rather than a generic name, then you will need to change that value on all servers if you remove that server from production. Alternatively you could ensure that autodiscover.example.com resolves internally on your network to the IP address of a CAS server, then set all CAS servers to use that value. Then when the servers are changed, all you need to do is update the DNS. If you have clients on your internal network which are not members of the domain, then you may well have already configured this. 

Multiple AD Sites

If you have your CAS servers in multiple AD sites, then you may well have to consider using site scope to control which server the clients will connect to. There are other things to consider if this is the best thing to do or not and this Technet article explains how to use Site Scope: http://technet.microsoft.com/en-us/library/aa997633(EXCHG.80).aspx

CAS Array

This is not related to the Exchange 2010 CAS Array function, and you shouldn't use the CAS array host name for this. The CAS array doesn't use HTTPS and also shouldn't be resolvable from outside. 

Blackberry "Buyer's Remorse" Screen

Does someone at RIM have a sense of humour I ask myself?

While playing around with a couple of Blackberry devices that belong to a client, I went through the common list of Blackberry diagnostic codes to see if they worked on an OS6 device (they do). 

When I came to the one for the Voice and Data use (BUYR), I had a surprise when the additional information was labelled "Buyer's Remorse". See the screenshot below. 

This is from my own 9700 that I have upgraded to OS 6. I only use it for Data, it doesn't have a voice subscription. 

Wondering if this was an OS 6 thing, I checked another device. This was a brand new 9780. 

Slightly different OS versions (6.5.0.54/6.00.294 on the 9780, versus 6.6.0.86/6.0.0.380 on the 9700). However no label on the sections. Therefore it would appear to be a 9700 only thing. A curious way to label that information - perhaps an indication of how addictive the Blackberry can be - not known as the Crackberry for no reason!

Case Study 2 Part 3 - Network Rebuild - Networking

This is part three of a three part posting of a recent case study.

Part 1 - Part 2

Networking

With all the changes we had to look at the networking. 

Internet Access

With the server in the data centre, the issue of bandwidth over the WAN connection became critical. 

Therefore the client upgraded their line to a 2mb SDSL line, although due to the distance from the exchange, we only get about 1.5mb. 

A second internet connection was also brought in. This is a basic connection which will be used for backup purposes only. In the meantime we have put a wireless connection on to it for use as a guest wireless. No connection to the production network. In the event of a failure of the SDSL line, a cable will be moved to use the backup connection. Not completely automated, but for this client, good enough. 

The servers in the data centre are connected to the production network via a site to site IPSEC VPN. This VPN is managed by pfSense, which sits in a virtual machine. Using the VMWARE virtual switches, the internal servers are isolated from the internet. 

As I wrote in part 2 about the servers, all traffic between the two servers and traffic from the internet goes across the VPN. What this means is that if the primary SDSL link is dropped, then all I have to do is reconfigure the VPN to use the backup connection. No need to make any DNS changes, and data remains under our control. 

All three internet connections - the SDSL, ADSL backup and data centre are covered by OpenDNS to provide a first line of protection against nasty's, but also stopping staff from browsing to sites they shouldn't be. For the guest wireless, the settings are more strict, so that the link cannot be abused. 

Internal Network

A production wireless network was also introduced, using two access points that have covered most of the building. This gives freedom to locate printers and other networking hardware. 

We also used the Windows 7 excuse to remove the last desktop printers, so the only printers left are networked. Although a HP Deskjet 4 which has been recently serviced was reprieved and a Jet Direct card picked up off eBay for £20 meant it was back in action as a network printer. 

When I did the original network I implemented a dual speed network. This is where all workstations are connected to a 10/100 switch, with a gb uplink to a 1000 switch. This was retained. A further switch was put in between the router from the ISP and the software firewall. This allows a machine to be connected to be outside the firewall. 

An APC UPS with a built in network card was also retained, which has more than enough capacity for the two servers and with the APC network tool installed on all the virtual servers, it will shut them down gracefully. 

Network Documentation

The network is documented live through OneNote. An Office 2010 licence has been used on one of the domain controllers which allows access to OneNote. Of course this is replicated live. As changes are made, they can be quickly updated in OneNote. So while the network documentation isn't any kind of formal, well written format, it is in such a way that could allow the network to be rebuilt. 

Did everything go to plan?

Given the size of the job, and the massive change that went through, things went quite smoothly. 

One of the servers was dead on arrival, BT took a while to install the SDSL line, and then more time to get the backup ADSL line to run at a decent speed. 

Printer publishing didn't work correctly, I had to completely redo group policy, the VPN didn't work initially for the clients and I completely forgot about expiring passwords with the roaming users (its been a while since I ran a large laptop fleet). Drive mappings initially worked when they felt like it. 

However overall the client is very pleased with what they have. 

Finally

At the end of 2010, the client's location had issues with access due to the weather. However the replacement network configuration allows all staff with computers at home to work from home, connecting via remote desktop gateway. 

The future

Now this work has been done, we can look ahead. 

With complete control over the entire platform server and workstation side, internal applications can be developed easily. An internal web application is already under development, and I have told the web developer to develop for Internet Explorer 9. It is my intention to implement the new IE 9 jump lists. A Blackberry interface is also under development, as this can be accessed via the BES Express that has been installed. The new Blackberry Playbook is being looked at with some interest. 

This new deployment provides a firm platform for some time to come, while significantly increasing the productivity of the end users. 

Project Conclusion

By making use of VPN technology and the server that has been located in the cloud, we have removed the dependency on any one ISP. This plays a key part in any business continuity, and in the day to day use of remote access for the mobile workers. It also means that as new internet technologies, such as Fibre to the Cabinet become available, those can be easily implemented with very little disruption to the business. 

Crucially though, by using native to Windows and Exchange technologies, the complexity of the network has not increased very much. There is very little proprietary technology in the network, so there is no vendor dependency other than Microsoft and VMWARE.

By using virtual machines, we have removed most of the hardware dependency, so replacement servers could be deployed from pretty much anyone in the event of a significant problem. 

Finally, it just works. Since it went live in late September 2010, it has not provided any major problems.  The business just gets on with what it does.