10.1 ESM and other consoles

---

Exchange divides basic administration into two areas: users and servers. On Exchange 2000 servers, you perform user management through Active Directory Users and Computers, and server management through the Exchange System Manager console (ESM). The logic here is that you are acting on quite different objects. Users, which include contacts and groups, are AD objects that may or may not be mail enabled. Users are stored in AD organizational units (OUs). Servers are also AD objects, but the AD holds server details in quite a different naming context or location. Along with other organizational data such as connectors, details of Exchange servers are stored within the Microsoft Exchange container in the AD configuration NC.

ESM (Figure 10.1) brings all of the common server administrative tasks together into one place and is the closest equivalent you can find to the previous Exchange 5.5 administrator program. The original intention, as expressed in Exchange 2000, was that a clear separation existed between the tasks that Exchange administrators perform and the work that AD administrators do. Therefore, Microsoft designed ESM as the primary tool to manage the overall shape of the Exchange organization (administration and routing groups), as well as organization-wide components such as recipient and server policies. It is certainly true that such a separation exists in some companies, but it is more common to find that an Exchange administrator also takes care of Exchange-related AD account maintenance, so dividing tasks across multiple consoles occasionally confused administrators. For this reason, Microsoft changed ESM in Exchange 2003 by supporting the option to perform "Exchange tasks" (such as move mailbox) within ESM. Previously, you had to do this through AD Users and Computers. When you think about the subject, it is more logical to be able to move mailboxes from ESM, because you view mailboxes grouped in stores rather than the user-centric view presented by AD Users and Computers. Note that you can move multiple mailboxes in one operation, including the ability to schedule the move during off-peak hours.

Figure 10.1: Managing Exchange through ESM.

Microsoft recognized that ESM functionality was weak in some other areas, so it upgraded ESM in Exchange 2003 to include the following features:

• Support extensions to existing options, such as public folder creation and population. Previously, you could only view the public folder hierarchy and view the status of folders. Now you can use ESM to work with public folders in much the same way as the Outlook Web Access client.

• Enhance the UI and functionality of other options, such as the Queue Viewer and the Message Tracking Center.

• Show whether a server is a standard (basic) server, front-end, or virtual server running in a cluster. ESM also displays the edition of Exchange running on the server. As you can see in Figure 10.2, the routing group contains a standard server running an evaluation version of the Enterprise edition of Exchange 2003 and a virtual server on a cluster. Note that clusters never report an evaluation copy, even if they run this software. Exchange 5.5 servers always report that they run the standard edition, even if they run the enterprise edition.

  
  Figure 10.2: Server types shown by ESM.

• Support new options, such as Exchange Mobile Services, the Mailbox Recovery Center, and the antispam measures now available through connection, recipient, and sender filters.

• Add an Internet Mail wizard to help inexperienced administrators (or those who simply need some help along the way) to create and configure email links to the Internet. Microsoft's analysis of calls reported to its support groups identified this as a major source of problems, so it made sense to automate the process.

• Add extra information gathered from clients to the columns available in ESM. Currently, only Outlook 2003 clients populate this information, but this may change in the future. Figure 10.3 shows some of the information you can expect to see, while Table 10.1 lists the most important of the new fields. The Exchange 2003 WMI providers expose this information to system management applications, so you can write your own code to take advantage of the data.

  
  Figure 10.3: New ESM columns.

  Table 10.1: Additional Columns Available to ESM 2003

  Column	Meaning
  Adapter Speed	NIC speed reported by the client in Kbits/second
  Client IP Address	IP address of the client
  Client Mode	Three values: 0 (unknown)-possibly a server application such as an antivirus agent; 1 (online); 2 (cached)
  Client Name	FQDN of the client workstation
  Latency	Last round-trip latency for RPC between client and server, reported in milliseconds
  MAC Address	Hardware address of the client
  Locale ID	Number of the locale ID of the client (1033 = English)
  Full Mailbox Directory Name	AD distinguished name of the mailbox
  Full User Directory Name	AD distinguished name of the user account connecting to the mailbox
  Open Messages	Current number of messages open by the client
  Open Attachments	Current number of attachments open by the client
  Code Page	Code page used by the client
  Host Address	Blank for Outlook clients; OWA clients report IIS-HTTP-DAV

The larger your organization, the more work ESM has to do to fetch and interpret the configuration data from AD and then display the data in the console. The version of ESM provided with Exchange 2000 is often slow to respond in large organizations. The difference between working in large and small organizations is quite remarkable, especially when you want to look at the properties of an object such as a Mailbox Store. Exchange 2003 is better, but you could not describe it as superquick if you want to retrieve properties of an object from the AD. Clearly, a faster server makes ESM more responsive, and a multi-CPU system is more responsive than a single-CPU system, while a slow or unreliable network connector to the DC used by ESM to retrieve configuration data from the AD slows console performance. Exchange 2003 replaces some RPCs with HTTP-DAV calls to fetch information about items such as public folders, which leads to improved performance, especially with large collections of data. For example, Figure 10.4 shows a new feature in ESM for Exchange 2003: public folder management. In this instance, we review the contents of a large public folder (16,053 items), and ESM uses the same type of calls as OWA to fetch the PF content from the server.

Figure 10.4: Managing public folders with ESM.

10.1.1 Other Exchange management snap-ins

Exchange provides a set of MMC snap-ins to allow you to create your own management environment. Each of the snap-ins can be loaded into a console file, or you can combine them together. The basic idea is to implement a granular approach to system management by allowing you to support different management scenarios by combining the snap-ins together into consoles that you can then allocate to different levels of support staff. For example, you can give a front-line support person staffing a help desk a console that allows him or her to maintain user accounts and mailbox properties but not view details of Mailbox Stores. To do this, you build a console that includes the snap-in to manage AD user objects (or even local users and groups, if you wanted to confine management to a single computer that is not a DC).

Implementing granular system management solves a major problem often encountered in early Exchange deployments. The only way to perform any administration of a first-generation Exchange server is through the administration program-even simple operations such as changing someone's telephone number or title. Building a single, monolithic program to do everything is acceptable for small implementations, when typically one or two people perform all system management-from setting up the network to configuring user workstations to managing applications such as Exchange. In larger companies, when you have different levels of staff doing different jobs, the all-in-one approach does not work so well. Why, for instance, should someone working in a front-line help-desk role who takes care of basic user management (update directory entries, monitor mailbox quotas, and so on) be able to change the configuration of an Internet connection? Exchange was not the only application that suffered from this problem. Windows NT suffers from exactly the same problem. User Manager for Domains is a good program when you want to perform all account management operations, but it is not very flexible and you cannot restrict its access to the SAM in any way. The lack of granularity and flexibility is indicative of two things: the roots of Windows NT as a LAN- based operating system and the need for Microsoft to serve small user communities that have evolved from Microsoft Mail. Exchange has moved on a lot since its early days and now offers much more flexibility for large implementations.

Moving forward, people who act as second-level support staff might need to deal with server properties, including routing groups and storage groups, so they would use a different console. Third-level support might have access to a console that contained all of the snap-ins or have total administrative access to computers and the network. Each company is different, so you need to devote some thought to consider exactly who will have access to the different snap-ins. There is a large degree of flexibility in Exchange administration now and you can be far more selective in allocating responsibilities to individuals. Be careful that you do not go overboard and stop people from doing their jobs in your efforts to restrict access to critical components such as routing groups. As always, common sense and knowledge of what support people do to be effective will go a long way toward ensuring successful system management.

Table 10.2 lists the different Exchange snap-ins that you can incorporate into an MMC console. ESM includes all available snap-ins. Just to spice up the management environment a little more, you can also manage part of Exchange through the Computer Management MMC snap-in (Figure 10.5).

Table 10.2: Exchange MMC Snap-Ins

MMC Snap-In	Use
Advanced Security	Manage the process to enroll users and provide the keys necessary to encrypt and decrypt messages.
Chat Networks	Manage the Exchange chat network (Exchange 2000 only).
Conferencing Services	Manage online data conferencing service (Exchange 2000 only).
Folders	Manage public folders and hierarchies.
Message Tracking Center	Track the progress of a single message across an Exchange organization.
Exchange System Manager	The standard ESM console (Figure 10.1)

Figure 10.5: Managing Exchange through computer management.

This snap-in allows you to manage Exchange on a server that you log on to, but you lose access to the other servers in the organization. Additionally, you cannot work with administrative groups or routing groups.

10.1.2 Running ESM on workstations

You can run ESM on both a server and on a workstation. Originally, Microsoft only provided formal support for ESM on Windows 2000 workstations. However, after dragging its feet for awhile (possibly understandable, since it did not want to use valuable testing resources to figure out what it needed to change to support Windows XP), Microsoft eventually released a patch in April 2003 to make ESM for Exchange 2000 work properly on Windows XP (SP1 or later). To get the patch, go to www.microsoft.com/downloads and search for Exchange2000-KB815529- x86-ENU.exe.

Out of the box, Exchange 2003 is quite happy if you run ESM on a Windows XP SP1 or later workstation with the Windows 2003 Management Pack, albeit after you configure the Windows XP SMTP service on the workstation, because ESM has a dependency on some of the SMTP components. While you must install the SMTP service on the workstation before you install ESM, you do not have to run the SMTP service after installation. Note that the workstation must be part of the same forest as the Exchange servers, so you cannot install a workstation into a standalone or test domain and then connect the workstation to manage Exchange. In addition, because of the conflicts between the MAPI components used by ESM and those used by Outlook, you cannot run Outlook and ESM on the same PC. With these restrictions in place, many administrators do not attempt to install ESM on workstations and instead use the Remote Desktop Connection feature included in Windows XP to connect to servers and manage them remotely. In passing, it is worth noting that facilities such as HP's Remote Insight Lights-Out Edition (RILOE) cards for Proliant servers help administrators keep servers online, because you can perform server management operations such as reboots through a Web browser interface without having to go anywhere near the server.

Note that you should not use the Exchange 2000 version of ESM to administer Exchange 2003-specific features such as Outlook Mobile Access or the Recovery Storage Group. It is logical to expect that the older version of ESM has zero knowledge of the new capabilities and may not function correctly because of this fact. With this in mind, it is best to upgrade all administrative workstations to use the Exchange 2003 version of ESM as soon as possible. Assuming that you deploy the Exchange 2003 version of ForestPrep, you can then use Exchange 2003 features of ESM against Exchange 2000 servers, such as:

• The new Move mailbox functionality

• The integrated Queue viewer

• Internet Mail wizard

• Some of the public folder management enhancements

• The Mailbox Recovery Center

---