Sunday, January 29, 2006

Exchange 2003 bandwidth requirements

I did some research over the weekend into the bandwidth requirements of
Exchange 2003 and Outlook 2003. Microsoft published an Operation paper titled "10 things to think about". Here they recommend using the following for a ballpark estimate:
Regular MAPI clients
# of concurrent users * 2.5 Kbps

Heavy MAPI clients
# of concurrent users * 3 Kbps

I noted some technology considerations below. I was also able to find
two white papers on traffic analysis; one by Citrix and the other by
Microsoft. Finally, I jotted down my initial thoughts.

-- TECHNOLOGY CONSIDERATIONS --

Exchange 2003 Considerations
* LDAP searches directed at Global Catalog servers. By default, Exchange will refer Outlook clients to LDAP servers in the Exchange servers local site for directory access.
* Public Folder replication (unable to predict)
* OWA usage - Based on readings a single Outlook client, based on a
heavy profile, could require as much as 15 Kb/s per client (see white
paper below)

Outlook 2003 Considerations
* Every environment is different depending on the users profile (think of
IOPS when considering storage)
* Improved MAPI communication - Data is compressed and more data per
packet sent that in previous versions of Outlook. (only when working with
Exchange 2003).
* A single Outlook client, based on a heavy profile,
could require as much as 10 Kb/s per client (see white paper below)
* Cached mode has been designed to work over WAN links and tolerate
latency. However, it does require synchronization of an OST and OAB
(offline address book). This could result in high network utilization
if many users connect to Exchange at the same time and/or synchronize
their mail at the same time.

* OAB (Offline Address Book) - In a large organization, the OAB can be
several MB's in size (38 MB in my current environment). This can grow
significantly large when PKI is implemented. In addition there are multiple scenarios where Exchange forces all users to execute a full download:
KB839826

Desktop search engines
* We've had some problems with the Google and MSN desktop
search engine. When these applications try and index a user's
mailbox, they'll execute as many connections as possible. Eventually one
desktop can put the load of 100 clients (just while indexing a single mailbox).
KB905184


-- WHITE PAPERS --
Citrix Traffic Analysis
Citrix Link

Microsoft Traffic Analysis
M$ Link


-- LINKS --
Top 10 things to Consider



-- MY THOUGHTS --
One approach could be to work with the current Exchange adminstrators to
try and establish 3 basic user profiles. Then
hopefully make some basic bandwidth estimates and work with the network
team on creating a flexible network plan. As the migration
moves forward that plan could be adjusted based on trends.

Another approach could be to look at WAN accelerators
Link

Teo

Tuesday, January 24, 2006

LegacyExchangeDN

-- Mail Routing --
The routing of mail to Exchange recipients is done with the LegacyExchangeDN attribute. Messages sent are stamped with the senders LegacyExchangeDN.

-- Migrations --
With any version of Exchange, when the mailbox is moved, it's LegacyExchangeDN is overwritten to represent the new location in the directory. Because of routing explanation above, this breaks replyability. Normally, this is fixed by adding an X.500 proxy address that represents the LegacyExchangeDN. Exchange 2003 SP1 does this to all mailboxes moved between administrative groups.

-- Disaster Recovery --
A great article on the role that the attribute LegacyExchangeDN plays in a disaster recovery scenario.
MSExchange.org

Friday, January 13, 2006

Finding where a user was deleted

A blog I review posted 3 steps that show who deleted a user account.


  1. adfind -default -showdel -f (isdeleted=TRUE) -gc

  2. repadmin /showobjmeta dcname deletedobjectDN find /i "isdeleted"

  3. Eventcomb to find event id in security logs.

    • a. psloglist \\dcname security -i 630 -a date.


Link

Thursday, January 05, 2006

Cached Mode, Security Groups, and Paged Pool Memory

The Exchange team's blog has an interesting article which goes into detail about security tokens, and how much paged pool memory they consume. If you have users in more than 80 security groups, it can impact performance. Read more by following the link below...

Link

Teo