The main reason this guidance was developed was due to customers requesting that CAS be placed in a perimeter network.  See http://msexchangeteam.com/archive/2009/10/21/452929.aspx for more information on why that is not supported.  This same guidance, as the article indicates, is true for the other server roles, with the exception of Edge Transport as it was designed from a usage scenario to only communicate from the perimeter network to the internal network via SMTP and to allow connections (LDAP and SMTP) from the internal network.

As for what customers can do - If their plan is to open up all the defined ports between the Exchange and AD servers in Site A and all Exchange and AD servers in Site B, then this would be supported since one could argue that there isn't really a "firewall" between the two sets of servers anymore.  They will be able to get support  after deploying like that. And if an issue comes and then, while helping them debug it, its found that there was network traffic blocking going on which breaks some aspect of Exchange communications with other server roles in the AD Sites, then they would be helped at least help them get into a supported state (without traffic limitations between the Exchange servers and DCs).

Yes this adds complexity.  Yes it could break things.  Yes customers have reasons to do it.

We’ve just published a new whitepaper on helping organizations choose Exchange as their voicemail system.  This whitepaper details the value that Exchange 2010's Unified Messaging capabilities offer to empower users, reduce cost and manage risk by replacing a previous voicemail system.

Here are the short and long URLs.  Please use the short one for most scenarios including tweeting or posting:

http://bit.ly/crRISt

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=70cfd1f1-fb01-4abb-a260-41b21ece5839

There are three versions (DOCX, PDF, XPS) available on the site for customers that haven’t quite made the switch to Office 2007/2010 yet.

Many thanks to Mark Sewell for this information.

Experience from the field has shown that the following best practices, hints and tips are useful in using JetStress to determine appropriate requirements and configuration. The download location for JetStress and other tools for Exchange 2007 can be found on this page: http://technet.microsoft.com/en-us/exchange/bb330849.aspx.

1. Follow the installed and online JetStress documentation carefully, paying particular attention to the storage subsystem requirements and configuration. Any design for carving out LUNs will need to balance the requirements for performance, recovery time and administrative costs (complexity). Use the Storage Requirements calculator provided:
• List of JetStress updates: http://msexchangeteam.com/archive/2007/07/05/445802.aspx
• Updated blog post: http://msexchangeteam.com/archive/2007/01/15/432207.aspx
• Updated download: http://msexchangeteam.com/files/12/attachments/entry438481.aspx
2. Storage Calculator assumes IOPS values for 80% disk capacity. Latest version makes this explicit. Performance will be less for stripes towards the spindle.
3. Ensure multipathing is in use, if at all possible, in preference to Active-Passive/Concurrent or static routes through the SAN fabric. Check that the multipath software has an active licence if required. Have the customer engage the storage vendor to ensure that there are no bottlenecks through the SAN fabric. There are different algorithms available for multipathing and the vendor can determine which is best for load balancing in the customer's environment.
4. The StorPort driver, introduced in Windows Server 2003, is much preferred over the older iSCSI and can deliver significantly better performance in hardware RAID and SAN environments.
5. Remove anti-virus software and all other non-essential applications, as far as is practical, so that you can take a baseline of JetStress performance. Then you can incrementally add back in required applications and see their effect on JetStress. It is not sufficient to simply disable AV software as the filter drivers will still be in place and could still block or delay file I/O. Management or monitoring software could cause a conflict. Hardware vendors who assist customers in setting up their environment often install such management or monitoring suites. The customer's own OS support team may also install these applications.
6. Also remove any third-party video drivers and verify that only the default VGA driver is installed (which can save a significant number of System PTEs) or use the /BASEVIDEO boot.ini switch.
7. JetStress threads are applied on a per storage group basis. The more storage groups you have, the more I/O you will have with a constant thread count. Use autotuning initially to arrive at an approximate thread count and then fine tune manually to hit the target IOPS for a given number of storage groups. Setting a fixed thread count is not going to provide an exact IOPS value but we are aiming for the actual IOPS to be within 5% of the target. Start with fewer threads and increase them over different tests, using the JetStress reports and Performance Monitor data to confirm that the server and storage are handling the target load. In this way you should arrive at an optimal thread count tuning that provides the best basis consistent JetStress results.
8. Need to view the report in conjunction with the Performance Monitor logs in order to determine that the I/O JetStress is generating is as expected (in terms of I/O sizes, ratios, burstiness, etc.). For example, performance graphs ramping up with time have been seen when using AMD Opteron servers. These turned out to be a missing boot.ini file /usepmtimer switch as per http://support.microsoft.com/kb/895980.

One addition the IO generation in JetStress is linked to the SGs due to the way the IO generation works in the tool. So if you need to add more threads this will generate more IO and spread it over the SGs. It does not mean that the tool gives you the amount of SGs you need! The more SGs you have the better in the Real World!