Enterprise Messaging: Linking Minds Together Across The Enterprise by David Matthiesen and Stacy Hunt Deployment Planning Now that you have selected your e-mail/groupware system, it is time to develop your deployment plan. However, before you can begin full scale deployment, you need to decide your implementation standards. Naming standards: What is the name of your organization/domain and site/network? What naming convention will you follow for your servers/post offices, e-mail users, distribution lists, schedule/calendar resources and public folder/databases? Be sure to take into account any protocol limitations on server names such as the NetBIOS requirement that the first 15 characters must be unique. SMTP, X.400 and X.500 conventions must be considered. Administrative standards: Who will have the right to create and/or modify new servers/post offices, e-mail users, distribution lists, calendar/schedule resourc es and public folders? Exchange, for example, is like NT Server in that there is little granularity in administrative access. It is either full access, no access or inflexible access. It is very important that you consider the security implications when distributing control to different groups. A tool by Master Design &Development (www.evinet.com/mdd) called Trusted Enterprise Manager assists in off-loading mundane administrative tasks without compromising good security practices. It can allow more (or less, if you want) access than an NT Account Operator would have to achieve the granularity desired. If you are a medium- to large-sized company, you will want to distribute the creation and maintenance of distribution lists and schedule/conference resources or increase your staff to handle the load. Reality Bites migration issues: Does the e-mail system you have selected include migration tools for importing legacy e-mail stores? If yes, you should migrate the user's e-mail when you create the account. Make sure to include procedures for either deleting the user's legacy e-mail account or making it a secondary e-mail account if needed. (Then delete secondary mail accounts whenever possible.) Client default install options: Do you want the client to install with a certain protocol order, a default font and the spell checker turned on? Some e-mail systems, such as Exchange, let you set all the defaults in a "profile" or "policy" for a client, so it is configured properly on installation. Server standards: Based on the software manufacturer's recommendations, the number of potential users and their required information-store disk space, how many servers will you need? You may wish to limit how much a user can store on a server, so you are not in constant danger of running out of server disk space. Some e-mail software allows you to set up controls on eligible recipients and the size of messages they can send. It is a good idea to l imit the size of e-mail items, so users do not bring down gateways, connectors and dial-up lines trying to send their hard drive contents to their coworkers. This may seem far fetched, but we have seen it attempted before. Twenty to 30 MB per user is a good measure to size your servers. Server hardware platform: It is a good idea to standardize your server hardware. This will make it easier for you to support and possibly allow you to get volume purchase discounts. Make sure that you take advantage of hardware-based RAID and other fault-tolerant methods to minimize the chance of downtime. Standardized hardware allows the efficient cloning of properly configured mail servers. Monitoring tools: Do monitoring tools come with the product? If so, do they monitor everything you require, or should you investigate a third-party tool? Do the tools monitor only certain points in your mail network with "pings" or messages to bogus accounts hoping to get an administrative status message back? Do they actually monitor and track mail flow? Backup strategy: Users will always delete something they need back, or a disk will crash and cause data loss. It is extremely important that you have a reliable backup and restore system in place. Have you already standardized on backup software at your company? Does this software work with your new e-mail system? Can you outsource the backup tasks to another group? Procedures should be clear on how to do a backup/restore of a user's mail store and any public folders/groupware applications. Depending on the e-mail software, you may need a spare server in order to restore a post office or public folder. Security standards: If the e-mail system you choose does not rely on the underlying operating system for security, you will have to develop standards to take this into account. You will want to follow any security standards already in place at your company, such as password length and expiration. If your company is international, there will be implications on what types of encryption that can be used. Uncle Sam's cloak-and-dagger folks do not like encryption routines they cannot easily crack if transmissions go outside our borders. Lotus handles this with Notes by having domestic and international versions. Remember, the first rule in most security models is that the servers and consoles need to be physically secure (i.e., locked up somewhere with limited access). Training: Your administrators, end users and groupware application developers will all need training on the new e-mail/groupware system. Audit vendor classes to determine if they are worthwhile for your administrators and developers. Evaluate any textual or CBT materials available and determine if they are worth distributing. If you are implementing a recently released e-mail system, you may need to develop your own training materials in-house. It is definitely worth giving your end users some training to ease frustration and to reduce nonproductive time learning the product on their own. If your system has groupware/public folder capability, you may wish to include a forum on tips and techniques for using the new e-mail system. Developers may wish to start an end-user group to share ideas and programming techniques. Billing: In the field of dreams company, e-mail is considered a corporate resource and your clients will not be charged to use it. Unfortunately, in these cost-conscious times, many IT departments find themselves having to justify their existence and the services that they provide. If you must develop a billing system for e-mail, good luck! You could bill on the amount of storage a user is taking, the amount of e-mail traffic they generate, or the number of reads/writes to a public folder/groupware applications, for example-some of the e-mail/groupware packages even provide the tools to monitor these statistics. If the unbelievable overhead cost of maintaini ng a billing system is worth it to your company, more power to you. Either way, you will end up discouraging use and slowing your rollout by billing. Next September 15, 1996 Print This Page E-mail this URL