Android Phones

I've started seeing clients purchase Android phones.  My advice - Don't buy one unless its running version 2.2 of the Android OS.  Full Exchange support is promised in 2.2 (Froyo).  I haven't seen it yet, but I can speak from experience, anything prior to 2.2 has very spotty Exchange support.  The Exchange calendar is definitely not supported prior to 2.2.

Single Instance Storage in Exchange

I'm a bit behind on my reading.  Single Instance Storage is gone in Exchange 2010.
 http://msexchangeteam.com/archive/2010/02/22/454051.aspx

I get the logic.  But it makes me wonder about Small Business Server.  I get that disk is cheap, but I think there are probably a lot of single Exchange server shops out there that buy a server and never plan on adding disks.

Exchange Queues filling up? (Part 2)

Here's the scenario... I'm deploying a single Exchange 2007 server (mailbox, CAS, Hub transport) at a client.  Its a transition from Exchange 2003.  Its pretty straightforward and its going fairly smoothly (kudos to the Exchange team for making it fairly painless) until the queues start filling up.

Having resolved an issue with the FQDN, I thought I was out of the woods.  I was wrong.

Messages started flowing for some domains, but overall, the queues still weren't moving.  After a bit of research, I come across this post... http://msmvps.com/blogs/bradley/archive/2007/10/15/i-already-flunked-the-bpa.aspx.

So I check the server using the command:
netsh int tcp show global

Nope, its definitely disabled.... hmmmm... then I come across this post...http://blogs.msdn.com/psssql/archive/2010/02/21/tcp-offloading-again.aspx.

Ok, its not Exchange related, but I check and the NIC has TCP Offload enabled.  So I disable that and restart.  Hmmm, no luck, but at least I've ruled that out.

After a bit more searching, I come across this kb article - http://support.microsoft.com/kb/951291.

Issue the command:
netsh interface tcp set global autotuninglevel=disabled

Check the status: netsh interface tcp show global

which returns this:
TCP Global Parameters

----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disabled

This changed the Receive Window auto-tuning level to disabled.

Restart the server.  Check the queue viewer.  All messages have been sent!

Here's an post that covers some tweaking Microsoft has done to the networking stack in Server 2008 and Vista.
http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2008/05/15/backward-compatible-networking-with-server-core.aspx

Enjoy.

Exchange Queues filling up?

Recently, I've been deploying a new Exchange 2007 server at a client.  We were almost through the transition when outbound email started to back up.  The queues would just start filling up with outbound messages.  This led to the discovery of a couple of problems with this brand new set up.

First, my last post detailed an issue (at least I think its an issue) where Exchange 2007 won't use the FQDN set on your outbound send connector.  If you have the Hub Transport role installed on the same server as the Mailbox role (which I think is a fairly common AND supported configuration), Exchange instead uses the internal name of the server.

Here's where this can cause issues.  Since we were transitioning from Exchange 2003 to Exchange 2007, when we flipped the SMTP traffic over to Exchange 2007, we simply redirected the DNS records to the new server.  In this scenario, the client had two external DNS entries for their mail server.  First, they had a "webmail.domain.com" entry that was used for OWA and Outlook Anywhere.  Second they had a "mail.domain.com" entry used for SMTP traffic.  Both point to the same address and both were ultimately redirected to the shiny new Exchange 2007 server.

In Exchange 2003 this didn't cause any issues, because the outbound FQDN could be set to match "mail.domain.com".  Here's where the issue arises.  In this client's single server Exchange 2007 configuration, they have an external DNS entry that says "hey, I'm mail.domain.com", but if you peek at the message headers, they say something like "I'm servername.domain.com" since this the internal name of the server.

Big ISP's like AOL, Comcast, etc really like you to have a reverse DNS entry for your mail server.  And they prefer it to match.  This is a relatively minor problem and easy to fix.  Otherwise, you can have mail delivery issues.  Fun error messages like :
451 4.4.0 Primary Target IP responded with ...
"421 4.4.2 Connection dropped" or "421 4.2.1 Unable to connect" or "421 4.7.1..." 

You get the idea.

There's an easy solution.  Create an external DNS entry that matches whatever your server is putting in the headers.  In this case, servername.domain.com.  You also will need a reverse DNS entry that matches.  Get this through your ISP.

This was the first mail flow issue we discovered.  Stay tuned for part 2.

Exchange 2007 Outbound FQDN not working

Let's say for example, you have a single Exchange 2003 server in your network. You decide to tansition it to Exchange 2007. You have a small network, less than 75 users so you don't go to all the trouble of setting up an Edge Transport role since you rely on an external provider for message hygiene, spam filtering, etc. So you have a single server running the Mailbox, Hub & Client Access roles.


All seems well, until you notice that you seem to be getting a lot of delivery failures on your outbound messages. Upon investigating, you discover that in the message headers the server name is the internal name of the server, NOT the external FQDN you used in Exchange 2003. Hmmm... that's weird.


If you poke around in Exchange 2007 you'll discover that there is a FQDN field right on the Send Connector property page. Great! Just set the FQDN and you are in business, right?  Wrong.

If you do a quick check of the Exchange 2007 help file, you find the following nugget...
If the Send connector is configured on a Hub Transport server that also has the Mailbox server role installed, any value that you specify for the FQDN field is not used. Instead, the FQDN of the server that is displayed by using the Get-ExchangeServer cmdlet is always used.


So you can set the value there or through the Command Shell and Exchange will happily ignore it. Instead, you'll get the Exchange Server name.  There are instructions in the help file for removing the Exchange server name from the headers, along with some warnings about how its not recommended. In my case, I just decided to create an external DNS entry, AND reverse DNS entry with the internal name of the server.

Message Returned, but with error status

Recently, I've been upgrading several clients to Trend Micro's Worry Free Business Security. A couple of times the upgrade was successful, but after a couple of days, the console would become unresponsive and eventually return "Message returned, but with error status." The console would then display some default gibberish on the status screen.

Restarting the Trend Micro Security Server Master Service would usually fix this temporarily. After trying the steps in several Trend Micro kb articles (EN-1037390 most notably) without success, I resorted to calling Trend Micro support.

The bottom line - a corrupt HTTPDB database. Here are the steps that I performed to fix the issue with Trend Support. Keep in mind, these steps worked for me and you will lose some settings (URL Filtering settings as well as the group settings seem to be the biggest casualty). So I suggest getting some screen captures of the settings you'd like to keep before trying this.

1. Close the WFBS Console if you have it open.
2. Stop the Trend Micro Security Server Master Service. In my case, the service would eventually just crash after attempting to stop for a long time.
3. Open Task Manager, kill the DBServer.exe process.
4. Open Windows Explorer and navigate to your \PCCSRV folder.
5. Look for the HTTPDB folder. Rename to HTTPDB_Backup.
6. Open the TEMP Folder. Delete the contents.
7. Restart the Trend Micro Security Server Master Service.
8. Wait a minute, then re-open the WFBS Console.

You should now be able to login. Recreate your settings and everything should work fine. Note that it will take a while for the clients to check back in and show up in the console.

Small Business Server 2008 Backup

I recently had my first experience with SBS 2008's restore process. I must say I'm impressed at how well it worked. It was a bit of a disaster recovery situation (aren't they always). I'll post more about this later, but suffice it to say in a 4 drive RAID5 system, half the drives had failed. After replacing the drives, we booted to the SBS 2008 installation media and started the restore. Within 2 hours, the server was backup as if nothing had happened. Most impressive Microsoft!