I wanted to post a follow-up to Cathy's documentation announcement with a bit more information on RPC Client Throttling.

With the release of Microsoft Exchange Server 2007, a new feature known as RPC Client Throttling is available to administrators to help manage the end-user performance experience. RPC Client Throttling was introduced to help prevent client applications from sending too many RPC operations per second to the Exchange server which could decrease overall server performance. These client applications include desktop search engines searching through every object inside a user's mailbox, custom applications written to manipulate data that is located in Exchange mailboxes, enterprise-class e-mail archiving products, or CRM enabled mailboxes with e-mail auto-tagging enabled. Client throttling allows Exchange to identify and help prevent server monopolization by a few users. When a client is identified by the Exchange server as causing a disproportionate effect on the server, the server will send a "back-off" request to the client to reduce the performance effect on the server. To learn more about RPC Client Throttling, see Understanding Exchange 2007 Client Throttling.

http://go.microsoft.com/fwlink/?LinkId=116695

- Tom Di Nardo

Share this post :

The Exchange Server documentation team is pleased to announce updates to the Exchange Server content.

To see what content has changed for Exchange Server 2007 with Service Pack 1, take a look at Exchange Server 2007 Documentation Updates.

To see what content has changed for Exchange Server Analyzer, take a look at Exchange Server Analyzer Topic Updates.

In particular, we would like to highlight the following new or updated topics:

• Exploring Windows Mobile 6.1 and Exchange ActiveSync Mailbox Policies: On April 1, 2008, Microsoft announced the release of Windows Mobile 6.1. All the new policy settings in Exchange 2007 SP1 are fully supported by Windows Mobile 6.1. This article summarizes the various enhancements to Exchange ActiveSync in Exchange 2007 SP1, and also gives you information about the supported policy settings for the different versions of the Windows Mobile operating system.
• Understanding Client Throttling: RPC Client Throttling is a new feature in Exchange Server 2007. It helps to prevent client applications from affecting overall server performance, allowing administrators to better manage the end-user performance experience
• White Paper: Outlook Anywhere Scalability with Outlook 2007, Outlook 2003, and Exchange 2007: This white paper provides an analysis of the scalability of the Outlook Anywhere feature for Microsoft Exchange Server 2007, Microsoft Office Outlook 2007, and Microsoft Office Outlook 2003, and an analysis of expected client network traffic between enterprise e-mail clients and Exchange Server 2007 SP1 in non-Outlook Anywhere scenarios.

You can see these articles and other Exchange Server documentation content in the Microsoft Exchange Server TechCenter.

The following downloads are also available for SP1 content:

• Microsoft Exchange Server 2007 Service Pack 1 Help
• Microsoft Exchange Server 2007 Service Pack 1 Shell Help

BTW, if you haven't noticed, all our topics in the Exchange Library now have a "Topic Last Modified" date at the top of the topic. And, if you wonder which topics apply to Exchange Server 2007 with Service Pack 1, we now have an "Applies to" tag for Exchange 2007 content.

You can now annotate topics in the Exchange Server 2003 documentation. Scroll to the Community Content section at the end of any topic in the Exchange 2003 Library, and click Add Community Comment. You'll be asked to sign in with your Windows Live ID and to register as a participant. Then, share your insights with the Exchange community.

- Cathy Anderson, Content Release Manager, Exchange User Documentation

Share this post :

Hi! This is my first post to the Exchange Team Blog - hope this is of use! My name is Robert Gillies, and I'm a Senior Consultant in the Federal Civilian Practice of Microsoft Consulting Services. One of my recent projects for one of my customers had to do with automating the install of Exchange 2007 SP1. I went to TechReady (our Microsoft "internal TechEd") in the fall and didn't find anyone who had a good demo script on how to do this type of scripted deployment that could be used for an enterprise customer. That made me think that maybe I should do something that could be presented to help other people that might just need a good starting point for their own installs. No matter how big your organization is, if you want to build Exchange 2007 labs, this can help you!

So - I wrote a script for my customer and trimmed it down for a presentation. I presented this script at the spring TechReady in January, and then April 8th I presented it at INTERACT2008 (http://www.interact08.com). I'm currently scheduled to present this at TechEd Orlando in June as well. Included below is, the script and the CSV files used by the script, and the remainder of this blog entry is a discussion/description of how to configure your own lab so that you can run these scripts on your own.

The goal of this exercise was to have a single script that could be run on a given machine, and based on the server naming convention install the appropriate roles and possibly make some configuration decisions. The customer I am working with for this has a very well defined server naming convention which makes this possible. One possibility for a change would be to have a CSV file that would define the Exchange roles based on what the installation team put into the file as opposed to being strictly name based.

Please note: below procedures and scripts were tested only in lab environments! This script is not officially supported by Microsoft.

Server Naming Convention

The server naming convention that was used for this lab/demo is as follows:

• First three letters of the machine name defines the role or domain that the server will fill. For this lab, I used "lab" for this role.
• Second three letter define the location of the servers. Since I live in Huntsville, AL and the local airport three letter code is HSV, I used "hsv" on all servers.
• A single dash is the seventh character.
• The next two or three letters define a server functionality. For this lab, the following two and three character codes are used:
  • "dc" is used to denote a domain controller
  • "xet" is used to denote an Exchange 2007 Edge Transport Server
  • "xht" is used to denote an Exchange 2007 Hub Transport Server
  • "xcs" is used to denote an Exchange 2007 Client Access Server
  • "xcl" is used to denote an Exchange cluster or cluster node
  • "xmb" is used to denote and Exchange Mailbox Server (or the Clustered Mailbox Server - CMS - that represents an Exchange Mailbox Server in a CCR cluster)
  • "xsc" is used to denote an Exchange SCR target server
• The next three characters are a numeric count of servers (remember that we designed for an enterprise deployment - but we probably could have gone with two digits here)
• The next two characters are only used on cluster nodes
  • "n1" to denote the first node
  • "n2" to denote the second node
  • "r1" and "r2" are used in the Exchange 2007 Service Pack 1 Enable-ContinuousReplicationHostName implementation (used to enable replication on a secondary network)

Using this naming convention, that will give us the following server names in our lab:

• labhsv-dc001 (The domain controller, global catalog and DNS server)
• labhsv-xcs001 (CAS)
• labhsv-xbh001 (Hub Transport)
• labhsv-xet001 (Edge Transport)
• labhsv-xsc001 (SCR Target)
• labhsv-xmb001 (Clustered Mailbox Server
  • labhsv-xcl001 (Cluster name)
    • labhsv-xcl001n1 (Cluster node 1)
    • labhsv-xcl001n2 (Cluster node 2)

Lab Diagram

The lab that we will be creating can be represented using this diagram:

Lab Configuration

Now I'll just list out what I did to build these servers so that you can build your own!

- Ensure that all machines in the lab are connected to the same network. If you want to update these machines to the latest patch levels, this network should connect to the Internet.

- Put a base OS load on all servers. My scripts all assume Windows Server 2003 32-bit, but if your favorite virtualization platform supports 64-bit guest OS, then you are welcome to use that. I just got Hyper-V RC0 and have started playing with that, so maybe a future blog entry will discuss the nuances of deploying this lab on Windows Server 2003 SP2 on Hyper-V RC0, just as I'm sure that deploying on Windows Server 2008 is in the future!

• All servers must have .NET Framework 2.0 installed.
• All servers must have MMC installed.
• All servers must have Windows PowerShell 1.0 installed.

- Disable the Scalable Networking Feature Pack (http://msexchangeteam.com/archive/2008/03/12/448421.aspx)

- DCPromo - I typically allow DNS to be installed by DCPromo process for these simple labs where I'm only going to have a single DC.

- Add reverse lookup zone. This is probably not strictly required - AD works just fine without this, I just like to have it.

- Join all machines to domain except for Edge Transport - remember that Edge is not supported as a member of the corporate forest. Edge also isn't supported in the corporate intranet, but we're just doing a demo here, so we'll let that one slide.

- Update all machines via Windows Update. My scripts all assume Windows Server 2003 Service Pack 2 and all required updates.

- Make sure that the site configuration is set such that our local subnet defines the site. This is most important if you are going to have an expanded lab with multiple sites/subnets.

- Raise the domain functional level to Windows Server 2003 level.

- Raise the forest functional level to Windows Server 2003 level.

- Create Cluster Service Account user (ClusAdmin). Grant user local admin rights on both cluster nodes.

- Log in as the Enterprise Administrator (to ensure Schema Admins permissions. Insert the Exchange 2007 SP1 DVD in the domain controller. Execute the command from the DVD:

Setup.com /PrepareAD /OrganizationName:TechReady

- While still logged in as the Enterprise Administrator, execute the following command from the DVD:

Setup.com /PrepareDomain

- Create Exchange Administrator user (ExchAdmin), set user to be a domain admin (LAB SETTING - this allows the user to be local admin on all machines so he can install Exchange - this user needs to be a local admin on all machines and that can be accomplished in ways other than making this user a domain admin if needed). Remove user from "domain users" group. Add this user to the "Exchange Organization Administrators" group.

- Install IIS on all required servers (including labhsv-xht001, labhsv-xcs001, labhsv-xcl001n1, labhsv-xcl001n2 and labhsv-xsc001). NOTE: No SMTP or NNTP!!!

- Set the domain name on the Edge server to "techready.lab" to match the internal name of the lab.

- Register the IP address of the Edge server in the internal DNS. (DNS is set to secure update only, and this machine is not a member of the domain).

- Install ADAM on the Edge Transport server.

- Network configuration on the CCR nodes:

• Name the first network "Public Network"
  • This network has DNS and default gateway defined
• Add the second network to both CCR nodes.
  • Second network adapter should be a "private" network - does not connect to the Internet.
  • Name the second network "Management Network"
  • This network does not have DNS servers or default gateway configured
  • This network does not register itself with DNS
  • This network is set to "Disable NetBIOS over TCP/IP"
  • Manually configure the network on the second NIC as follows:

Node1

Address: 10.1.1.101
Mask: 255.255.255.0

Node2

Address: 10.1.1.102
Mask: 255.255.255.0

• Disable strict name checking as per http://support.microsoft.com/kb/281308
• In the file c:\windows\system32\drivers\etc\hosts, on both cluster nodes, add the following lines:

10.1.1.1 labhsv-xcl001r1
10.1.1.2 labhsv-xcl001r2

NOTE: That says "R1" and "R2" on the end, not "N1" and "N2". This is for the "Enable-ContinuousReplicationHostName" cmdlet where we need unique names for cluster resources to force our continuous replication across our management network.

• Ensure that the connection ordering is correct. In the "network connections" window, go to the "Advanced" menu, "Advanced Settings" selection. Move "Public Network" to the top, "Management Network" to the second. (Your "most public" network should be at the top, "least public" at the bottom.)

Definition of CSV Files

PowerShell provides a fairly simple way to read data from CSV files. When reading a CSV file in PowerShell, an object is created that represents the file. This object can be "looped through" to examine each line of data, with the first line defining attributes on the object that can be read. For instance, I could read the ScriptSettings.csv file into an object called $ScriptSettings, and then access the product key defined in that file by the variable $ScriptSettings.ProductKey based on the definitions laid out below.

Each of these files is detailed below by describing what each element is. Actual format, as CSV files, is that the descriptive name of each element is in the first line of the file, with the various attributes to be given to the install script on each line below. Take care to ensure that the right attributes line up in the same order as the "header line" in the first line of the file.

ScriptSettings.csv:

Descriptive Name (from file)	Description	Example
ProductKey	This is a product key for Exchange Server 2007 that will be applied to each and every server in the environment	12345-12345-12345-12345-12345
GCServer	This is the "short name" of a single GC server that will be used on all of the commands in the script that write to the Active Directory.  This will ensure that when we have writes to the AD followed quickly by a read that AD replication delays will not affect execution of our script.	labhsv-dc001
FirstPFServer	This is the "short name" of the first hub server installed in the organization.  Could be used in the future to facilitate replication of public folders.	labhsv-xhb001

FSW.csv:

Descriptive Name (from file)	Description	Example
HTName	This is the name of the hub transport server where the FSW shares will be created.  This was added to allow for FSW creation on two different HT servers in two different datacenters with the same data file.	labhsv-xhb001
CMSName	This is the name (not necessarily the FQDN) of the CMS (Clustered Mailbox Server) for which given FSW (File Share Witness) is being created.	labhsv-xmb001
Share	This is the share name that will be created on the HT server and later utilized by the CMS (the specific CMS in this row) as the FSW.	fsw-labhsv-xmb001
ClusterAdmin	This is the account (in domain\account format) that will be used by the cluster utilized by the CMS in this row as the cluster service account.	clus.admin

ClusterInfo.csv:

Descriptive Name (from file)	Description	Example
CMSName	This is the name (not necessarily the FQDN) of the CMS (Clustered Mailbox Server) for which given FSW (File Share Witness) is being created.	labhsv-xmb001
ClusterAdmin	This is the account (in domain\account format) that will be used by the cluster utilized by the CMS in this row as the cluster service account.	clus.admin
ClusterAddr	This is the TCP/IP address of the cluster represented by the CMSName that defines this row.	192.168.0.182
CMSAddr	This is the TCP/IP address of the CMS that defines this row.	192.168.0.183
Node1ReplName	This is a machine name used by the Exchange cluster to define replication on a secondary network (rather than the primary client-access network).  This name is specific to the first cluster node, and should be the same as the cluster node with the "n" node designator replaced with "r".  For the example here, the cluster node would be labhsv-xcl001n1.	labhsv-xcl001r1
Node1ReplAddr	This is the TCP/IP address of the Node1ReplName on this row.	10.1.1.1
Node2ReplName	This is a machine name used by the Exchange cluster to define replication on a secondary network (rather than the primary client-access network).  This name is specific to the second cluster node, and should be the same as the cluster node with the "n" node designator replaced with "r".  For the example here, the cluster node would be labhsv-xcl001n1.	labhsv-xcl001r2
Node2ReplAddr	This is the TCP/IP address of the Node2ReplName on this row.	10.1.1.2

SCRInfo.csv:

Descriptive Name (from file)	Description	Example
SCRName	This is the name (not necessarily the FQDN) of the SCR target server.	labhsv-xsc001
SourceCMS	This is the name (not necessarily the FQDN) of the CMS that will act as the source for the SCR replication targeting this SCR target server.	labhsv-xmb001

Note that if the lab is built with the machine names and IP addressed defined in the diagram above, the included CSV files will work without changing.

Also note that during execution of the script, it is assumed that the CSV files will be located in the same directory as the script itself.

Execution of the Script

You should deploy this lab in the following order:

• labhsv-xet001 (not really required in any order)
• labhsv-xhb001 (required before the cluster nodes)
• labhsv-xcs001 (in production you need CAS before Mailbox roles)
• labhsv-xcl001n1 (required before node 2 and SCR)
• labhsv-xcl001n2
• labhsv-xsc001

On each server where Exchange will be deployed, follow these steps:

• Mount your Exchange 2007 SP1 CD
  • Note that SP1 is required for the Enable-ContinuousReplicationHostName cmdlet
• Open Windows PowerShell
• Change directory to where you stored the script and CSV files
• Execute the following command to allow scripts to run:
  • Set-ExecutionPolicy RemoteSigned
• Execute the script with a command line similar to the following:
  • ./E2K7Install.ps1 installdir:d:

After all that, if you are still with me, you are probably wondering where to get the script and those CSV files? Right here:

http://msexchangeteam.com/files/12/attachments/entry448823.aspx

Finally, I hope you found this useful. If for whatever reason, you create a tear down Exchange 2007 labs or demos often, this should save you quite a bit of time in the long run!

- Robert Gillies

Share this post :

It's been a while since we last blogged about this Outlook feature that most users feel is an error, the RPC Dialog Box. You might get a popup error that will say:

Outlook is retrieving data from the Microsoft Exchange Server <Server name>. You can cancel the request or minimize this message to the Windows taskbar until Outlook closes the message automatically.

There are many potential causes or combinations of areas that need to be addressed to properly diagnose and correct this issue. First, please keep in mind that the RPC Dialog Box is something that works off a timer. We have 5 to 8 seconds (depending upon Outlook version, 5 seconds in Outlook 2002 and 8 seconds in Outlook 2003 and 2007) to get an RPC request on the network, to the server, the server to respond, get its response on the network and the client to receive. With that being said, I call this a 10,000 foot problem. There is not necessarily a specific event generated within the application that you can just point your finger to. The idea behind troubleshooting these types of issues is you need to build a funnel to rule out what is not causing them. It's basically a process of elimination. The troubleshooting steps that I have outlined below are for what I would call a "remote client". This does not necessarily mean remote clients are connected via a VPN, it just means that you may be in another building, campus location, or on a different network segment. The affected clients are not "local" to the Exchange server.

Typically if the RPC Dialog Box affected all users in your environment, I would also be looking a data from the server, along with the network and the client configuration. In troubleshooting a remote client scenario, it has already been pre-determined that "local" users are not impacted, and it is only users at a separate or external location. I can then narrow the 10,000 foot problem to let's say 5,000 feet.

First I want to know about connectivity and the topology itself. There are some simple utilities that I run to acquire the information needed:

1. From the Outlook client workstation use Tracert to determine how many hops from the impacted Outlook Client to the Exchange Server? What devices do the IP Addresses map to?

258495 XCLN: Troubleshooting Client Connectivity Issues Using Command Line Utilities
http://support.microsoft.com/default.aspx?scid=kb;EN-US;258495

I want to know what each networking device is relative to the IP's that are returned. Are any of these devices firewalls and do they have a "Session time out" setting similar to our value for TCPKeepAliveTime? Our defaults are 2 hours as documented in:

324270 How to harden the TCP/IP stack against denial of service attacks in Windows Server 2003
http://support.microsoft.com/default.aspx?scid=kb;EN-US;324270

2. From the Outlook client workstation test for a Black Hole Router by issuing a ping command with a packet size:

Ping <exchange server_name> or <Exchange server ip address> -f -l 1472

By "pinging" with a packet size, I'm looking to see if there are any segments that have smaller MTU sizes configured. The return value if this is occurring would come back as:

Packet needs to be fragmented but DF set

You can find more information in the Knowledge Base:

314825 How to Troubleshoot Black Hole Router Issues
http://support.microsoft.com/default.aspx?scid=kb;EN-US;314825

3. Does your Network include a WAN Accelerator? Can you bypass the device, or (depending on vendor) either exclude MAPI or RPC traffic? WAN Accelerators generally come in 2 flavors:

Compress the compressed, or pattern matching. RPC is already compressed and the re-compressed data does not necessarily have any large performance gains based on independent testing. You can read more on the web on independent testing that has been done. I've also seen products that that will keep Outlook sessions open for users. If we exceed limits on sessions that are set in Exchange automatically, you will see event IDs 9646 on the server. These events are another subject that I'll cover in a later blog post to follow.

4. Are the remote users using Outlook in Cached Exchange Mode? If not, can we place the user in Cached Mode as a troubleshooting step? Yes, this will download to ost the first time and may take a few minutes however this sort of scenario is what cached mode is designed for.

5. Network Card. Configurations and settings need to be confirmed. These steps are to be taken on the affected workstation. (Note: these instructions are for how to obtain the settings in Windows XP, but these settings should be checked for any OS):

• Are there any External DNS Servers listed in the Primary or Secondary DNS Entries?
• Is your Local Area Connection at the top of the binding order? Start > Control Panel > Network Connections > Advanced > Advanced Settings - Make sure the in