S 4.412 Secure migration of Windows Server 2003 to Server 2008
Initiation responsibility: IT Security Officer
Implementation responsibility: Administrator
The migration of Windows Server 2003 to Server 2008 first requires careful planning. For this purpose, the migration strategy must be specified first:
- For a new installation, the data of the old IT system is secured, a new (current) IT system is installed on the same hardware and the services are reinstalled again using the secured databases. This method is connected with downtimes during the migration and requires a high amount of planning. There is the risk of a prolonged downtime in the event of unexpected problems.
- For an in-place update, an update of the system software is initiated out of the running system. This method includes various risks, among others, the acceptance of "old problems" in the configuration, production downtimes during the update and the risk of a failed update.
- For a "real" migration, the new system is installed on new hardware in parallel to the old system and the productive services are subsequently moved from the old system to the new system.
The third scenario offers the best protection against production or data losses, but requires the availability of additional hardware to install the new IT system in parallel to the migration. Due to the better test capabilities, in particular, this migration scenario should be primarily selected.
Migration planning
For the planning, at least the following aspects must be considered:
- The required time frames of the migration must be taken into account considering the effects on productive services on the migrated system or additional systems depending on these services.
- It must be specified who carries out the migration.
- The procedure for the migration must be selected.
- Test steps during the migration process including termination criteria.
- Contingency plans and handling options must be discussed and specified.
- The affected users as well as the persons responsible for dependent IT systems must be informed on the steps of the migration affecting them.
The results should be documented in a migration concept. More detailed information on the migration concept and its contents can be found in S 2.319 Migration of servers.
If there are no Server 2008 systems available yet in the Windows domain, the migration of the domain controller (see S 4.317 Secure migration of Windows directory services) or at least increasing the Active Directory function level must also be included in planning. Here, it must be tested in advance if problems with existing applications occur resulting from the changes in the Active Directory (see T 2.156 Compatibility problems when increasing the Active Directory function level).
If data of the source system is stored on an external data medium such as a SAN/NAS or an external hard disk, it must be specified whether the files are copied during the migration or the new server is to access the data on the existing storage system. The second method is the easier method, since there is no copy operation, but is subject to certain restrictions. For example, the authorisations of local user accounts might get lost when local accounts with the same name have another SSID on the target system and the data encrypted by BitLocker or EFS cannot be migrated in this manner.
If data is copied in existing directories on the target system, it must be considered in contrast that the inheritance of access rights on the target directory with lower-level files then relates to the existing rights in the target directory and no longer to the original rights in the source directory (see T 2.116 Data loss relating to copying or moving data under Windows Server 2003 and higher). The authorisations for source and target directory must be therefore compared in advance.
Aids
For the migration of systems to a Windows 2008 Server, Microsoft provides extensive aids. This includes migration manuals for the server roles, which describe in detail the individual steps for preparing the target and the source system, for performing the migration and for the final steps. If the system to be migrated has several roles, a separate migration manual should be consolidated in advance for the roles involved based on the migration manuals.
In the appendices to the migration manuals, work sheets helping you to collect and document the relevant configuration settings for the migration in the old system can be found. The information asked for here, however, should also be part of a good system documentation (see S 2.25 Documentation of the system configuration).
For the individual server roles, special Windows server migration tools installed on the source and on the target system and ensuring an automated transmission of the service configuration are used in some cases. Under Windows Server 2008 R2, the migration tools can be installed subsequently as feature; a separate installation is required on the source system. The migration tools also support the migration of servers to a target platform operated as Server Core (see S 4.416 Use of Windows Server Core) as well as the migration from physical to virtual machines. The migration tools require the previous installation of .NET-Frameworks 2.0 as well as of the Windows PowerShell and enough available storage space for the installation. The source and the target system must be installed in the same language.
Since the installation of migration tools may also require rebooting a server, it should already be considered during the migration planning phase.
Preparing for migration
In order to prepare the migration, different steps must be performed or tested:
An administration account on the source and on the target system is needed to perform the migration.
The target server must provide enough storage space for the acceptance of the data. Here, a potentially active quota management on the target system must also be taken into account.
The source system should be backed up completely prior to the migration in order to have a defined fallback point if problems occur which cannot be solved in the time window specified for the migration.
On the source and on the target system, all current patches should be installed to ensure that all known errors in the system software are eliminated.
The system time on the source and target system must be synchronised, for instance via a shared external time source.
Depending on the server role, the corresponding migration tools must be installed both on the source system and on the target system.
For communication, the Microsoft migration tools need the ports udp/7000 and tcp/7000. They must be permitted on the local firewalls of the two systems and in the network between the two systems.
Finally, all affected users and administrators of dependent systems and applications must be informed promptly about the migration process and the restrictions resulting from this.
Performing the migration
To ensure that the consistency of the target system is not threatened, it must be ensured that the target system cannot be accessed by unauthorised third parties during the migration process. Likewise, work on the source system resulting in a change in the configuration or the database may no longer be carried out after the migration has been started. Corresponding access can be prevented organisationally or even better technically, for example on the network level.
After the migration has been completed, all relevant functions of the server should be tested thoroughly to detect any possible migration errors and to prevent the productive operation from being affected.
To provide no unnecessary points of attack on the target system, the migration tools should be removed from the system after the migration has been completed and the UDP and TCP ports set up for this purpose in the local firewall and on additional security gateways in the network are closed again.
Review questions:
- Was the migration to Windows Server 2008 planned based on need?
- Are all tools required in the course of the migration to Windows Server 2008 known and tested?
- Is it ensured that the extensive authorisations of the migration team are reset after the migration to Windows Server 2008 has been completed?
- Has an IT security concept been developed for the migration phase of Windows Server 2008?
- Is it ensured that all exceptions required during the migration to Windows Server 2008 are cancelled again after the migration?
- Have all persons affected been prepared adequately for the migration to Windows Server 2008?