Robert's Rules of Exchange: Table of Blog Contents
Published Nov 02 2010 10:09 AM 4,685 Views

Overview

This post will be kept up to date as a sort of "Table of Contents" for the Robert's Rules of Exchange series. As each post is published, the list will be updated with the title and link to that post. Each post in the series will also have a link to this "Table of Blogs" to make it easy for you to find and navigate between posts.

The list in The Ideas section will also be updated as appropriate.

The Blog Posts

The following articles have been completed and are available at the link.

  1. The Scenario
  2. Namespace Planning
  3. Storage Planning and Testing (idea from John Rodriguez)
  4. Multi-Role Servers 

The Ideas

Note that these ideas for posts could change over time. Any one of these single line items could become two or more posts, depending on how long they end up being. And if you know me, you know I can get a bit, well, verbose at times. I also reserve the right to change the order of these posts as they are written. For instance, the JetStress Testing post may be published out of order because I'm waiting on another document to be published first - I will be referencing this other document, and need it to be public before I write anything on the subject.

I fully expect that I will get a good set of ideas from readers, and I will add those to this list when I feel like I can add something to the discussion about a topic. In other words, "when I want to write about something" â?? just because you have an idea doesn't mean I will write about it! No promises!!

  • Robert's Rules of Exchange: The Exchange Profile Analyzer
  • Robert's Rules of Exchange: JetStress Testing
  • Robert's Rules of Exchange: Installation of Exchange
  • Robert's Rules of Exchange: LoadGen Testing
  • Robert's Rules of Exchange: Certificates
  • Robert's Rules of Exchange: CAS for Internet Facing Site
  • Robert's Rules of Exchange: CAS for Proxy Site
  • Robert's Rules of Exchange: CAS for Redirect Site
  • Robert's Rules of Exchange: CAS for Co-Existence
  • Robert's Rules of Exchange: Autodiscover
  • Robert's Rules of Exchange: OAB Download
  • Robert's Rules of Exchange: Availability Service
  • Robert's Rules of Exchange: EdgeSync
  • Robert's Rules of Exchange: File Level Anti-Virus
  • Robert's Rules of Exchange: Exchange Anti-Virus
  • Robert's Rules of Exchange: Message Hygiene / Anti-Spam
  • Robert's Rules of Exchange: Reverse Proxy
  • Robert's Rules of Exchange: Outlook Anywhere
  • Robert's Rules of Exchange: Exchange ActiveSync
  • Robert's Rules of Exchange: Database Availability Group - The Quorum
  • Robert's Rules of Exchange: Creation of a DAG
  • Robert's Rules of Exchange: DAG Networks
  • Robert's Rules of Exchange: DAG Databases
  • Robert's Rules of Exchange: DAG Activation - Non-DAC Mode
  • Robert's Rules of Exchange: DAG Activation - DAC Mode
  • Robert's Rules of Exchange: Client Access During Datacenter Failures
  • Robert's Rules of Exchange: Journaling
  • Robert's Rules of Exchange: Domain Secure
  • Robert's Rules of Exchange: GALSync
  • Robert's Rules of Exchange: Federation with IOREPL
  • Robert's Rules of Exchange: Federation (Exchange 2007 Style)
  • Robert's Rules of Exchange: Federation with the Microsoft Federation Gateway
  • Robert's Rules of Exchange: Backup and Restore with DPM
  • Robert's Rules of Exchange: RBAC Planning (idea from John Rodriguez)
  • Robert's Rules of Exchange: Regulatory Compliance (idea from John Rodriguez)

Robert Gillies

14 Comments
Not applicable
Good idea!
I hope we can see articles about system's usability by users and not just server-side and infrastructure. My first idea on general scenario (and common problem from the beginning...)
I can create a company wide Contact database using public folder. Noow this Contatct database need to be syncronized with PDA using ActiveSync. Also in outlook when I have a high number of contact i need tofilter them by company and address type (the common question is : i need a mail address to John Doe of the XYZ company.)

See you
LSo
Not applicable
Hi,

Good idea. Please add to the List Archive Database on other Database as the Live Data and Singelitem Recovery procedure.

Regards Steven
Not applicable
Good ideas, gentlemen.  I'll add those to my list.
Not applicable
Good idea...!!!
Can you add following  points:
1. Network bandiwdth planning for exchange services. (Internal WAN for site connectivity and internet badwidth for webmail access)
2. Check-list before starting implementation
3. DR setup (which may include DAG, CAS URLs etc)
4. Anti-spam solutions
5. Server placements in Firewall network infrastructure
6. Server recovery procedure for each role (considering server hardware, OS failure, how to create a same server)

Thanks....!!!
Not applicable
@Sachin_G - Great list, and some great ideas.  I will say that #3 is already planned to be covered completely with high availability and site resilience configuration options.  #4 I will also cover as far as native Exchange capabilities and Forefront Protection for Exchange capabilities (probably won't go too much into third party spam, but might be able to do something with Forefront Online Protection for Exchange to throw some "cloud" into the mix).

Could you be a bit more explicit around what you are looking for in #5?  Exchange expects Edge in a DMZ / Perimeter Network, and all other servers to be "behind the firewall".  What else do you want covered there?
Not applicable
Hi Robert,

Just wanted to say that I'm looking forward to the rest of your posts!

I see you've mentioned Exchange Profile Analyser, can I suggest adding details on how to calculate the current user mail profile (IOPS) using perfmon. I've just gone through the process, and it would have been nice to have some clear guidance on how to do it.
Not applicable
@oneill3 - Good idea.  I am planning a blog around the profile analyzer, and that would be a good addition.  Thanks for the note!
Not applicable
Thanks Robert for considering my points....
Regarding point 5 , In exchange 2003 we had front-end server which used to be in DMZ zone. Incase of exchange 2010, we can place CAS server in inside zone and use reverse proxy (ISA or Apache) to enable web-access to internet users. However if any organization does not have reverse proxy then is it good idea to open port 443 from outside network (internet) to the CAS server which is in inside zone of the firewall (which is most secured and with other production servers). Any special considerations we need to keep in mind during architecting the email solution with exchange 2010.
Else I am ok with your response on point no.5.
Thanks.....!!!
Not applicable
@Sachin_G - I think I can answer the question here.  Since ISA came out, we haven't supported putting FE or CAS in the perimeter network / DMZ.  Our recommendation is to put ISA or similar (some reverse proxy) in the DMZ to examine the traffic and pre-authenticate

users.  But, we do have customers that deploy without the reverse proxy.  In fact, if you look at how Microsoft deploys Exchange 2010 today you'll see that we don't have reverse proxy in our deployment...  (http://technet.microsoft.com/en-us/library/ff829232.aspx#_Toc266439883)

Not applicable
Thanks for providing the link....
Hardware Load-balancer definately has some advantages and provides the flexibility to configure load-balancing methods as per requirment. Infact as per my knowledge some load-balancers act as Reverse Proxy...!!!
Is Microsoft IT using load-balancer's revers proxy functionality by eliminating ISA ?

But for mediam size organizations CAS NLB is a cost-effective option.

As per older practice, all web facing servers needs to be there in DMZ. Now we are bringing the CAS server in inside zone, the concern is we are bringing the internet user's request directly to the inside zone of the firewall. In case of ISA reverse proxy the internet user's session is terminated on ISA and ISA generates seperate request to actual server. Incase of any attact Reverse proxy goes down (with limiting access to internet users) but CAS server continues to service internet users without any issue.

Any Architecture always has plus and minus points....
Not applicable
Looks interesting as we are just completing our 2007 migration and are planning 2010.
One thing I note is generally there is a lack of UM material.
I realise you are virtualising everything in your lab, and UM is not supported virtualised, but UM looks like a useful role that it would be nice to have covered.
Also Sachin_G request 6 seems reasonable, not quite covered in DPM I think. Additionally the Archive, folder/databases that are new to 2010, not sure if that is what Steve is talking about.
Not applicable
@Sashin_G - While Windows NLB does have limitations, I know that we have customers using it.  I want to show that here, and will do so as we get to those sections.  And as you say, any architecture has pros and cons.  I am deploying my lab using TMG to show that use.  As with all decision points, thought needs to be put into whether you utilize a reverse proxy or not.

@Adrian Pettitt - I will certainly expand my thinking around what to do with the DPM entry, thinking more around bare metal restores or other DR scenarios.  I think that what you're asking for around archive mailboxes and folders and such will be covered in the same entry as what @Steve mentioned above.

As with any of the blog entries, if I miss some technologies or questions, let me know.  We'll surely either have some "dogs and cats" entries (rounding up the things we missed), or I can answer in the comments.
Not applicable
Thanks Robert, eagerly waiting for your posts, can you also tell us whether or not you have considered #1 from Sachin_G's list ?
Not applicable
@MuzDaf - I think that bandwidth planning has been well documented.  Look here: http://technet.microsoft.com/en-us/library/cc745931.aspx

By combining the client network requirements in that document with the replication network requirements in Ross' Exchange 2010 Mailbox Role Requirements Calculator, and understanding your SMTP traffic inbound and outbound, you should be able to figure all of your Exchange-related bandwidth requirements.
Version history
Last update:
‎Jul 01 2019 03:55 PM
Updated by: