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.
Tuesday, April 27, 2010
Thursday, April 22, 2010
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.
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.
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.
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.
Subscribe to:
Posts (Atom)