Gservo
24th January 2003, 02:36 PM
(contributed by Paul Robichaux, News Editor, exadmin@winnetmag.com)
I've lost track of the number of messages I've received from readers that begin "I just took over an Exchange server ...." It happens all the time: People change jobs, retire, or otherwise transfer responsibility for an Exchange server to someone else. In many of these cases, the new administrator gets a pig in a poke, with no foreknowledge of how the Exchange environment is configured or what to look out for. This problem is particularly acute for administrators who are hired to maintain an Exchange network after a consultant (or the boss's son) has "helped" with it. To ease transitions, administrators need to know what to look for when they take over an Exchange environment and what information to provide when they hand over an environment to someone else.
First, what should you look for when you take over an Exchange network? When I evaluate a customer's Exchange configuration, the first thing I want to know is how big the Exchange organization is. I ask how many mailboxes the organization has, how many servers the mailboxes are spread across, where the servers are located, and how big the servers' Information Stores (ISs) are. The answers give me a good idea of what kinds of things to look for as I proceed with the evaluation.
Next, I typically ask questions about two radically different areas: backup and restore processes and connectivity. Knowing how the servers' critical data is protected--or how it isn't protected--provides valuable information that can come in handy during situations ranging from design reviews to emergency recoveries. Connectivity is important because knowing how the Exchange servers connect to each other and to the Internet helps me build a mental map of how messages should be flowing. That map is also useful if I'm trying to figure out why messages aren't flowing.
Then, I ask about security. I always ask new clients to download and run the free Microsoft Baseline Security Analyzer (MBSA) tool, which scans servers to check that they have the latest set of recommended OS security patches. (You can download MBSA at the URL below.) Because I can easily script MBSA to scan multiple machines and its reports can be quite detailed, I can get a good picture of the overall level of Windows patch management. MBSA also helps me identify critical Windows security fixes that might be missing. Unfortunately, MBSA doesn't help identify Exchange-related hotfixes or patches, although Microsoft might enhance it to do so in the future.
http://download.microsoft.com/download/e/5/7/e57f498f-2468-4905-aa5f-369252f8b15c/mbsasetup.msi
Only after I have information about the OS baseline configuration do I start worrying about Exchange-specific settings. This approach might seem backward, but it makes sense: Exchange is so dependent on the integrity and correctness of the underlying OS that assessing the OS first is smart. For Exchange 2000 Server or later, I want to know how servers are arranged into routing and administrative groups, what Exchange system policies have been applied, and whether message tracking has been turned on. I also find it useful to know how (or
whether) Exchange is configured to use firewalls, Microsoft Internet Security and Acceleration (ISA) Server 2000, or other network filtering or screening, including antispam and antivirus software.
Finally, I always take screen shots of settings dialog boxes and property pages. Capturing screens is much faster than making notes of the settings as you inspect each page.
You'd probably like to have this same depth of information when you start working on a new-to-you server. But what about the poor soul who has to follow in your footsteps? What can you do to make his or her life easier? Simple: Gather the information I've described in one easy-to-find location. In past columns, I've talked about the mainframe mindset of recording in a logbook every configuration change that occurs; even if you don't go that far, a ring binder labeled "EXCHANGE" and filled with the kind of useful information I discuss here will be a much-appreciated welcome gift to your successor. Who knows--maybe your excellent documentation will start a trend. (We can hope, at least.)
I've lost track of the number of messages I've received from readers that begin "I just took over an Exchange server ...." It happens all the time: People change jobs, retire, or otherwise transfer responsibility for an Exchange server to someone else. In many of these cases, the new administrator gets a pig in a poke, with no foreknowledge of how the Exchange environment is configured or what to look out for. This problem is particularly acute for administrators who are hired to maintain an Exchange network after a consultant (or the boss's son) has "helped" with it. To ease transitions, administrators need to know what to look for when they take over an Exchange environment and what information to provide when they hand over an environment to someone else.
First, what should you look for when you take over an Exchange network? When I evaluate a customer's Exchange configuration, the first thing I want to know is how big the Exchange organization is. I ask how many mailboxes the organization has, how many servers the mailboxes are spread across, where the servers are located, and how big the servers' Information Stores (ISs) are. The answers give me a good idea of what kinds of things to look for as I proceed with the evaluation.
Next, I typically ask questions about two radically different areas: backup and restore processes and connectivity. Knowing how the servers' critical data is protected--or how it isn't protected--provides valuable information that can come in handy during situations ranging from design reviews to emergency recoveries. Connectivity is important because knowing how the Exchange servers connect to each other and to the Internet helps me build a mental map of how messages should be flowing. That map is also useful if I'm trying to figure out why messages aren't flowing.
Then, I ask about security. I always ask new clients to download and run the free Microsoft Baseline Security Analyzer (MBSA) tool, which scans servers to check that they have the latest set of recommended OS security patches. (You can download MBSA at the URL below.) Because I can easily script MBSA to scan multiple machines and its reports can be quite detailed, I can get a good picture of the overall level of Windows patch management. MBSA also helps me identify critical Windows security fixes that might be missing. Unfortunately, MBSA doesn't help identify Exchange-related hotfixes or patches, although Microsoft might enhance it to do so in the future.
http://download.microsoft.com/download/e/5/7/e57f498f-2468-4905-aa5f-369252f8b15c/mbsasetup.msi
Only after I have information about the OS baseline configuration do I start worrying about Exchange-specific settings. This approach might seem backward, but it makes sense: Exchange is so dependent on the integrity and correctness of the underlying OS that assessing the OS first is smart. For Exchange 2000 Server or later, I want to know how servers are arranged into routing and administrative groups, what Exchange system policies have been applied, and whether message tracking has been turned on. I also find it useful to know how (or
whether) Exchange is configured to use firewalls, Microsoft Internet Security and Acceleration (ISA) Server 2000, or other network filtering or screening, including antispam and antivirus software.
Finally, I always take screen shots of settings dialog boxes and property pages. Capturing screens is much faster than making notes of the settings as you inspect each page.
You'd probably like to have this same depth of information when you start working on a new-to-you server. But what about the poor soul who has to follow in your footsteps? What can you do to make his or her life easier? Simple: Gather the information I've described in one easy-to-find location. In past columns, I've talked about the mainframe mindset of recording in a logbook every configuration change that occurs; even if you don't go that far, a ring binder labeled "EXCHANGE" and filled with the kind of useful information I discuss here will be a much-appreciated welcome gift to your successor. Who knows--maybe your excellent documentation will start a trend. (We can hope, at least.)