Okay, sorry to dismiss the earlier Server Fault message--it led me on the right track, at least. I called Dell support and had them walk me through disabling the performance features on the NIC, which resolved the issue. I think the key was disabling global chimney and receive side scaling, as I had tried most of the other steps as per the other Server Fault question posted. Of course none of these settings should cause problems, so maybe it's going to vary from server to server.
I also upgraded the driver version for the NIC, applied a BIOS patch and the latest Windows optional update rollup for Hyper-V issues, including a blue screen issue that we had experienced twice in the last week: KB2264080.
Here's the Dell support script I followed:
In a command prompt:
a. netsh int tcp set global chimney=disabled
b. netsh interface tcp set global rss=disabled
b. On each NIC inside the Broadcom Advanced Control Suite (BACS)
i. Disable IPv4 Checksum Offload
ii. Disable IPv4 Large Send Offload (LSO)
iii. Disable Receive Side Scaling (RSS)
. Uncheck the TCP Offload Engine (TOE) checkbox
v. Click Apply
Intel Configuration
a. Open Device Manager
b. On each Intel NIC in Device Manager, disable the following:
c. NOTE: Not every option is available or exist on the Advanced Tab.
i. Offload Receive IP Checksum
ii. Offload Receive TCP Checksum
iii. Offload TCP Segmentation
iv. Offload Transmit IP Checksum
v. Offload Transmit TCP Checksum
vi. IPV4 Checksum Offload
vii. Large Send Offload v2 (IPV4)
viii. Large Send Offload v2 (IPV6)
ix. Receive-Side Scaling
x. TCP Checksum Offload (IPV4)
xi. TCP Checksum Offload (IPV6)
In Windows Server 2008
1. Start à Run à CMD
2. netsh interface tcp set global rss=disabled
a. netsh int tcp set global autotuninglevel=disable
The first question is where does the failure appear? Inside the exchange organisation or in emails sent outside the organisation? So the first question is does the error appear for internal emails, external emails, or both? OWA is obviously an exchange component in its own right, and so the emails are accepted by the exchange system the moment you click send, so we can assume that you've got a basic working system of some kind set up.
For external emails, as you say this is where the problem lies, I'd be looking at the SMTP send connector(s) for the organisation. You've got a box installed with the exchange hub transport role, and you might have another box configured as an edge transport server.
So the question is do you have an edge server? And what queues are showing issues? Are you using the default address space scope/ email routing? Are you using a smarthost? Is there a firewall between any of these servers? This is where I would start digging for the problem.
Best Answer
In WindowsITPro blog they say that this update created a problem with the MAPI RPC component.
Other mail services (OWA, ActiveSync, etc.) should work properly, because they don't use the faulty component.
The update has been removed from "Microsoft updates".
As they strongly suggest, you better test all updates before applying them to avoid such situations.
Alternatively, if you don't have any special systems, you could just wait for someone else to be the Guinea pig.