SEMblog

Today is the day that support for Windows XP ends, but it is also the end of another product that was much loved in its day and even now is still in widespread use, and that is Exchange 2003.

Exchange 2003 was where I really got heavily involved with the Exchange product. I had played around a bit with Exchange 5.5 and 2000 at previous employers, but it was around the time of Exchange 2003 SP1 release that I really started to spend time with it.

I was thrown in to a migration from Exchange 2000 to 2003 within weeks of starting a new job, and having built my first server, interest in the product grew very quickly. It was working on Exchange 2003 problems within the community that first got me recognition from Microsoft via their MVP programme - which I have just been received for the ninth year.

Getting RPC over HTTPS to work was my first major achievement, and it became one of the most popular articles on my web site. Documentation wasn't great and it required manual registry changes to work correctly.

I remember the joy of having the 16gb database limit increased to 18gb initially, up to 75gb with a registry change that was introduced with one of the service packs.

By the time we got to service pack 2, Exchange 2003 was a pretty rock solid product. Reliable, with plenty of third party support. The introduction of ActiveSync over HTTP was particularly important, as just a short time later the iPhone was released which took advantage of it. Until that point, mobile sync support was limited to Windows Mobile devices or Blackberry.
There was a version of ActiveSync at RTM, but until the HTTP version came out, it only really worked for users in the USA, who had free email to text services.

Looking at it now, Exchange 2003 is a fairly basic email application, but for many companies it does all that they need. However it is starting to show its age. There are problems with some modern ActiveSync devices and OWA does not like the modern browsers and unless you are using Internet Explorer, the OWA experience is pretty painful. The limitation of 75gb on a database in standard edition is very limiting for all but the smallest of companies.

It was also the last version of Exchange that was administrated purely through a GUI. However with email platforms becoming bigger all the time, a GUI only approach quickly showed its weaknesses and the move to a modern scripting language like PowerShell was overdue.

As with many things, it was good for its time, but the more modern versions of Exchange, particularly Exchange 2010 are simply much better, more feature rich and a lot more suitable for the demands of a modern IT infrastructure. 

Back in 2009 I posted that automated tools like those at mxtoolbox will return false negative results on the SMTP banner tests. (http://semb.ee/banner2007)

This is because the SMTP banner presented for inbound email is different to outbound email.

This is still the case with Exchange 2010 and 2013. You shouldn't try and change the Receive Connector configuration to "fix" this problem as will cause further issues with Exchange.

However with those tools providing false information, it raises the question of how do you easily test the banner so that you can see how a remote server will see your server?

Of course one way is to simply send an email to a remote server which you have control over, and check the headers. That isn't always practical and if you don't have your own server, using something Gmail or Hotmail might mean the message gets block because you haven't configured things correctly.

One of the blacklist operators has setup a system that will show you exactly what you are sending back, in the form of an NDR.

The details are here:

http://cbl.abuseat.org/helocheck.html

After sending the message, you will get an NDR back similar to this:

helocheck.abuseat.org rejected your message to the following e-mail addresses:

helocheck@helocheck.abuseat.org (helocheck@helocheck.abuseat.org)

 helocheck.abuseat.org gave this error:

*** The HELO for IP address 123.123.123.123 was 'mail.example.co.uk' (valid syntax) ***

 A problem occurred during the delivery of this message to this e-mail address. Try sending this message again. If the problem continues, please contact your helpdesk.

Diagnostic information for administrators:

Generating server: server.example.co.uk

helocheck@helocheck.abuseat.org

helocheck.abuseat.org #550 *** The HELO for IP address 123.123.123.123 was 'mail.example.co.uk' (valid syntax) *** ##

Original message headers: 

This service is a quick and easy way to verify the server is configured correctly. 

Recently at a client we configured some mailboxes as Resources. 
It was then decided that they would be better off as shared mailboxes, as they could be used for other tasks. Therefore the mailbox was converted to shared:

set-mailbox mailboxname -type:shared

However any emails sent to the new Shared mailbox were continuing to go in to the Deleted Items folder. This is the standard behaviour for a resource mailbox, as it is only expecting to get calendar items. 

The key is to disable the Calendar processing. You can see the current setting thus:

get-calendarprocessing mailboxname | select identity, AutomateProcessing

To disable it completely, you need to change the value of AutomateProcessing to none

set-calendarprocessing mailboxname -AutomateProcessing None

In this case, the folder still needed to accept and process calendar entries, so we changed it to AutoUpdate.

set-calendarprocessing mailboxname -AutomateProcessing AutoUpdate

The full parameters are discussed in the Technet article:

http://technet.microsoft.com/en-us/library/dd335046(v=exchg.141).aspx

Kudos to Holly at the client for finding the value which I had completely forgotten about!

Just deployed a new Kemp Load Balancer with a client which promptly broke their cross site DAG.

Usual horrible error:

[PS] C:\Windows\system32>Get-DatabaseAvailabilityGroup -Status

WARNING: Unable to get Primary Active Manager information due to an Active Manager call failure. Error: An Active

Manager operation failed. Error The Microsoft Exchange Replication service may not be running on server XXX-3. Specific

 RPC error message: Error 0x6ba (The RPC server is unavailable) from cli_AmGetDeferredRecoveryEntries.

(server xxx-3 is the remote server).

Discovered that the problem was due to an option enabled on the Kemp called Enable Server NAT (SNAT). You can find this under System Configuration, Miscellanious Options, Network Options. Disabling that corrected the issue almost immediately. Seems that the NAT broke the DAG. 

I was recently asked to look at an Exchange server giving the common PowerShell connection failure due to Kerberos authentication. 

The following error occurred while attempting to connect to the specified Exchange server 'rpi-exchange.rp.local':

"The attempt to connect to http://rpi-exchange.rp.local/PowerShell using "Kerberos" authentication failed: Connecting to the remote server failed with the following error message: The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL. For more information, see the about_Remote_Troubleshooting Help topic. "

The usual reasons for this error are well documented and I am not covering them here. After spending an hour going through the usual suspects, I started to look for anything else, as this was giving a Connection Refused error, which wasn't hugely documented past the Remote PowerShell permission. 

I then had a brainwave. I was working on a system in a school. Schools have pretty restricted Internet access in most cases. This usually means a proxy. 

Netsh winhttp show proxy 

That command immediately showed there was a proxy, running

Netsh winhttp reset proxy

Cleared the proxy settings and allowed the Exchange Management Console to start correctly. 

The client was then advised to check their proxy configuration settings, specifically the exceptions list so that the correct ones were in place, as I feared that next time Group Policy applied the proxy settings, the change would be reset.