Windows Server Migration Checklist - ServerMigrator

Before beginning a server migration project, a number of mandatory prerequisites are needed to be met in order to complete a server migration successfully.



These requirements are standards to meet both the requirements for Microsoft Windows server security and the Winzero ServerMigrator software.

Download the Server Migration Checklist

New Release: Winzero TakeControl

Winzero new product release: TakeControl allows administrators to gain administrative access to files, folders and shares without destroying the original permissions by appending the Administrators group SID to ACLs.

The Challenge
To gain access to files and folders, Administrators can take ownership and grant full access control permissions and rights to themselves if they want to modify, rename or delete these files or folders. During this process the original permissions are removed and must be reconstructed to maintain security.

The Solution
Grant Administrators full control to files, folders or shares without taking ownership or destroying the original permission using Winzero TakeControl.

Avoid Take Ownership

Using standard Windows functions, if you must access a file or a folder that you do not have rights to, you must take ownership of that file or folder. When you do this, you replace the security permissions that were originally created for the file or folder.

Winzero TakeControl uses an append process to add the Administrators group with full control to each folder ACL and file ACL. without changing the original NTFS permission.

Download a fully functional trial version or learn more how TakeControl can help with profile migration and server migration projects.

Access Denied Using Multiple Server Names (OptionalNames)

Bulletin: 022109

Software Effected:
ServerMigrator - multiple server name feature

Issue:
Using the multiple name feature (OptionalNames) in ServerMigrator to assign both the old and new server name to the target server, the new server name and the old server name are both reachable by ping, DNS is working correctly and the old server has been shut down however access is denied.
When clients try to connect to a share using the old server name. Access is denied. Logon Failure: target account name is incorrect.
The following error appears in the event viewer when accessing the old server UNC name:

The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/OldServerName/domainName. This indicates that the password used to encrypt the Kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm and the client realm. Please contact your system administrator.

Solution:
For Windows 2003 or newer servers, for the OptionalNames value to work correctly edit or add the following Registry entry.

HKLM\System\CurrenControlSet\Services\LanmanServer\Parameters
DisableStrictNameChecking
REG_DWORD=1
for DNS aliasing to work.

The final solution to this issue was finally resolved thanks to our client, Ken Jackson at Malco Products Inc., (www.malcopro.com) in Barberton, Ohio.
After using ServerMigrator to add additional names to a server, change the DNS setting of the old server to point to the new server IP address and verify that the registry settings are correct, Manually remove the old server name from the domain using the Active Directory User and Computers MMC. Once deleted, add the old server name to Active Directory again and reboot the server with the two names.

Once again our thanks go to Ken Jackson for his efforts in resolving this issue.

Password Copy Issue

Bulletin: 111108

Software Effected:
ServerMigrator, PasswordCopy and WADMigrator

Issue:
Just recently Microsoft has released an update that is preventing passwordcopy from accessing the system32 directory that a number of our clients started experiencing in the last week.

Solution:
We have identified this issue and have resolved it. There will be a new ServerMigrator and PasswordCopy available starting November 12th that over rides the password copy problem some of our clients were experiencing.

New Update Releases:
ServerMigrator2007 version 5.10
PasswordCopy32 version 3.00
WADMigrator version 5.00

* PasswordCopy Server Edition and Domain Edition will be repalced with PasswordCopy32 followed by PasswordCopy64.

Windows Server 2008, Upgrade or Migrate?

Bulletin: 022408

Software Effected:
ServerMigrator, RemoveUnknown, Accessreporter, RenameITSE

Issue:
We are planning on deploying Windows Server 2008 shortly, would you recommend upgrading existing servers to Server 2008 or migrating clean to Server 2008?
Are there any steps we should take before rolling out Windows Server 2008?

Solution:
Before you begin, verify hardware and software compatibility before deciding which path to follow.
Regardless of which path you select for deploying Windows Server 2008, we strongly recommend analyzing and cleaning up the old server before moving foward. In either case, "garbage in, garbage out", your end result will only be sucessful as what you bring into server 2008.

Windows Server 2008 in place upgrade
Winzero recommends the following steps above and beyond the Microsoft upgrade path.

Report and cleanup obsolete users and local groups. Remove disabled accounts and accounts that do not or have not accessed the server for a period of time. Remove local groups with out members or local groups that do not have access to folders or shares.

Report, verify and cleanup File, folder and Share ACLs. Tighten security by removing the everyone group in ACLs.

Report and remove unknown accounts and SIDs in localgroups and files, folders and share ACLs.

Windows Server 2008 Migration
Winzero recommends the following steps above and beyond the Microsoft migration path.

Report and cleanup obsolete users and local groups. Remove disabled accounts and accounts that do not or have not accessed the server for a period of time. Remove local groups with out members or local groups that do not have access to folders or shares.

Report, verify and cleanup File, folder and Share ACLs. Tighten security by removing the everyone group in ACLs.

Report and remove unknown accounts and SIDs in localgroups and files, folders and share ACLs.

if your migration involves server consolidations, report duplicate user names and duplicate localgroups names from the servers that will be combined. Verify if accounts and groups are to be merged or renamed before migrating.

Taking these additional steps before upgrading or migrating to Windows Server 2008 will improve security and provide the fastest time-to-benefit.

Windows Tips...

Watch the latest videos on YouTube.com

Multiple Server Names

Winzero ServerMigrator has an option to add multiple server names to one server. This feature is handy when trying to remap user connections by allowing the new server to have two names: the old server name and the new server name.

However in our customer's enviroment a server would not respond to a cname that had just been created. After using the multi name utility and adding the new name to DNS and then connecting to “\\SecondServerName\c$” the server responded with an error “A duplicate name exists on the network.” Windows Server 2000 and 2003 listens for it’s “netbios” name only and ignore requests that come through with any other name.

A Simple Registry Fix.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\LanmanServer\Parameters

Check for or add the following registry value:

Value name: DisableStrictNameChecking
Data type: REG_DWORD
Radix: Decimal
Value: 1

Rebooot the server.

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.