Microsoft Exchange and Remote Desktop Services Specialists

SEMblog

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

Future Version of Exchange Error When Removing Public Folder Database

During a recent migration from Exchange 2007 to 2010 I found I was unable to remove the public folder store from the Exchange 2007 server. 

It was returning the following error when using remove-publicfolderdatabase or using EMC on Exchange 2007. 

Remove-PublicFolderDatabase : Object is read only because it was created by a future version of Exchange: 0.10 (14.0.100.0). Current supported version is 0.1 (8.0.535.0).

Obviously the Exchange 2010 server had touched the database in some way, probably due to the Offline Address Book migration. 

The fix was quite simple - remove it using the Exchange 2010 Exchange Management Shell. Can't use the GUI as the Exchange 2007 public folders do not appear in there.

Get-PublicFolderDatabase -Server EXCH2007 | Remove-PublicFolderDatabase

Where "Exch2007" is the name of the Exchange 2007 server. 

After removing the database I refreshed the GUI and was then able to drop the Storage Group and complete the removal of Exchange 2007. 

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!