Server Data Migration by Server Type

Server migration, server consolidations and data migration require different scenarios based upon the type of server being migrated and the type of server being migrated to.

Member Server to Member Server
(Same domain or workgroup)

When migrating from a member server to a member server the local accounts, their properties, the local groups and their members must be copied to the target server.
Because SIDs are unique to each server an account and group remapping is required to be performed. In other words any ACLs with SourceComputer\SourceAccount must be reassociated to TagetComputer\TargetAccount.

Account rights must also be remapped to reflect the rights on the target computer

MSVR ServerMigrator performs these steps automatically including copying copy files, folders shares, file permissions, share permissions and account passwords to the target server.

Member Server to Member Server
(Different domain)

A trust relationship must be in place. If the source domain will be removed a domain migration must be performed.

When migrating from a member server to a member server the local accounts, their properties, the local groups and their members must be copied to the target server.
Because SIDs are unique to each server an account and group remapping is required to be performed. In other words any ACLs with SourceComputer\SourceAccount must be reassociated to TagetComputer\TargetAccount.

Account rights must also be remapped to reflect the rights on the target computer

Domain accounts and groups in ACLs are migrated explicitly with the data.

MSVR ServerMigrator performs these steps automatically including copying files, folders shares, file permissions shares, share permissions and account passwords to the target server.

Member Server to Domain Controller
(Same or different domain)

Proper trusts must be in place prior to starting a member server to domain controller data migration.
Before a data migration can be performed, the local accounts and local groups must be converted to domain accounts and domain local groups.
The source server must be reACLed with the new domain accounts and groups.

Domain accounts and groups in ACLs are migrated explicitly with the data.

MSVR ServerMigrator has an optional component to convert local accounts to domain accounts ReACL the source server and copy files, folders shares, file permissions and share permissions to the target domain controller.

Domain Controller to Domain Controller
(Same or different domain)

Proper trusts must be in place prior to starting a domain controller to domain controller data migration. If the source domain is to be removed a domain migration must be performed.

Domain accounts and groups in ACLs are migrated explicitly with the data.

MSVR ServerMigrator copies files, folders shares, file permissions and share permissions to the target domain controller.

Domain Controller to Member Server
(Same or different domain)

Proper trusts must be in place prior to starting a domain controller to member server data migration. If the source domain is to be removed a domain migration must be performed.

Domain accounts and groups in ACLs are migrated explicitly with the data.

MSVR ServerMigrator copies files, folders shares, file permissions and share permissions to the target member server.

Why Understanding SIDs is Important

An understanding of Windows Security Identifiers (SIDs) is important to successful server, server data and domain migrations.

The SID is a unique name (alphanumeric character string) that is used to identify an object, such as a user or a group of users in a network of NT/2000/XP/2003 systems.

Windows grants or denies access and privileges to resources based on ACLs, which use SIDs to uniquely identify users and their group memberships. When a user requests access to a resource, the user’s SID is checked by the ACL to determine if that user is allowed to perform that action or if that user is part of a group that is allowed to perform that action.


SIDs are NOT Portable

This information is useful for troubleshooting issues involving security reporting, server migrations and domain migrations.

All SIDs are unique within a given system and are issued by what is known as an "Authority" such as a domain or local server. While Windows 2000/2003 is most comfortable using SIDs in the form of a simple binary data structure, we humans like to see things in a simple string format so that we can more easily recognize them.

As a result, you and I never see SIDs in their native format but instead see things like S-1-5-12-7723811915-3361004348-033306820-1006.

The format of this SID breaks down as follows:

S - The string is a SID.
1 - The revision level.
5 - The identifier authority value.
12–7723811915-3361004348-033306820 Domain or local computer identifier
1006 – The RID (Generated for each object from 1000 and up)

Any group or user that is not created by default will have a RID of 1000 or greater. A RID is a Registered ID. This is the last portion of the SID. Once a RID has been issued it will never be used again even if the user and user account are deleted.
However there are always exceptions in Microsoft Windows. Certain RIDs (below 1000) are predefined:

500 - Administrator S-1-5-21----500
501 - Guest S-1-5-21----501
502 – KRBTGT S-1-5-21----502

512 - Domain Admins S-1-5-21----512
513 - Domain Users S-1-5-21----513
514 - Domain Guest S-1-5-21----514
515 - Domain Computers S-1-5-21----515
516 - Domain Controllers S-1-5-21----516
517 - Cert Publishers S-1-5-21----517
518 - Schema Admins S-1-5-21----518
519 - Enterprise Admins S-1-5-21----519
520 - Group Policy Creator Owners S-1-5-21----520
533 - RAS and IAS Servers S-1-5-21----533


During a server or domain migration new accounts and groups are created on the target. Therefore; even if the account names are the same, new SIDs are created and any rights that the original account has or had, the new account does not.

There are two methods of dealing with SID disassociation:

SidHistory - Append the old SID to the new account (Windows 2000 and up). This method is available in domain migration only. There are known issues using this method.

ReACL Process – by creating a mapping between old and new SIDs, The new SIDs are appended or replaced for each ACL for files, folders, shares, local groups membership, printers, mapped drives, profiles and rights.

SIDs That Are Portable - Well Known SIDs

Well-known SIDs are a group of SIDs that identify generic users or generic groups. Their values remain constant across all operating systems and for this reason are termed well-known SIDs

You can find the well-known SIDs in Active Directory in a container called WellKnown Security Principals. To see this container, launch Adsiedit.msc or Ldp from the Windows Server 2003 Support Tools and use it to view the top-level containers inside the Configuration naming context.

A universal well-known SID is a SID that is common to all machines. That is, the value SID is the same on my machine as it is on yours.

These SIDs include BuiltIn accounts and groups (BuiltIn\Administrators) as well as label accounts such as the Everone group

Well Known SIDs

• SID: S-1-0
Name: Null Authority
Description: An identifier authority.

• SID: S-1-0-0
Name: Nobody
Description: No security principal.

• SID: S-1-1
Name: World Authority
Description: An identifier authority.

• SID: S-1-1-0
Name: Everyone
Description: A group that includes all users, even anonymous users and guests. Membership is controlled by the operating system. Note By default, the Everyone group no longer includes anonymous users on a computer that is running Windows XP Service Pack 2 (SP2).

• SID: S-1-2
Name: Local Authority
Description: An identifier authority.

• SID: S-1-3
Name: Creator Authority
Description: An identifier authority.

• SID: S-1-3-0
Name: Creator Owner
Description: A placeholder in an inheritable access control entry (ACE). When the ACE is inherited, the system replaces this SID with the SID for the object's creator.

• SID: S-1-3-1
Name: Creator Group
Description: A placeholder in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the primary group of the object's creator. The primary group is used only by the POSIX subsystem.

• SID: S-1-3-2
Name: Creator Owner Server
Description: This SID is not used in Windows 2000.

• SID: S-1-3-3
Name: Creator Group Server
Description: This SID is not used in Windows 2000.

• SID: S-1-4
Name: Non-unique Authority
Description: An identifier authority.

• SID: S-1-5
Name: NT Authority
Description: An identifier authority.

• SID: S-1-5-1
Name: Dialup
Description: A group that includes all users who have logged on through a dial-up connection. Membership is controlled by the operating system.

• SID: S-1-5-2
Name: Network
Description: A group that includes all users that have logged on through a network connection. Membership is controlled by the operating system.

• SID: S-1-5-3
Name: Batch
Description: A group that includes all users that have logged on through a batch queue facility. Membership is controlled by the operating system.

• SID: S-1-5-4
Name: Interactive
Description: A group that includes all users that have logged on interactively. Membership is controlled by the operating system.

• SID: S-1-5-5-X-Y
Name: Logon Session
Description: A logon session. The X and Y values for these SIDs are different for each session.

• SID: S-1-5-6
Name: Service
Description: A group that includes all security principals that have logged on as a service. Membership is controlled by the operating system.

• SID: S-1-5-7
Name: Anonymous
Description: A group that includes all users that have logged on anonymously. Membership is controlled by the operating system.

• SID: S-1-5-8
Name: Proxy
Description: This SID is not used in Windows 2000.

• SID: S-1-5-9
Name: Enterprise Domain Controllers
Description: A group that includes all domain controllers in a forest that uses an Active Directory directory service. Membership is controlled by the operating system.

• SID: S-1-5-10
Name: Principal Self
Description: A placeholder in an inheritable ACE on an account object or group object in Active Directory. When the ACE is inherited, the system replaces this SID with the SID for the security principal who holds the account.

• SID: S-1-5-11
Name: Authenticated Users
Description: A group that includes all users whose identities were authenticated when they logged on. Membership is controlled by the operating system.

• SID: S-1-5-12
Name: Restricted Code
Description: This SID is reserved for future use.

• SID: S-1-5-13
Name: Terminal Server Users
Description: A group that includes all users that have logged on to a Terminal Services server. Membership is controlled by the operating system.

• SID: S-1-5-18
Name: Local System
Description: A service account that is used by the operating system.

• SID: S-1-5-19
Name: NT Authority
Description: Local Service

• SID: S-1-5-20
Name: NT Authority
Description: Network Service

• SID: S-1-5-32-544
Name: Administrators
Description: A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group.

• SID: S-1-5-32-545
Name: Users
Description: A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group. When a computer joins a domain, the Domain Users group is added to the Users group on the computer.

• SID: S-1-5-32-546
Name: Guests
Description: A built-in group. By default, the only member is the Guest account. The Guests group allows occasional or one-time users to log on with limited privileges to a computer's built-in Guest account.

• SID: S-1-5-32-547
Name: Power Users
Description: A built-in group. By default, the group has no members. Power users can create local users and groups; modify and delete accounts that they have created; and remove users from the Power Users, Users, and Guests groups. Power users also can install programs; create, manage, and delete local printers; and create and delete file shares.

• SID: S-1-5-32-548
Name: Account Operators
Description: A built-in group that exists only on domain controllers. By default, the group has no members. By default, Account Operators have permission to create, modify, and delete accounts for users, groups, and computers in all containers and organizational units of Active Directory except the Builtin container and the Domain Controllers OU. Account Operators do not have permission to modify the Administrators and Domain Admins groups, nor do they have permission to modify the accounts for members of those groups.

• SID: S-1-5-32-549
Name: Server Operators
Description: A built-in group that exists only on domain controllers. By default, the group has no members. Server Operators can log on to a server interactively; create and delete network shares; start and stop services; back up and restore files; format the hard disk of the computer; and shut down the computer.

• SID: S-1-5-32-550
Name: Print Operators
Description: A built-in group that exists only on domain controllers. By default, the only member is the Domain Users group. Print Operators can manage printers and document queues
.
• SID: S-1-5-32-551
Name: Backup Operators
Description: A built-in group. By default, the group has no members. Backup Operators can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators also can log on to the computer and shut it down.

• SID: S-1-5-32-552
Name: Replicators
Description: A built-in group that is used by the File Replication service on domain controllers. By default, the group has no members. Do not add users to this group.
The following groups will show as SIDs until a Windows Server 2003 domain controller is made the primary domain controller (PDC) operations master role holder. (The "operations master" is also known as flexible single master operations or FSMO.)

• SID: S-1-5-32-554
Name: BUILTIN\Pre-Windows 2000 Compatible Access
Description: An alias added by Windows 2000. A backward compatibility group which allows read access on all users and groups in the domain.

• SID: S-1-5-32-555
Name: BUILTIN\Remote Desktop Users
Description: An alias. Members in this group are granted the right to logon remotely.

• SID: S-1-5-32-556
Name: BUILTIN\Network Configuration Operators
Description: An alias. Members in this group can have some administrative privileges to manage configuration of networking features.

• SID: S-1-5-32-557
Name: BUILTIN\Incoming Forest Trust Builders
Description: An alias. Members of this group can create incoming, one-way trusts to this forest.

• SID: S-1-5-32-558
Name: BUILTIN\Performance Monitor Users
Description: An alias. Members of this group have remote access to monitor this computer.

• SID: S-1-5-32-559
Name: BUILTIN\Performance Log Users
Description: An alias. Members of this group have remote access to schedule logging of performance counters on this computer.

• SID: S-1-5-32-560
Name: BUILTIN\Windows Authorization Access Group
Description: An alias. Members of this group have access to the computed tokenGroupsGlobalAndUniversal attribute on User objects.

• SID: S-1-5-32-561
Name: BUILTIN\Terminal Server License Servers
Description: An alias. A group for Terminal Server License Servers.

• SID: S-1-6
Name: Site Server Authority An identifier authority.

• SID: S-1-7
Name: Internet Site Authority An identifier authority.

• SID: S-1-8
Name: Exchange Authority An identifier authority.

• SID: S-1-9
Name: Resource Manager Authority An identifier

Pre-Server Migration Checklist

To reduce server migration risks and known issues, I have compiled a checklist of items that need to be addressed prior to migrating servers or server data from one server to another.

Windows Server Migration Checklist

Verify that the account performing the migration has administrative rights to all servers involved in the migration.

Verify that domain trusts (if required) are up and correctly configured.

Verify that all servers are reachable from the computer the server migration is being conducted from. (Check WINS and/or DNS)

Verify if migration software agents are installed and running (if required)

Compile a list of folders, folder trees, files and shares that will be migrated.

Verify the target drive or drives the data will be moved to.

Will the tree structure and folder names be the same?

Is there enough free space on the target drive to accommodate the data?

Will the migration be done during business hours or off hours?

Will the data migration require a resynchronization to reflect changes that have occurred to the source data during the migration?

Will local accounts and groups be migrated to the target server? (Member Server to Member Server)

Will local accounts and local groups need to be converted to domain accounts? (Member Server to Domain Controller in the same domain)

Will source domain Local Groups need to be migrated to the target domain? (Domain Controller to Domain Controller in different domains)

Will migrated local user account’s passwords need to be migrated during the migration? (To reduce migration impact on end users)

Will the source server be removed from the domain once the migration is complete?

Will the target server be renamed with the source server name once the migration is completed?

Will the Target Server have multiple server names including the source servers’ names to reduce post migration access issues?

Are users home drives being moved in the migration?
If yes, are plans in place to repoint the user’s home drive to the target server?

Are users roaming profiles being moved in the migration?
If yes, are plans in place to repoint the user’s roaming profile to the target server?

Is there a phone number available from the third party software manufacture for support or standby if issues arise?

By working through the above checklist the server migrator will have a deeper understanding of issues that can arise during a Windows Server Migration.

Ensure Adminitratve Rights Before You Begin...

Before starting any Microsoft Windows server migration or data migration, the operator account must have "GOD" ” privileges and rights to all servers involved in the server migration.

Servers within the Same Windows Domain

The simplest way to gain Administrative access to servers within a domain is to either create a domain account to use as the operator for all migrations and add that account the Domain Admins group or add your account to the Domain Admins group of the domain. Next add or verify that the Domain Admins group is a member of the local Administrators group of each server that will participate in the migration including all source and target servers.

If access to the Domain Admins group is restricted because of network policies, then add the domain account that will be used for the migration directly to the local Administrators group of each server involved in the migration.

Servers in Multiple Windows Domains

Migrating servers or migrating data from one server to another server in a different domain required Administrative access to both domains and all servers in the migration project.
Create or select a domain account from the target domain. The target domain is where server that the data is being moved to is located. Add the server migration account to the Domain Admins group of the target domain. Then add the Target domains Domain Admins Group to the Administrators group of the Source domain.
Verify that the Target Domain Admins group is a member of the local servers Administrators group of all servers involved in the migration in both the Source and Target domains.

Windows WorkGroups

Server migration is possible in Windows Workgroups if all the servers are within one Workgroup. The Account used for the migration must be the Administrator account and the password for the Administrator account on all servers must be the same.
By using the Administrator accounts with the same password is the only way to gain access to multiple servers in a Microsoft Workgroup.