Exchange doesn’t even know what the definition of competition is in today’s enterprise environment!  Ok, calm down you Gmail fanatics! 

See this post from Mohamed Baher (an MCS engineer):

I’m happy to announce Microsoft’s strong position in Gartner’s 2010 MarketScope for E-Mail Systems report, in which Microsoft is the only vendor given the top rating of “Strong Positive”. Microsoft is uniquely positioned to deliver e-mail and calendaring technology to customers in the way that makes most sense to them – on-premise, in the cloud, or a combination of both. See the full report at http://www.gartner.com/technology/media-products/reprints/microsoft/vol10/article19b/article19b.html

-Source: http://blogs.technet.com/b/mbaher/archive/2010/08/31/exchange-is-on-top-gartner-s-2010-marketscope-for-e-mail-systems.aspx

From the report itself:

Microsoft released the fifth version of Exchange in November 2009. Exchange 2010, which is starting to increase its market penetration, promises improvements in storage efficiencies, high availability and disaster recovery, as well as more granular administration control and user self-service options. We expect adoption to follow the normal trajectory of previous Exchange releases, peaking at 50% by the end of 2012. The real action, however, is around Microsoft’s Exchange Online service, a subset of the large Business Productivity Online Standard Suite (BPOS) cloud collaboration offering. Throughout 2009 Microsoft added features to the service, and, more importantly, cut the price in half (to $5 per user per month), while quintupling the storage (to 25GB per user) — bringing it close to price and storage parity with Google GAPE. In November 2009, Microsoft said it had 1 million BPOS subscribers. We suspect that number has since doubled.

In 2H10 Microsoft will release the first service pack for Exchange 2010, with an emphasis on archiving, mobility, browser access, resiliency and management services. In 1H11 it will update Exchange Online with the 2010 version of Exchange, which is better suited to working in a multitenant environment. The current 2007 cloud release lacks some essential features, such as password synchronization, a health and performance console, multimailbox search and end-user password resetting. Furthermore, simple e-mail administration requests, such as to track a message, forward mail to an external mail box and disable ActiveSync require submission of a service request to the Exchange Online help desk, which creates operational inefficiencies for customers. Nonetheless, Microsoft continues to prosper in the e-mail market with both its on-premises and cloud options. Longer term, we will see the introduction of numerous hybrid e-mail models from Microsoft, with some mail boxes live in the cloud and others live on-premises. Google has emerged as its closest e-mail competitor, and it will remain so for the next few years.

Rating: Strong Positive

Like many of you, I was excited to see that Exchange 2010 SP1 was released earlier this week.  I downloaded and and ran it right away on my demo lab environment to be immediately disappointed with the following error:

Ok, so Exchange needs some prerequisites, no big deal, right?  I wish they were in the Microsoft Update queue, but hey its brand spanikin’ new so maybe they haven’t gotten to it yet.

I then clicked the link(s) to get the downloads and was greeted again by an error!

Ask my question on Bing… that’s rich.

So finally, I TYPED the links, one at a time to finally get to a page with hotfixes for download.  Yeah, I know typing is required from time to time, but don’t tease me with hyperlinks that don’t work Microsoft! 

Anywho, the links are a grab bag of hotfixes.  Some from the MSDN site, others from the Connect site.  Not very reassuring as many of these links are with a lesser SLA from Microsoft…

Once I installed the updates, Exchange 2010 SP1 did install successfully (it took about an hour).  Also worth noting, while it wants a reboot after each one, I just did them all followed by a single reboot at the end.

Finally, to save you the trouble of rounding up all the updates – here is a ZIP I made with them ready to go:

Exchange2010SP1HotFixes.zip

=========UPDATE=========

Looks like you can also get them from this link as well (one at a time): http://technet.microsoft.com/en-us/library/bb691354.aspx

Microsoft was quick to release this one – you can now try Exchange 2010 SP1 without the trouble of even installing it!

Checkout this pre-canned virtual machine of Exchange 2010 with SP1:

http://www.microsoft.com/downloads/details.aspx?FamilyID=53F7382A-3664-4DE3-8303-31E514D69F02&displaylang=en

You’ll need Hyper-V to use this machine, as Virtual PC doesn’t support x64 guests.

Exchange 2010 SP1 was published to TechNet, today!

Download the release here:

http://www.microsoft.com/downloads/details.aspx?FamilyID=50B32685-4356-49CC-8B37-D9C9D4EA3F5B&displaylang=en

If you’re interested to learn what it’s all about, read these previous posts:

Exchange 2010 introduces a nifty new feature called Shadow Redundancy. Being one of the bigger changes in this version, it is well documented and discussed.

This post is on Delayed SMTP Acknowledgement, which is a subset of this feature – not Shadow Redundancy as a whole.  However to fully grasp what I will be discussing, it’s important to understand a few basics about Shadow Redundancy to appreciate the purpose and spirit of Delayed SMTP Acknowledgement.

I encourage you to first travel to some of the above links, but most importantly, understand a few points:

Exchange 2007 sent messages to recipients through Transport Servers (Hub/Edge). If a Transport server were to fail with messages in its queue, these messages are lost.  Generally, this is only a small amount of data loss, but loss is loss, and we want to avoid that!

To mitigate this risk you could:

     A. Attempt to replay transaction logs (recover the database) from a separate disk; but this assumes the failure was limited to a single disk or database. More importantly the queue database uses circular logging by default so you cannot assume this approach will work anyway.

     B. Backup your Queue databases. This sounds simple on the surface, but the database is changing each time a message is sent and received. Restoring a queue database is likely irrelevant unless you had truly continuous backups.

     C. Leverage the Transport Dumpster. This feature is used for LCR/CCR environments only, but might resubmit messages in some scenarios.

Exchange 2010’s Shadow Redundancy sends the message down multiple SMTP paths (different Hub or Edge Transport servers) so that if the destination does not confirm successful delivery, another Transport server is able to submit the message. This means, we can sustain a failure of a Transport server/database, provided you have multiple servers.

Let’s take a look at a modified TechNet diagram to see an example:

Note that the Hub server sends the same message to two Edge servers. The lower edge server only submits the [shadow] message if it learns that the top edge server failed to do so.

Please understand I’m greatly simplifying this process. To fully understand all the steps involved, read the documentation linked above.

Ok, so now that we understand Shadow Redundancy, let’s ask the obvious question:

What about servers that do not support Shadow Redundancy?

A very valid concern, as this of course includes all previous versions of Exchange and most servers on the internet today.

Enter: “Delayed Acknowledgement”.

Delayed Acknowledgement is an attempt made by Exchange 2010 Transport servers to protect messages received from less sophisticated mail servers.

This is accomplished by making the sending server wait while the message is delivered behind the scenes of the 2010 environment.

Let’s explore this in more detail via the below illustration:

(Click for higher quality)

As you can see, this is a best effort attempt to protect email that does not support full Shadow Redundancy. This protection covers the scenario where your receiving Transport server fails after it accepts the message from the sending server, but before it delivers it to the user’s mailbox. If this failure were to happen, the original sending server would never get it’s acknowledgement and therefore it would be that server’s behavior to queue or resubmit the message.

See the below image to visualize this scenario:

(Click for higher quality)

So as you can see, while this isn’t as robust as true Shadow Redundancy, it does attempt to ensure messages are not lost when a Transport server fails.

Now that we see how it works, I’d like to point out some of the gotchas and configurable options:

As we saw in the first diagram, it’s possible for the sending server to think a message was delivered if the background submission takes more than 30 seconds. Because of this, messages that naturally take this long anyway (due to network conditions or latency, or whatever) will not be protected. Now, you can change 30 seconds to something higher, but you risk the sending server timing out on you.

There are additional reasons the Transport server might let the sending server “off the hook”, including:

· Submission queue in suspended state

· Message is in deferred state due to transient error

· Delivery queue is in retry or suspended state

· Delivery queue exceeds DelayedAckSkippingQueueLength value

· Message is routed to unreachable queue

So in closing, Delayed SMTP Acknowledgement is not as robust as it’s bigger brother Shadow Redundancy, but does a best-effort to protect messages in transport. You can configure the MaxAcknowledgementDelay via the Set-ReceiveConnector command.

You shouldn’t have to, but if you need to disable this feature, do so via:

Set-ReceiveConnector "ConnectorName" -MaxAcknowledgementDelay 0

See this sample scenario from TechNet:

Assume that all messages are typically delivered within 20 seconds in your environment, but due to performance requirements, you don’t want to delay acknowledgement more than 15 seconds for messages received from the Internet. After analyzing the message flow, you conclude that 95 percent of messages are delivered within the 15 second interval. This example configures the Receive connector from the Internet to delay acknowledgement for only 15 seconds. In this scenario, your environment provides shadow redundancy for 95 percent of messages received from the Internet.

Set-ReceiveConnector "From the Internet" -MaxAcknowledgementDelay 00:00:15.

References:

· Understanding Shadow Redundancy

· Configure Shadow Redundancy

· TechNet Webcast: Deploying and Managing Microsoft Exchange Server 2010 Transport Servers

=========UPDATE=========

New to SP1:

Shadow Redundancy Promotion

Exchange 2010 introduced the shadow redundancy feature to minimize the loss of any message during delivery after it enters the Exchange organization. Exchange Transport servers achieve this by using the shadow redundancy SMTP protocol extension.

However, in any organization Exchange Transport servers need to communicate with other third-party SMTP servers that may not support the shadow redundancy protocol. This is especially true with Edge Transport servers that handle message traffic with various hosts on the Internet. When receiving messages from hosts that don’t support shadow redundancy in Exchange 2010 RTM, Transport servers delay sending acknowledgement to incoming messages until they verify final delivery within the organization. However, when a specific threshold was reached, the Transport server issued an acknowledgement even if final delivery wasn’t verified. This presented a scenario where messages received from hosts that don’t support shadow redundancy can be lost in transit.

To address this issue, a new feature called shadow redundancy promotion is introduced in Exchange 2010 SP1. When faced with the scenario described above, instead of issuing an acknowledgment without delivery confirmation, a Transport server now routes the message to any other Transport server within the site so that the message is protected by shadow redundancy.

-Source: http://technet.microsoft.com/en-us/library/ff629378.aspx