Exchange Advice Video – YOUR Advice

SP2 is out

www.microsoft.com/.../details.aspx

Oh and one more thing I forgot to add:  S doesn't support exchange smtp traffic through load balancers ... so you need extra IP addresses assigned and more name spaces if you want to play this game:

technet.microsoft.com/.../gg476049.aspx

Again:  you can do it ... but it's a mess.  Why not just let SMTP load balance itself?

@Bernd Kruczek

Sorry Bernd, but ip affinity has nothing to do with the problem I'm referencing.  The problem is there are basically 3 ways to deploy a hardware loadbalancer:  Proxy mode, direct return path, and IP gateway.  By FAR, the most common way to deploy Load balancers in Exchange deployments is to use the proxy method, because it requires no special networking considerations.  However, when you run in proxy mode, a load balancer will replace the source IP in the header with it's own IP address.  This causes a lot of real world problems.  So let's go over what you'll run into if you did this.

Secnario:  Accounting has this "app-x" that needs to be able to relay mail externally and has no authentication options you can look up.   So let's go over each of the three models and see what happens:

1.  In the proxy model, you have to end up putting in the source IP of the load balancer because thats where HTS sees all the traffic coming from.  Now your app can relay externally ... but so can every client in your network ... and if you don't have an edge/hardware message hygiene so can every external IP that can hit the NAT.  In other words, you almost completely opened up your SMTP topology to everyone.  Not good.

2.  In the direct return path model, all initial traffic get redirected with the original IP header so the HTS replies directly and no masking problem occurs.  all better right?  Well maybe not.  See, most message hygiene solutions don't like a secondary IP address acknowledging traffic and will start denying the messages because of suspected spoofing.  This can _sometimes_ be bypassed and configured around ... but not all message hygene solutions support that.  Not only that, but now you're registering multiple PTR records and other routing annoyances to keep everything working.

3.  The final option is the most "bullet proof":  we setup a unique subnet for the HTS boxes and use the load balancer as the default gateway.  But now we are changing  our network layout .... for SMTP.  This falls in the category of "needlessly complex" and most people will avoid this design because of it.

Or we avoid having to choose between complex and incomplete and simply use MX records and multiple smarthosts ... which is the native resilience SMTP has always had.

Final note:  I've read the F5 white papers.  Here's a fun one for you:  notice they dont show you how to setup SMTP on the F5?  They have screenshot walk throughs and even templates in the UI for POP3, IMAP, RPC, OWA .... but not for SMTP.  There's a reason fore that.

@ Justin K.

Sorry Justin, that ist not correct what you are writing about Hardware Loadbalancing of HT Servers for incoming SMTP Traffic. On mostly all HLB you can configure IP Address handling, also known als Persistence / Affinity. Have a look at the whitepapers from BIG IP/F5 and Kemp Technologies.

Bernd

Remember that your product, while deployed by techies, is used every day by average non-technical users. Microsoft, a company chalk full of IT people, seems to forget that the people using their products every day won't understand that they have to jump through hoops or pat their head and rub their tummy to get the product to do what they want. It should just work, and work right the first time.

An example of what I mean is this post:

blogs.technet.com/.../prevent-archiving-of-items-in-a-default-folder-in-exchange-2010.aspx

"The workaround is to have users apply the Personal never move to archive personal tag (displayed as Never under Archive Policy in Outlook/OWA) to a default folder."

Really guys... do you expect doctors, lawyers, accountants, and non-technical people in general to fully understand that request from their IT department? Even if you get some percentage of them to do it, you won't get all of them to do it, and the IT department will either feel the brunt of their furstrations or not deploy that particular part of the product altogether. This type of "just have your users do technical step X" seems to pop up over and over again, and it really isn't realistic to expect 100% (or even 50%) our end users to be able to do it.

So please.... the next time you introduce some new feature, or you come up with some "workaround" for a problem, remember who the real customer base is that will be asked to use/implement it. We simply can't turn non-technical people into techies...

Make a great fat client for managing Exchange 2010 without having to switch between multiple, slower running, Powershell (the new Microsoft Java) based management tools.  

We are a single site, single domain, 500 user system.  We are a small ($ 100 million a year) healthcare business and Exchange is just one of many applications/platforms I have to support.  (Previous experiences include Exchange 5.5, 2000, and 2003).  The main reason we switched to Exchange 2010 was the increase in performance on modern hardware and OSs.

Get sp2 out to your user base for testing.  That way you might be able to avoid the RU screw-ups.

Any hope of the PST Capture (mentioned in July) tool being released in CY2011?

OK, I have a couple general Tips for the Exchange builders out there:

1.  Resist the temptation to use your load balancers for Hub Transport roles, instead leverage the native resilience available with multiple destination IPs and/or MX records.  Because most Load Balancers are deployed in a Proxy configuration they re-write the IP headers and will wreck havoc on your receive connectors and anti-spam engines (very difficult to isolate traffic when it all appears to come from a single IP).

2.  Even if you are planning to publish all services to a single FQDN, go ahead and "reserve" generic names for HTTP, SMTP, and RPC services in your new UCC/SAN certificate request.  Companies grow and change, and Exchange may need to grow and change with it.  Being able to adapt to new TLS requirements, add a new OWA site for FBA while keeping the original default at IWA, and a host of other "tweaks" could force you to go back to the "re-provisioning your certificate" well much earlier than you'd like (and not all providers let you re-provision for free).

3.  PowerShell.  PowerShell.  PowerShell.

your last blog post in UM was on 13 Jun 2011, really ???

are your dropping UM ? or is it going to be absorbed in to Lync?