Exchange Advice Video – YOUR Advice

Published 11-30-2011 12:46 PM 1,430 Views

You hear from us pretty often. While we absolutely want you to read Ross’ blog and factor in transaction log space in your capacity planning or listen to Perry talk about how we’ve shifted to a services culture, we like hearing from you too. As part of our Exchange Ideas video series, we asked some folks in the Exchange community, “If you could give one piece of advice to other Exchange folks in 15 seconds or less, what would it be?”

In this Exchange Advice video, you are imparting your wisdom to the rest of the Exchange world and we think some of your recommendations are pretty fantastic.

Let us know what you’d like to talk about and share with the rest of the Exchange community. We’ll be around at upcoming events and would love to hear from you.


Ann Vu
Technical Product Manager

Not applicable

Here is my advice: stop trying to ram Exchange Online down people's throats.  If people want it, they will move to it.  You have a great team of developers who make the best product around.  Let the system engineers do their job.

Not applicable

My recomendation is to get sp2 out already:)

i want to start testing it , we have deployment in december....

Not applicable

Awaiting SP2 and address book segregation!

Not applicable

I wish there was an easy way to change internal AD Domain name!

Not applicable

Still waiting for UM en-gb voice mail preview - come on guys its been over a year since sp1, why oh why do we not have this - its a real shame, and reflects very poorly on you

Not applicable

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?

Not applicable

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.

Not applicable

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

Not applicable

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

Not applicable

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.

Not applicable

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:

"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...

Not applicable

@ 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.


Not applicable

@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.

Not applicable

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:

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

Not applicable
Version history
Last update:
‎Nov 30 2011 12:46 PM
Updated by: