Many of the previous chapters discussed the importance of documentation in a Windows Server 2003 environment. This chapter looks at the many different types of documentation and discusses the benefits—some of which are obvious, some not.
There are several main types of documentation, including the following:
Historical/planning (who made which decision)
Support and maintenance (to assist with maintaining the hardware and software on the network)
Policy (service-level agreements)
Training (for end users or administrators)
It is also critical that any documentation produced be reviewed by other stakeholders in the organization to make sure that it meets their needs as well, and to simply get input from other sources. For technical procedures, the document also must be tested and “walked through.” With a review process of this sort, the document will be more useful and more accurate. For example, a server build document that has gone through this process (that is, reviewed by the IT manager and network administrator) is more likely to be complete and useful in case the server in question needs to be rebuilt in an emergency.
Documentation that is not historical and that is intended to be used for supporting the network environment or to educate on company policies should be reviewed periodically to make sure that it is still accurate and reflects the current corporate policies and processes.
The discipline of creating effective documentation that satisfies the requirements of the appropriate support personnel as well as management is also an asset to the company and can have dramatic effects. The material in this chapter gives a sense of the range of different documents that can have value to an organization and should help in the process of deciding which ones are critical in the organization.
Some of the benefits of documentation are immediate and tangible, whereas others can be harder to pin down. The process of putting the information down on paper encourages a level of analysis and review of the topic at hand that helps to clarify the goals and contents of the document. This process should also encourage teamwork and collaboration within the organization, as well as interdepartmental exchange of ideas.
For example, an Exchange Server maintenance document written by the Exchange administrator might be reviewed by the marketing manager who is concerned about the company’s ability to send out emails to the existing and potential client base. The CIO should review the document as well to make sure that the maintenance process meets her concerns, such as meeting an aggressive service-level agreement (SLA).
Consequently, documentation that has specific goals, is well organized and complete, and goes through a review or approval process should contribute to the overall professionalism of the organization and its knowledge base. The following sections examine some of the other benefits of professional documentation in the Windows Server 2003 environment.
Quite simply, the right documentation allows an organization to better organize and manage its data and intellectual property. Rather than having the company’s policies and procedures in a dozen places, such as individual files for each department or worst of all, in the minds of many individuals, consolidating this information into logical groupings can be beneficial.
A design document that details the decisions made pertaining to a Windows Server 2003 migration can consolidate and summarize the key discussions and decisions, as well as budgetary concerns, timing issues, and the like. And there will be one document to turn to if questions emerge at a later date.
Similarly, if a service-level agreement is created and posted where it can be accessed by any interested parties, it should be very clear what the network users can expect from the Windows Server 2003 infrastructure in terms of uptime or prescheduled downtimes.
A document that describes the specific configuration details of a certain server or type of server might prove very valuable to a manager in another company office when making a purchasing decision. The documents also must be readily available so that they can be found when needed, especially in the case of disaster recovery documents. Also, it’s handy to have them available in a number of formats, such as hard copy, in the appropriate place on the network and even via an intranet.
Tip
Place documentation in various locations where it is easily accessible for authorized users, such as on the intranet, in SharePoint Portal Server, in Windows SharePoint Services, in a public folder, or in hard-copy format.
By simply having these documents available and centralizing them, an organization can more easily determine the effects of changes to the environment and track those changes. Part of the knowledge-management process needs to be change management so that, while the information is available to everyone, only authorized individuals can make changes to the documents.
Proper Windows Server 2003 documentation can be time consuming and adds to infrastructure and project costs. It is often difficult to justify the expense of project documentation. However, when looking at documents, such as in maintenance or disaster recovery scenarios, it is easy to determine that creating this documentation makes financial sense. For example, in an organization where downtime can cost thousands of dollars per minute, the return on investment (ROI) on disaster recovery and maintenance documentation is easy to calculate. Likewise, in a company that is growing rapidly and adding staff and new servers on a regular basis, tested documentation on server builds and administration training can also have immediate and visible benefits.
Well-thought-out and professional design and planning documentation should help the organization avoid costly mistakes in the implementation or migration process, such as buying too many server licenses or purchasing too many servers.
Baselining is a process of recording the state of a Windows Server 2003 system so that any changes in its performance can be identified at a later date. Baselining also pertains to the overall network performance, including WAN links, but in those cases it may require special software and tools (such as sniffers) to record the information.
A Windows Server 2003 system baseline document records the state of the server after it is implemented in a production environment and can include statistics such as memory utilization, paging, disk subsystem throughput, and more. This information then allows the administrator or appropriate IT resource to determine how the system is performing in comparison to initial operation.
Troubleshooting documentation is helpful both in terms of the processes that the company recommends for resolving technical issues, as well as documenting the results of actual troubleshooting challenges. Often, companies have database and trouble-ticket processes in place to record the time a request was made for assistance, the process followed, and the results. This information should then be available to the appropriate support staff so they know the appropriate resolution if the problem comes up again.
Organizations may also choose to document troubleshooting methodologies to use as training aids and also to ensure that specific steps are taken as a standard practice for quality of service to the user community.
Chapter 2, “Planning, Prototyping, Migrating, and Deploying Windows Server 2003 Best Practices,” provides a detailed look at the type of documentation needed in the design and planning process. This documentation is extremely important when an organization engages in a new project in that it provides both a historical record of what and how the decisions were made and makes sure that the stakeholders are in agreement.
The first step in the implementation of Windows Server 2003 environment is the development and approval of a design. Documenting this design contributes to the success of the project. The design document records the decisions made during the design process and provides a reference for testing, implementation, and support. The key components to a design document include the following:
The goals and objectives of the project
The background or what led up to the design
The approach that will be used to implement the solution
The details of the end state of the project
Goals and objectives can be surprisingly hard to pin down. They need to be detailed and concrete enough to define the results that you want while staying at a high level. For instance, “reduce downtime” is too vague to be considered a functional goal, whereas “implement server clustering with Windows Server 2003 Enterprise Edition to reduce downtime to less than five minutes in the case of single server failure” is much more specific.
Including the background of meetings and brainstorming sessions that led up to the decisions for the end state of the project provides the groundwork for the detailed designs provided later in the document. For example, a decision may have been made “because the CEO wants it that way,” which affects the post-migration environment. Other decisions may have come about after many hours of debates over the particulars and required technical research to come up with the “right” answer. Recording this level of information can be extremely useful in the future if performance issues are encountered or additional changes to the network are being considered.
The description of the end state to be implemented can be very high level or can drill down to more specific configurations of each server, depending on the document’s audience. However, it is recommended that the design document not include step-by-step procedures or other details of how the process will be accomplished. This level of detail is better handled, in most cases, in dedicated configuration or training documents as discussed later in this chapter.
Migration documentation can be created at the same time or shortly after the design documentation to provide a roadmap of the Windows Server 2003 migration. It can also be created after the testing phase is completed, depending on time and resources available. If produced shortly after the design document, this document may need updating after the prototype or testing phase to more accurately reflect the migration process.
Note
The results of testing the design in a prototype or pilot might alter the actual migration steps and procedures. In this case, the migration plan document should be modified to take these changes into account.
The following is a table of contents for a Windows Server 2003 migration plan:
Windows Server 2003 Migration Plan
Goals and Objectives
Approach
Roles
Process
Phase I – Design and Planning
Phase II – Prototype
Phase III – Pilot
Phase IV – Implementation
Phase V – Support
Migration Process
Active Directory Preparation
Windows NT
Windows 2000
Summary of Migration Resources
Project Scheduling
Windows Server 2003 Training
Administration and Maintenance
A project plan is essential for more complex migrations and can be useful for managing smaller projects, even single server migrations. Tasks should be laid out in the order in which they will occur and be roughly half-day durations or more, because a project plan that tries to track a project hour by hour can be overwhelmingly hard to keep up to date.
Tools such as Microsoft Project facilitate the creation of project plans (see Figure 24.1) and enable the assignment of one or more resources per task and the assignment of durations and links to key predecessors. The project plan can also provide an initial estimate of the number of hours required from each resource and the associated costs if outside resources are to be used. “What if” scenarios are easy to create by simply adding resources to more complex tasks or cutting out optional steps to see the effect on the budget.
Note that it’s a great idea to revisit the original project plan after everything is completed (the baseline) to see how accurate it was. Many organizations fail to take this step and miss the opportunity of learning from the planning process to better prepare for the next time around.
Thorough testing is critical in the success of any implementation project. A test plan details the resources required for testing (hardware, software, and lab personnel), the tests or procedures to perform, and the purpose of the test or procedure.
It is important to include representatives of every aspect of the network in the development of the test plan. This ensures that all aspects of the Windows Server 2003 environment or project and its impact will be included in the test plan.
High-level migration procedures should be decided on during a design and planning process and confirmed during a prototype/testing phase. The initial migration document also should focus on the tools that will be used to migrate data, users, and applications, as well as the division of labor for these processes.
A draft of the document can be put together, and when the process is tested again, it can be verified for accuracy. When complete, this information can save you a great deal of time if a number of servers need to be migrated.
Tip
Server migration procedures should be written in such a way so that even less-experienced resources can use the procedures for the actual migrations.
The procedures covered can include the following:
Server hardware configuration details
Windows Server 2003 version for each server
Service pack (SP) and hotfixes to install on each server
Services (such as DNS and DHCP) to enable or disable and appropriate settings
Applications (such as antivirus and SQL Server) to install and appropriate settings
Security settings
Steps required to migrate services and data to the new server(s)
Steps required to test the new configuration to ensure full functionality
Steps required to remove old servers from production
As with the documented server migration process, the desktop migration process should be discussed in the design and planning phase and documented in the migration document. In some migrations to Windows XP, the changes may be minimal, whereas other migrations may require dramatic upgrades. For instance, a desktop machine may qualify for an inplace upgrade to Windows XP, while another may require hardware or a system replacement.
What specifically is documented will vary between organizations; however, the recommended areas to consider documenting are as follows:
Hardware inventory
Installation method(s) (such as Remote Installation Services, third-party imaging software, and network-based installations)
Base installation applications
Security configuration
Templates being used
Language options
Accessibility considerations
Users and their related information (username, password, and contact information) in other systems or directories need to be migrated to take advantage of Windows Server 2003. The procedures to migrate the users should be examined during the design and planning phases of the project.
User information may exist in many different places such as an Active Directory (AD) domain, an application, and more. The user information may be inconsistent depending on where it exists and how it is stored. Procedures should be documented for migrating the user information from each different location. For example, if some users will be migrated from another operating system or from multiple forests, separate procedures should be documented for each process.
Another scenario to document is the migration of user profiles and desktops. Although some of this information may be redundant with desktop migration scenarios, it is nonetheless important to capture the procedures for making sure that, when clients log on after the migration, all their settings still exist and they won’t have any problems with the applications they use. This is a very important consideration for mobile users. For instance, will mobile users need to come back into the office to have settings changed or migrated? Will these changes be performed the next time they log on?
The migration process can often be a long process, based on the amount of data that must be migrated. It is very helpful to develop both high-level and detailed checklists to guide the migration process. High-level checklists determine the status of the migration at any given point in the process. Detailed checklists ensure that all steps are performed in a consistent manner. This is extremely important if the process is being repeated for multiple sites.
The following is an example of a Windows Server 2003 server build checklist:
Task: Initials Notes Verify BIOS and Firmware Revs Verify RAID Configuration Install Windows Server 2003 Enterprise Edition Configure Windows Server 2003 Enterprise Edition Install Security Patches Install Support Tools Install System Recovery Console Add Server to Domain Install Antivirus Install and Configure Backup Agent Apply Rights, Templates, and Policies Set up and Configure Smart UPS Sign off: Date:
Active Directory is one of the core services for a Windows Server 2003 environment. As such, documenting the AD infrastructure is a critical component to the environment. There are many aspects to document as they relate to AD, including, but not limited to, the following:
Forest and domain structure such as DNS names, NetBIOS names, mode of operation, and trust relationships
Names and placement of domain controllers (DCs) and global catalog (GC) servers
Flexible Single Master Operations (FSMO) locations on DCs or GCs
Sites, site links, link costs, and site link bridges
Organizational unit (OU) topology
Special schema entries (such as those made by applications)
Security groups and distribution lists
AD-integrated DNS information
AD security
Group Policy Object (GPO) configurations and structure
This information can be extremely useful in day-to-day operations, as well as when you’re troubleshooting AD issues such as replication latency or logon problems.
Network configuration documentation is essential when you’re designing technologies that may be integrated into the network, when managing network-related services such as DNS, when administering various locations, and when troubleshooting. Network environments usually don’t change as much as a server infrastructure. Nonetheless, it’s important to keep this information current and accurate through periodic reviews and analysis.
Network configuration documentation also includes WAN infrastructure connectivity. Consider documenting the following:
Internet service provider contact names, including technical support contact information
Connection type (such as frame relay, ISDN, OC-12)
Link speed
Committed Information Rate (CIR)
End-point configurations, including routers used
Enterprise networks can have many different types of WAN links, each varying in speed and CIR. This documentation is useful not only for understanding the environment, but also for troubleshooting connectivity, replication issues, and more.
Network devices such as firewalls, routers, and switches use a proprietary operating system. Also, depending on the device, the configuration should be documented. Some devices permit configuration dumps to a text file that can be used in the overall documentation, whereas others support Web-based retrieval methods. In worst-case scenarios, administrators must manually document the configurations.
Network device configurations, with possibly the exception of a firewall, rarely change. If a change does occur, it should be documented in a change log and updated in the network infrastructure documentation. This allows administrators to keep accurate records of the environment and also provides a quick documented way to rebuild the proper configurations in case of a failure.
The configuration document, often referred to as an as-built, details a snapshot configuration of the Windows Server 2003 system as it is built. This document contains essential information required to rebuild a server.
The following is a Windows Server 2003 as-built document template:
Introduction
The purpose of this Windows Server 2003 as-built document is to assist an
experienced network administrator or engineer in restoring the server in the
event of a hardware failure. This document contains screen shots and
configuration settings for the server at the time it was built. If settings
are not implicitly defined in this document, they are assumed to be set to
defaults. It is not intended to be a comprehensive disaster recovery with
step-by-step procedures for rebuilding the server. In order for this document
to remain useful as a recovery aid, it must be updated as configuration
settings change.
System Configuration
Hardware Summary
Disk Configuration
Logical Disk Configuration
System Summary
Device Manager
RAID Configuration
Windows Server 2003 TCP/IP Configuration
Network Adapter Local Area Connections
Security Configuration
Services
Lockdown Procedures (Checklist)
Antivirus Configuration
Share List
Applications and Configurations
Administration and maintenance documentation can be critical in maintaining a reliable network environment. These documents help an administrator of a particular server or set of servers organize and keep track of the different steps that need to be taken to ensure the health of the systems under his care. They also facilitate the training of new resources and reduce the variables and risks involved in these transitions.
Note that Windows Server 2003 systems, as discussed previously, can serve several different functions on the network, such as file servers, print servers, Web servers, messaging servers, terminal servers, and remote access servers. The necessary maintenance procedures may be slightly different for each one based on its function and importance in the network.
One key component to administration or maintenance documentation is a timeline detailing when certain procedures should be followed. As Chapter 22, “Windows Server 2003 Management and Maintenance Practices,” discusses, certain daily, weekly, monthly, and quarterly procedures should be followed. These procedures, such as weekly event log archiving, should be documented to make sure that there are clearly defined procedures and frequency in which they should be performed.
Administration and maintenance documentation contains a significant amount of procedural documentation. These documents can be very helpful for complex processes, or for processes that are not performed on a regular basis. Procedures range from technical processes that outline each step to administrative processes that help clarify roles and responsibilities.
Although policy documents may not be exciting reading, they can be an administrator’s best friend in touchy situations. A well-thought-out, complete, and approved policy document makes it very clear who is responsible for what in specific situations. It’s also important to be realistic about which polices need to be documented and what is excessive—for example, document policies concerning when and how the servers can be updated with patches, newer hardware, or software.
Administration and maintenance documentation can be extensive, and checklists can be quick reminders for those processes and procedures. Develop comprehensive checklists that will help administrators perform their scheduled and unscheduled tasks. A timeline checklist highlighting the daily, weekly, monthly, and quarterly tasks helps keep the Exchange environment healthy. In addition, these checklists function as excellent auditing tools.
Procedural documents can be very helpful for complex processes. They can apply to technical processes and outline each step, or to administrative processes to help clarify roles and responsibilities.
Flowcharts from Microsoft Visio or a similar product are often sufficient for the more administrative processes, such as when testing a new patch to a key software application, approving the addition of a new server to the network, or scheduling network downtime.
If there is one type of documentation that a network needs, disaster recovery policies and procedures are highly recommended. Every organization should go through the process of contemplating various disaster scenarios. For instance, organizations on the West Coast may be more concerned with earthquakes than those on the East Coast. Each disaster can pose a different threat. Therefore, it’s important to determine every possible scenario and begin planning ways to minimize those disasters.
Equally important is analyzing how downtime resulting from a disaster may affect the company (reputation, time, productivity, expenses, loss in profit or revenue) and determine how much should be invested in remedies to avoid or minimize the effects.
A number of different components comprise disaster recovery documentation. Without this documentation, full recovery is difficult at best. The following is a table of contents for the areas to consider when documenting disaster recovery procedures:
Executive Summary or Introduction
Disaster Recovery Scenarios
Disaster Recovery Best Practices
Planning and Designing for Disaster
Business Continuity and Response
Business Hours Response to Emergencies
Recovery Team Members
Recovery Team Responsibilities
Damage Assessment
Off-Hours Response to an Emergency
Recovery Team Responsibilities
Recovery Strategy
Coordinate Equipment Needs
Disaster Recovery Decision Tree
Software Recovery
Hardware Recovery
Server Disaster Recovery
Preparation
Documentation
Software Management
Knowledge Management
Server Backup
Client Software Configuration
Restoring the Server
Build the Server Hardware
Post Restore
Active Directory Disaster Recovery
Disaster Recovery Service Level Agreements
Exchange Disaster Recovery Plan
Complete RAID 5 Failure
Complete RAID 1 Failure
Complete System Failure
NIC, RAID Controller Failures
Train Personnel and Practice Disaster Recovery
The first step of the disaster recovery process is to develop a formal disaster recovery plan. This plan, while time consuming to develop, serves as a guide for the entire organization in the event of an emergency. Disaster scenarios, such as power outages, hard drive failures, and even earthquakes, should be addressed. Although it is impossible to develop a scenario for every potential disaster, it is still helpful to develop a plan to recover for different levels of disaster. It is recommended that organizations encourage open discussions of possible scenarios and the steps required to recover from each one. Include representatives from each department, because each department will have its own priorities in the event of a disaster. The disaster recovery plan should encompass the organization as a whole and focus on determining what it will take to resume normal business function after a disaster.
Backup procedures encompass not just backing up data to tape or other medium, but also a variety of other tasks, including advanced system recovery, offsite storage, and retention. These tasks should be carefully documented to accurately represent what backup methodologies are implemented and how they are carried out. Step-by-step procedures, guidelines, policies, and more may be documented.
Periodically, the backup documents should be reviewed and tested, especially after any configuration changes. Otherwise, backup documents can become stale and can only add more work and add to the problems during recovery attempts.
Recovery documentation complements backup documentation. This documentation should include where the backup data resides and how to recover from various types of failures (such as hard drive failure, system failure, and natural disaster). As with backup documentation, recovery documentation can take the form of step-by-step guides, policies, frequently asked questions (FAQs), and checklists. Moreover, recovery documents should be reviewed and revised if necessary.
Monitoring is not typically considered a part of disaster recovery documentation. However, alerting mechanisms can detect and bring attention to issues that may arise. Alerting mechanisms can provide a proactive means to determining whether a disaster may strike. Documenting alerting mechanisms and the actions to take when an alert is received can reduce downtime and administration.
Organizations using failover technologies or techniques such as clustering or network load balancing (NLB) can benefit from having documentation regarding failover. When a system fails over, knowing the procedures to get the system back up and running quickly can help you avoid unnecessary risk. These documented procedures must be thoroughly tested and reviewed in a lab setting so that they accurately reflect the process to recover each system.
Changes to the environment may occur all the time in an organization, yet often those changes are either rarely documented or no set procedures are in place for making those changes. IT personnel not responsible for the change may be oblivious to those changes, and other administration or maintenance may be adversely affected.
Documented change management seeks to bring knowledge consistency throughout IT, control when and how changes are made, and minimize disruption from incorrect or unplanned changes. As a result, documenting change procedures should entail the processes to request and approve changes, high-level testing procedures, the actual change procedures, and any rollback procedures in case problems arise.
Documenting performance-related information is a continuous process due to the ever-changing metrics of business. This type of documentation begins by aligning with the goals, existing policies, and SLAs for the organization. When these areas are clearly defined and detailed, baseline performance values can be established using the System Monitor, Microsoft Operations Manager (MOM), or third-party tools (such as PerfMon and BMC Patrol). Performance baselines capture performance-related metrics, such as how much memory is being used, average processor utilization, and more; they also illustrate how the Windows Server 2003 environment is performing under various workloads.
After the baseline performance values are documented and understood, the performance-related information that the monitoring solution is still capturing should be analyzed periodically. More specifically, pattern and trend analysis needs to be examined on a weekly basis if not on a daily basis. This analysis can uncover current and potential bottlenecks and proactively ensure that the system operates as efficiently and effectively as possible.
Although the System Monitor can log performance data and provide reporting when used with other products such as Microsoft Excel, it behooves administrators to use products such as MOM for monitoring and reporting functionality. For example, MOM can manage and monitor multiple systems and provide graphical reports with customizable levels of detail.
Management-level reporting on performance data should be concise and direct but still at a high level. Stakeholders don’t require an ample amount of performance data, but it’s important to show trends, patterns, and any potential problem areas. This extremely useful information provides a certain level of insight to management so that decisions can be made as to what is required to keep the systems operating in top-notch condition. For instance, administrators identify and report to management that, if current trends on Exchange Server processor utilization continue at the current rate of a 5% increase per month, this will require additional processors in 10 months or less. Management can then take this report, follow the issue more closely over the next few months, and then determine whether to allocate funds to purchase additional processors. If the decision is made to buy more processors, management has more time to negotiate quantity, processing power, and cost instead of having to potentially pay higher costs for the processors at short notice.
Technical performance information reporting is much more detailed than management-level reporting. Details are given on many different components and facets of the system. For example, many specific counter values may be given to determine disk subsystem utilization. In addition, trend and pattern analysis should also be included to show historical information and determine how to plan for future requirements.
Administrators can easily feel that documenting security settings and other configurations is important but that this documentation may lessen security mechanisms in the Windows Server 2003 environment. Nevertheless, documenting security mechanisms and corresponding configurations is vital to administration, maintenance, and any potential security compromise.
As with many of the documents about the network environment, they can do a lot of good for someone either externally or internally trying to gain unauthorized access. So, security documentation and many other forms of documentation, including network diagrams, configurations, and more, should be well guarded to minimize any security risk.
Some areas regarding security that should be documented include, but aren’t limited to, the following:
Auditing policies including review
Service packs (SPs) and updates
Certificates and certificates of authority
Firewall and proxy configurations
Antivirus configurations
Access control policies including NTFS-related permissions
Encrypting File System (EFS)
Password policies (such as length, strength, and age)
GPO security-related policies
Registry security
Lockdown procedures
Although the documentation of policies and procedures to protect the system from external security risks is of utmost importance, internal procedures and documents should also be established. Developing, documenting, and enforcing a change-control process helps protect the system from well-intentioned internal changes.
In environments with multiple administrators, it is very common to have the interests of one administrator affect those of another. For instance, an administrator might make a configuration change to limit volume size for a specific department. If this change is not documented, a second administrator might spend a significant amount of time trying to troubleshoot a user complaint from that department. Establishing a change control process that documents these types of changes eliminates confusion and wasted resources. The change control process should include an extensive testing process to reduce the risk of production problems.
A network environment may have many security mechanisms in place, but if the information such as logs and events obtained from them isn’t reviewed, security is more relaxed. Monitoring and management solutions (such as MOM) can help consolidate this information into a report that can be generated on a periodic basis. This report can be invaluable to continuously evaluating the network’s security.
The reports should be reviewed daily and should include many details for the administrators to analyze. MOM, for example, can be customized to report on only the most pertinent events to keeping the environment secure.
Management should be informed of any unauthorized access or attempts to compromise security. The technical details that an administrator appreciates are usually too detailed for management. Therefore, management-level reporting on security issues should contain only vital statistics and any risks that may be present. Business policy and budget-related decisions can then be made to strengthen the environment’s security.
Training documentation can entail a myriad of options. For example, an organization can have training documentation for maintenance and administration procedures, installation and configuration of new technologies, common end-user tasks, ways various network components can be used, future technologies, and much more. The documentation should match current training procedures, and it can also help define which trainings will be offered in the future.
Administrators are responsible for the upkeep and management of the network environment. As a result, they must be technically prepared to address a variety of issues such as maintenance and troubleshooting. Training documentation should address why the technologies are being taught and how the technologies pertain to the network environment, and it should also provide step-by-step hands-on procedures to perform the tasks.
Training materials and other forms of documentation for end users offer the users a means for learning an application, ways to map network drives, ways to locate information, and much more. End-user training documentation also serves as a great reference tool after training has been concluded.
To gain control over how the system is to be used, it’s important for an organization to implement system usage policies. Policies can be set on end users as well as on the IT personnel. Policies for end users may include specifying which applications are supported on the network, that gaming is not allowed on the local machine or the network, and that users must follow specific steps to obtain technical support. On the other hand, IT personnel policies may include when to set database replication intervals or specify that routine system maintenance can occur only between 5:00 a.m. and 9:00 a.m. on Saturdays.
Most, if not all, aspects of a Windows Server 2003 network environment can be documented. However, the type of documentation that may benefit the environment depends on each organization. Overall, documenting the environment is an important aspect of the network and can assist all aspects of administration, maintenance, support, troubleshooting, testing, and design.
Have documentation reviewed and approved by other stakeholders in the organization to make sure that it meets their needs as well, and to simply get input from another source. For technical procedures, the document also must be tested and walked through.
Consolidate and centralize documentation for the organization.
Document the company’s policies and procedures for securing and maintaining.
Create well-thought-out and professional planning and design documentation to avoid costly mistakes in the implementation or migration process, such as buying too many server licenses or purchasing too many servers.
Baseline and document the state of a Windows Server 2003 so that any changes in its performance can be identified at a later date.
Use tools such as Microsoft Project to facilitate the creation of project plans, enable the assignment of one or more resources per task, and the assignment of durations and links to key predecessors.
Create disaster recovery documentation that includes step-by-step procedures for rebuilding each server and network device to minimize downtime and administration.
Document daily, weekly, monthly, and quarterly maintenance tasks to ensure the health of the systems.
Use documentation to facilitate training.
Document business and technical policies for the organization.