File Server migrations from on-premise to the Cloud are not easy, especially if you are changing your LDAP or Active Directory domain. File shares and servers are integrated with LDAP or AD user groups for authentication. Permission and role access is given through Access Control Lists on Windows NTFS or Linux. These permissions and policies are typically scripted and specific to user groups for access to file shares and printer spools. Changing your AD or LDAP authentication will mean a remapping back to the targeted File Server location and reference. Even if you keep the Authentication protocols the same, there are many considerations in moving File Servers into the Cloud.
Pre-requisites
- Understand FS landscape and details including scripts, policies, user groups, references
- Understand how the current drive setup; namespaces; Win DFS namespace and how replication is configured on each server. For eg is there a folder target with a copy of the data at each site?
- Ensure that DFS can be mapped into a NAS or Cloud NAS platform. There are OS dependencies and SMB issues which need to be clarified by the SME.
- Clean up the existing file servers of misc junk, only move what is needed.
- Create the target cloud FS platform (can be NAS or similar).
- Choose right migration tool and approach – an idea is given below.
Constraints/Risks:
- Discovery of existing //FS domains is mandatory and takes time – you need to understand the below
- FileServer naming conventions and number of drives and uses
- Are you moving: GPOs, SID, policies or permissions ? If not see below
- If User Groups are not being moved over, they will need to be rebuilt eg. Accounting
- What tool will you use to do the remapping, building of user groups, policies and permissions?
- AD groups are the basis for authenticating the letter Drives eg Accounting, if you are moving or changing AD this will impact //FS access
- Name spaces; FS reference IDs will change once FS location changes
- You will likely need to use scripting to re-map the existing permissions and logic structures, on-premise in the new cloud environment – do you have someone who can do it?
Drives: Eg
| An assumption is that a firm will have drive naming conventions: Example
G: – mapped to \\server\homefolders$\%username%
|
A key fact is that this subfolder access is controlled by AD groups.
If a folder is not a G, I, or Z folder than it falls into ‘Other’. Assumption: The target environment will likely imitate the drives and user groups which now exist. We can remap using the existing on-premise scripting logic. |
General Strategic Approaches
If you are moving from On-Premise to the Cloud directly, without changing your AD/LDAP domain details, then the process becomes much easier. If, on the other hand, you are migrating your assets to the Cloud and changing your domain details, then the migration approach is decidedly complicated. Some general options are given below.
Before you being the //FS migration decide on the approach; Assume that policies, permissions etc not being migrated and that the Cloud NAS is a greenfield build.
- Move all files from on-premise at the same time, at the beginning of the project
- same process as 2) below except all files for all users are done at once
- this assumes that proper analysis, cleansing has taken place
- would require a NOC to handle error issues for the users
- hard to script for all the end users and establish proper policies, folder structures
- harder to troubleshoot issues
- Not Recommended.
- Match AD migration approach, which is user/group based; sync the on-premise FSs with a Cloud NAS, decommission on-premise over time
- replicate user groups and permissions to the Cloud NAS
- proper analysis and cleansing has been done
- move users on a rolling basis, determined by (?) applications (ones being migrated, ones being left on premise)
- for migrated apps where apps are moved to the Cloud, user groups //FS access should naturally follow
- remap using scripts, user groups, permissions, folder setup and access per app migration rollout
- keep using the on-premise
- replicate data, and over time, do a cutover
- keep FS on-premises until the cutover, just in case of an issue, decommission after Cloud NAS proven
- Recommended
- Move all files from on-premise at the same time, at the end of the project
- Same as 2
- Benefit is that at least your entire program is completed
- Issues would be trust back to on premise DFS for new users, created against the new AD domain or in the Cloud Directory services accessing AD on-premise (these issues can be resolved)
- Could replicate DFS into Cloud NAS or other platform over time and test then do a controlled cutover when ready
- Possibly a good option.
Migration Approach
There is a detailed ‘standard’ approach to migrating DFS to a new Cloud platform. A summary below is given of the steps that would impact a migration from DFS to a Cloud NAS. AD, DNS setups are involved.
SoftNAS is a Cloud NAS on AWS (or Azure) to which, you can migrate NFS/DFS/CIFS and files. It comes in 1 and 20 TB AMIs.
Detailed post I created, on how to migrate to SoftNas is here
These are general migration steps and a checklist, not CloudNAS based. They simply serve as a checklist of important considerations and highlight the inter-dependencies which exist in a //FS environment, with AD-Permissions-Access Control Entry-SID etc. etc.
Step 1: Build the new server
New server-build on Windows 2016 R2 or NEWDC.
25GB C partition. 100-500 users can get by on a RAID 5 or 10 controller.
Setup Cloud NAS, go through installation sets.
Step 2: Promote the new Server to be the DC
Step 3: Move FSMO roles
Move the AD Flexible Single Master Operation (FSMO) roles:
- Schema master
- Domain naming master
- RID master
- PDC emulator
- Infrastructure master
Step 4: Move the Schema Master
Important and sometimes missed.
Step 5: Migrate DNS
Since DNS should already be installed on the new DC it should now have the full DNS structure downloaded. Verify this by opening the DNS MMC and seeing the data.
Point the static IP address devices to use the new server as the DNS server.
Step 6: Migrate WINS
Manually update static IP address devices to use the new server as the WINS server. Hub and spoke are used for larger domains.
Step 7: Migrate DHCP
Standard Microsoft documented practice can be followed.
Step 8: Migrate Printers (not applicable in this probably)
Step 9: Move users to new printer shares
- Use a script to migrate the printers
- Use in the script, the old server name (OLDDC) and the new server name (NEWDC).
- Launch the script from the login script when users log in.
- Usually the printers are not renamed.
Script needs to work on both 32 bit and 64 bit apps and drivers.
Next migrate the Files.
Step 10: Migrate File Shares – Phase 1
Several hours per server. Budget 4.
- Download and install a File Migration Utility onto NEWDC.
- Create a new migration project.
Step 11: Migrate File Shares – Phase 2
- After Phase 1 is done schedule downtime for the file server to do Phase 2. Usually on the weekends.
- When ready for Phase 2, click on “Continue” and confirm to turn off the shares. This will turn off all access to the old server and copy all files that have changed since the phase 1 file copy.
Update the login script to reflect the shared folder change. A simple script could look like:
NET USE S: /D
NET USE S: \\NEWDC\SHARED
Step 12: Change User Folders
- Can manually go through Active Directory Users and Computers and update the profile tab on all users to point to the new home directory. Or:
- Run the ChgHomeDir script from the Migration Scripts
Step 13: Retire WINS
Step 14: Cleanup on OLDDC
Step 15: Final Steps
- At this point migration is done
b. Install Backup and Anti-Virus agents
==END