Monday, May 31, 2010

Remote shutdown problem in 2003 based computers

Hi All,

Most us should have faced the subjected problem. Anybody searched for a solution ?

Here is one

A Windows Server 2003-based computer stops responding when you shut down the computer in a remote console session. This problem occurs randomly.

Note You may establish a remote console session by using the Remote Desktop Connection tool (Mstsc.exe) together with the /console switch.

In a regular Windows Server 2003 shutdown process, the operating system has a time-out period during which the service control manager (SCM) shuts down services. If the SCM does not finish shutting down all the services within the time-out period, the operating system continues to shut down without waiting. The time-out period is specified in the WaitToKillServiceTimeout registry entry. The default time-out period lasts 20 seconds.

However, if you shut down a computer in a remote console session, the operating system continues to shut down regardless of the time-out period. In this case, the operating system continues to shut down several seconds after the SCM sends a shutdown notification to the service. Then, the NTFS driver begins to shut down as part of the system shutdown process. The NTFS driver begins to shut down earlier than expected when the service is still shutting down. The service may access disk resources during the shutdown process. A deadlock is likely to occur between the NTFS shutdown operation and the disk resource access.


There is a hotfix available from Microsoft in the following link..

I certainly won't promise you that it solves all of the issues - but I've not seen a hang since I installed the last version of this patch. A version of the hotfix is available for both Windows Server 2003 sp1 and sp2.

Scalable Networking Pack (SNP) Known issue

After you install Windows Server 2003 Service Pack 2 (SP2) or Windows Server 2003 Scalable Networking Pack (SNP) on a computer that has a TCP/IP Offload-enabled network adapter, you may experience many network-related problems.

The following issues may occur when Windows Server 2003 SNP is turned on:

1.    When you try to connect to the server by using a VPN connection, you receive the following error message:
Error 800: Unable to establish connection.
2.    You cannot create a Remote Desktop Protocol (RDP) connection to the server.
3.    You cannot connect to shares on the server from a computer on the local area network.
4.    You cannot join a client computer to the domain.
5.    You cannot connect to the Exchange server from a computer that is running Microsoft Outlook.
6.    Inactive Outlook connections to the Exchange server may not be cleaned up.
7.    You experience slow network performance.
8.    You may experience slow network performance when you communicate with a Windows Vista-based computer.
9.    You cannot create an outgoing FTP connection from the server.
10. The Dynamic Host Configuration Protocol (DHCP) server service crashes.
11. You experience slow performance when you log on to the domain.
12. Network Address Translation (NAT) clients that are located behind Windows Small Business Server 2003 or Internet Security and Acceleration (ISA) Server experience intermittent connection failures.
13. You experience intermittent RPC communications failures.
14. The server stops responding. The server runs low on non paged pool memory
15. 32 MAPI sessions exceeded (9646 errors) causing the inability for Outlook clients to connect to the Information Store. This can occur more frequently with VPN connected clients and we have also seen scenarios where Exchange 2007 is affected with Windows 2003 SP2 installed as well.
16. You cannot connect to shares on the server from a computer on the local area network.
17.  You cannot connect to Microsoft Exchange Server from a computer that is running Microsoft Outlook.
18.  You can only connect to Web sites that are hosted on the server or on the Internet by using a secure sockets layer (SSL) connection. In this scenario, you cannot connect to a Web site that does not use SSL encryption.
19.  You experience slow network performance.
20.  You cannot create an outgoing FTP connection from the server.
21.  You experience intermittent RPC communications failures.
22.  Some Outlook clients may be unable to connect to Exchange.
23.  You cannot run the Configure E-mail and Internet Connection Wizard successfully.
24.  Microsoft Internet Security and Acceleration (ISA) Server blocks RPC communications.
25.  You cannot browse Internet Information Services (IIS) Virtual Directories.
26. Non-paged pool memory leaks caused by having the Chimney feature enabled. Sometimes you can't even start the IIS services when Non-paged pool gets below 20MB.
27. The Inability to logon to Outlook Web Services or even IIS for that matter, either locally or remotely.
28. Networking throughput is decreased when these features are turned on. This is the opposite of what the Networking Pack is supposed to do.
29. Cluster ISAlive checks fail randomly
30. TCP Connections are reset when RSS is enabled.
31. TCP port exhaustion
32. After you install the Scalable Networking Pack (SNP), a Windows Server 2003-based computer may stop responding during shutdown or during hibernation. When this problem occurs, the computer does not respond to the ping command.

Work around:

To work around this problem, disable the TCP Chimney Offload feature. To do this, run the Netsh int ip set chimney DISABLED command at a command prompt.


Install the hotfix mentioned in MS KB 948496

Troubleshooting Slow RPC Request Processing Issues

When you use Microsoft Office Outlook in MAPI mode, Outlook executes client operations as remote procedure calls (RPCs) between the client and the server. If the user is running in online mode, these RPC calls occur synchronously. Any delay by the server in fulfilling these synchronous requests directly affects the user experience and the responsiveness of Outlook. In contrast, most operations that are performed when you run in cached mode occur against the user’s local copy of the mailbox or are issued to the server in the form of asynchronous (background) RPCs. Generally, asynchronous RPCs do not affect the responsiveness or overall experience of the Outlook client itself.
When the Microsoft Exchange Information Store service first starts on a server, it registers with the RPC service and receives an allocation of 500 RPC threads. Clients connect and disconnect to individual threads as they perform daily operations. This includes reading and sending e-mail, creating appointments and tasks, and viewing calendars. The MSExchangeIS\RPC Requests performance counter indicates how many threads are currently in use (“owned” by clients). The MSExchangeIS\RPC Operations/sec performance counter reflects the number of operations the server received in the past second. If the number of RPC requests increases steadily over time, it is a clear indication that the server cannot process client operations quickly enough. When the MSExchangeIS\RPC Requests performance counter reaches 500, all RPC threads have been exhausted, and clients will be unable to submit new requests to the server until all operations on an existing thread have been completed and that thread is released.
Because the MSExchangeIS\RPC Operations/sec performance counter reflects a server’s current workload, it is extremely useful for identifying bottlenecks in Exchange processing, especially if administrators know the expected values for their server during peak periods and normal operations. Servers which perform acceptably when receiving 300 RPC operations per second may struggle to keep up with 1500 RPC operations per second. Administrators should always review the MSExchangeIS\RPC Operations/sec counter and correlate changes in this value with changes in the number of RPC requests.
If clients are complaining of poor Exchange performance, and MSExchangeIS\RPC Requests and MSExchangeIS\RPC Operations/sec are both low or zero, this is a clear indication that the bottleneck is not on the server itself. The issue here is that something external to the server is preventing information from reaching the server at all. Administrators should review Active Directory performance, network performance, client configuration, and other areas that may result in data not reaching the Exchange server.
If MSExchangeIS\RPC Requests is steadily increasing while MSExchangeIS\RPC Operations/sec remains fairly stable, this indicates that the server cannot handle the existing workload. Administrators should verify hardware components, including physical memory, storage, and processor capability, or decrease the number of users on the server.
If MSExchangeIS\RPC Requests is steadily increasing but MSExchangeIS\RPC Operations/sec steadily decreases, this indicates that the Exchange server is the source of the bottleneck. In this situation, something is preventing the Information Store from completing RPC operations, and the associated RPC threads remain allocated. As more and more threads are allocated, the server has fewer available threads for new operations, so the number of new operations decreases. If the server eventually reaches 500 outstanding RPC requests, new RPC operations will be refused. This is generally caused by either a serious physical resource shortage (memory or disk) or a processing issue within the Information Store or an integrated component (antivirus, journaling, and so on).
The following table includes the most important counters for troubleshooting and isolating RPC processing issues.

Performance counters for RPC processing

Expected values
MSExchangeIS\RPC Requests
Indicates the number of MAPI RPC requests currently being serviced by the Microsoft Exchange Information Store service.
The Microsoft Exchange Information Store service can support up to 500 RPC requests simultaneously before rejecting new client requests.
  • It should always be lower than 70.
MSExchangeIS\RPC Averaged Latency
Indicates the latency in milliseconds, averaged across all RPC operations in the past 1024 RPC packets.
See "Client Throttling" later in this topic for information about how clients are affected when overall server RPC average latency increases.
  • It should always be less than 25 milliseconds.
MSExchangeIS\RPC Operations/sec
Indicates the current number of RPC operations that are submitted to the Information Store each second.
  • This is a good indicator of client activity and is used for information only.
MSExchangeIS\RPC Num. of Slow Packets
Indicates the number of RPC packets in the past 1024 that have latencies that are longer than two seconds.
  • This should always be less than two. Certain normal operations may take longer than two seconds, but the average should always be less than two.
 Client-Side Monitoring
Microsoft Office Outlook 2003 and Office Outlook 2007 include added client-side monitoring features. Client-side monitoring is used to find client errors and latency problems. You can enable client-side monitoring on an Exchange server by modifying the server's registry. When enabled, Outlook 2007 and Outlook 2003 clients send data to the server based on status and state of connection, which includes failed RPC requests and error conditions. This information is aggregated on the server and logged in event log entries on the server. For detailed steps on how to enable client-side monitoring in Outlook.

 Client Throttling 

Exchange 2007 includes a new feature known as RPC Client Throttling which is available to help administrators manage their end user's 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 located in Exchange mailboxes, enterprise-class e-mail archiving products, and CRM enabled mailboxes with e-mail auto-tagging enabled. Client throttling enables Exchange to discover 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. For detailed information about the client throttling features that are available with Exchange 2007

Explanation of Active Directory Domain Functional Level Features

Windows Server 2003 domain functional level features
- Domain rename capability
Windows Server 2003 functional level supports rename of Active Directory domain.
- Cross-forest transitive trusts
Windows Server 2003 functional level supports transitive trusts between two or more Active Directory forests.
- Universal group caching
Windows Server 2003 functional level supports Universal group caching which eliminate the need for local global catalog server
- Intersite topology generator (ISTG) improvements
More efficient ISTG algorithm allows support for extremely large numbers of sites.
- Multivalued attribute replication improvements
This allows incremental membership changes.
- Lingering objects (zombies) detection
Windows Server 2003 ability to detect zombies, or lingering objects.
- AD-integrated DNS zones in application partitions
This allows storing of DNS data in AD application partition for more efficient replication. 
Windows Server 2008 domain functional level features
- Fine-grained password policies
Allows multiple password polices to be applied to different users in the same domain.
- Read-Only Domain Controllers
Allows implementation of domain controllers that only host read-only copy of NTDS database.
- Granular auditing
Allows history of object changes in Active Directory.
- Distributed File System Replication (DFSR)
Allows SYSVOL to replicate using DFSR instead of older File Replication Service (FRS). It provides more robust and detailed replication of SYSVOL contents.

Exchange monitoring

Hi Team,

Check this site for a cool tool for live monitoring of exchange servers..

This tool is especially useful for Exchange administrators and developers. By using this tool, you can gather real-time data about the users in an Exchange environment and learn more about the inner workings of MAPI, OWA, POP3, IMAP4, NNTP and other protocols.

Wednesday, May 26, 2010

Some exchange level questions and Tips....

The following feature enhancements are provided in Microsoft Exchange 2000 Enterprise Server:

Database size is limited only by hardware (with a maximum size of 16 terabytes).

Up to four storage groups can be created on server.

Up to five information stores can exist in each storage group.

Exchange 2000 Enterprise Server can be clustered on the Microsoft Cluster Server Service.

Exchange 2000 Enterprise Server can be implemented as a front end server for front end/back end configuration.

The X.400 Connector is included.

The limitations to Microsoft Exchange 2000 Server Standard Edition include:

Four storage groups can be created on a server.

One mailbox store database and one public folder store database that can be accessed by using MAPI and Outlook Web Access

Up to four more public folder store databases that are only accessible programmatically

Maximum 16-gigabyte (GB) database limit per database

Microsoft Exchange 2007 Server

Standard – 5 storage groups, 5 databases, no clustering, LCR support

Enterprise – 50 Storage groups, 50 databases, clustering, CCR support

What is difference between exchange 2003 standard & Enterprise Edition

Exchange Server 2003 Standard Edition

Exchange 2003 Standard Edition is designed to meet the

messaging and collaboration requirements of small and

medium corporations and for specific messaging server roles

or branch offices.

• One storage group can be created on a server

• One mailbox store database and one public folder

store database that can be accessed by using MAPI and

Outlook Web Access

• Up to four more public folder store databases that

are accessible only programmatically

• Maximum 16-gigabyte (GB) database limit per

database (75 GB with Microsoft Exchange Server 2003 Service

Pack 2)

• Exchange clustering is not supported

• X.400 connector is not included

Exchange Server 2003 Enterprise Edition

Exchange 2003 Enterprise Edition is designed for large

enterprise corporations. With Exchange 2003 Enterprise

Edition, you can create multiple storage groups and

multiple databases. Exchange 2003 Enterprise Edition

provides an unlimited message store that removes the

constraints on how much data a single server can manage.

• Four storage groups

• Five databases per storage group

• 16 terabyte database limit, limited only by


• Exchange clustering is supported

• X.400 connector is included

Difference between exchange 2007 standard and enterprise edition

Exchange Server 2007 Edition Offerings

Feature Standard Edition Enterprise Edition

Storage Group Support 5 storage groups 50 storage groups

Database Support 5 databases 50 databases

Database Storage Limit 16 TB per database 16 TB per database

Single Copy Clusters Not supported Supported

Local Continuous Replication Supported Supported

Cluster Continuous Replication Not supported Supported

Standby Continuous Replication *** Supported Supported

Exchange Server 2007 Client Access Licenses

Exchange Server 2007 is offered in two client access license (CAL) editions: Standard CAL and Enterprise CAL.

• The Exchange Server Standard CAL provides access to e-mail, shared calendaring and Outlook Web Access (OWA). In addition you will get advancements that reduce the cost and complexity of the messaging system by giving IT Administrators the messaging protection their company demands, the anywhere access their end users want and the reliability they need.

• The Exchange Server Enterprise CAL is an additive CAL and requires that a Standard CAL is also purchased for each user or device. The Exchange Server Enterprise CAL provides access to Unified Messaging and advanced compliance, as well as Forefront Security for Exchange Server and Exchange Hosted Filtering for onsite and hosted antivirus and anti-spam protection.

A CAL is required for each user or device (depending on the license) accessing the server. Either version of the CAL may be run against either version of the server.

Difference between exchange 2003 & exchange 2007

1.Protection: anti-spam, antivirus, compliance, clustering with data replication, improved security and encryption

2.Improved Information Worker Access: improved calendaring, unified messaging, improved mobility, improved web access

3.Improved IT Experience: 64-bit performance & scalability, command-line shell & simplified GUI, improved deployment, role separation, simplified routing

4.Exchange Management Shell: a new command-line shell and scripting language for system administration (based on Windows PowerShell). Shell users can perform every task that can be performed in the Exchange Server graphical user interface plus additional tasks, and can program often-used or complex tasks into scripts that can be saved, shared, and re-used. The Exchange Management Shell has over 375 unique commands to manage features of Microsoft Exchange Server 2007.

5."Unified Messaging" that lets users receive voice mail, e-mail, and faxes in their mailboxes, and lets them access their mailboxes from cell phones and other wireless devices. Voice commands can be given to control and listen to e-mail over the phone (and also send some basic messages, like "I'll be late")

6.Removed the database maximum size limit. Database size is now limited by hardware capability and the window for backups and maintenance.

7.Increased the maximum number of storage groups and mail databases per server, to 5 each for Standard Edition (from 1 each in Exchange Server 2003 Standard), and to 50 each for Enterprise Edition (from 4 groups and 20 databases in Exchange Server 2003 Enterprise).

8.Autodiscover for over the air (OTA) provisioning

9.Out of Office - You can now configure Out of Office messages directly from your mobile device. Setting Out Of Office messages on the PPC device configures the message on the Exchange 2007 server, thus an they can be seen both in Outlook and OWA.

Exchange 2007 has Role base Infrastructure. These are:

Mailbox Role

• Stores Mailboxes and Public folder

Client Access Role

. Client request for mail are fetched by this Role

• Browser-based clients using either the full-featured Outlook Web Access (OWA) or a new OWA Light client

• Mobile devices via Exchange ActiveSync (EAS)

• Phone devices via Outlook by Phone

• POP3 or IMAP4 clients, such as Outlook Express and Eudora

Hub Transport

Responsible for all internal mail flow

Inbound mail are accepted by Edge Transport and passed on to Mailbox server and all outbound mail is relayed from the Hub Transport to the Edge Transport and out to the Internet.

Edge transport

Edge Transport server handles all Internet-facing mail flow, which provides Simple Mail Transfer Protocol (SMTP) relay and smart host services for the Exchange organization.

Unified Messaging

Unified Messaging combines email, voicemail and fax into the Exchange Server databases, and makes this data available to mailbox users via both telephone and computer.

Exchange 2007 System Requirements


• x64 architecture-based computer with Intel processor that supports Intel 64 architecture

• AMD processor that supports the AMD64 platform

• Intel Itanium IA64 processors not supported

• Intel Pentium or compatible 800-megahertz (MHz) or faster 32-bit processor (for testing and training purposes only; not supported in production)


• Minimum: 2 gigabytes (GB) of RAM for Single Roles

• 5 GB of RAM. if Roles are installed on single server.

• 8 megabytes (MB) of RAM per mailbox

• Minimum based on number of storage groups

Disk space

• At least 2.5 GB on the drive on which you install Exchange

• An additional 500 MB of available disk space for each Unified Messaging (UM) language pack that you plan to install

• 200 MB of available disk space on the system drive

• In Exchange 2007 RTM, a hard disk drive that stores the message queue database on an Edge Transport server or Hub Transport server with at least 4 GB of free space

• In Exchange 2007 SP1, a hard disk drive that stores the message queue database on an Edge Transport server or Hub Transport server with at least 500 MB of free space

• Disk partitions formatted as NTFS file systems.

Top 10 new features of Exchange 2007

1. Server roles: A new modular system that configures Exchange as one (or more) of five basic server roles. Choosing a role means enabling only those features necessary to that role, thereby decreasing the surface area for attacks through other features.

2. WebReady Document Viewing: A new option in OWA allows Office documents (Word, Excel, PowerPoint, and PDF) to be accessed as e-mail attachments or through public folders to be displayed as HTML, even if Office isn’t installed on the client PC.

3. Exchange Management Shell: The PowerShell scripting language, specifically optimized for Exchange, offers potent new tools for the day-to-day e-mail administrator.

4. Exchange ActiveSync: Improved direct push e-mail ensures ActiveSync clients receive messages on server connect. Other mobile-friendly features include inline message fetch — the ability to download long attachments without reloading the entire message — and information rights management, which allows users with proper authority to view protected messages without being connected to a server.

5. Exchange Forefront and Exchange Hosted Services: Forefront is a rebranding of the Antigen anti-virus/anti-spam products acquired from Sybari, which together provide a quality local security gateway. The Exchange Hosted Services version, available by subscription, delivers additional security, archiving, and continuity.

6. Outlook Web Access: The latest OWA client is a near-perfect clone of the Outlook 2003 desktop interface. Features and views are nearly the same, and performance is excellent. Incredibly, thin-client deployment becomes a real option.

7. Outlook auto-discover: Exchange 2007 combined with Outlook 2007 means administrators will no longer need to walk to client desktops to configure Outlook access to a specific account location. Users simply enter their user names and passwords, and Outlook automatically finds local Exchange servers, locates the proper e-mail account, and sets up access.

8. Smart scheduling: The addition of Scheduling Assistant and Calendar Attendant mean that Exchange tracks not only the schedules of all meeting invitees but also the availability of meeting rooms and can manage all of this on the server, so meetings can be fully scheduled without everyone’s Outlook client being connected.

9. Improved search: A rewritten search algorithm noticeably boosts the speed at which Outlook can find specific messages in large message stores. Administrators can access the same fast indexing in multiple-mailbox searches.

10. Bundled encryption: Exchange can now automatically encrypt all e-mail messages sent within the local organization. It also automatically supports TSL (Transcript Security Layer) encryption, including built-in certificates, as long as both hosts support TLS.

Local Continuous Replication

Local continuous replication (LCR) is a single-server solution that uses built-in asynchronous log shipping and log replay technology to create and maintain a copy of a storage group on a second set of disks that are connected to the same server as the production storage group. The production storage group is referred to as the active copy, and the copy of the storage group maintained on the separate set of disks is referred to as the passive copy. The following figure illustrates a basic deployment of LCR.

Basic deployment of LCR

Cluster Continuous Replication

With CCR, you create a two-node Windows Server 2003 or Windows Server 2008 cluster and the passive node runs Exchange with its own copy of the database, without any client connections or offered services. You have two copies of the data, one for each node, so this is a shared-nothing model with the data not being a single point of failure. The initial copy of the database is generated through a process called seeding, where the existing database is copied from the active node to the passive node on passive node storage. This initial copy can take a significant amount of time depending on the size of the database. Once the database is in place, the passive node pulls the transaction logs from the active node via a hidden, secured file share. Once the transaction logs are closed, the passive node copies them to an inspector folder, inspects the logs, and then plays the logs into its copy of the mailbox database, thus keeping its database up-to-date.

Microsoft Exchange Server stores consist of two fundamental elements: transaction logs and the database. Information is written to the Extensible Storage Engine memory cache first, then to a transaction log by the log writer, and then to the database (.edb file). The writes to the database are done via another set of writes to memory in the Information Store cache buffers, which are then written to disk by the lazy writer.

In Exchange 2007, the transaction log files are a maximum of 1MB. When a transaction log is full or a certain amount of time has elapsed, a new log file is created and the current log file is renamed in a sequence with the format E(storage group)(8 digit hexadecimal number).log. These transaction logs make their way into the database via various Exchange components, as described above. Once the entire content of a transaction log has its content written to the database, the checkpoint file (Edb.chk) is updated to reflect the transaction has been written to the database and does not need to be re-read in the case of a recovery situation

Transaction logs:

One of the most important components of Exchange server is the transaction logs. Exchange server was designed to write all transactions to these log files and commit the changes to the databases when the system allows. Users can send and receive messages without touching the database thanks to this write-ahead method of logging.

When a message is sent, the transaction is first recorded in the transaction logs. Until the transaction is committed to the Exchange database (EDB), the only existence of this data is in the system memory and the transaction logs. In the event of a crash, you lose the contents of the memory and all you are left with is the record in the transaction log. These transaction logs are crucial to the recovery of a failed Exchange server, whether it was a minor crash that required a reboot, or a more catastrophic failure requiring the deployment of your disaster recovery plans. The same goes for other transactions such as received messages, deleted items and messages moved to different folders.

When an Exchange server is started, and the Microsoft Information Store (Store.exe) comes online. ESE checks the databases to determine whether they are in a consistent state or/and inconsistent state. This information is stored with a flag in the database header and signifies whether the store was shutdown cleanly (consistent) or if there are outstanding transactions in the transaction logs that have yet to be committed. If you want to determine if the database is in a consistent, or inconsistent, state you can use ESEUTIL and append the /MH switch which will check the database header and report the state.

C:\Program Files\Exchsrvr\bin\eseutil /mh “Path\to\file.edb”

Exchange 2007 Roles

Edge Transport Role

The Edge Transport role is installed on the edge of the network and therefore is installed on a standalone server that is not a member of the Active Directory domain. Because the server is not a member of the Active Directory domain, Active Directory Application Mode (ADAM) is used to sync AD with the Edge Transport server. ADAM and a component called EdgeSync are used to perform scheduled one-way synchronization of the configuration and recipient information from Active Directory. This allows the Edge Transport to perform recipient lookups and Spam filtering.

The Edge Transport role performs a number of functions including Anti-spam and Anti-virus protection. The Edge Transport uses connection filtering, content filtering, recipient filtering, SenderID, sender and IP reputation to reduce the amount of Spam delivered to the end users inbox. Mail tagged as Spam will sit in a Spam quarantine from which administrators can delete or allow messages tagged as Spam. One of the top features is the ability for Outlook 2003 and 2007 clients to merge their Spam settings (like white and black lists) to the Edge Transport server to increase the efficiency and accuracy of the filters. The built in VSAPI has been improved and the introduction of transport agents will allow third party AV applications to provide stronger AV filtering.

Edge Transport Rules are used to protect the Exchange organization by applying rules and, based on whether the message passes or fails, appropriate action is taken. Unlike the Anti-virus and Anti-Spam processing, Edge Transport rules are based on SMTP and MIME addresses, words in the subject or message body, and SCL rating. The Edge Transport role also handles address rewriting; in Exchange 2007 an administrator can modify the SMTP address on in or outbound mail.

The Edge Transport server is also responsible for all mail entering or leaving the Exchange organization. Mail travels inbound through the Edge Transport and once the Edge Transport Rules have been applied the message is passed on to the Hub Transport server. Because the Edge Transport is responsible for all in and outbound mail, you can configure multiple Edge Transport servers for redundancy and load balancing.

Hub Transport Role

The Hub Transport role is responsible for all internal mail flow. This role is similar to the bridgehead server in an Exchange 2000/2003 organization. In fact it originally was called the Bridgehead Role until it was changed.

The Hub Transport server, as well as the rest of the server roles, is installed on member server(s) in an Active Directory domain. There is no need for ADAM on this, or any other role aside from the Edge Transport. Because it is a member of an AD domain, all its configuration information is stored in AD and any other Hub Transport servers you install will get their configuration from AD.

Inbound mail is accepted from the Edge Transport and passed on to the user's mailbox and all outbound mail is relayed from the Hub Transport to the Edge Transport and out to the Internet. The Hub Transport and Edge Transport servers are very similar and in fact, one can forgo the Edge Transport server and configure the Hub Transport to accept mail from, and send mail to, the Internet. Hub Transport agents can also be deployed to enforce corporate message policies such as message retention, something that will come as good news to administrators attempting to comply with SarbOx rules.

The Anti-Spam and Anti-virus features of the Edge Transport can be configured on the Hub Transport in order to reduce the number of servers required. It is quite feasible that you may only have one server in your Exchange organization with all the roles installed on it. In this case you cannot have an Edge Transport and all those features will be passed on to the Hub Transport role.

Mailbox Role

The simplest of the roles has to be the Mailbox Role. Quite simply the Mailbox role holds the Exchange databases within which the user mailboxes are contained. It is also home to the Public Folder databases if you enabled Public Folders. (They are not enabled by default in Exchange 2007)

Client Access Role

The Client Access Role is similar to the role a Front-End server would play in an Exchange 2000/2003 organization. The Client Access server is the server that users connect to with their mail client, mobile device, or web browser. The Client Access server handles all connections whether they come from an application such as Outlook 2003 or 2007, Outlook Express, or any other MAPI, POP3 or IMAP4 client. The Client Access server also handles connections made from mobile devices such as a Windows Mobile 5 Smartphone, or any other device using Exchange ActiveSync. Exchange ActiveSync in Exchange 2007 supports all devices with PocketPC 2002/2003 and Windows Mobile 5. Figure 2 shows how all the clients and roles connect to each other.

Exchange 2007's Client Access Server accepts connections from:

Browser-based clients using either the full-featured Outlook Web Access (OWA) or a new OWA Light client

Mobile devices via Exchange ActiveSync (EAS)

Phone devices via Outlook by Phone

POP3 or IMAP4 clients, such as Outlook Express and Eudora

Unified Messaging Role

The last, and in my opinion, coolest role is the Unified Messaging Role. The Unified Messaging role is responsible for merging your VOIP infrastructure with your Exchange organization. What does this allow for?

combined voice, fax, and mail in one inbox

access to voice, fax and mail via multiple interfaces

Need to check your voicemail but all you have is Internet access

Transport Rules

Transport rules and edge rules work in a similar manner but because of some fundamental differences to their intended use there are some differences. That said all rules, whether transport or edge, are made up of the following components.

Condition – The first component of any rule is the condition. This is what triggers the rule to take effect. In an Exchange organization some of the conditions that you may find are things such as sender, recipient, message header; anything that can identify an e-mail message. If a message is passed through an Edge Transport or Hub Transport server and it does not meet any of the conditions specified, it will pass through and continue on its way. However if one of the conditions are met it will run through the rest of the process.

Exception – After a condition is met, the message is checked to see if it meets any exceptions. An exception can be used to fine tune a rule with a general condition. If a message meets one of the conditions applied, but also meets the exception it is released for regular delivery; however if it does not then in continues through the rule processing.

Action – the final stage is the action stage. This is where a message that has met the condition specified, but does not meet an exception has an action taken on it. Here is where a message coming from an external source that contains inappropriate content can be rejected. Another scenario is when an internal user tries to send confidential information to inappropriate people inside or outside your organization.

Eg:- New-TransportRule -Name 'Test Rule –Comments ‘Test rule for Demo’ -Conditions 'Microsoft.Exchange.MessagingPolicies.Rules.Tasks.FromPredicate' -Actions 'Microsoft.Exchagne.MessagingPolicies.Rules.Tasks.LogEventAction' –Exceptions


-Enabled $true -Priority '0'

Autodiscover and Exchange 2007

The Autodiscover service uses a user's e-mail address or domain account to automatically configure the user's profile. By using the e-mail address or domain account, the Autodiscover service provides the following information to the client computer that is running Outlook 2007:

• The user’s display name.

• Separate connection settings for internal and external connectivity.

• The location of the user’s Exchange 2007 server that has the Mailbox server role installed.

• The URLs for Exchange features such as free/busy information, UM, and the OAB.

• Outlook Anywhere server settings. Outlook Anywhere was formerly known as RPC over HTTP.

So when a user starts Outlook 2007 for the first time, they no longer have to specify any information if their computer is joined to the domain. Outlook 2007 will start, gather the information automatically, log the user on to their mailbox, and begin retrieving information from your Exchange deployment.

Public Folder

For those of you who want to use public folders, there are three basic steps you'll need to take to get started:

1. Create the public folder database

2. Modify public folder database settings

3. Create public folders

Step 1: Create the public folder database

You can't create new public folders unless you have public folder infrastructure. That means that you need to have a public folder database in place and mounted. When you use the New-PublicFolderDatabase cmdlet to create a public folder database, you basically set only the name and storage group for the new database.

In addition to creating a public folder database, you may decide to create this database in a separate storage group. For more information about how to create a storage group, see How to Create a New Storage Group.

Create and mount a public folder database

• This command creates a public folder named PFDatabase on the First Storage Group:

New-PublicFolderDatabase -Name "PFDatabase" -StorageGroup "First Storage Group"

• The new public folder database is created in the dismounted state. This command mounts the database created in the previous step:

Mount-Database -Identity "PFDatabase"

Step 2: Modify public folder database settings

After you create and mount the public folder database, you may need to change some of the public folder settings by using the Set-PublicFolderDatabase cmdlet. Modifying public folder database settings is not a task that you will perform every day—it'll usually just be a one-time task. Here are a few examples of some of the things you can change.

Modify information about a public folder database

• This command sets the retention settings for the public folder database named PFDatabase that resides on SERVER01:

Set-PublicFolderDatabase -Identity "Server01\PFDatabase" -DeletedItemRetention 07.00:00:00 -RetainDeletedItemsUntilBackup $true -EventHistoryRetentionPeriod 14.00:00:00 -ItemRetentionPeriod unlimited

• This command sets the storage quota for all public folders in the public folder database named PFDatabase:

Set-PublicFolderDatabase -Identity PFDatabase -IssueWarningQuota 2000MB -QuotaNotificationSchedule "Sun.3:00 AM-Sun.3:15 AM, Tue.3:00 AM-Tue.3:15 AM, Thu.3:00 AM-Thu.3:15 AM"

By using this command, public folder owners will be notified when their public folders meet the storage quota. For more information, see How to View or Modify Public Folder Settings.

• This command sets the public folder referral settings:

Set-PublicFolderDatabase -Identity "Server1\PublicFolderDatabase01" -UseCustomReferralServerList $true -CustomReferralServerList "MBXSERVER01:1","MBXSERVER02:50"


The CustomReferralServerList parameter accepts an array in the following format: serverID:cost. Separate multiple servers with a comma. For more information, see How to Configure Public Folder Referrals.

Step 3: Create public folders

Now it's time to create your public folders. Just like with the public folder database, there are few options that you can set when creating a public folder. This time you'll use the New-PublicFolder cmdlet. For more information about creating public folders, see How to Create Public Folders.

Create a new public folder

• This command creates a new public folder in the root of the public folder tree on the closest Mailbox server that has a public folder database. This is because the command doesn't specify a server or a path:

New-PublicFolder -Name "Legal"


If you don't specify a server, the cmdlet checks if the local server is an Exchange 2007 Mailbox server that has a public folder database. If it is, the public folder is created locally. If it is not, Exchange finds the closest (by site cost) Exchange 2007 Mailbox server that has a public folder database on which to create the public folder.

• This command creates a new public folder named Pending in an existing public folder named Legal on the Mailbox server named My Server:

New-PublicFolder -Name "Pending" -Path \Legal -Server "Server01"

Well, in a nutshell, that's how you get started with public folders. Next, I'll show you how to use the Shell to complete your daily public folder tasks.

Modifying Public Folder Settings

Public folders and mail-enabled public folders have entirely different settings. If the public folder is mail-enabled, you'll use the Set-MailPublicFolder cmdlet. If the public folder isn't mail-enabled, you'll use the Set-PublicFolder cmdlet.

This section shows you how to modify settings for public folders that aren't mail-enabled. For details about how to mail-enable public folders, including how to configure their settings, see Creating and Configuring Mail-Enabled Public Folders.

When you use the New-PublicFolder cmdlet to create a public folder, you're limited in how many settings you can specify. So, after you create the public folder, you'll need to use the Set-PublicFolder cmdlet to customize the folder.

Configure the settings of a public folder

• This command specifies that a public folder can use storage size limits other than the values that are set on the public folder database:

Set-PublicFolder -Identity "\Legal" -UseDatabaseQuotaDefaults: $False


The value for the Identity parameter must include the path. For example, if the public folder named Marketing existed under a parent folder named Business, you would provide the following value: "\Business\Marketing"

• This command specifies that over-storage-quota warnings should be sent when the size of the public folder exceeds 10 megabytes (MB):

Set-PublicFolder -Identity "\Legal\Pending" -StorageQuota 10MB


The -StorageQuota parameter cannot be used when the -UseDatabaseQuotaDefaults parameter is set to True.

Creating and Configuring Mail-Enabled Public Folders

Mail-enabling a public folder provides an extra level of functionality to users. In addition to being able to post messages to the folder, users can send e-mail messages to, and sometimes receive e-mail messages from, the folder. Mail-enabled public folders have different settings than regular public folders. Public folders will have an e-mail address just like a regular e-mail account.

When you use the Enable-MailPublicFolder cmdlet, you're limited in how many settings you can specify. You need to use the Set-MailPublicFolder cmdlet to set some of the more complicated settings.

Mail-enable a public folder

• This command mail-enables the root public folder named Legal:

Enable-MailPublicFolder -Identity "\Legal"

• This command mail-enables the root public folder named Marketing on a server named Server01:

Enable-MailPublicFolder -Identity "\Marketing" -Server "Server01"

• This command mail-enables the public folder named Pending (which is a subfolder of the Legal public folder) and hides the public folder from the address list:

Enable-MailPublicFolder -Identity "\Legal\Pending" -HiddenFromAddressListsEnabled $True

Now that your public folder is mail-enabled, you may want to modify some of the settings. Here are a few of the things you can do.

Configure the settings of a mail-enabled public folder

• This command changes the primary SMTP address of the public folder named Legal to

Set-MailPublicFolder -Identity "\Legal" -PrimarySmtpAddress


You cannot change the primary SMTP e-mail address if the EmailAddressEnabled parameter is set to True. If EmailAddressEnabled is set to True, the public folder uses the defined e-mail address policy. For more information, see Managing E-Mail Address Policies.

• This command disables the e-mail address policy of the mail-enabled public folder named Pending:

Set-MailPublicFolder -Identity "\Legal\Pending" -EmailAddressEnabled $False

• This command assigns a value (string) to the first custom attribute of the mail-enabled public folder named Sales:

Set-MailPublicFolder -Identity "\Legal" -CustomAttribute1 "Legal Information"

• This command sets a 200 megabyte (MB) size limit for the mail-enabled public folder named Legal, after which the folder can no longer send e-mail messages:

Set-MailPublicFolder -Identity "\Legal" -SendStorageQuota 200MB

Viewing Public Folder Information

To keep a handle on your public folders, you'll want to view information about them from time to time. There are a few commands you can use to view public folder information.

1. Get-PublicFolder This cmdlet displays the attributes for all public folders. You can use this cmdlet to view information about both mail-enabled public folders and regular public folders.

2. Get-MailPublicFolder This cmdlet displays mail-related information about mail-enabled public folders.

3. Get-PublicFolderStatistics This cmdlet displays statistical information about public folders, such as folder size and last logon time.

View information about public folders

• These commands display information about the root public folder:



Get-PublicFolder -Identity "\"

• This command displays the names of the root public folder and all the public folders below it in the hierarchy:

Get-PublicFolder -Recurse
Format-List Name

By default, system folders are not displayed. (For example, system folders are not displayed when you run the command Get-PublicFolder -Recurse
Format-List Name.)

• This command displays the names of all the system folders (which are not displayed by default):

Get-PublicFolder -Identity \NON_IPM_SUBTREE -Recurse
Format-List Name

• This command displays information about the public folder named Legal in the root public folder of the server named Server01:

Get-PublicFolder -Identity "\Legal" -Server "Server01"

• This command displays information about the public folder named Pending that is contained in the public folder named Legal:

Get-PublicFolder -Identity "\Legal\Pending"

• This command displays information about the public folder named Legal and all the public folders contained within it:

Get-PublicFolder -Identity "\Legal" -Recurse

• This command displays information about only the public folders that are contained within the public folder named Legal (but not the parent Legal folder or subfolders of the subfolders):

Get-PublicFolder -Identity "\Legal" -GetChildren

• This command pipes the output of the Get-PublicFolder cmdlet to the Format-List command and displays only the names of all public folders:

Get-PublicFolder -Recurse
Format-List Name

• This command displays all public folders in the folder named Legal, but limits the number of results that are returned to 100:

Get-PublicFolder -Identity "Legal" -Recurse -ResultSize 100
Format-List Name


You can use the ResultSize parameter only in combination with the Recurse or GetChildren parameters.

• This command displays all public folders in the folder named Legal, with no limit on the number of results that are returned:

Get-PublicFolder -Identity "Legal" -Recurse -ResultSize Unlimited
Format-List Name

View mail-related information

Although you use the Get-PublicFolder cmdlet to view information about mail-enabled public folders, you'll need to use Get-MailPublicFolder if you want to view mail-related information about mail-enabled public folders. Here's a list of types of information you can view

View mail-related information about mail-enabled public folders

• This command displays the names of all mail-enabled public folders:

Get-PublicFolder "\" -Recurse -ResultSize Unlimited
Get-MailPublicFolder -ErrorAction SilentlyContinue
Format-List Name


Setting the ErrorAction parameter to SilentlyContinue stops errors from displaying when folders that are not mail-enabled are encountered by the command.

• This command displays the information about a specific mail-enabled public folder in a table format:

Get-MailPublicFolder -Identity "\Legal"

• This command displays mail-related information about the mail-enabled public folder named Pending that is contained in the folder named Legal:

Get-MailPublicFolder -Identity "\Legal\Pending"

• This command displays mail-related information about a mail-enabled public folder and connects to the domain controller named Contoso01-DC:

Get-MailPublicFolder -Identity "\" -DomainController "Contoso01-DC"

View public folder statistics

Viewing the statistics of a public folder allows you to see information such as the display name, creation time, last modified time, and item size.

View public folder statistics

• This command displays the statistics for a public folder named Pending that is contained in the folder named Legal with a piped command to format the list:

Get-PublicFolderStatistics -Identity "\Legal\Pending"

• This command displays the name and item size for all the public folders on Server01:

Get-PublicFolderStatitics -Server "Server01"
Format-List Name,ItemSize

Modifying Client Permissions

After you've created your public folders, you'll want to determine who owns, edits, and views the public folders. Before you mess with permissions, you should read Configuring Public Folder Permissions.

You can use the Add-PublicFolderClientPermission cmdlet to add permissions, or you can use scripts to add public folder client permissions. Before you use any of the scripts in the following examples, you should read Scripts for Managing Public Folders in the Exchange Management Shell.

Add client access rights to a public folder

• This command adds Publishing Editor permissions for the user Kim to access the public folder named West Coast:

Add-PublicFolderClientPermission -Identity "\Marketing\West Coast" -AccessRights PublishingEditor -User Kim

• This script adds Reviewer permissions for the user David to access the top-level public folder named Sales and all of the public folders contained within the Sales tree:

AddUsersToPFRecursive.ps1 -TopPublicFolder "\Sales" -User "David" -Permission Reviewer

Sometimes, you need to remove a user's permissions to public folders. Here are some examples for getting that done. You can use the Remove-PublicFolderClientPermission cmdlet or a script to remove permissions.

Remove a client user's permissions to access a public folder

• This command removes the user David's permissions to create items in the public folder named Oregon:

Remove-PublicFolderClientPermission -Identity "Sales\West Coast\Oregon" -User David -AccessRights CreateItems

• This script removes the user David and replaces him with the user Kim to access items in the public folder Sales and all folders under it:

ReplaceUserWithUserOnPFRecursive.ps1 -TopPublicFolder "\Sales" -UserOld "David"


Exchange Server 2007 uses queues as temporary repositories for messages until they're processed. There are five different types of messaging queues in Exchange Server 2007:

 Submission queue

 Mailbox delivery queue

 Remote delivery queue

 Poison message queue

 Unreachable queue

Submission queue

The submission queue is probably the most important messaging queue in Exchange Server 2007.

The submission queue is related to the submission task, which refers to the process of adding a message to the transport pipeline. Any message that passes through the Exchange Server 2007 transport enters the pipeline through the submission process. There are four ways in which submission can occur.

SMTP submission -- This process involves an outside entity that sends an SMTP message to the organization. The message enters the organization through an Edge Transport server, which scrutinizes the message to make sure that it's not spam. The Edge Transport server then routes the message through a receive connector to a Hub Transport server, where it is submitted into the submission queue.

Directories -- Submission also occurs when a correctly formatted message is copied into either the replay directory or the pickup directory. These directories exist by default on every Exchange 2007 server that's hosting Edge Transport Server or Hub Transport Server roles.

The replay directory links foreign mail gateways to an Exchange Server. When messages arrive through the foreign gateway, they are placed into the replay directory for submission and delivery.

The pickup directory tests mail flow. Administrators can place correctly formatted messages into this folder, and they will be submitted and eventually delivered. Although the pickup directory was designed mainly for testing, some applications place messages into the pickup directory to send them.

Store driver -- When a user composes and sends an email message through Microsoft Outlook, the message is sent through the Mailbox server hosting the user's mailbox. Instead of trying to deliver the message itself, the Mailbox Server hands the message off to the store driver, which places it into the submission queue.

Agents -- The transport agent might generate and submit messages, for example. Once messages are submitted into the submission queue, the SMTP categorizer handles them. How the categorizer works differs, depending on whether it's running on a Hub Transport server or an Edge Transport server.

If the categorizer is running on an Edge Transport Server role, its responsibilities are minimal. The categorizer places messages into the delivery queue directly. Messages from an Edge Transport server are delivered to a Hub Transport server, not to final recipients.

On the Hub Transport server, the categorizer must perform three primary tasks:

Recipient resolution -- The categorizer determines who will receive the message. If distribution lists are involved, then they are expanded. If journaling is enabled, then that also takes place at this stage.

Routing decisions -- The categorizer must determine how to route the message. Routing is based on a message's intended destination, and typically falls into one of four categories:

1. Messages intended for Internet recipients

2. Messages intended for recipients with mailboxes on Mailbox servers that reside in the same Active Directory site as the Hub Transport server

3. Messages intended for recipients with mailboxes on Mailbox servers that reside in a different Active Directory site than the Hub Transport server

4. Messages intended for recipients whose mailbox resides on a legacy Exchange server

Mailbox delivery queue

Mailbox delivery queues are located only on Hub Transport servers and are used to deliver messages to recipients with mailboxes within the Exchange Server organization. Therefore, if a message is intended for a recipient within your Exchange organization, that message will flow through the submission queue first. It then will be placed into the mailbox delivery queue. From there, the message is sent to the mailbox server using an encrypted remote procedure call (RPC).

Remote delivery queue

When a user sends an SMTP message intended for a recipient in a remote domain, that message passes through the submission queue into the remote delivery queue. From there, the message is forwarded to its final destination.

Remote delivery queues can exist on both Hub Transport and Edge Transport servers. This queue isn't used solely to deliver SMTP messages to servers and remote domains. It's used to deliver messages to any destination outside an Active Directory site that contains the Hub Transport or Edge Transport server that the queue exists on. In most cases, this means that the remote delivery queue will be used to send messages across the Internet.More Exchange Server 2007 mail flow resources:.In large organizations though, the remote delivery queue can be used to send messages to other parts of the Exchange Server organization.

Poison message queue

When either a Hub Transport or Edge Transport server fails, some messages passing through the queues at that time could become corrupted. When the server reboots, Exchange Server temporarily suspends all message queues and checks messages within those queues to ensure that they won't be harmful to the Exchange Server. The server deems harmful messages as poison. Such poison messages might cause a queue to freeze, for example.

Exchange Server 2007 moves poison messages to the poison message queue, which remains suspended at all times to prevent delivery of these messages. Every Hub Transport server and Edge Transport server has its own poison message queue. When the queue is empty, Exchange Server hides it from view. The queue becomes visible if a message enters it. This allows you to use the Queue Viewer to examine and/or delete poison messages.

Unreachable queue

Messages initially enter the transport pipeline through the submission queue. There, they're sorted into other queues based on their destination. Occasionally, a message with an invalid destination may make it into the transport pipeline. When this message is encountered, Exchange places it into the unreachable queue.

The main database file is called mail.que and by default can be found here:

C:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue

The other files are in the locations as described below:

Trn.chk - The checkpoint file.

Trn.log - The current transaction log file.

Trntmp.log - The next provisioned transaction log file that is created in advance.

Trnnnn.log - Other transaction log files that are created when Trn.log reaches its maximum size.

Trnres00001.jrs - The Reserve log file.

Trnres00002.jrs - The Second Reserve log file.

Temp.edb – Temp DB used to verify database schema on start-up.

Just before we move on to another area, it is worth stating how to move the queue databases. One important reason for moving the Queue DB and logs is performance. Another slightly less well known reason is that the drive on which the Queue DB and logs are stored must have 4GB or more free space otherwise the server will apply back pressure and start slowing the flow of messages!

When moving the DB, the usual rules for splitting transaction logs and DB files apply. To move the databases you must edit the EdgeTransport.exe.config file which by default is located at the location below and then stop and restart the msexchangetransport service:

C:\Program Files\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config

The other actions which you can perform in queue viewer are shown below:

Suspend queue This action temporarily prevents delivery of messages that are currently in the queue.

Resume queue The opposite of Suspend queue.

Retry queue When a connection to the next hop for a queue fails, a retry timer is set. This forces an immediate connection attempt.

Suspend message This action temporarily prevents delivery of a single message.

Resume message The opposite of Suspend message.

Remove message This action permanently prevents delivery of a message.

Export message This action copies a message to the file path that you specify. The messages are not deleted from the queue, but a copy of the message is saved to a file location. Before you export a message, you must suspend the message in the queue.


Remove (with NDR)

To remove a message from a queue and submit a non-delivery report (NDR) to the sender, select the message and then click Remove messages (with NDR).

NDR messages are not sent for NDR messages that are removed by using the Remove (with NDR) action.

Remove (without Sending NDR)

To remove a message from a queue without sending an NDR, select the message and then click Remove (without sending NDR).

The message properties that you can use to create filter expressions or display in the columns of the Messages page are described in the following list:

Date Received

This field shows the date-time when the message was received by the server that holds the queue in which the message is located.

Expiration Time

This field shows the date-time when the message will expire and will be removed from the queue if the message cannot be delivered.

From Address

This field shows the Simple Mail Transfer Protocol (SMTP) address of the sender of the message. This value is taken from MAIL FROM: in the message envelope.


This field shows the integer that represents a particular message. The message identity is assigned by the queue database when the message is received for processing. You can include an optional server and queue identity to identify a unique instance of the message.

Internet Message ID

This field shows the value of the MessageID: header field. The value is expressed as a GUID followed by the SMTP address of the sending server, as in this example:

Last Error

This field shows the last error that was recorded for a message.

Message Source Name

This field shows the name of the component that submitted this message to the queue.

Queue ID

This field shows the identity of the queue that holds the message. The queue identity is expressed in the form Server\destination, where destination is a remote domain, mailbox server, persistent queue name, or the queue database identifier. The queue database identifier is represented as an integer and can be determined by viewing the message properties.

Retry Count

This field shows the number of times that delivery of a message to a destination was tried.


This field shows the spam confidence level (SCL) rating of the message. Valid SCL entries are integers 0 through 9. An empty SCL entry indicates that the message hasn't been processed by the Content Filter agent.

Size (KB)

This field shows the size of the message rounded up to the nearest kilobyte (KB).

Source IP

This field shows the IP address of the external server that submitted the message to the Exchange organization.


This field shows the current message status. A message can have one of the following status values:

Active If the message is in a delivery queue, the message is being delivered to its destination. If the message is in the Submission queue, the message is being processed by the Categorizer.

Suspended The message was suspended by the administrator.

Pending Remove The message was deleted by the administrator but was already in delivery. The message will be deleted if the delivery ends in an error that causes the message to re-enter the queue. Otherwise, delivery will continue.

Pending Suspend The message was suspended by the administrator but was already in delivery. The message will be suspended if the delivery ends in an error that causes the message to re-enter the queue. Otherwise, delivery will continue.

Ready The message is waiting in the queue and is ready to be processed.

Retry The last connection attempt failed for the queue in which this message is located. The message is waiting for the next queue retry.

Subject This field shows the subject of a message and is expressed as a text string. The value is taken from the Subject: header field.

Shell Command

get-command *queue*

Remove-Message -Filter {FromAddress -like "**" -and SCL -gt 5} -withNDR $false

SMTP categorizer

The SMTP categorizer (also referred to as the categorizer) is a component of the Exchange Server 2003 transport engine. When a message is submitted to the transport process, the categorizer uses the header information on the message to query Active Directory for information about how and where the message must be delivered. For example, from an SMTP address such as, the categorizer identifies the Exchange Server 2003 server that contains the user's mailbox and determines how to route the message to that server. The categorizer also expands distribution lists and applies per-user limits to messages. For more information about the architecture of the SMTP transport engine, see SMTP Transport Architecture.

The categorizer relies on DSAccess for the list of Active Directory servers that it should use for lookups. However, like DSProxy, the categorizer uses its own mechanism to read information from Active Directory, only after it has the server list.

There are two types of categorizers. One is the base categorizer, which is installed with the IIS SMTP transport stack, and the other is the Exchange categorizer, which is installed with Exchange. The base categorizer is implemented in Aqueue.dll. The base categorizer performs some basic functions, such as using LDAP queries to resolve recipient information against Active Directory. It also performs efficient batching, sending a number of queries as one. The base categorizer can also perform distribution list expansion. It has the SMTP forwarding features, and it triggers categorizer server events. Exchange Server 2003 enhances the basic categorizer by installing a DLL called PhatCat.dll. The PhatCat.dll adds to the functionally provided by the base categorizer. It does not replace the base categorizer default functionality, but it does extend the base categorizer functionality for its own use.

Transport agents

Transport agents let you install custom software, created by Microsoft, by third-party vendors, or by your organization, on a computer that is running Microsoft Exchange Server 2007. This software can then process e-mail messages that pass through the transport pipeline on a Hub Transport server or Edge Transport server. Custom transport agents provide additional functionality to Exchange 2007, such as anti-spam or antivirus programs or any transport function that your organization may require.

Transport agents have full access to all e-mail messages that they encounter. Exchange puts no restrictions on a transport agent's behavior. Transport agents that are unstable or contain security flaws may affect the stability and security of Exchange. Therefore, you must only install transport agents that you fully trust and that have been fully tested in a test environment.

You cannot administer transport agents by using the Exchange Management Console. To administer transport agents, you must use the Exchange Management Shell. For more information about how to use the Exchange Management Shell

Install-TransportAgent -Name <"TransportAgentID"> -TransportAgentFactory <"TransportAgentFactory"> -AssemblyPath <"FilePath">

When you install a transport agent by using the Exchange Management Shell, Exchange 2007 only registers the DLLs that are associated with the transport agent. You must make sure all files, registry keys, and other objects that the transport agent depends on are installed correctly and configured. After Exchange loads the DLLs, it continues to reference the DLLs after the command has completed.

Transport agents are installed in a disabled state to make sure mail flow is not affected by transport agents that have not yet been configured. After a transport agent has been configured correctly, use the following command to enable the Transport agent:


To use the Exchange Management Shell to install a new fictitious transport agent that scans messages for viruses

Run the following command:

Install-TransportAgent -Name "Antivirus for Exchange" -TransportAgentFactory "" -AssemblyPath "c:\Program Files\Vendor\TransportAgent\AvTransportAgentFactory.Dll"

To enable the newly installed transport agent, use the following command:

Enable-TransportAgent "Antivirus for Exchange"

To use the Exchange Management Shell to view a summary list of all transport agents


Viewing Detailed Configuration of a Specific Transport Agent


Exchange 2007

Frequently Asked Questions

Q: What is Exchange Server 2007?

A: Microsoft Exchange Server 2007 is the next version of Microsoft Exchange. Microsoft Exchange is the industry's leading e-mail, calendaring, and unified messaging server. The release of Exchange Server 2007 is closely aligned with the 2007 Microsoft Office release. Together, these products deliver a best-in-class enterprise messaging and collaboration solution.

Q: What's new in Exchange Server 2007?

A: Exchange 2007 provides built-in protection to keep the e-mail system up and running and protected from outside threats and lets employees work more productively from wherever they are by using a variety of clients. These clients include Microsoft Office Outlook 2007, Microsoft Office Outlook Web Access, and mobile devices. Exchange Server 2007 makes it easier for IT departments to deliver these new capabilities to their organizations by making the messaging environment easier to manage and more cost-efficient. For more information about Exchange Server 2007, see What's New in the Exchange 2007 product documentation.

Q: How does Exchange Server 2007 integrate with Microsoft Office Outlook 2007?

A: Outlook 2007 provides the most complete e-mail, calendaring, contacts, and tasks functionality available in an e-mail client that is compatible with Exchange. When Outlook 2007 is used with Exchange Server 2007, users benefit from the new Scheduling Assistant that automates time-consuming meeting and resource scheduling, the ability to plan and customize out-of-office communications, and managed e-mail folders that facilitate compliance with internal and regulatory policies. Outlook 2007 and Exchange Server 2007 also combine to enhance security by offering features that are easy to use and let users confidently send and receive sensitive business communications through e-mail. By enabling the Autodiscover service, you can reduce the complexity of client configuration and reduce administrative costs that are associated with troubleshooting connectivity issues for users.

Q: Where can I find Microsoft Exchange Server 2007 product documentation?

A: You can find Exchange Server 2007 product documentation on the Exchange Server 2007 Technical Library Web site, on the Start menu, or by clicking F1 within the product after it has been installed. You can also access product documentation from the Microsoft Exchange Server TechCenter. You can visit the Exchange Server Community Web site or the Exchange Team Blog Web site for additional product information, common issues, and troubleshooting assistance.

Q: What are the Exchange Server 2007 licensing options?

A: Customers can purchase the Exchange Enterprise Client Access License (CAL) or the Exchange Standard CAL. The Exchange Enterprise CAL is sold as an add-on to the Exchange Standard CAL. Two server editions will continue to be offered: Exchange Server Enterprise Edition and Exchange Server Standard Edition. You can run either CAL together with either server edition. For more information about Exchange Server 2007 editions and Client Access Licenses, see Exchange Server 2007 Editions and Client Access Licenses.

Q: What do I get with the Exchange Enterprise CAL vs. the Exchange Standard CAL?

A: In addition to the improvements and new capabilities that are available with the Exchange Standard CAL, the Exchange Enterprise CAL includes Unified Messaging, advanced compliance capabilities, and on-premises and hosted antivirus and anti-spam protection. For more information about Exchange Server 2007 editions and Client Access Licenses, see Exchange Server 2007 Editions and Client Access Licenses.

Q: What are the different editions of Exchange Server 2007?

A: Exchange Server 2007 is offered in two server editions: Standard Edition and Enterprise Edition. Exchange Server 2007 Standard Edition is designed to meet the messaging and collaboration needs of small and medium organizations. It may also be appropriate for specific server roles or branch offices. Exchange Server 2007 Enterprise Edition, designed for large enterprise organizations, enables the creation of multiple storage groups and databases. For more information about Exchange Server 2007 editions and Client Access Licenses, see Exchange Server 2007 Editions and Client Access Licenses.

Hardware and Software Requirements

Q: Will I have to buy new hardware to run Exchange Server 2007?

A: If you are running 64-bit hardware in your current messaging environment, you may not have to buy additional hardware. However, Exchange 2007 does require hardware and an operating system that are 64-bit. 64-bit hardware provides the system architecture that is required to support the increased memory, storage, and enhanced security requirements in a more cost-effective manner. For more information about how to select the hardware for Exchange 2007, see How to choose server hardware for Exchange Server 2003 that can be effectively re-used for Exchange 2007.

Q: Which 64-bit processors are supported by Exchange Server 2007?

A: Exchange Server 2007 supports servers that have "x64" processors. Most new servers include processors from Intel and AMD that provide this x64 support. The Intel processors are called Intel Extended Memory 64 Technology (EM64T), and the AMD processors are called AMD64. Exchange Server 2007 does not support Itanium (IA-64) processors.

Q: Should servers that are running Active Directory domain controllers and the global catalog be upgraded to 64-bit?

A: For the best performance, when an Active Directory organization contains more than 20,000 objects, you should upgrade to 64-bit. Upgrading servers that run Active Directory domain controllers and the global catalog to 64-bit improves the overall performance and scalability of your Exchange Server 2007 environment. However, 32-bit domain controllers are still supported.

Lookup and response times between the Exchange 2007 categorizer and the Active Directory directory service will improve with the use of 64-bit. The size of the Extensible Storage Engine (ESE) database that holds Active Directory can frequently be larger than 3.0 gigabytes (GB). This prevents caching of the contents of the whole database, and therefore increases lookup and response times. By using 64-bit, the available RAM for caching can be increased beyond 4.0 GB. This is large enough to cache the whole ESE database, even for large Active Directory organizations, and will improve Exchange 2007 lookup and response times.

Q: Will I need the 64-bit version of Windows Server 2003 to run Exchange Server 2007?

A: You will need the 64-bit version of Windows Server 2003 or Windows Server 2003 R2 to deploy Exchange 2007. Volume licensing customers can exchange their 32-bit version of Windows Server 2003 for the 64-bit version any time by using their media kits.

Q: How can I upgrade my current Exchange 2000 Server or Exchange Server 2003 environment?

A: When you upgrade to Exchange Server 2007, you cannot perform an in-place server upgrade on an existing Exchange server. Instead, you must install a new Exchange 2007 server into the existing organization, and then move the required data to the new Exchange server. Exchange Server 2007 supports mixed environments that include Exchange 2000 Server, Exchange Server 2003, or both. This allows for an easier and more gradual transition. For more information about how to plan and deploy Exchange Server 2007, see the Microsoft Exchange Server 2007 product documentation.

Active Directory

Q: Should I map my current routing groups to my current Active Directory sites?

A: Yes. Exchange 2007 is based on Active Directory sites. If your current Microsoft Exchange environment maps as closely as possible to Active Directory sites, your interoperability and migration story will be easier. Additionally, the recommended upgrade path is to upgrade all the Exchange 2000 Server or Exchange Server 2003 servers in a single routing group before you upgrade the next routing group. This lets you fully decommission a routing group as you upgrade and reduces the complexity of your current routing topology. Mapping the Exchange 2000 Server or Exchange Server 2003 routing groups to the Exchange 2007 physical topology also makes it easier to plan for an upgrade to Exchange 2007 because the two environments are similarly organized and generally correlate to Active Directory sites.

Q: Should I create a dedicated Active Directory site for Exchange Server 2007?

A: You can deploy Exchange Server 2007 directly into your organization's existing Active Directory topology. For many organizations, deploying directly into the existing Active Directory topology greatly simplifies the overall management of the Exchange 2007 deployment. However, given the extensive access to domain controllers and global catalog servers that is required by Exchange 2007, you may decide to create dedicated sites for your organization. You might want a dedicated site if other applications in your organization must access Active Directory domain controllers and the global catalog server.

Q: Why do I have to disable link state routing?

A: Link state routing must be disabled whenever two or more routing groups are configured to send or receive mail from an Exchange 2007 computer that has the Hub Transport server role installed. (The Hub Transport server was formerly known as a bridgehead server). This is because Exchange 2007 uses Active Directory to determine routing topology. The Exchange 2007 servers do not propagate link state updates. If link state routing is enabled and there is more than one routing group configured to send mail to or from an Exchange 2007 Hub Transport server, routing loops might occur.

Q: Why are routing groups not used in Exchange Server 2007?

A: Exchange 2007 uses Active Directory sites to replace routing groups. Using Active Directory is more efficient because it allows for site awareness and eliminates the requirement to create and maintain a routing topology that is separate from an organization's physical topology.

Exchange 2007 Server Roles

Q: Can the Exchange 2007 server roles be deployed and configured on the same physical hardware?

A: Because Exchange 2007 is role-based, you can deploy all Exchange Server 2007 server roles, except the Edge Transport server role on a single physical server. If you are clustering, you cannot deploy the Mailbox server role on the same server as the Client Access, Unified Messaging, Hub Transport, or Edge Transport server roles. When the server roles are installed on the same or shared hardware, they function as separate entities.

Q: Why must I deploy an Exchange 2007 server that has the Client Access server role installed in every Active Directory site that contains user mailboxes?

A: Installing the Client Access server role in every Active Directory site that contains user mailboxes reduces the use of corporate bandwidth by redirecting the connection to the Client Access server that is in the same Active Directory site in which the user's mailbox is contained.

Q: What if the Client Access server role is not available from the Internet?

A: You can disable redirection for the Client Access server. The Internet-accessible Client Access server will act as an HTTP proxy to the Client Access server that is located in the same site as the user's mailbox.

Q: Why must I deploy an Exchange 2007 server that has the Hub Transport server role installed in the same Active Directory site in which I deployed an Exchange 2007 server that has the Unified Messaging (UM) server role installed?

A: Unified Messaging servers submit voice mail and fax messages to a Hub Transport server by using SMTP. This can occur only if they are deployed in the same Active Directory site.

Q: Why must I deploy an Exchange 2007 server that has the Client Access server role installed in the same Active Directory site in which I deployed an Exchange 2007 server that has the Unified Messaging server role installed?

A: Unified Messaging Web services that run on the Client Access server enable full client functionality for UM-enabled users. Additionally, installing and configuring a Client Access server in the same site as the Unified Messaging servers reduces the bandwidth that is required if they are deployed in separate Active Directory sites.

Q: What is the Autodiscover service?

A: The Autodiscover service gathers the required configuration information in Active Directory to enable Outlook 2007, Office Outlook Web Access, and mobile e-mail clients to efficiently locate and connect to the appropriate Exchange 2007 Mailbox server that contains the user's mailbox. The Autodiscover service is also used to make configuring Outlook 2007 clients easier and to provision mobile devices that are used to connect to Exchange 2007. By default, the Autodiscover service is enabled.

Exchange 2007 Management

Q: Can I manage Exchange Server 2003 or Exchange 2000 Server by using Exchange Server 2007 management interfaces?

A: No. All administration of Exchange Server 2007 must be done by using the Exchange Management Console or the Exchange Management Shell. All administration of Exchange 2000 Server or Exchange Server 2003 must be done by using their respective administrative interfaces. The one exception to this rule is that you can use Exchange System Manager found in Exchange Server 2003 to perform most Exchange Server 2007 public folder administrative tasks.

Q: What is happening with public folders?

A: Public folders are similar to mailbox stores, but the information within a public folder store is contained within a dedicated database. Exchange 2007 de-emphasizes public folders. Public folders may not be included in future releases, but support for public folders will be maintained through at least 2016. Current Microsoft Exchange customers should plan to migrate to Outlook 2007 and Exchange 2007. We recommend that you investigate integrating Microsoft Windows SharePoint Services with Exchange Server 2007 if you must have an application that supports sharing documents, calendar items, contacts, and tasks and archiving distribution lists. For other customized applications that are being developed, you should use Microsoft .NET.

Q: How do I set exchange 2007 to suppress out of office message going to distribution groups?

A: On the Set-DistributionGroup cmdlet, or the Set-DynamicDistributionGroup cmdlet, use the SendOofMessageToOriginatorEnabled parameter allows Out of Office messages to be delivered to the senders of e-mail messages that are sent to this distribution group. Just set it to $false, which is the default setting.

Exchange Management Shell

Basic Tips which we will get while opening the window


Tired of spam? Who isn't? You can configure real-time block list (RBL) providers with the Exchange Management Shell by running the following two commands:

1) Set-IPBlockListProvidersConfig -Enabled $True -ExternalMailEnabled $True

and then

2) Add-IPBlockListProvider -Name -LookupDomain -AnyMatch $True

Basic Command

1. Get-MailboxStatistics -server del-msg-01
export-csv c:\filename.csv

Result :-Display name,mailbox Itemcount,storage limit status)

2. Get-MailboxDatabase 'DEL-MSG-01\First Storage Group'

Result :- Provides the database details

3. Get-Mailbox -Server del-msg-01

Result :- Name ,Alias,ServerName,ProhibitSendQuota

Taking member list from a DL

Get-DistributionGroup –Identity “DistributionGroup Name”
select-object name,primarysmtpaddress
out-file c:\grolupname.txt

For send mail access list

Get-DistributionGroup -Identity "DistributionGroup Name"
Select-Object AcceptMessagesOnlyFrom,AcceptMessagesOnlyFromDLMembers -wrap
out-file c:\allow\AccessHOAllUser.txt

For Group owner Info

Get-DistributionGroup -Identity "DistributionGroup Name"
Select-Object ManagedBy
export-csv c:\groupowner\AccessHOAllUser.txt

Managed by(Right to change the group members)

Add-ADPermission -Identity "test-idgroup" -User smtpaddress -AccessRights "writeproperty" -Properties "member"

Full access for a mailbox

Add-MailboxPermission -Identity "smpaddress" -User "" -Accessright Fullaccess

Send as

Add-ADPermission "Mailbox" -User "Domain\User" -Extendedrights "Send As"

Mailbox Quota assigned for a server

Get-Mailbox –Server del-Msg-01
Format-Table Name,Database,*quota*
out-file c:\storagegroup.txt

Last Logon time

Get-mailbox -Resultsize unlimited –server ho-srv-mbx-01
select-object DisplayName,TotalItemSize,StorageLimitStatus,LastLogonTime
out-file c:\fn.txt

Mailbox size in Mb’s

Get-mailbox -Resultsize unlimited –server ho-srv-mbx-04
select-object Database,DisplayName,@{expression={$_.totalitemsize.value.ToMB()}}
out-file c:\details.txt

Mailbox quota assigned for mailbox’s in a particular database

Get-Mailbox -Database "Database name"
Sort -Property DisplayName
ft DisplayName, *quota >> c:\filename.txt

Tracking by sender

get-messagetrackinglog -Sender "smtp address" -EventID "SEND" -Start "01/27/2009 12:01:00 AM" -End "01/27/2009 11:59:00 PM" -resultsize unlimited
Select-Object timestamp,Sender,@{expression={$_.recipients}},MessageSubject,EventId,RecipientCount
export-csv d:\filename.csv

Tracking by Recipient

get-messagetrackinglog -Recipients:smtp address -EventID "RECEIVE" -Start "01/27/2009 12:01:00 AM" -End "01/27/2009 11:59:00 PM" -resultsize unlimited
Select-Object timestamp,Sender,@{expression={$_.recipients}},MessageSubject,EventId,RecipientCount
export-csv d:\filename.csv

Public Folder client permission using Shell

Checking the current Permission

Get-PublicfolderclientPermission –Identity \”Public Folder name” –user “user name”

Giving Permission(owner/contributor/default/Author..)

Add-PublicFolderClientPermission -Identity \"Public Folder name" -user “User Name” -accessright Contributor

Removing a Permission

Remove-PublicFolderClientPermission -Identity \"Public Folder name" –user “User Name” -accessright Contributor

Powershell command to delete the calendar item with specific keywords in the subject and from a specific sender from any Calendar in the Organization. Below is the script:

Export-Mailbox -SenderKeywords -SubjectKeywords "enter keywords here" -IncludeFolders "\Calendar" -DeleteContent

The above command will search every mailbox in the Organization and delete the meeting request meeting both the conditions mentioned

If you want to delete the meeting request from a particular users' calendar, you can use:

Export-Mailbox -Identity -SenderKeywords -SubjectKeywords "enter keywords here" -IncludeFolders "\Calendar" -DeleteContent

If you want to test if the rules are matching the required criteria before deleting, you can export the item to another test mailbox, using:

Export-Mailbox -Identity -TargetMailbox -SenderKeywords -SubjectKeywords "enter keywords here" -IncludeFolders "\Calendar"

Send a mail using command prompt

smtpsend -f sender mail id -t recipient id -h smtpserver

Who Invented the Computer

Babbage invented a 'counting machine' called The Difference Engine.

The abbreviation for computer is “Common Operating Machine Particularly Used For Technical Education And Research.