Вы находитесь на странице: 1из 24

http://technet.microsoft.com/en-us/library/cc745931.

aspx

Company Network Requirements


Microsoft Online Services is available to your company over your Internet connection. It may replace applications
that operated within your company network. The traffic that previously was confined to your network will now
travel between your company and the Internet. You must ensure that your companys connection to the Internet is
configured correctly and that it has enough capacity to handle the network traffic.

Network Configuration
If your company protects your connection to the Internet with a firewall or proxy server, refer to the table below to
see the ports used by Microsoft Online Services.

Ports Applications

TCP 443 Web Portals (Microsoft Online Services Administration Center and My
Company Portal)

Microsoft SharePoint Online

Microsoft Online Services Sign In application

Microsoft Office Outlook 2003, Office Outlook 2007 and Office Outlook
Web Access (OWA)

TCP 25 Mail routing

TCP 80 and 443 The Microsoft Online Services Directory Synchronization tool uses port 443 for
all outbound synchronization connections in Microsoft Online Services.
Depending on the option selected during the migration process, Microsoft
Online Services Migration Tools can use either port 80 or port 443 when
connecting to an internal or external Exchange messaging server for mailbox
migration. All e-mail that is being migrated to Microsoft Online Services is
sent over port 443 through an HTTPS connection.

TCP 80 and 443 minimum; Microsoft Office Live Meeting


UDP ports and ports 8057
and 3478 recommended for
audio and video

The computers on your network must be able to successfully perform standard Internet DNS lookups. If your
computers can reach standard Internet sites, your network meets this requirement.

Note

If your company uses an authentication proxy, you must add microsoftonline.com to your proxys
exceptions list in order to work with Microsoft Online Services.
Microsoft Office Outlook 2003 can be used with Microsoft Online Services. However, you must install the
Microsoft Exchange Online Connector for Office Outlook 2003 to use the free/busy information and offline
address book (OAB) features with Office Outlook 2003. For more information, see About Microsoft
Exchange Online Connector for Office Outlook 2003.

Bandwidth Considerations
Microsoft Online Services currently offers three online services: Microsoft Exchange Online, SharePoint Online, and
Office Live Meeting . Each of the services has its own bandwidth requirements.

There are many variables to consider when estimating network traffic. Some of these variables are:

The services that your company has subscribed to

The number of client computers in use at one time

The type of task each client computer is performing

The performance of your Internet browser software

The capacity of the network connections and network segments associated with each client computer

Your companys network topology and the capacity of the various pieces of network hardware

The following sections provide guidelines for estimating the bandwidth usage of each service. Detailed
specifications are beyond the scope of this topic. For more detailed information about estimating the network traffic
for each online service, see the links to other documentation in each of the following sections.

Exchange Online
The information in this section will help you begin to estimate the network bandwidth that your company will need
to run Exchange Online.

The estimates provided in this section are based on the following assumptions:

The average message size is 50 kilobytes (KB).

Every message delivered is read.

Half of all incoming mail is deleted.

OWA clients log on and log off two times per day.

Note

Office Outlook 2007 log on and log off costs were not evaluated because company e-mail users generally stay
logged on for days at a time.

The following table lists the message usage for light, medium, heavy, and very heavy e-mail users. This
information will be used later in this section to estimate network traffic.
Activity Light Medium Heavy Very heavy

Messages sent per day 5 10 20 30

Messages received per day 20 40 80 120

Average message size 50 KB 50 KB 50 KB 50 KB

Messages read per day 20 40 80 120

Messages deleted per day 10 20 40 60

OWA log on and log off per day 2 2 2 2

The following table shows the amount of network traffic generated by each type of user in each e-mail client. All
values are in kilobytes (KB) per day per user.

E-Mail Client Light Medium Heavy Very Heavy

Office Outlook 2007 1,300 KB/day/user 2,600 KB/day/user 5,200 KB/day/user 7,800 KB/day/user

OWA 6,190 KB/day/user 12,220 KB/day/user 24,270 KB/day/user 36,330 KB/day/user

To apply this information to your company, consider the following examples. Each example assumes that the users
are in the same time zone and that they perform most of their work during the same eight hours of the day.

Example: If your company has 100 heavy Office Outlook 2007 users, heres how to calculate the average
network traffic, measured in bytes per second.

Network bytes/sec = (100 heavy users (5,200 KB/user day)) (8


hr/day 3600 sec/hr) = 18.5 KB/sec

Assuming a daily peak of twice the average usage, your network connection would need to support
approximately 37 KB/sec.

Example: If your company has 100 medium OWA users, heres how to calculate the average network
traffic, measured in bytes per second.

Network bytes/sec = (100 medium users (12,220 KB/user day)) (8


hr/day 3600 sec/hr) = 42.4 KB/sec

Assuming a daily peak of twice the average usage, your network connection would need to support
approximately 84.9 KB/sec.

For more capacity planning information, see White Paper: Outlook Anywhere Scalability with Outlook 2007, Outlook
2003, and Exchange 2007.

SharePoint Online
The information provided in this section will help you begin to estimate the network bandwidth that your company
will require to run SharePoint Online. This information is based on the following assumptions:

An average interaction (page load) transfers approximately 100 KB.

A typical user generates about 36 interactions (page loads) per hour.


About 10 percent of a companys users will be active at the same time.

To show how to apply this information to your company, consider the following example. This example assumes
that all of the users are in the same time zone and that they perform most of their work during the same eight
hours of the day.

Example: If your company has 1000 SharePoint Online users, heres how to calculate the average
network traffic for each user, measured in bytes per second.

Network bits per second = (100,000 bytes/load 8 bits/byte 36


loads/hr) 3600 seconds/hr = 8000 bits per second

A company with 1000 users would have approximately 100 active users at any one time. Those 100 users
would require approximately 100 x 8000 bits per second or 800 kilobits per second of available network
bandwidth. Assuming a daily peak of twice the average usage, your network connection would need to
provide approximately 1.6 megabits per second of network bandwidth.

In addition to the bandwidth requirement, SharePoint Online requires a network latency of no greater than 250
milliseconds.

For more detailed information about capacity planning for SharePoint Online, see Plan for bandwidth requirements.

Office Live Meeting


The information in this section will help you begin to estimate the network bandwidth that your company will need
to run Office Live Meeting .

Office Live Meeting offers two different clients:

Office Live Meeting Client (Windows-based client)

Office Live Meeting Web Access (Web-based client)

The following table lists the bandwidth requirements for each of the functions available in the Office Live Meeting
Client. All values are in kilobytes per second (KBps) for one user.

Function Bandwidth required

Data transfer 56 KBps

Voice 80 KBps (50 KBps minimum)

Video 350 KBps (50 KBps minimum)

Office RoundTable 700 KBps (100 KBps minimum)

Note

The bandwidth requirements listed are cumulative. For example, if you want to use voice, video, and Office
RoundTable, the minimum bandwidth would be 50 + 50 + 100 = 200 KBps per user.

Office Live Meeting Web Access (MWA) is an alternative for users of the Office Live Meeting service who cannot
install or run the Windows-based meeting client. MWA is an applet-based program that runs on any of the Java
runtime environments specified in the Microsoft Office Live Meeting (2007 version) system requirements. MWA
does not require installation of any files. However, initiating application sharing on Macintosh computers using MWA
does require installation of an application-sharing component.
The minimum bandwidth recommendation for the MWA client is 56 KBps.

Migration and Directory Synchronization Tools


The Migration Tools and Directory Synchronization tool are installed on computers on your company network,
behind a firewall or proxy server. These computers should have direct access to your companys domain controllers
and e-mail servers. They will connect to Microsoft Online Services through your companys firewall or proxy server.

Your company may use the Migration Tools to migrate mailbox content from your existing e-mail environment to
Exchange Online. Migration will impact your network only when actually performing the migrations. When
migrating large numbers of mailboxes, you should perform the migrations in small batches to minimize the impact
to your network bandwidth. The Migration Tools console reports the total size of the mailboxes selected to be
migrated. When you know the number and the size of your existing mailboxes, you can determine the impact on
your e-mail servers and your network bandwidth. For more information about e-mail migration, see About E-Mail
Migration.

If your company establishes directory synchronization using the Directory Synchronization tool, there will be a one-
time impact on your network when all of your companys user accounts and e-mail enabled contacts and groups
are synchronized for the first time. This operation will use the available network bandwidth for the duration of the
synchronization. You can expect the first synchronization of 500 objects to take approximately 70 minutes. The
first synchronization of 5,000 objects will take approximately 120 minutes. The actual time will be determined by
the available bandwidth of your organizations Internet connection.

After the first synchronization, the Directory Synchronization tool will synchronize changes every three hours. The
impact of this traffic is usually very small. For more information about directory synchronization, see About
Directory Synchronization.

Synchronization Time
When you know the number of mail-enabled objects that will be copied during the initial synchronization, refer to
the table below for an estimate of how long the initial synchronization may take. You can use this information to
decide when to schedule your first directory synchronization.

Objects Estimated first synchronization Subsequent synchronizations

500 5 minutes 30 seconds

1,000 10 minutes 1 minute

5,000 45 minutes 5 minutes

15,000 2.5 hours 10 minutes

Note

The actual time will be influenced by the available bandwidth of your organization's Internet connection.
http://blogs.technet.com/b/exchange/archive/2008/04/10/3405349.aspx

EDIT 5/30/2008: The content of this article has since been published in our official Exchange
documentation. Please go here for the most updated version.

As part of a broader investigation, we measured the network costs between Enterprise email clients and
Exchange 2007 SP1. The values presented here might help you get a ball-park value for the network
requirements connecting your datacenter to your users. The clients we considered were: Outlook 2007
Online mode; Outlook 2007 Cached mode; Outlook 2007 Cached mode via RPC/Http (Outlook Anywhere)
and Outlook Web Access. We are not reporting the network bytes passed between Exchange roles, but
the bytes entering and leaving the 'datacenter.' Outlook Anywhere and Outlook Web Access connect to
the 'Client Access Server' role, while Outlook 2007 (in both Online and Cached mode) connects directly to
the 'Mailbox' role. The network traffic from earlier Outlook versions can be estimated from the Exchange
2003 results, published in the whitepaper
http://www.microsoft.com/technet/prodtechnol/exchange/2003/clinettraf.mspx, as there haven't been
fundamental changes in the Exchange-Outlook communications in the 2007 releases.

Our user profile started with the message send and delivery rates from the 'light, medium, heavy and very
heavy' knowledge worker profiles. We further assumed: an average message size of 50kB; that every
message delivered was read; and half of the incoming mail was deleted. Our Web client logged in -
logged off twice/day, while we neglected the logon - logoff costs from the other clients. (Enterprise email
users tend to stay logged in for days at a time.)

Profile Light Medium Heavy Very Heavy

Sent /day 5 10 20 30

Received /day 20 40 80 120

Ave message Size 50k 50k 50k 50k

Messages read /day 20 40 80 120

Messages deleted /day 10 20 40 60

OWA logon-logoff /day 2 2 2 2

The network bytes transferred for each action is independent of mailbox size, so we did not perform
separate measurements for each profile, but measured the costs of the actions and summed them for
each profile.

Note that for Outlook 2007 in Cached mode and Outlook Anywhere, which work off a local copy of the
user mailbox, there is negligible traffic associated with reading or deleting mail - as these actions work
against the local copy - but every mail received is downloaded to the client.

In the table below, all values are in Kilobytes/day/user. I've broken out the sending portion from the other
actions (labeled as 'aggregate').

Profile Light Medium Heavy Very Heavy


Sending 190 380 760 1,140

Outlook
2007 -
aggregate 2,510 5,030 10,050 15,070

Online

total 2,700 5,410 10,810 16,210

Sending 260 520 1,040 1,560

Outlook
2007 -
aggregate 1,040 2,080 4,160 6,240
Cached
mode

total 1,300 2,600 5,200 7,800

Sending 310 620 1,230 1,850

Outlook
Anywhere aggregate 1,230 2,470 4,940 7,400
2007

total 1,540 3,090 6,170 9,250

Sending 800 1,600 3,200 4,800

Outlook
Web aggregate 5,390 10,620 21,070 31,530
Access

total 6,190 12,220 24,270 36,330

To use these values, suppose you had a Datacenter with 10,000 Medium Outlook Cached mode users.
Further assume all these users were in the same time zone, so they did the majority of the work during an
8 hour day.

This would predict the Average network bytes/sec would be


or

Assuming a daily peak of twice this average value, the network coming into the 'datacenter' would have to
support roughly 15 megabits/sec from these users alone.

http://technet.microsoft.com/en-us/library/cc540453(EXCHG.80).aspx

White Paper: Outlook Anywhere Scalability with Outlook 2007,


Outlook 2003, and Exchange 2007
Topic Last Modified: 2011-01-19

Tom Di Nardo, Senior Technical Writer, Microsoft Exchange Server

May 2008

Summary

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.

Note:

To print this white paper, click Printer Friendly Version in the Web browser.

Applies To
Microsoft Exchange Server 2007

Table of Contents

Introduction

Outlook Connections

TCP Protocol Connection Limit

Outlook Anywhere Path

Port Exhaustion Causes Scalability Limitations

Mitigating Port Exhaustion Scalability Limitations

Windows Server 2008 and Multiple IP Addresses

Refer Outlook Directly to Global Catalog Servers

Worker Process Recycling May Cause Performance Issues

Mitigating Process Recycling Issues


LoadGen Does Not Simulate DSProxy Connections

Client Network Traffic

Conclusion

Additional Information
Introduction
Outlook Anywhere scalability and client network traffic are two areas that generate many questions about the
number of connections Outlook makes and sustains to an Exchange server. This area is frequently the subject of
discussion when site consolidation is being discussed which also raises the issues of network costs and
Transmission Control Protocol (TCP) connection limits. The TCP connection limitations are largely hit by hosting
companies and large enterprise customers who force all MAPI connectivity through RPC over HTTP (RPC/HTTP). In
the following sections we will cover each of these areas in detail to help show the behavior you can expect to see
when using Outlook Anywhere in your Exchange 2007 deployment.

Outlook Connections
Because of many variables that can exist in an Exchange 2007 environment, it is difficult to provide a solid number
of client connections for all possible variables. The actual number of connections that will be seen in a non-default
Exchange 2007 environment can vary based on using ISA Server, public folders, Outlook Add-ins, and so on.
Outlook connections can also vary based on the features or usage patterns of the client, including accessing shared
calendars, public folder usage, or offline address books. Because of these variables, it is most useful to provide
information about the connection values that will be seen in a default Exchange 2007 installation. Keep in mind
that a larger number of connections will be seen during initial logon. After a minute you will see the number of
connections reach a steady state. It is important to be aware that these startup connections are not accounted for
in the illustrations below. This behavior is seen in both Outlook 2003 and Outlook 2007. It is impossible to predict
exactly how many connections will be used because of the previously mentioned variables. However, an increase of
between 25 and 50 percent at startup has been regularly observed.

The numbers provided in this topic were collected by running TCPView on a default installation of Exchange 2007.
This includes a server that has the Mailbox server role installed, a server that has the Client Access server role
installed, Windows Server 2003 Active Directory, and default Outlook 2003 and Outlook 2007 clients. For more
information about TCPView, see TCPView for Windows.

The illustration below details how these connections look from inside the firewall on the corporate network (inside
firewall):
The illustration below details how these connections look from an Outlook Anywhere perspective when coming into
the corporate network via RPC over HTTP (outside firewall):

TCP Protocol Connection Limit


The TCP protocol has a requirement that each connection have a unique ordered list, also known as an n-tuple,
which consists of source address, source port, destination address, and destination port. All incoming connections
use the same destination address or port, so the number of incoming connections is limited by the non-paged pool
size. Each outgoing connection consumes a port on an address. The TCP port is a 16-bit number, so there are at
most 65,535 ports.

The change to 64-bit hardware in Exchange 2007 exposed this scalability limit. In Exchange 2003, the memory
constraints in 32-bit hardware hide this limit and because of those memory constraints, memory availability would
be exhausted before the TCP connection limit could be reached. Now, with 64-bit hardware and an almost endless
amount of memory, Exchange is no longer limited in this area and can therefore hit the TCP connection limitation.
Usually, this affects enterprise customers who are running at very high scale and who are trying to maximize as
much scale-up from their hardware as possible.

Return to top

Outlook Anywhere Path


RPC/HTTP is a tunneling protocol where Exchange uses a pair of virtual channels to create a virtual connection from
Outlook to Exchange. Each virtual channel is a single directional data stream that is transported over various real
channels. The client to RPC Proxy channel is HTTP/HTTPS and the RPC Proxy to Exchange channel is TCP. The client
then establishes four channels. Data flows on these as follows:

1. Client to Proxy
2. Proxy to Exchange
3. Exchange to Proxy
4. Proxy to Client
Once all four channels are established, RPC then treats this as a single full duplex tunneled connection from
Outlook to Exchange. Each real channel can be replaced without interrupting the data flow over the virtual
connection.

Exchange has two kinds of connections, mail and directory. Each of these connections will appear as a pair of
virtual channels. Mail connections flow from Outlook to the RPC Proxy component on the Client Access server to the
Mailbox server. In deployments were Internet Security and Acceleration (ISA) Server is used, ISA Server will proxy
these connections to the Client Access server (RPC/HTTP Proxy). Because ISA Server is still a 32-bit application, it
will be unable to scale the TCP connections to the physical connections limit before it runs out of available non-
paged pool memory. Non-paged pool memory is used for managing the high number of connections established.
This limit will be reached before any Exchange limits are reached. The testing documented here does not deal with
this issue. However, it is an important consideration for any real-world deployment. Exchange then uses its data
store to service the requests and replies to the client. The directory connections flow from Outlook to the RPC
Proxy component on the Client Access server to the DS Proxy component on the Mailbox server to an Active
Directory global catalog server. The RPC connection is processed on the DC (not on the Exchange server), with the
DS Proxy component merely copying bytes from one TCP connection to the other. The large number of outbound
connections from Exchange to the DC is a function of the DS Proxy component that tunnels connections.

The TCP connections limits discussed earlier in this topic exist in both Windows Server 2003 and Windows Server
2008 as consumers of the TCP protocol. One IP address is used as the source IP address when it opens a
connection to a remote computer. Each Client Access server is bound by the Windows port limit of 65,535 available
ports. The Client Access server depletes the available pool of ports as each client uses anywhere between 2 and 8
connections. The information store process has a hard limit of 60,000 RPC context handles which are associated
with each RPC/HTTP virtual connection between Outlook and Exchange. Therefore, the store process is limited to
60,000 of these mail connections.
The following performance counters are helpful in determining whether a server is reaching this limit:

RPC/HTTP Proxy (Windows Server 2008 Only)

Current Number of Incoming RPC over HTTP Connections

Current number of unique users

RPC/HTTP requests per second

Number of Failed Back-End Connection attempts per Second


MSExchangeIS

RPC Averaged Latency

RPC Requests

RPC Operations/Sec
Web Service (Windows Server 2003 Only)

Current Connections

Note:

These counters are only useful on servers where no other Web service is used.

Memory

Pool Nonpaged Bytes

Pool Paged Bytes


Process

Private bytes / LSASS, W3WP and any Exchange-specific processes running


The current number of incoming RPC/HTTP connections and current number of unique users counters
that are available with Windows Server 2008 will determine how many user connections there are and how many
different NT user accounts are connected. The other counters will help determine potential causes of the denial of
new user connections to a server and how the server is failing.

Return to top

Port Exhaustion with Outlook Anywhere Causes Scalability Limitations


The key discovery and conclusion is that a Mailbox server will deplete outbound source IP ports far more quickly
than it will reach any inbound limit. This occurs because of the way that DSProxy operates. DSProxy opens a single
outbound connection for every inbound connection it receives. For every inbound connection to DSProxy, the
Mailbox server opens an equivalent number of outbound connections to a global catalog.

Other related observations are:

Clients do not share connections. New connections are established for every new client connecting.

Connections are removed as soon as a client logs off.

If a client opens a mailbox on a Mailbox server other than the one hosting their mailbox, or views a
calendar or folder on another Mailbox server, additional TCP connections are established from the Client
Access server to that Mailbox server.

If multiple mailboxes or calendars are viewed on a Mailbox server other than the one hosting their
mailbox, no additional connections are created beyond those established for the first mailbox or calendar
viewed.

Because ISA Server is still a 32-bit application, it will be unable to scale the TCP connections to the
physical connections limit before it runs out of available non-paged pool memory. Non-paged pool
memory is used for managing the high number of connections established. This limit will be reached
before any Exchange limits are reached. The testing documented here does not deal with this issue, but it
is an important consideration for any real-world deployment.
Return to top

Mitigating Port Exhaustion Scalability Limitations


There are two possible ways to mitigate the issue of port exhaustion: by using Windows Server 2008 with multiple
IP addresses, reverting to Exchange 2003 RTM behavior and scaling out the Client Access server deployment by
adding additional Client Access servers to service client connections.

Windows Server 2008 and Multiple IP Addresses


A registry key was created in Windows Server 2008 which allows the server to use 65,535 outbound connections
for each IP assigned to the system, even for multiple IPs assigned to the same network adapter. This feature will
allow some additional headroom but does not address the other limits, such as the store connection limit. It should
also be noted that each RPC/HTTP virtual connection consumes 61 KB of RAM on the Client Access server so that a
server that will be using many TCP connections must be configured with sufficient RAM to manage the connections
and also the load Exchange puts on it. If you do not plan for this, you will be encountering issues related to
memory pressure which can cause the server to thrash (continuously page). For information about implementing
the registry change detailed here, see Microsoft Knowledge Base article, How to enable the port scalability feature
for RPC proxies and for applications in Windows Server 2008.

Refer Outlook Directly to Global Catalog Servers


Another method that is available for mitigating the issue of port exhaustion is to refer Outlook directly to global
catalog servers and scale out your Client Access server deployment by adding additional Client Access servers to
service the client connection load.

Important:

This change should only be considered in exceptional circumstances. This change presents the problem of
requiring the manual configuration of all possible global catalogs into the registry of every Client Access server.
The supportability issues of this change should be fully understood before you implement it in a production
environment.

The following change must be made to enable this configuration for the Mailbox server:

The Do Not Refer HTTP to DSProxy key must be set as detailed in How to control the DSProxy process for RPC over
HTTP connections in Exchange Server 2003 SP1.

The following changes must be made to enable this configuration for the Client Access server:

Use the following procedure to modify the ValidPorts setting in registry key
HKLM\Software\Microsoft\RPC\RPCProxy so that the entries referring to 6004 point to every available global
catalog in addition to a Mailbox server. These entries must exist for both the fully qualified domain name (FQDN)
and the short NETBIOS name of every available global catalog.

Procedures

Caution:

Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating
system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing
the registry, back up any valuable data.

Use the following procedure to modify the PeriodicPollingMinutes value in the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigu
rator\

To modify this value, set it to 0 to prevent the Microsoft Exchange Service Host service from updating the
ValidPorts subkey automatically.

Use Registry Editor to modify the PeriodicPollingMinutes value


1. On the Exchange server that has the Client Access server role installed, open Registry Editor.

2. Browse to:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHtt
pConfigurator\

3. Right-click PeriodicPollingMinutes and then click Modify.

4. In the Value data field, enter a value of "0" without quotation marks.

5. Close Registry Editor.

6. Restart the Microsoft Exchange Service Host service for changes to take effect.

Use the following procedure to modify the ValidPorts value in the registry.

Use Registry Editor to modify the ValidPorts value


1. On the Exchange server that has the Client Access server role installed, open a Registry Editor.

2. Browse to: HKLM\Software\Microsoft\RPC\RPCProxy.

3. Right-click ValidPorts and then click Modify.

4. In the Value data field, enter the FQDN and NETBIOS name for every available global catalog in the
following format: GC01:6004;gc01.contoso.com:6004.
5. Close Registry Editor.

6. The new setting will take effect in approximately five minutes.

Conclusion

Note:

IIS reads the Enabled and ValidPorts registry entries on startup. In addition, RPC over HTTP rereads the
contents of the ValidPorts key approximately every five minutes. If the ValidPorts entry is changed, the
changes are implemented within five minutes.

The following changes must be made to enable this configuration for the global catalog server:

Use the following procedure to create a Multi-String Value entry named NSPI protocol interface sequences in the
registry key HKLM\System\CCS\Services\NTDS\Parameters\ on each global catalog server and set its value
to ncacn_http:6004.

Use Registry Editor to create the NSPI interface protocol sequences Multi-String Value entry
1. On the Exchange server that has the Client Access server role installed, open Registry Editor.

2. Browse to: HKLM\System\CCS\Services\NTDS\Parameters\.

3. Right-click in the action pane, select New\Multi-StringValue, and enter the name NSPI interface
protocol sequences.

4. Right-click NSPI interface protocol sequences and then click Modify.

5. In the Value data field, enter a value of "ncacn_http:6004" without quotation marks.

6. Close Registry Editor.

7. Restart the server for changes to take effect.

Return to top

Worker Process Recycling May Cause Performance Issues


RPC over HTTP runs in the Default Application Pool (DefaultAppPool) in Internet Information Services (IIS). By
default, this application pool is configured to recycle worker processes every 29 hours. During the recycling
process, IIS allows active worker threads an additional 90 seconds to finish servicing requests before IIS
terminates the active threads.

Because RPC over HTTP uses long-running connections, the connections may not finish within the additional 90
seconds that are given to the worker threads. In this scenario, the connections are terminated, which causes
Outlook to lose connectivity with IIS. When this action occurs, Outlook immediately tries to reconnect. If many
Outlook clients are disconnected at the same time, the large number of simultaneous reconnections may
overwhelm the server.

Mitigating Process Recycling Issues


To mitigate any performance issue that may occur because of worker process recycling, configure the following
items in IIS:

If practical, move the RPC over HTTP component into its own application pool.

Turn off worker process recycling on application pools in which RPC over HTTP is configured.

Increase the HTTP.sys queue limit from the default value of 1,000 to 10,000.
Procedures
Use Internet Information Services Manager to move the RPC over HTTP component to a new application pool in IIS
6.0
1. Start Internet Information Services Manager.

2. Expand the local computer, right-click Application Pools, point to New, and then click Application
Pool.

3. In the Add New Application Pool dialog box, type a descriptive name such as
MSExchangeOutlookAnywhere, click Use existing application pool as template, click
DefaultAppPool in the Application pool name list, and then click OK.

4. Expand Web Sites, expand the Web site in which the Rpc Web application is located. For example,
expand Default Web Site. Right-click Rpc, and then click Properties.

5. On the Virtual Directory tab, click the new application pool in the Application pool list. For example,
click MSExchangeOutlookAnywhere.

6. Click OK.

Use Internet Information Services Manager to turn off worker process recycling in IIS 6.0
1. Start Internet Information Services (IIS) Manager.

2. Expand the local computer, expand Application Pools, right-click the appropriate application pool, such
as DefaultAppPool or the new application pool that you created, and then click Properties.

3. Click to clear the Recycle worker processes (in minutes) check box, and then click OK.

Use Internet Information Services Manager to increase the queue length in IIS 6.0
1. Start Internet Information Services (IIS) Manager.

2. Expand the local computer, expand Application Pools, right-click the appropriate application pool, such
as DefaultAppPool or the new application pool that you created, and then click Properties.

3. Click the Performance tab, and then modify the value in the Request queue limit box. Replace the
default value of 1000 with 10000.

4. Click OK.

Use Internet Information Services Manager to move the RPC over HTTP component to a new application pool in IIS
7.0
1. Start Internet Information Services Manager.

2. Expand the local computer, click Application Pools, and then click Add Application Pool.

3. In the Name box, type a descriptive name, such as MSExchangeOutlookAnywhere, and then click OK.

4. In the Connections pane, expand Sites, expand the Web site in which the Rpc Web application is
located. For example, expand Default Web Site Click Rpc, and then click Advanced Settings.

5. Note any settings that appear in the Advanced Settings dialog box.

6. Under General, click the ellipsis () button that appears next to DefaultAppPool.
7. In the Application pool list, click the new application pool that you created, and then click OK two times.

Use Internet Information Services Manager to turn off worker process recycling in IIS 7.0
1. Start Internet Information Services Manager.

2. Expand the local computer, and then click Application Pools.

3. In the Application Pools pane, click the appropriate application pool, such as DefaultAppPool or the
new application pool that you created, and then click Advanced Settings.

4. In the Recycling section, modify the Regular Time Interval (minutes) value. Replace the default value
of 1740 with 0 (zero). A value of zero turns off worker process recycling.

5. Click OK.

Use Internet Information Services Manager to increase the queue length in IIS 7.0
1. Start Internet Information Services Manager.

2. Expand the local computer, and then click Application Pools.

3. In the Application Pools pane, click the appropriate application pool, such as DefaultAppPool or the
new application pool that you created, and then click Advanced Settings.

4. In the General section, modify the Queue Length value. Replace the default value of 1000 with 10000.

5. Click OK.

Return to top

LoadGen Does Not Simulate DSProxy Connections


The Microsoft Exchange Load Generator (LoadGen) tool does not simulate any DSProxy connections. The affect of
this is not significant from a performance perspective, but it is significant from a scale testing perspective.
Customers who use LoadGen to simulate Outlook Anywhere users will not hit the outbound ports scalability issue
described earlier in this topic. This will result in a test where a much larger number of users will be able to connect
to Exchange by using Outlook Anywhere than would be able to do this in a production environment. The load on
the server is believed to be minimal, but the missing DSProxy connections will allow the server to support far more
clients during LoadGen testing than it would allow in a production environment.

The LoadGen Tool team is investigating adding support for directory connections in a future release of the LoadGen
tool. Until LoadGen is updated to reflect these connections, it is critical that scalability testing of Outlook Anywhere
with LoadGen not be used exclusively to determine the maximum number of concurrent users that a server can
support.

LoadGen connections RPC TCP


(Store connections only) connections connections
(Outlook Anywhere only)

Outlook 2003 online 1 2

Outlook 2003 cached 1 2

Outlook 2007 online 1 2

Outlook 2007 cached 2 4

Client Network Traffic


As part of the Outlook Anywhere scalability testing, analysis was done to determine the network costs between
enterprise e-mail clients and Exchange 2007 SP1. The values presented here may help an organization determine
an estimated value for the network use requirements that are part of connecting end-users to the Exchange 2007
infrastructure. The testing performed in this analysis included the following scenarios: Outlook 2007 online mode;
Outlook 2007 cached mode; Outlook 2007 cached mode through RPC/HTTP (Outlook Anywhere) and Outlook Web
Access. No reporting on the network bytes passed between Exchange roles was performed. This analysis is limited
to the bytes entering and leaving the datacenter. Outlook Anywhere and Outlook Web Access connect to the
Exchange servers with the Client Access server role installed, while Outlook 2007 (in both online and cached mode)
connects directly to the Exchange servers that have the Mailbox server role installed. The network traffic from
previous Outlook versions can be estimated from the Exchange 2003 results that are published in the Client
Network Traffic with Exchange Server 2003 white paper because there have not been fundamental changes in
Exchange-Outlook communications in the 2007 releases.

The user profile started with the message send and delivery rates from the "light", "medium", "heavy" and "very
heavy" knowledge worker profiles. The following assumptions were made for the purposes of these tests:

An average message size of 50 KB

Every message delivered was read

Half of all incoming mail was deleted

Web clients logged on and logged off two times per day

Logon and logoff costs from the other client types were not evaluated because enterprise e-mail users
generally stay logged on for days at a time.

Profile Light Medium Heavy Very heavy

Sent per day 5 10 20 30

Received per day 20 40 80 120

Avg. message size 50k 50k 50k 50k

Messages read per day 20 40 80 120

Messages deleted per day 10 20 40 60

Outlook Web Access logon and logoff per day 2 2 2 2

The network bytes transferred for each action is independent of mailbox size, so separate measurements for each
profile were not performed, but measurement of the costs of the actions were made and totaled for each profile.

Note:

For Outlook 2007 in cached mode and Outlook Anywhere, which work from a local copy of the user mailbox,
there is insignificant traffic associated with reading or deleting mail because these actions work against the
local copy. However, every e-mail received is downloaded to the client.

In the following table, all values are in kilobytes per day per user. The sending portion has been separated from
the other actions, which are labeled as 'aggregate'.

Profile Light Medium Heavy Very heavy

Sending 190 380 760 1,140

Outlook 2007 online mode Aggregate 2,510 5,030 10,050 15,070

Total 2,700 5,410 10,810 16,210

Sending 260 520 1,040 1,560

Outlook 2007 cached mode Aggregate 1,040 2,080 4,160 6,240


Total 1,300 2,600 5,200 7,800

Sending 310 620 1,230 1,850

Outlook Anywhere in Exchange 2007 Aggregate 1,230 2,470 4,940 7,400

Total 1,540 3,090 6,170 9,250

Sending 800 1,600 3,200 4,800

Outlook Web Access 2007 Aggregate 5,390 10,620 21,070 31,530

Total 6,190 12,220 24,270 36,330

To better understand how these values can be used, consider the following example:

Suppose a datacenter has 10,000 "Medium" Outlook cached mode users. Further assume these users are in the
same time zone and they perform most of their work during the same 8-hours of the day. The graphic here
predicts what the average network bytes per second would be.

or

Assuming a daily peak of twice the average value, the network coming into the datacenter would have to support
approximately 15 megabits per second from these users alone.

If these users were running in online mode, per-user bandwidth consumption value would be replaced as shown in
the following formula:

or

Assuming a daily peak of twice the average value, the network coming into the datacenter would have to support
approximately 30 megabits per second from these users.

Return to top

Conclusion
By using the information that is provided here, you can start to evaluate how to properly size your Outlook
Anywhere deployment and the network utilization requirements for your Exchange 2007 environment.

Additional Information
For the complete Exchange 2007 documentation set, see the following resources:

Exchange Server 2007 Help

Exchange Server TechCenter


http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/f0a6e335-02b8-42a0-b5a3-
83724d0ff4de/

Hi All,

How to calculate bandwidth requirement for Exchange 2007 for 3000 users. All servers located
in datacenter so I just want to calculate link between MPLS cloud to Datcenter.

o Reply
o Quote

Answers

Wednesday, January 20, 2010 6:12 AM

Frank.Wang

Frank.Wang

MCC, MSFT CSG

11,295
Recent Achievements1553

New Blog RaterForums Answerer IVForums Replies V

Frank.Wang's threadsView Profile

(MCC, MSFT CSG)

11,295

Sign In to Vote

Hi,

Please read this blog of Exchange team. Hope it will be helpful.


Client Network Traffic with Exchange 2007
http://msexchangeteam.com/archive/2008/04/10/448668.aspx

Frank Wang

o Marked As Answer byFrank.WangMicrosoft Contingent Staff, ModeratorTuesday, January 26, 2010 1:37 AM
o

o Reply
o Quote

All Replies

Wednesday, January 20, 2010 6:12 AM

Frank.Wang

Frank.Wang

MCC, MSFT CSG

11,295
Recent Achievements1553

New Blog RaterForums Answerer IVForums Replies V

Frank.Wang's threadsView Profile

(MCC, MSFT CSG)

11,295

Sign In to Vote

Hi,

Please read this blog of Exchange team. Hope it will be helpful.


Client Network Traffic with Exchange 2007
http://msexchangeteam.com/archive/2008/04/10/448668.aspx

Frank Wang

o Marked As Answer byFrank.WangMicrosoft Contingent Staff, ModeratorTuesday, January 26, 2010 1:37 AM
o

o Reply
o Quote
Wednesday, January 20, 2010 6:51 AM

Gurvinders

Gurvinders
10

Recent Achievements200

First Marked AnswerFirst Forums Reply

Gurvinders's threadsView Profile

10

Sign In to Vote

Thanks for your reply.. it's good Articel

i have one calculation

No. of users in each site 3000

Average bandwidth consumption per user 4 Kbps

Bandwidth requiremnet for 3000 users 12Mbps

Users in Germnay on lAN - 350 1.4Mbps


Final Bandwidth 10.6Mbps

If Further Asia users be added- 400 12Mbps

can you please confirm if it's correct

as per my knowledge it should be 4 KB not 4 Kb.. can you please confirm.

o Reply
o Quote
Wednesday, January 20, 2010 9:02 AM

Frank.Wang

Frank.Wang

MCC, MSFT CSG

11,295
Recent Achievements1553

New Blog RaterForums Answerer IVForums Replies V

Frank.Wang's threadsView Profile

(MCC, MSFT CSG)

11,295

Sign In to Vote

Yes, It's 4 KB.

The article is also list:

In the table below, all values are in Kilobytes/day/user.

Not Kilobits(Kbps).
Frank Wang