218 CHAPTER 5 BEST PRACTICES AND DISASTER PREVENTION

220 CHAPTER 5 BEST PRACTICES AND DISASTER PREVENTION Public Folders For some organizations, the public folder feature is barely used, if used at all, while at other organizations it is an indispensable resource. Public folders are covered more thoroughly in Chapter 12, Public Folders, but the following list contains some basic information on best practices for public folders: . Ensure that you have at least two replicas of the organization forms libraries and each administrative group s Schedule+ Free Busy folders. Preferably, there should be a replica of these folders in each routing group. . Enable deleted item recovery for each public folder store. . Confirm that the Everyone group is not granted the Create Top Level Public Folder permissions at either the Exchange organization level or at the administrative groups. Configure Message Tracking There will come a time when you ll need to figure out where message delivery is failing. The best tool for that is the built-in message-tracking feature. This can be enabled for each server, or it can be enabled using an Exchange system policy. Figure 5.7 shows the properties of a server and the check box for enabling this feature. You can use the message tracking in the Exchange System Manager to track the path that a message took to be delivered within your organization. You need to make sure you have sufficient disk space for the message-tracking logs. On busier servers, I have seen message tracking generate 50 to 100MB of message-tracking logs per day. For more information about message tracking, see Chapter 8, Keeping an Eye on Exchange 2003 Usage. Consider also turning on subject logging so that you can view the subject of the message from the message tracking logs. Figure 5.7 Enabling message tracking Monitor Your Servers Almost nothing is worse than getting a telephone call from an important user and having that user explain to you that something is not functioning in the e-mail system. It is especially bad if the problem is something you should have known about. I cover more details about the actual steps to set

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost mac Web Hosting services

218 CHAPTER 5 BEST PRACTICES AND DISASTER PREVENTION

EXCHANGE 2003 ORGANIZATION BEST PRACTICES 219 one administrator tell me that he had someone who created folders and was storing things in the Deleted Items folder; the user s rationale was these were things he might want to get back. To configure the server to empty the Deleted Items folders, you will need to configure a Mailbox Manager recipient policy. I am assuming in this text that you don t currently have a Mailbox Manager policy, so I m not going to walk you through the steps to integrate a recipient policy into your existing Mailbox Manager policies. Create a new Mailbox Manager policy using the following steps: 1. Open the Exchange System Manager console, and click the Exchange organization to display the global properties and administrative groups. 2. Open the Recipients container and then open the Recipients Policies container. 3. Right-click on the Recipients Policies container, and choose New Recipient Policy. 4. Check the Mailbox Manager Setting box, and click OK. 5. Assign the policy a name, such as Default Mailbox Manager Settings. 6. Click the Modify button, and then click OK twice. (This defines the filter to automatically affect all mailboxes in the entire organization. You can refine the filter if this is not what you desire.) 7. Click the Mailbox Manager Settings (Policy) property page, and then clear all the folders in the folder list except for Deleted Items. 8. Highlight the Deleted Items folder in the folder list, click Edit, set the Age Limit to the number of days you want, clear the Message Size check box, and then click OK. You should have Mailbox Manager Settings properties that look like Figure 5.6. Figure 5.6 Mailbox Manager settings for emptying the Deleted Items folder of any messages older than 14 days You have now defined the policy. This policy will affect all mailboxes in the organization; it will automatically delete any message in the Deleted Items folder that has been in that folder (and not modified) for more than 14 days. The final step is to modify the properties of each Exchange server to indicate when the Mailbox Manager should actually run. I recommend running it during a time when the tape backup and online maintenance are not running; no more than once per day should be sufficient. More information is available about this process in Chapter 7, Tweaking Operations.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost mac Web Hosting services

218 CHAPTER 5 BEST PRACTICES AND DISASTER PREVENTION

218 CHAPTER 5 BEST PRACTICES AND DISASTER PREVENTION Figure 5.5 Mailbox storage limits TIP By preventing any single mailbox from growing to gigabytes and gigabytes in size, you reduce the likelihood that you will run out of disk space on either the server s Exchange transaction log disk or the Exchange database disk. Also configured on the Limits property page is the number of days to keep deleted mailboxes (Keep Deleted Mailbox For) and deleted messages (Keep Deleted Items For). I strongly recommend enabling these on all mailbox stores. At some point, this will save you from having to perform a tape restore when you are busy doing a million other things. The Keep Deleted Items For option allows Outlook MAPI users to undelete messages that they have deleted. The only types of items that cannot be recovered are messages that were expired from a public folder because of age limits or deleted from a mailbox using the Mailbox Manager function. TIP Messages that have been deleted by POP3 clients or by using a hard delete (Shift+Delete), thereby bypassing the Deleted Items folder, can be recovered from the deleted item cache. See Microsoft Knowledge Base article 246153, How to recover items that have been hard deleted in Outlook, for how to do this. Automatically Purge Deleted Items In some organizations, I have noted that users delete messages but then forget to empty their Deleted Items folder. This is an example of a situation where you can implement a technological solution to correct user behavior. Administrators can force users to empty their Deleted Items folders using Outlook options or by using the Outlook admin templates and a Group Policy Object. But I think the server-based solution is better. First, you will need to decide how long items can remain in the Deleted Items folder. I think a good figure is between 7 and 14 days. Next, users need to be briefed, or this configuration option needs to be placed in the acceptable use policy or the service-level agreement. In the past, I have simply referred to this as a feature of the server that will automatically purge anything that is stored in that folder for longer than the specified number of days. After all, it is the Deleted Items folder. I did have

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost mac Web Hosting services

HOW DID WE DO THAT? THE CASE FOR

EXCHANGE 2003 ORGANIZATION BEST PRACTICES 217 Figure 5.4 Global message delivery defaults In Figure 5.4, I configured the default maximum incoming (Receiving) and outgoing (Sending) message size to 5MB and the maximum number of recipients to 100. The maximum number of recipients will include the membership of any distribution lists to which the user addresses a message. If a mail-enabled group has more than 100 members, a user will not be able to send to that group unless they have specifically had their account s maximum recipient limit overridden. Contrary to popular belief, the maximum incoming and outgoing message size limits cannot be overridden on a user-by-user basis; but the maximum recipient limit can be overridden on the Delivery Restrictions properties of a user account by clicking the Delivery Options button. Establish Mailbox Limits Are you looking for a surefire way to get your user community upset? Impose mail storage limits without informing them. I am a strong advocate of mail storage limits for a number of reasons; most notably, they help me to plan the amount of disk capacity required for each server and they require that the user manage the messages they deem worth keeping. The tricky part is figuring out what a good set of mailbox limits are. I think a good starting point for most organizations is 50 to 75MB, but that is just me. If there is a business reason why users need more space than that in their mailbox, I ll be the first person in front of the CEO to ask for more money for larger disks and higher-capacity tape drives (after all, we have to be able to back up all that extra storage in a reasonable amount of time). You can configure limits on the properties of each individual mailbox store (on the Limits property page) or by using an Exchange system policy. If you have more than a few mailbox stores that all need identical limits, you can save yourself a lot of time and ensure that the limits are applied consistently by using an Exchange system policy. Figure 5.5 shows the Limits property page. I have configured the storage limits as I typically recommend. You should note a couple of important facts about these limits. First, if an Outlook MAPI client or Outlook Web Access client exceeds their Prohibit Send At limit, they will get a message stating that they have exceeded their mailbox limit and they must delete some items before they can reply to messages or send messages. If the client exceeds the Prohibit Send and Receive At limit, the mailbox will shut down and no longer accept new messages. For this reason, I set the Prohibit Send and Receive At limit to a relatively high limit.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost clan Web Hosting services

HOW DID WE DO THAT? THE CASE FOR

216 CHAPTER 5 BEST PRACTICES AND DISASTER PREVENTION useful to all administrators. EXCHDUMP.EXE has several command-line switches that will allow you to dump information about the Exchange server s HTTP, SMTP, RPC, routing group, recipient policies, or address list configuration, if you are looking for a specific piece of information. NOTE One third-party solution that you can use for documentation is Ecora s Enterprise Auditor Suite (www.ecora.com). This tool can be useful not only in documenting your Exchange organization (and other components on your network) but also in helping implement a change and configuration management control system. Exchange 2003 Organization Best Practices You can and should impose a number of Exchange configuration settings, restrictions, and limits to prevent your users from abusing the Exchange servers and your bandwidth. In addition, you should document all of these restrictions in an acceptable use policy so that the user community is aware of their existence. Further, you can impose some configuration options and limits that may help to make maintaining servers easier. These limits may affect only a particular subset of your users or may affect the entire organization. And all of these limits can be overridden on a per-user account basis. Establish Global Limits If you have the Exchange Admin or Exchange Full Admin role at the Exchange organization level, then you have the necessary permissions to enable these restrictions. The limits I m talking about are the global message sizes and maximum number of message restrictions. You can find these restrictions in the Exchange System Manager console by opening the Exchange organization container, then opening the Recipients container, and then clicking on the Global Settings container. Right-click the Message Delivery object, choose Properties, and then choose the Defaults property page (shown in Figure 5.4). I Have That Written Down! A couple of years ago, I sat through a disaster recovery drill that one of my larger corporate clients was performing. They had just done a complete changeover to Exchange 2000, and they wanted to test their knowledge of Exchange 2000 recovery. I was simply along for the ride as an observer rather than a participant. This customer completely recovered an Exchange 2000 server (running on a Windows 2000 member server) in just more than three-and-a-half hours. This included rebuilding the operating system, the Exchange software, the antivirus software, a couple of custom Registry changes and restoring the SRS database, mailbox store, and public folder store. The most I did during that entire time was sit back, smile, and nod occasionally when the Exchange administrator turned to confirm something with me. Personally, I think a three-and-a-half-hour recovery time (start to finish) for a server that supported several hundred users is rather remarkable. My hat is off to their Exchange administrator for being so well organized. What was the key to her success? Everything about the original installation was well documented. During the configuration of each server, she had kept meticulous notes of what was installed, what order it was installed in, the locations of files and directories, the configuration of the backup software, the service packs applied, and even the antivirus software configuration.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost clan Web Hosting services

HOW DID WE DO THAT? THE CASE FOR

HOW DID WE DO THAT? THE CASE FOR DOCUMENTATION 215 . Updates to your antivirus software that had to be applied separately from routine, automatic updates . Updates and service packs for your tape backup software Tools That Can Help Doing thorough system documentation is a daunting task, but some tools are available to help. If you are interested in dumping the entire Exchange configuration into a text file, the LDIFDE.EXE utility can be of use. In this example, I m dumping the entire Exchange container from the configuration partition of the Active Directory. This will include the Exchange configuration as well as the Active Directory Connector information. The organization name is volcanosurfboards.com, and I m dumping this to a text file called E2K3.LDF. Ldifde -f e2k3.ldf -d cn=Microsoft .Exchange,cn=services,cn=configuration,dc=volcanosurfboards,dc=com Warning, though, this dumps everything out to the text file, and if you are not fairly adept at reading the configuration information in Active Directory, it will be nearly meaningless. However, in the event of a failure of your system, this information may be useful to a Microsoft Product Support Services engineer. In even a small organization, this file will exceed 3MB. Another tool that is included with Exchange 2003 is the EXCHDUMP.EXE utility that is found in the c:program filesexchsrvrbin directory. EXCHDUMP.EXE is intended to dump specific pieces (or all) of your Exchange configuration information. If you want all the configuration for your server, at the command prompt type this: exchdump /all This will create two files, Full_servername.txt and Summary_servername.htm. Both of these files will be more than 1MB for even a small Exchange organization and may not be immediately Documenting Everything On a fairly large Exchange 5.5 installation that I worked on, the administrator decided everything should be documented so that anything could be re-created in the event any component was lost or accidentally deleted. I spent a couple of days painstakingly creating templates in Word so we could just fill in the blanks for each Exchange 5.5 server. Naturally, the configuration information varied somewhat from one component to another, so no single table could be used easily for all components. I finally managed to create a reasonably comprehensive configuration document. The Exchange administrator looked at it and decided it was too much work to fill out those tables for each Exchange server and that the Word document was not visual enough. His solution: we created documents full of screen captures. While I was a little frustrated about the time I had spent creating my Word templates, his solution worked just as well as mine. And his solution made it a little easier to visualize what settings needed to be configured for each server and component. The point is: find something that works for you; just make sure you are getting things documented.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost clan Web Hosting services

CONTROLLING OUTBOUND SMTP MAIL TO THE INTERNET 651

CONTROLLING INBOUND SMTP MAIL 653 . Each SMTP server that will accept mail for your organization must have a public IP address; the DNS hostname record points to this IP address. . The default recipient policy in the Exchange organization must be modified or a new recipient policy must be created to include the Internet domain for which you will be accepting SMTP mail. The default recipient policy includes only the Internet domain that matches the Active Directory domain name. . The publicly exposed IP addresses should have PTR records for those IP addresses registered if they will also be used for sending mail. This may be handled by the owner of the IP addresses rather than the organization that will be using them. . Finally, you should have a good virus protection strategy in place for your organization. See Chapter 17, Securing Exchange Server 2003. Defining an Inbound Mail Strategy There are about as many possible configurations for inbound mail as there are companies using Exchange; your exact needs will depend on your organization. Many organizations have only a single Exchange 2003 server and don t have a lot of room in their budget for building in redundancy, fault tolerance, or load balancing for Internet mail. However, for many organizations, inbound SMTP mail is considered business critical and must be accepted from sending hosts. In these organizations, redundancy is important; these organizations may have one or more SMTP servers accepting inbound SMTP mail. Handling Inbound Mail Yourself Organizations with only one or two Exchange servers may choose to direct inbound mail directly to the Exchange server. Figure 16.5 shows the Exchange servers for BobsBoogieBoards.com; they are a small Exchange organization with two Exchange servers. This organization wants to receive e-mail from the Internet to either of these servers. The servers use private IP addresses, and the firewall takes care of the translation between the public and the private IP addresses. The public hostnames (mail1.bobsboogieboards.com and mail1.bobsboogieboards.com) do not need to match the internal hostnames. Figure 16.5 Designing a smaller network s inbound SMTP mail strategy Firewall reverse NAT translation 131.107.2.201 -> 192.168.1.201 131.107.2.202 -> 192.168.1.202 External IP Addresses 131.107.2.201 131.107.2.202 Firewall Internet Hub Exchange 2003 Internal IP Address 192.168.1.201 Exchange 2003 Internal IP Address 192.168.1.202

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost mac Web Hosting services

CONTROLLING OUTBOUND SMTP MAIL TO THE INTERNET 651

652 CHAPTER 16 INTERNET CONNECTIVITY informs the recipient of something important (for example, This message was scanned for viruses and worms, This message is only for the intended recipient, or The author of this message, not the company, is responsible for its content. ) I am not a big fan of appending server-based disclaimers to messages for a couple of reasons. First, I doubt the effectiveness of these disclaimers. If I accidentally e-mail a sensitive document to my biggest competitor, I doubt the disclaimer at the bottom of the message indicating that she should delete the message if she is not the intended recipient is going to be very effective. Second, I am a big supporter of S/MIME digital signatures. The digital signature is created when the client clicks the Send button, and it is created by the client software, not by the server. Any modification to the message contents after the fact will break the digital signature. Since the digital signature is modified, the recipient cannot accurately verify the integrity of the message. That being said, where is the best place to implement disclaimers? If your boss insists on e-mail disclaimers and if your organization is never going to worry about S/MIME digitally signed messages, then go ahead and invest in some type of system that will automatically stamp a disclaimer onto the message at the server or SMTP gateway. If you are concerned that future S/MIME signatures may be an issue, then require your clients to include the disclaimer as part of their message signature. NOTE Diane Poremsky and Sue Mosher have compiled a list of third-party products that append disclaimers to outgoing messages. See www.slipstick.com/addins/content_control.htm. If you are currently using (or planning to use) some type of SMTP gateway system for e-mail content inspection or virus scanning, check to see whether that system also includes the ability to include a disclaimer on the outbound (or inbound) messages it processes. Many of these products include such a feature. I see a couple of advantages to this approach, including that nothing has to be implemented on the Exchange server and that only messages leaving the organization have the disclaimer attached to them. If you want all internal and external messages to have a disclaimer attached to the message, this will have to be implemented internally on the Exchange server. Exchange 2003 does not have a built-in feature that performs this task, but you could develop an event sink to do this. Developing an event sink to modify outbound message content is not a simple task. Unless you are prepared for a pretty big development project, you should probably find a third-party product to do this. NOTE For some samples and more information on disclaimers, see Chapter 5, Best Practices and Disaster Prevention. Controlling Inbound SMTP Mail Any server (or all servers) can be configured to receive inbound SMTP mail from the outside merely by pointing an MX record to that server s SMTP virtual server. This is a function of the DNS administrator, not the Exchange administrator. DNS MX records are created exactly the same for all types of SMTP servers regardless of whether they are Exchange, Unix, or AS/400. Before You Start Before you start accepting inbound SMTP mail for your organization, you will need to take care of or plan for a few issues: . At least two DNS servers on the Internet must host your Internet domain name, the hostname records for the servers that will accept mail for your organization, and the MX records. Some organizations choose to run these DNS servers themselves, and others rely on their ISP or a DNS hosting service.

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost mac Web Hosting services

CONTROLLING OUTBOUND SMTP MAIL TO THE INTERNET 651

CONTROLLING OUTBOUND SMTP MAIL TO THE INTERNET 651 Figure 16.4 Configuring an SMTP Connector to use a smart host In this case, each of the Exchange servers has had an SMTP virtual server created specifically for e-mail that will be sent to the Internet. You might want to do this if you want to place more restrictions on the SMTP virtual servers that send mail to the Internet. Should You Use Separate SMTP Virtual Servers? When you configure an SMTP Connector for outbound messages, should you create additional SMTP virtual servers for use with the SMTP Connector? When directing DNS MX records for inbound Internet messages to an SMTP virtual server, should you create an additional SMTP virtual server for inbound Internet messages? In general, I try to keep each Exchange server s configuration as simple as possible. If the internal configuration for the SMTP virtual server will also work for external connections, then I don t create an additional SMTP virtual server. If I create the additional SMTP virtual server, this means I must also configure and manage an additional IP address on the Windows 2003 server. Therefore, I prefer to keep the configuration simple as long as I can. Although I could configure multiple virtual servers using the same IP address, I would have to worry about using different TCP port numbers and the complexity of configuring all clients that will use that SMTP virtual server with a different port. I might want to create an additional SMTP virtual server for several reasons. In all cases, I would use the additional SMTP virtual server for external tasks and reserve the default SMTP virtual server for internal Exchange-to-Exchange communications. Here are some of those reasons: . The externally exposed SMTP virtual server should have different authentication requirements. . External SMTP messages are subject to different message size limits than internal messages. . Internal clients should be allowed to relay, but external SMTP clients should not be allowed to relay. . Message filters should be applied only to mail inbound to specific virtual servers. Adding Disclaimers to Outbound Mail I talked a little about disclaimers in Chapter 5, Best Practices and Disaster Prevention. A disclaimer is some type of text prepended to the top or appended to the bottom of an outgoing message. The text

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost mac Web Hosting services

MICROSOFT EXCHANGE, ESQ. 209 . An attorney must

MICROSOFT EXCHANGE, ESQ. 211 NOTE An emerging trend is the managed service provider trend where a third party acts as your messaging front-end for inbound SMTP. Organizations such as FrontBridge (www.frontbridge.com) have the scalability and staffing to react quickly to changes in virus threats or spam assaults. With these utilities installed, you will be able to monitor and scan all of your SMTP messages for very specific words and phrases and then either reject the messages or add a disclaimer to them. An add-on even exists for MailSweeper called PornSweeper, which will scan all messages for embedded or attached graphics and attempt to determine whether these pictures would be considered pornographic or offensive to some users. However, note that while these utilities are helpful, they cannot guarantee that no harmful messages will be allowed through the system. Implementing such systems requires additional management overhead. Depending on how you configure these systems, you may have to manage the queues of messages that have been filtered. Disclaimers Some organizations are taking other steps that are arguably not effective. One popular approach has been the use of a legal disclaimer appended to all outbound SMTP messages, stating that this e-mail may not represent the views of the organization as a whole. The disclaimer may cover breach of confidentiality information, notice of virus scanning, company liability, and more. Figure 5.3 shows an example of a message with a disclaimer; often the disclaimer is bigger than the message itself. Figure 5.3 A sample disclaimer Now that disclaimers have been used for a while, the consensus is that they are not enforceable in a court of law, so this may not be the most effective use of your time and resources. NOTE For more information about disclaimers and some sample disclaimers, visit www.emaildisclaimers.com/. To enable a disclaimer to be appended to each of your outgoing SMTP messages, you can configure an SMTP event sink. Event sinks are actually COM-compatible program code, typically Visual Basic, VBScript, javaScript, C, or C++. This code is triggered by a defined event, such as an outgoing message being sent to an SMTP virtual server, and then it processes the rules you specified, such as

Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost adult Web Hosting services