Many discussions of the business reasons for new software deployments echo common themes: enhance productivity, eliminate downtime, reduce costs, and the like. Translating these often somewhat vague (and occasionally lofty) aspirations into concrete goals sometimes takes a bit of effort. It is well worth taking the time, however, to refine the big picture into specific objectives before moving on. An IT department should serve the needs of the business, not the other way around; if you don’t understand those needs clearly, you’ll have a hard time fulfilling them.

Be sure to ask for the input of people close to where the work is being done—department managers from each business area should be asked about what they need from IT, what works now, and what doesn’t. These people care about the day-to-day operations of their computing environment. Will the changes help their staff members do their work? Ask about work patterns, both static and burst—the finance department’s workflow is not the same in July as it is in April. Make sure to include all departments and any significant subsets—human resources (HR), finance, sales, business units, executive management, and so on.

You should also identify risks that lie at the business level, such as resistance to change, lack of commitment (frequently expressed as inadequate resources: budget, staff, time, and so on), or even the occasional bit of overt opposition. At the same time, look for positives to exploit; enthusiastic staff can help energize others, and having a manager in your corner can smooth many bumps along the way. By getting people involved, you can gain allies who are vested in the success of the project.

IT goals are often obvious: improve network reliability, provide better security, deliver enhanced administration, and maybe even implement a particular new feature. They are also easier to identify than those of other departments—after all, they are directly related to technology.

When you define your goals, make sure that you are specific. It is easy to say you will improve security, but how will you know when you have done so? What’s improved and by how much? In many cases, IT goals map to the implementation of features or procedures; for example, to improve security, you will implement Internet Protocol Security (IPsec) and encrypt all traffic to remote networks.

Don’t overpromise, either—eliminating downtime is a laudable goal but not one you are likely to achieve on your network and certainly not one on which you want your next review based.

A number of aspects of your organization’s business should be considered when evaluating your overall IT requirements and the business environment in which you operate. Consider things such as the following:

Part of planning is projecting into the future and predicting how future business needs will influence the activities of the IT department. Managing complicated systems is easier when it’s done from a proactive stance rather than a reactive one. Predicting network change is an art, not a science, but it behooves you to hone your skills at it.

This is primarily a business assessment, based on things such as expected growth, changes in business focus, or possible downsizing and outsourcing—each of which provides its own challenges to the IT department. Being able to predict what will happen in the business and what those changes will mean to the IT department enables you to include room for expansion in your network design.

When attempting to predict what will happen, look at the history of the company. Are mergers, acquisitions, spin-offs, and so on common? If so, this indicates a considerable need for flexibility from the IT department and the need to keep in close contact with people on the business side to avoid being blindsided by a change in the future.

As people meet to discuss the deployment, talk about what is coming up for the business units. Cultivate contacts in other parts of the company and talk with those people regularly about what’s going on in their departments, such as upcoming projects and what’s happening with other companies in the same business sector. Reading the company’s news releases and articles in outside sources can also provide valuable hints of what’s to come. By keeping your ear to the ground, doing a little research, and thinking through the potential impact of what you learn, you can be much better prepared for whatever is coming up next.

You should get an idea of what the current network looks like before moving to a new operating system. You will require configuration information while designing the modifications to the network and deploying the servers. In addition, some aspects of Windows Server 2012 R2, such as the sites used in Active Directory replication, are based on your physical network configuration. (A site is a segment of the network with good connectivity, consisting of one or more Internet Protocol [IP] subnets.)

For reasons such as this, you want to assess a number of aspects related to your physical network environment. Consider such characteristics as the following:

As part of planning, you should inventory the existing network servers, identifying each system’s operating system version, IP address, Domain Name System (DNS) names, and the services provided by that system. Collect such information by performing the following tasks:

You can gather hardware and software inventories of computers that run the Windows operating system by using a tool such as SCCM. Review the types of clients that must be supported so that you can configure servers appropriately. This is also a good time to determine any client systems that must be upgraded (or replaced) to use Windows Server 2012 R2 functionality. You can also gather this information with scripts or a software management program.

Look at your current network services, noting which services are running on which servers and the dependencies of these services. Do this for all domain controllers and member servers that you’ll be upgrading. You’ll use this information later to plan for server placement and service hosting on the upgraded network configuration. Some examples of services to document are as follows:

This list is only the beginning. Your network will undoubtedly have many more services that you must take into account.

When you document your network infrastructure, you will need to review many aspects of your network security. In addition to security concerns that are specific to your network environment, the following factors should be addressed:

Depending on your existing network security mechanisms, the underlying security methods can change upon deployment of Windows Server 2012 R2. Windows Server 2003 is the minimum forest and domain functional level Windows Server 2012 R2 supports. When the forest and domain functional levels are raised to this level or higher from a lower level, Kerberos is the default authentication mechanism used between computer systems. This also means that although the Windows NT 4 security model (using NTLM authentication) continues to be supported, it is no longer the default authentication mechanism.

Examining the administrative methods currently in use on your network provides you with a lot of information about what you are doing right and identifies areas that could use some improvement. Use this information to tweak network procedures where needed to optimize the administration of the new environment.

Network administrative model Each company has its own type of approach to network administration—some are very centralized, with the IT department making even the smallest changes, whereas others are partially managed by the business units, which control aspects such as user management. Administrative models fit into these categories:

Disaster recovery The costs of downtime caused by service interruption or data loss can be substantial, especially in large enterprise networks. As part of your overall planning, determine whether a comprehensive IT disaster recovery plan is in place. If one is in place, this is the time to determine its scope and effectiveness and verify that it is being followed. If one isn’t in place, this is the time to create and implement one.

Document the various data sets being archived, schedules, backup validation routine, staff assignments, and so on. Make sure there are provisions for offsite data storage to protect your data in the case of a catastrophic event such as a fire, earthquake, or flood.

Examine the following:

Network management tools This is an excellent time to assess your current suite of network management tools. Pay particular attention to those that are unnecessary, incompatible, redundant, inefficient, or otherwise not terribly useful. You might find that some of the functionality of those tools is present natively in Windows Server 2012 R2. Assess the following aspects of your management tools:

Many goals of the various business units and IT are only loosely related, whereas others are universal—everyone wants security, for example. Take advantage of where goals converge to engage others in the project. If people can see that their needs are met, they are more likely to support others’ goals and the project in general.

You have business objectives at this point; now they must be prioritized. You should make lists of various critical aspects of projects and dependencies within the project plan as part of the process of winnowing the big picture into a set of realistic objectives. Determine what you can reasonably accomplish within the constraints of the current project. Also, decide what is outside the practical scope of this Windows Server 2012 R2 deployment but is still important to implement later.

The objectives that are directly related to the IT department will probably be clearer—and more numerous—after completing the analysis of the current network. These objectives should be organized to conform to existing change-management procedures within your enterprise network.

When setting goals, be careful not to promise too much. Although it’s tempting and sometimes easier in the short run to try to do everything, you can’t. It’s unlikely that you will implement every single item on every person’s wish list during the first stage of this project, if at all. Knowing what you can’t do is as important as knowing what you can.

You should create a project schedule, laying out the timeline, tasks, and staff assignments. Including projected completion dates for milestones helps you keep on top of significant portions of the project and ensures that dependencies are managed.

You must be realistic when considering timelines—not just a little bit realistic, but really realistic. This is, after all, your time you are allocating. Estimate too short a time, and you are likely to spend evenings and weekends at the office with some of your closest coworkers.

A number of tasks will be repeated many times during the rollout of Windows Server 2012 R2, which should make estimating the time needed for some things fairly simple: a 1-hour process repeated 25 times takes 25 hours (unless it’s automated). If, for example, you are building 25 new servers in-house, determine the actual time needed to build one and then do the math.

When you have a rough idea of the time required, do the following:

Determining the budget is a process constrained by many factors, including but not limited to IT-related costs for hardware and licensing. In addition to fixed IT costs, you also must consider the project scope and the non-IT costs that can come from the requirements of other departments within the organization. Thus, to come up with the budget, you need information and assistance from all departments within the organization, and you must consider all aspects of the project.

Many projects end up costing more than is initially budgeted. Sometimes this is predictable and preventable with proper research and a bit of attention to ongoing expenses. As with timelines, pad your estimates a little bit to allow for the unexpected. Even so, it helps if you can find out how much of a buffer you have for any cost overruns.

In planning the budget, also keep in mind fiscal periods. If your project is crossing budget periods, find out whether next year’s budget for the project is allocated and approved.

No matter how carefully you plan any project, it is unlikely that everything will go exactly as planned. Accordingly, you should plan for contingencies. By having a number of possible responses to unforeseen events ready, you can manage the vagaries of the project better.

Start with perhaps the most common issue encountered during projects: problems getting the assigned people to do the work. This all-too-common problem can derail any project or at least cause the project manager a great deal of stress. After all, the ultimate success of any project depends on people doing their assigned tasks. Many of these people are already stretched pretty thin, however, and you might encounter times when they aren’t quite getting everything done. Your plan should include what to do in this circumstance—is the person’s manager brought in, or is a backup person automatically assigned to complete the job?

Another possibility to plan for is a change in the feature set being implemented. If such shifts occur, you must decide how to adjust to compensate for the reallocated time and money required. To make this easier, identify and prioritize the following:

Items on both of these lists should be relatively small and independent of other processes and services. Avoid incurring additional expenses; you are more likely to be given extra time than extra funding during your deployment.

In general, ask yourself what could happen to cause significant problems along the way. Then, more important, consider what you would do in response. By thinking through potential problems ahead of time and planning what you might do in response, you can be prepared for many of the inevitable bumps along the way.

You have goals, know the timeline, and have a budget pinned down—now it’s time to get serious. Starting with the highest-priority aspects of the project, estimate the time and budget needed to complete each portion. Work your way through the planned scope, assessing the time and costs associated with each portion of the project. This helps ensure that the time and budget are sufficient to complete the project successfully as designed.

As you finalize the project plan, each team member should review the final project scope, noting any concerns or questions he has about the proposal. Encourage the team to look for weak spots, unmet dependencies, and other places where the plan might break down. Although it is tempting to ignore potential problems that are noted this late in the game, you do so at your own peril. Avoiding known risks is much easier than recovering from unforeseen ones.

You also must assess the impact of the projected changes on your current network operations. Consider issues such as the following:

This is a good time to review seriously the security measures implemented on your network. Scrutinize the security devices, services, protocols, and administrative procedures to ensure that they are adequate, appropriate, well documented, and adhered to rigorously.

Security in Windows Server 2012 RTM and Windows Server 2012 R2 are not the same as in early versions of Windows Server operating systems—the security settings for the default (new) installation of Windows Server 2012 RTM and Windows Server 2012 R2 are much tighter than in those early versions. This might mean that services that were functioning perfectly prior to an upgrade don’t work the same way afterward. Some services that were previously started by default are now disabled when first installed.

Assign staff members to be responsible for each aspect of your security plan and have them document the completion of tasks. Among the tasks that should be assigned are the following:

While you are rolling out Windows Server 2012 R2 is an excellent time to fine-tune your administration methods and deal with any issues introduced by the growth and change in the project scope. Well-designed administrative methods with clearly documented procedures can make a huge difference in streamlining both the initial rollout and ongoing operations.

Active Directory provides the framework for flexible, secure network management so you can implement the administration method that works best in your environment. There are mechanisms that support both centralized and distributed administration; Group Policy options offer centralized control, and selected administrative capabilities can be securely delegated at a highly granular level. The combination of these methods allows administration to be handled by using the method that works best for each business in its unique circumstances.

You will also want to select and implement standards. If your IT department has not implemented standards for naming and administration procedures, this is a good time to do so. You’ll be gathering information about your current configuration, which will show you the places where standardization is in place and the places where it would be useful.

Make sure that any standards you adopt allow for likely future growth and changes in the business. Using an individual’s first name and last initial is a very simple scheme for creating user names and works well in a small business. Small businesses, however, don’t necessarily stay small forever—even Microsoft initially used this naming scheme, although it has been modified greatly over the years.

You can also benefit from standardization of system hardware and software configuration. Supporting 100 servers (or clients) is much easier if they share a common set of hardware, are similarly configured, and have largely the same software installed. This is possible, of course, only to a limited degree and depends on the services and applications that are required from each system. Still, it’s worth considering.

When standardizing server hardware, keep in mind that the minimum functional hardware differs for various types of servers—that is, application servers have very different requirements than file servers. Also, consider the impact of the decisions the IT department makes on other parts of the company and individual employees. There are some obvious things to watch for such as unnecessarily exposing anyone’s personal data—surprising numbers of businesses and agencies still do this.

Formalized change-management processes are very useful, especially for large organizations and those with distributed administrative models. By creating structured change-control processes and implementing appropriate auditing, you can control the ongoing management of critical IT processes. This makes it easier to manage the network and reduces the opportunity for error.

Although this is particularly important when dealing with big-picture issues such as domain creation or Group Policy implementation, some organizations define change-control mechanisms for every possible change, no matter how small. You have to determine for which IT processes you must define change-management processes and find a balance between managing changes effectively and overregulating network management.

Even if you’re not planning to implement a formal change-control process, make sure that the information about the initial configuration is collected in one spot. By doing this, and by collecting brief notes about any changes that are made, you will at least have data about the configuration and the changes that have been made to it. This will also help later, if you decide to put more stringent change-control mechanisms in place, by providing at least rudimentary documentation of the current network state.

The physical structures and facilities supporting your server room are critically important. Without adequate support structures and facilities, you will have problems. The primary considerations for support structures and facilities have to do with the physical environment of the servers. These considerations also extend to the physical security of the server environment.

Just as hardware and software have availability requirements, so should support structures and facilities. Factors that affect the physical environment are as follows:

Temperature and humidity should be carefully controlled at all times. Processors, memory, hard drives, and other pieces of physical equipment operate most efficiently when they are kept cool; between 65 and 70 degrees Fahrenheit is the ideal temperature in most situations. Equipment that overheats can malfunction or cease to operate altogether. Servers should have multiple, redundant internal fans to ensure that these and other internal hardware devices are kept cool.

Humidity should be kept low to prevent condensation, but the environment shouldn’t be dry. A dry climate can contribute to static electricity problems. Antistatic devices and static guards should be used in most environments.

Dust and other contaminants can cause hardware components to overheat or short out. Servers should be protected from these contaminants whenever possible. You should ensure that an air-filtration system is in place in the server room or hosting facility. The regular preventive maintenance cycle on the servers should include checking servers and their cabinets for dust and other contaminants. If dust is found, the servers and cabinets should be carefully cleaned.

Few things affect the physical environment more than wiring and cabling. All electrical wires and network cables should be tested and certified by qualified technicians. Electrical wiring should be configured to ensure that servers and other equipment have adequate power available for peak usage times. Ideally, multiple dedicated circuits should be used to provide power.

Improperly installed network cables are the cause of most communications problems. Network cables should be tested to ensure that their operation meets manufacturer specifications. Redundant cables should be installed to ensure the availability of the network. All wiring and cabling should be labeled and well maintained. Whenever possible, use cable management systems and tie wraps to prevent physical damage to wiring.

Ensuring that servers and their components have power is also important. Servers should have hot-swappable, redundant power supplies. Being hot swappable ensures that the power supply can be replaced without having to turn off the server. Redundancy ensures that if one power supply malfunctions, the other will still deliver power to the server. You should be aware that having multiple power supplies doesn’t mean that a server or hardware component has redundancy. Some hardware components require multiple power supplies to operate. In this case, an additional (third or fourth) power supply is needed to provide redundancy.

The redundant power supplies should be plugged into separate power strips, and these power strips should be plugged into separate local uninterruptible power supply (UPS) units if other backup power sources aren’t available. Some facilities have enterprise UPS units that provide power for an entire room or facility. If this is the case, redundant UPS systems should be installed. To protect against long-term outages, gas-powered or diesel-powered generators should be installed. Most hosting and collocation facilities have generators. Nevertheless, having a generator isn’t enough; the generator must be rated to support the peak power needs of all installed equipment. If the generator cannot support the installed equipment, brownouts (temporary outages) will occur.

In addition, access controls should be used to restrict physical access to the server room or facility. Use locks, key cards, access codes, or biometric scanners to ensure that only designated individuals can gain entry to the secure area. If possible, use surveillance cameras and maintain recorded tapes for at least a week. When the servers are deployed in a hosting or collocation facility, ensure that locked cages are used and that fencing extends from the floor to the ceiling.

The following checklist summarizes the recommendations for designing and planning structures and facilities:

Day-to-day operations and support procedures must be in place before you deploy mission-critical systems. The most critical procedures for day-to-day operations involve the following activities:

Monitoring is critical to the success of business system deployments. You must have the necessary equipment to monitor the status of the business systems. Monitoring enables you to be proactive in system support rather than reactive. Monitoring should extend to the hardware, software, and network components but shouldn’t interfere with normal systems operations—that is, the monitoring tools chosen should require only limited system and network resources to operate.

Without careful analysis, the data collected from monitoring is useless. Procedures should be put in place to ensure that personnel know how to analyze the data they collect. The network infrastructure is a support area that is often overlooked. Be sure you allocate the appropriate resources for network monitoring.

Resources, training, and documentation are essential to ensuring that you can manage and maintain mission-critical systems. Many organizations cripple the operations team by staffing minimally. Minimally staffed teams will have marginal response times and nominal effectiveness. The organization must take the following steps:

Every change to hardware, software, and the network must be planned and executed deliberately. To do this, you must have established change-control procedures and well-documented execution plans. Change-control procedures should be designed to ensure that everyone knows what changes have been made. Execution plans should be designed to ensure that everyone knows the exact steps that were or should be performed to make a change.

Change logs are a key part of change control. Each piece of physical hardware deployed in the operational environment should have a change log, which should be stored in a text document or spreadsheet or, ideally, a ticketing system that is readily accessible to support personnel. The change log should show the following information:

You should have well-defined backup and recovery plans. The backup plan should specifically state the following information:

Backups should be monitored daily to ensure that they are running correctly and that the media are good. Any problems with backups should be corrected immediately. Multiple media sets should be used for backups, and these media sets should be rotated on a specific schedule. With a four-set rotation, there is one set each for daily, weekly, monthly, and quarterly backups. By rotating one media set offsite, support staff can help ensure that the organization is protected in case of a disaster.

The recovery plan should provide detailed, step-by-step procedures for recovering the system under various conditions, such as procedures for recovering from hard disk drive failure or troubleshooting problems with connectivity to the back-end database. The recovery plan should also include system design and architecture documentation that details the configuration of physical hardware, application-logic components, and back-end data. Along with this information, support staff should provide a media set containing all software, drivers, and operating system files needed to recover the system.

You should practice restoring critical business systems by using the recovery plan. Practice shouldn’t be conducted on the production servers. Instead, the team should practice on test equipment with a configuration similar to the real production servers. Practicing once a quarter or semiannually is highly recommended.

You should have well-defined problem-escalation procedures that document how to handle problems and emergency changes that might be needed. Some organizations use a three-tiered help desk structure for handling problems:

All crises and emergencies should be responded to decisively and resolved methodically. A single person on the emergency response team should be responsible for coordinating all changes and executing the recovery plan. This same person should be responsible for writing an after-action report that details the emergency response and resolution process used. The after-action report should analyze how the emergency was resolved and the root cause of the problem.

In addition, you should establish procedures for auditing system usage and detecting intrusion. In Windows Server 2012 R2, auditing policies are used to track the successful or failed execution of the following activities:

You should have an incident-response plan that includes priority escalation of suspected intrusion to senior team members and provides step-by-step details on how to handle the intrusion. The incident-response team should gather information from all network systems that might be affected. The information should include event logs, application logs, database logs, and any other pertinent files and data. The incident-response team should take immediate action to lock out accounts, change passwords, and physically disconnect the system if necessary. All team members participating in the response should write a postmortem report that details the following information:

The team leader should write an executive summary of the incident and forward this to senior management.

The following checklist summarizes the recommendations for operational support of high-availability systems:

You should always create a plan before deploying a business system. The plan should show everything that must be done before the system is transitioned into the production environment. After a system is in the production environment, the system is deemed operational and should be handled as outlined in “Planning for day-to-day operations” earlier in this chapter.

The deployment plan should include the following items:

Checklists are a key part of the deployment plan. The purpose of a checklist is to ensure that the entire deployment team understands the steps the members need to perform. Checklists should list the tasks that must be performed and designate individuals to handle the tasks during each phase of the deployment—from planning to testing to installation. Prior to executing a checklist, the deployment team should meet to ensure that all items are covered and that the necessary interactions among team members are clearly understood. After deployment, the preliminary checklists should become part of the system documentation, and new checklists should be created any time the system is updated.

The deployment plan should include a contact list that provides the name, role, telephone number, and email address of all team members, vendors, and solution-provider representatives. Alternative numbers for cell phones and pagers should also be provided.

The deployment plan should include a test plan. An ideal test plan has several phases. In Phase I, the deployment team builds the business system and support structures in a test lab. Building the system means accomplishing the following tasks:

The deployment team can conduct any necessary testing and troubleshooting in the isolated lab environment. The entire system should undergo burn-in testing to guard against faulty components. If a component is flawed, it usually fails in the first few days of operation. Testing doesn’t stop with burn-in. Web and application servers should be stress tested. Database servers should be load tested. The results of the stress and load tests should be analyzed to ensure that the system meets the performance requirements and expectations of the customer. Adjustments to the configuration should be made to improve performance and optimize the configuration for the expected load.

In Phase II, the deployment team tests the business system and support equipment in the deployment location. Team members conduct similar tests as before, but in the real-world environment. Again, the results of these tests should be analyzed to ensure that the system meets the performance requirements and expectations of the customer. Afterward, adjustments should be made to improve performance and optimize as necessary. The team can then deploy the business system.

After deployment of the server or servers, the team should perform limited, nonintrusive testing to ensure that the system is operating normally. After Phase III testing is completed, the team can use the operational plans for monitoring and maintenance.

The following checklist summarizes the recommendations for predeployment planning of mission-critical systems: