How to Migrate Local Server Users and Groups Only Between Member Servers This document is to help migrate server accounts, local user accounts with properties and passwords and local server groups from Windows server to Windows server with similar or different OS versions. Both ADUM ServerMigrator and ManageRED Resemble solutions allow for the migration of local accounts form server to server automatically. Software Installation Install either ADUM ServerMigrator or ManageRED Resemble on the target server. The target server is the server where the accounts are to be migrated to. Software Configuration From the Menu Select Configuration and select Add or Remove Domains or Workgroups. If the servers are in domains, type the NetBIOS domain name in upper case and click on Verify. After it is successfully verified click the Add button then Close the window. If the servers are in workgroups, type the NetBIOS workgroup name in upper case and click on Add. A Special note for workgroups: Both source and target servers must be in the same work group. The account being used for the migration must be Administrator, The Service account on both the source and target servers must be Administrator and ALL Administrator accounts must have the same password. From the Menu select Configuration and Select either Add Remove Servers or Add Hidden Server, if UNC naming format does not list the server. With either option add both the source and target servers to the server list. Pre-Migration Check In the main UI select the source server from the left window labeled Source Servers. From the Menu Select Server Migration and Choose PreMigration Check… At this point all entries should have a green checkmark icon representing that each prerequisite is in place for a successful migration. Click Close to continue or fix any issues and run the pre-migration Check again until all prerequisites are met. Pre-Migration Requirements Requirements Prior to Resemble Installation Multi Domain Migration - Windows Trust Requirements Establish a two way trust relationship between domains if the migration involves multiple domains Verify the trust relationship – To verify, check that you are able to list accounts from each domain in each domain Add the Domain Admins group to each domain’s Administrators group The account used to perform the migration must be a member of the target servers domain’s Domain Admins group Same Domain Server Migration Requirements Verify or add the Domain Admins group to each server’s Administrators group The account used to perform the migration must be a member of the domain’s Domain Admins group Windows Workgroup Server Migration Requirements The account used to perform the migration must be the Administrator account. If the Administrator account has been renamed the account must be changed to back to Administrator on each server The Administrator’s password on each server must be the same On the target server check and verify that the Local Password Policy is equal to or less restrictive then the source server’s password policy. NetBIOS Naming Resolution Requirements NetBios browsing must be enabled to resolve computer names In the TCP/IP Advanced Network Card Properties of the source and target WINS tab enable NetBIOS over IP for both the source and target servers Verify that both source and target servers have Enable lmhost Lookup enabled If naming resolution is an issue and server names are not resolved create an lmhosts file. Group Policy Requirements Verify that Windows Firewall is disabled on both the source and target server. Verify IP Filtering is disabled for both the source and target servers in the Advanced TCP\IP Options Setting to Permit All On Windows 2008 servers, disable User Account Control (UAC) Server Requirements Verify that the Windows directory is shared as ADMIN$ on both the source and target servers Verify that the drives are shared as C$, D$ E$ etc. on both the source and target servers Verify that the Remote Registry services is running on both the source and target servers Verify that the RPC services is running on both the source and target servers Verify that EFS is disabled on both the source and target servers Verify that the account used as the service account has Logon as a Service and Logon Locally rights enabled on both the source and target servers. Know Installation Issues: The ADUM Scheduling service is not running This is a common issue at the first installation. To remedy, connect to the server(s) that displays the error, start the services MMC and navigate to the ManageRED Schedule service or FSTScheduler. Click on the logon option. Re-enter the service account name and password and click Apply. If the service is running, stop and restart the service. Unable to Verify Source or Target Server Names This issue will arise when the target server is unable to resolve NetBIOS Names. Create an lmhosts file. Add the IP Address and name of the source domain server, add the IP address and the name of the target server, add the IP Address of the domain controller and the domain name if required in a domain scenario. Save the new lmhosts file. Register the lmhosts file to cache and verify the cache table that all entries are in cache. Administrator Account Password Containing Special Characters A known LDAP issue exists if the first character of the Administrator’s password begins with a special character. This issue will prevent connecting computers from the source to the target because LDAP translation will drop the first character of the password, the password will become incorrect and the operation will fail. To remedy this issue change the password of the source or target servers Administrator’s password so that the password begins with an alpha-numeric character. 64 Bit Windows Servers Resemble and ServerMigrator supports Windows 64-bit 2003, 2008 and 2008 R2 Servers. In order to successfully copy 64-bit passwords check the LSA Settings in the Registry of the server that they match the following details for the Security Packages entry for HKLM System\CurrentControlSet\Lsa\ Security Pakages – Kerberose msv1_0 Schannel wdigest tspkg ONLY! Remove any other packages not in this list. If you make changes to the LSA registry settings, you must reboot the server for the changes to take effect. Known Issues with Virus Software Disable Virus software (Norton, Symantec, Sunbelt VIPRE, AVG, McAfee etc.) during installation and during migration. Virus software will falsely mark and remove the password copy feature as a Trojan. The User and Local Group Migration Process Before you begin, create a fake empty folder on the source server on any drive. This fake folder will be migrated to the target server with no files in order to start a migration project. From the left window labeled Source Servers select the source server On the Menu select Server Migration From the dropdown select Member Server to Member Server Migration. Enter a meaningful Project Name. Select and add the fake folder that was previously created on the source server Select the destination drive to copy the fake folder to Click OK to begin. From the popup Files and Folder Migration options select the Do Not Copy DATA (Files and Folders) During the migration Process… option. Click Continue In the Ready to Start Project summary window click Continue At this point the project will start and the summary of the actions will be displayed in the right Window of the main UI. The first step will re-verify the migration prerequisites. Once the verification phase is complete, the collection process of objects and data begins locally on the source server. User information, group information, file, folder and share information and security settings are collected and stored. In this scenario copying of data is not executed. When the collection phase is completed the collected data is imported to the target server and the accounts and groups are recreated based on the collected information. Note - all created objects have new SIDs assigned based on the SID of the target server. When the project is completed, an option to save the results is displayed. Results of the Local Account Migration User Accounts User account samAccountNames are recreated on the target server. Passwords for each account are copied. User name and description properties are copied to the target Terminal server settings and properties are copied to the target server for each account that is populated on the source server All user rights are migrated to the target server Local groups Local group samAccountNames are recreated on the target server. Group description properties are copied to the target Group membership is populated with migrated accounts of the target server in the same samAccountName structure as the source server. How to Migrate local Server Accounts Between Member Servers – Copyright ADUM - ManageRED Software 2012 all rights reserved. Revision 1.0 Aug. 7, 2012 ADUM – ServerMigrator, ManageRED Resemble ManageRED: http://www.managered.com Support Blog: http://winzerofaqs.blogspot.com Migration blog: http://domainreconfigure.blogspot.com Twitter Updates: http://twitter.com/managered/ Akos Sandor WinzeroTech, ManageRED, TECHNVR, ADUM, Resemble, ServerMigrator Server migration, server account migration, user migration, Windows member server migration How to Migrate Local Server Accounts Between Member Servers Only How to migrate local server user accounts and local groups between member servers 8/7/2012
© Copyright 2024