Mastering Microsoft Exchange Server 2003 phần 9 ppt

Figure 16.38: Entering information required to locate an Exchange server−based mailbox Don't click Next. First, click More Settings to open the dialog box shown in Figure 16.39. Tab over to the Connection property page. This is where you set up ROH. Don't worry about the offline stuff at the top of this dialog box. Select Connect to My Exchange Mailbox Using HTTP. Then click the Exchange Proxy Settings button to open the Exchange Proxy Settings dialog box, shown in Figure 16.40. If you're using an ROH front−end server, enter the fully−qualified domain name of the server; if not, enter the fully−qualified name of the Exchange server your mailbox resides on. I'm using EXCHANGE02 as my ROH front−end server, so I've entered its fully−qualified domain name. Next, select Mutually Authenticate the Session When Connecting With SSL to assure the highest level of security. Then, in the Principal Name for Proxy Server field, enter the name of your ROH front−end server or the server that contains your mailbox if you're not using a front−end server. Be sure to prefix the server name with msstd:, as in Figure 16.40. I'm using the internal Windows 2003 domain names of my ROH front−end server, because I'm doing this test not on the Internet but within my local area network. Figure 16.39: Setting Outlook 2003 to connect to Exchange server using ROH RPC Over HTTP 558 Figure 16.40: Setting parameters required to connect Outlook 2003 to Exchange server using ROH Next, select Connect Using HTTP First, Then Connect Using My Local Area Network (LAN). This ensures that your Outlook 2003 client always tries to connect using HTTP. If an attempt to connect using HTTP fails, the client reverts to a RPC over TCP/IP−based connection. Finally, select Basic Authentication in the Proxy Authentication Settings area of the Exchange Proxy Settings dialog box. OK your way out of the two dialog boxes you opened. You should now be back in the Exchange Server Settings wizard page shown earlier in Figure 16.38. Click Next and a dialog box opens, asking for your username and password. The wizard uses these to connect to your Windows/Exchange environment and to check the Exchange server and mailbox information you provided. If all goes well, you'll find yourself back in the mail profiles dialog box, shown in Figure 16.41. I have two profiles. I've selected Prompt for a Profile to Be Used so that when I start up Outlook, I have a choice of using one or the other of my two profiles. If you have only one profile, checking this box is unnecessary. Figure 16.41: A newly created ROH−based Outlook 2003 profile is in place. In Figure 16.42, I've started Outlook. I'm offered a choice of profiles. I'm choosing the one that supports RCP over HTTP. Figure 16.43 shows my Outlook 2003 client as it opens using ROH. Because Outlook can fall RPC Over HTTP 559 back to RPC over TCP/IP mode if it can't connect to your Exchange server using ROH, there's no way in looking at the Outlook client to know for sure that ROH is in use. There are a couple of ways to check the protocol. If your Outlook client is on the Internet and your internal network is protected by a firewall that allows external access using only the HTTP protocol and you can open your Exchange mailbox, you have to be using HTTP. Another way to check the protocol your Outlook 2003 client is using to communicate with your Exchange 2003 servers is with a packet sniffer. Packet sniffers can show you the ports being used by a particular network node to communicate with another network node. Figure 16.42: Choosing to use an ROH−based profile when opening Outlook 2003 Figure 16.43: Outlook 2003 opened using an ROH profile In Figure 16.44, I'm using CommView (www.tamos.com), a very nice and inexpensive software−based packet sniffer, to monitor communications between my Windows XP workstation set up for ROH Outlook 2003−to−Exchange 2003 connectivity, BARRYXPPRO (IP address: 192.168.0.247), and my Exchange ROH front−end server, EXCHANGE02 (IP address 192.168.0.105). CommView is running on EXCHANGE02. Notice in the second line in Figure 16.44 that communication between the two computers uses only port 443. That proves ROH is being used. 'What!' you might be exclaiming, 'I thought HTTP used port 80.' It does, but secure HTTP communications, such as those that use https:// instead of http://, use port 443. Secure HTTP is supported by the Secure Sockets Layer (SSL) protocol, which you'll notice is an unchangeable default on the dialog box shown earlier in Figure 16.40. RPC Over HTTP 560 Figure 16.44: A software−based packet sniffer shows that an ROH−based Outlook 2003 client and an Exchange ROH server are communicating using the secure HTTP port, 443. When I use CommView to look at communications between EXCHANGE02 and my mailbox server, EXCHANGE01, a variety of ports are used, but not port 443. This demonstrates that Exchange ROH front−end servers talk to back−end servers using standard Exchange server−to−Exchange server communications ports. Tip One quick and dirty, though not always as reliable, alternative to a packet sniffer such as CommView is the netstat command built into Windows. Open a command prompt, type netstat, and press Enter. It might take as much as a minute to complete, but you'll soon see a list of the other computers your computer or server is connected to and the ports being used for the connection. Some ports will be listed numerically, others will be listed by the name of the service they support, such as LDAP. That does it for RPC over HTTP. Now let's look a bit at RPC over TCP/IP. RCP Over TCP/IP Aside from ensuring that remote users install and set up their Outlook client properly, you don't have to do much else to support ROTI remote users on the server side. Users will have to create an entry for the server in the HOSTS file on the computer on which they are running Outlook. Except for Outlook 2003, the entry must be for the Exchange server name only, not the fully−qualified domain name of the server−that is, EXCHANGE01, not EXCHANGE01.BGERBER.COM. Outlook 2003 accepts fully−qualified domain names as well as server names. For more on the HOSTS file, see Mastering Windows Server 2003 (Sybex, 2003). The remote procedure calls that support Exchange client/server communications must be capable of passing through the ISP−based link between your client and server. Technically, this requires that certain TCP/IP ports be enabled on all firewalls and routers between the client and the server. I'll talk more about using ROTI with firewalls in Chapter 18. To connect Outlook to the server, you need to get to the MS Exchange Settings Properties dialog box. To do this for Outlook 2000 and earlier, right−click the Microsoft Outlook icon on your desktop, and select Properties. Double−click Microsoft Exchange Server in the MS Exchange Setting Properties dialog box. Enter the name of your Exchange server as named in your HOSTS file. Then type in your mailbox's display name or alias, and click Check Name. You'll know that all is well if the display name for your mailbox shows up underlined. Click OK to exit the various dialog boxes and open your mailbox. It takes a while the first time, but when your client is capable of talking to the server directly over the Internet, you will be able to do virtually anything that you can do locally. If you're using Outlook 2002 or 2003, follow the instructions in the previous section for entering and checking a connection to an Exchange mailbox, ignoring all the stuff about RCP Over TCP/IP 561 ROH. Supporting Roving Users Some users sit at the same desk all day, every day. Others move around all the time, often not even having a computer of their own. These users are often referred to as roving users. Basically, you want all roving users to have a directory on a server where they can pick up their Exchange and other settings every time they log in to the network, whatever workstation they use to log in. The Exchange settings that you're interested in are those for home server and mailbox name. You want a roving user to get the same server and mailbox name, no matter what workstation he or she chooses to log in on. Supporting a roving Exchange user is no different from supporting a roving user who is working with any other software, such as Microsoft Word. With Exchange, you want to present the same server and mailbox name. With Word, your goal is for the user to get the same default template, window−size settings, and so on. The specific procedures that you must follow to support roving users depend on the workstation (and sometimes network) operating system that you're using. Fortunately, Microsoft has a tool for simplifying the job of setting up correct profiles for roving Exchange users. This tool, PROFGEN.EXE, can be found in the Exchange Resource Kit. You can also download the program for free from Microsoft's Exchange website. A third−party product, Profile Maker, is easier to use and more comprehensive in scope than PROFGEN.EXE. Check it out at the site of its manufacturer, AutoProf.com (www.autoprof.com). Migrating Foreign Messaging System Users to Exchange You can move users from foreign messaging systems to your Exchange system. In some cases, Microsoft provides specific migration tools, while in others it provides more generic tools. Remember that your primary goal is to import data from your legacy messaging system into Windows 2003's Active Directory and Exchange's information stores. Migration is a complex process. Rather than describe it here in detail, I just want to make sure that you know it's available. Most of the documentation for migration is provided only online and on the Exchange Server CD−ROM, in the Migrate directory. Let's take a quick look at your options. Exchange Server ships with comprehensive migration tools for the following foreign messaging systems: Other Exchange Server organizations• Microsoft Mail for PC Networks• Lotus cc:Mail• Lotus Notes versions• Novell GroupWise• Migrations for all the systems listed are done entirely using the Microsoft Exchange Server Migration Wizard, which is installed along with Exchange Server. To start the wizard, select Start > All Programs > Microsoft Exchange > Deployment > Migration Wizard. Migrations move most available directory and message data to the Exchange 2003/Windows 2003 environment, and both also assume a live network link between your Exchange system and the foreign messaging system. If everything is running properly, these migrations are a Supporting Roving Users 562 piece of cake. You can also migrate from the following foreign messaging systems by extracting data from the old system into a file using a Microsoft−supplied source extractor and then importing it into Exchange using the Migration Wizard: Microsoft Mail for AppleTalk networks• IBM PROFS• NetSys (formerly Verimation MEMO)• If that's not enough, Microsoft provides information on building your own migration source extractor to produce data that can be imported into Active Directory using the Migration Wizard. Finally, and this is very neat, using the Migration Wizard, you can migrate directory information from any LDAP−compliant directory. And, if your legacy messaging system supports IMAP4, you can move mailbox data from it to Exchange mailbox stores using the Migration Wizard. Note Whichever route you take, be sure that someone on your migration team fully understands both the foreign electronic messaging system that you're working with and the computer operating system that it runs on top of. Without this expertise, you can get into some very hot water. If no one in your organization qualifies for this distinction, consider getting help from the vendors of your electronic messaging system and operating system, or think about hiring a knowledgeable consultant or two. Summary This chapter covered a number of advanced features of Exchange Server 2003 and Exchange−related features of Windows Server 2003. These features enable Exchange administrators to do everything from tracking Exchange Server−based messages to modifying e−mail address formats to migrating foreign messaging system users to Exchange. The Exchange Message Tracking Center is used to follow a message through an Exchange organization. Messages can be tracked as they move across Exchange servers and connectors, right up to the point that they leave an Exchange organization. Both e−mail and system messages can be tracked. Message tracking is useful both to prove to users that a message did indeed reach its destination and for troubleshooting Exchange system problems or apparent problems. Exchange managers can modify the default e−mail address formats used to create e−mail addresses for Exchange recipients. One of the most interesting and often−used modifications involves the creation of secondary SMTP proxy addresses for a user. Secondary proxies enable a user to have multiple Internet addresses. When secondary proxies are created that involve domains not already registered in an Internet−connected DNS server, MX and host records for the domain must be created in the DNS, or other SMTP hosts won't be capable of sending messages to the new secondary proxy address. Several Exchange features are implemented at the global or Exchange organization−wide level. Using recipient policies, Exchange managers can set up differently formatted default e−mail addresses for different Exchange recipients. A variety of selection criteria is available for specifying the recipients covered by a recipient policy. Exchange managers can also set up address lists using similar filters. Address lists are visible to users in their Outlook address books. The Exchange recipient update service, running on an Exchange server, keeps recipient e−mail addresses and address lists current as selection criteria change and new recipients are added to recipient policies and address lists. Multilingual details and address templates, Summary 563 respectively, support Outlook client features and one−off address creation in Outlook. Exchange administrators can set Exchange organization−wide message size and recipients per message limits for Exchange mailboxes. Manual creation of Windows 2003 users and Exchange 2003 mailboxes and other recipients can be very labor−intensive. It is possible to import information into Windows 2003 Active Directory and export it from Active Directory. The programs LDIFDE.EXE and CSVDE.EXE can be used for Active Directory imports and exports. The programs are run at a command prompt and are not very easy to use. Exchange administrators must possess a good deal of knowledge regarding Active Directory and the format of LDIFDE.EXE and CSVDE.EXE import files, as well as the format of individual entries in LDIFDE.EXE and CSVDE.EXE import files, before they can safely undertake Active Directory imports. Exchange server troubleshooting is a constantly moving target. The best tools are an advanced Exchange server management book; use of online support from Microsoft and others, ensuring that the latest Windows 2003 and Exchange 2003 service packs are installed on servers; and, if all else fails, use of paid Microsoft or other consulting support. Connectors that link Exchange routing groups can be monitored to assure that they are available. The status of each connector is automatically displayed in the Monitoring and Status\Status container in Exchange System Manager. You can also set things up so that you are notified when a connector is down. Supporting both remote and roving Outlook clients is quite easy with Exchange. Remote clients can be supported over the Internet connection using either a traditional RPC over TCP/IP connection or an RPC over HTTP link. Roving users are most easily supported using a product such as Microsoft's PROFGEN.EXE. Exchange Server 2003 comes with a variety of tools for migrating users from foreign messaging systems to Exchange. The Exchange Migration Wizard simplifies migration from a number of messaging systems, supporting live links to these systems during migration. For other foreign messaging systems, Microsoft provides source extractors to pull data from the systems and place it into files. The files can then be imported using the wizard. Summary 564 Chapter 17: Exchange Server Reliability and Availability Overview One of the biggest issues for my clients is Exchange server disaster recovery. The first time a client brings up the subject, I tell them that disaster recovery is the last thing they should worry about. After they get up off the floor, I tell them that they should focus first on Exchange server reliability and availability, of which disaster recovery is but the last part. I go on to tell them that if they worry about the whole reliability and availability spectrum, they'll not only prepare themselves for serious nondisaster recovery scenarios, but they also might be able to avoid many of the disasters that haunt their nightly dreams. If you want to achieve optimal Exchange server reliability and availability, you have to focus on three major areas: System redundancy• Standard backup and recovery• Disaster recovery• In this chapter, I'll focus on each of these in detail. When you're done, you'll know what you need to protect your Exchange server system and to assure both yourself and your users that their Exchange environment is as well protected as possible given available resources. Featured in this chapter: Redundant systems• Standard backup and recovery vs. disaster recovery• Standard backup and recovery• Disaster recovery• Redundant Systems Redundant computing and networking systems can be an easy, though not always inexpensive, route to Exchange server reliability and availability. Automatic failover from a nonfunctional to a functional component is best. However, even if you have to bring your system down for a short time to replace a component with no or minimal data loss, you'll be a hero to your users. In addition to eliminating or sharply reducing downtime, redundant systems can help you avoid the pain of standard or disaster−based Exchange server recovery. Systems redundancy is a complex matter. It's mostly about hardware, though a good deal of software, especially operating system software, can be involved. I'm going to deal here with two areas that are essential to redundant systems: server redundancy and network redundancy. Server Redundancy There are two basic kinds of server redundancy: Intraserver redundancy• 565 Interserver redundancy• Intraserver redundancy is all about how redundant components are installed in a single server. Interserver redundancy involves multiple servers that, in some form or other, mirror each other. The goal with either kind of redundancy is for good components or servers to replace bad ones as quickly as possible. Automatic replacement is highly desirable. Okay, let's look at redundant components and servers in more detail. Intraserver Redundancy When you think redundancy in a server, you think about storage, power, cooling, and CPUs. Redundant disk storage and power components are the most readily available in today's servers. Tape storage has lagged behind disk storage in the area of redundancy, but it is available. Redundant cooling fans have been around for some time. Historically, Intel has not offered good support for redundant CPUs. However, the company now provides hardware for this purpose, and that hardware is finding its way into production servers. Let's look at each aspect of server redundancy in more detail. Redundant Storage Redundant disk storage relies on a collection of disks to which data is written in such a way that all data continues to be available even if one of the disk drives fails. The popular acronym for this sort of set up is RAID, which stands for Redundant Array of Independent Disks. There are several levels of RAID, one of which is not redundant. Here's a quick look at each: RAID 0 Part of each byte of data is written (striped) to each drive in the array. RAID 0 is not redundant, but it provides the highest performance, because each byte of data is written in parallel, not sequential, fashion. RAID 0 is included here because RAID 0 strategies are used in another RAID design that I discuss later. RAID 1 All data on a drive is mirrored to a second drive. This provides the highest reliability. Write performance is fairly slow, because data must be written to both drives. Read performance can be enhanced if both drives are used when data is accessed. Mirroring requires lots of disk storage compared to RAID 5 (see below). RAID 0+1 As with RAID 0, data is striped across each drive in the array. However, the array is mirrored to one or more parallel arrays. This provides the highest reliability and performance, but has the same high disk storage requirements as RAID 1. RAID 5 Part of each byte of data is striped to each drive in the array. However, writes include parity information that allows any data to be recovered from the remaining drives if a drive fails. RAID 5 is reliable, though performance is slower. With RAID 5, you lose the equivalent of one disk in total GB of storage. For example, a RAID 5 array of three 36GB drives gives you 72GB, not 108GB of storage. This is more efficient than RAID 1 or 0+1, which require a disk for each drive mirrored, but write performance is about one−third of RAID 0+1, and read performance is about one−half of RAID 0+1. Server Redundancy 566 So, which RAID level is right for you? RAID 0+1 is nice, but I reserve it for clients with really demanding performance requirements. You compromise some with RAID 5, but it's the best price− performance−reliability option. It should be clear how RAID works from a general redundancy/reliability perspective. Now you're probably wondering how it works to assure high availability. The answer is pretty simple. With a properly set up RAID 1, 0+1, or 5 system, you simply replace a failed drive and the system automatically rebuilds itself. If the system is properly configured, you can actually replace the drive while your server keeps running and supporting users. If your RAID system is really highly neat, you set up hot spares that are automatically used should a disk drive fail. So, how do you know a RAID disk failed, and what do you do about it other than inserting a good drive? Most systems make entries in the Windows system event log. Many also let you know by talking to you. I'll never forget the first time a RAID 5 disk failed in one of my client's Dell servers. I got a call about a high−pitched whistling sound. They reported that they were 'going nuts from the sound.' So I had to figure out what was up as quickly as possible. I contacted Dell premium support and within five minutes, I knew it was a failed RAID drive. I used the administrative terminal server option in Windows 2000 to get to the computer over the Internet, using a virtual private network connection for security. Using Dell's support software for its RAID arrays, I was quickly able to shut off that horrible sound and set the server to the tasks of checking the failed drive and attempting to reinsert it into the array. Meanwhile, users were happily working away on their Exchange−based e− mail, knowing nothing about the failure. The drive recovered without a problem. If the failed drive was not recoverable, I would have asked my clients to remove the failed drive and insert a ready−to−go standby drive into the server. The server has three active RAID drives and three empty slots all on a hot−swap backplane. So, drive removal and insertion can be done without interrupting user access to the server. I could have also installed a fourth drive and set it up to act as a standby drive. The initial failure would then have triggered a rebuild of the array onto the standby drive. Then, at my leisure, I could come by and check the failed drive to see if it was still serviceable. If RAID sounds like a good idea, but you're worrying about costs, consider this. On my recommendation, one of my clients recently (June 2003) bought a Dell PowerEdge 1600SC server with 72GB of usable RAID 5 storage, hot−swappable drives and power supplies, a hot−spare drive, a 2.4GHz Intel Xeon processor, and 1GB of memory for around $3,000. Figure out what you'd pay for a quality server without all these features and I think you'll conclude that the peace of mind that comes with redundant server hardware is worth the extra cost. Warning As you'll remember from Chapter 12, 'Managing the Exchange Server Hierarchy and Core Components,' Exchange Server quickly writes data to simple transaction logs and then later commits the data to the information store when time is available. This assures that data are on disk and will not be lost should system memory fail. If you're using RAID 5 for your information stores, you should place your log files on RAID 1 or 0+1 mirrored drives. Disk mirroring is faster than RAID 5's parity bit−based striping. Tip For the best performance, be sure to use a RAID solution that is implemented in hardware on a RAID adapter. Limited software−based RAID is available in Windows Server 2003, but you're not going to be happy with the speed of such an implementation. RAID solutions don't necessarily have to be implemented inside a server. There is one very viable, if expensive, RAID solution that connects to your server or servers via a very high−throughput link. The technology is called a Storage Area Network (SAN). SAN devices connect to servers using fiber optic cable. You can connect multiple servers to a SAN. Each server is connected to the SAN through one or more very high−speed switches. This provides excellent throughput between the SAN and each server. Backups also Server Redundancy 567 [...]... included in Windows Server 2003' s large library of drivers Using a Spare Server with Windows 2003 and Possibly Exchange 2003 Installed If your ready−to−go spare server includes only Windows, then you need to install Exchange For more on installing Exchange, see the upcoming section, 'Installing Exchange Server 2003. ' If Exchange is already installed, then you just need to recover your Exchange mailbox... store database recovery Check out Microsoft Knowledge Base article number 298 901 for help Also, watch for options to not replay logs in Exchange aware backup programs This option is included in the Windows Server 2003 built−in backup program as augmented by the installation of Exchange Server 2003 Recovering an Entire Exchange Server If you lose an entire Exchange server, how you recover it depends... software for Windows 2003 For more on ASR and Windows Server 2003 backup in general, see Mastering Windows Server 2003 (Sybex, 2003) It's important to remember that ASR doesn't back up the nonsystem data on your computer For example, it doesn't back up the Exchange server application itself or Exchange information stores Another really exciting option for Windows backup is Windows 2003' s new VSCS VSCS... backup of the Windows Server 2003 portion of a volume is built into the Windows 2003 backup program This includes the nondatabase aspects of Exchange Exchange program files, for example Exchange Server 2003 adds a set of application programming interface (API) hooks that support VSCS backup of Exchange information store databases However, as with Exchange individual mailbox backup APIs, Exchange VSCS APIs... using a simple DNS trick 5 69 Server Redundancy Windows Server Clusters The Enterprise and Datacenter editions of Windows Server 2003 include clustering capabilities Interserver redundancy clustering is supported by the Microsoft Cluster Service (MSCS) MSCS supports clusters using up to eight servers or nodes The servers present themselves to clients as a single server A server in a cluster uses ultra−high−speed... Windows and possibly Exchange 2003 already installed on it • Reinstall Windows 2003 from scratch and recover System State and, if appropriate, Active Directory data Once Windows is installed on your server, and assuming you didn't use the spare server option with Exchange already installed, you need to install Exchange 2003 on your server When you install Exchange, you don't 583 Exchange Recovery Strategies... especially useful in Exchange environments with lots of incoming POP3, IMAP4, OWA, RPC over HTTP, and LDAP traffic Implementing MSCS clusters is beyond the scope of this book For more information on planning and deploying MSCS clusters, check out Mastering Windows Server 2003 (Sybex, 2003) and Microsoft' s Windows Server 2003 website Redundant SMTP Servers Back in Chapter 13, 'Managing Exchange 2003 Internet... interserver redundancy Clustered servers share standard RAID or SAN devices They can benefit greatly from all forms of intraserver redundancy Backing up and restoring Windows Server 2003 and Exchange Server 2003 is easier than it was with earlier versions of the two products An Automatic System Recovery (ASR) backup of a Windows 2003 server captures everything you need to reconstruct a stand−alone server. .. contacting EXCHANGE0 1, it would then look for other MX records for bgerber.com If EXCHANGE0 2 were available, it would send to that server You can have as many MX records for a mail server as you want Just be sure each points to a different server and has a different priority value Network Redundancy As you'll remember from Chapter 15, 'Installing and Managing Additional Exchange Servers,' Exchange Server 2003. .. VSCS backup of an Exchange 2003 server But think of the total neatness here You can back up an entire Exchange server, disk volume by disk volume If something goes wrong, you can reliably restore whole volumes in a snap VSCS, where have you been all my life? Be sure to coordinate VSCS volume backups For example, if Windows Server 2003 is installed on one volume and Exchange Server 2003 on another, you . clusters, check out Mastering Windows Server 2003 (Sybex, 2003) and Microsoft& apos;s Windows Server 2003 website. Redundant SMTP Servers Back in Chapter 13, 'Managing Exchange 2003 Internet Services,'. advanced features of Exchange Server 2003 and Exchange related features of Windows Server 2003. These features enable Exchange administrators to do everything from tracking Exchange Server based messages. Outlook 2003 to Exchange 2003 connectivity, BARRYXPPRO (IP address: 192 .168.0.247), and my Exchange ROH front−end server, EXCHANGE0 2 (IP address 192 .168.0.105). CommView is running on EXCHANGE0 2. Notice