Hey Andrew, Thanks for that. I've set up DFS successfully in the past. Funny enough, this time I@ve elected to use the SAN replication but DFS for the namespace. The problem is that the file structures are also changing. So on the old server the path is something like this: \\Fileserver.FQDN\SharedFolders\Admin\SectionShareName The new server is something like this: \\FileServer.FQDN\Data\Dept\CompanyName\Admin\SectionShare. I have no control over the new path. IF I did, I would have a much easier job on my hands. I also cant migrate everyone over at once. This is because there's a mixture of drive maps and network short cuts. There are also security systems and custom applications pointing to both drive letters and UNC paths. In fact, there are one or two pointing to IP addresses! I'm only a month here so I don't want to seem negative to the management but this situation is impossible. There's no way I can do this without some down time. You know what makes things worse? The hardware is ten years old and badly needs to be decommissioned. Twice in the past five weeks the primary server has simply fallen over without reason that I can detect in the logs. In fact, up until five weeks ago this wasn't even the primary server. But the primary server died the day I got here. Simply hung and never got past POST ever again. I was very lucky there was a backup. Keep the suggestions coming. I'm working on a script that I'll run at log in for each section that I'm targeting. For example estates. I'll run it on their PC's on the morning of the migration. It will do the following. 1. Give me the hostname, Username and primary IP address so I can identify this machine and hopefully the area of the building that they are in. Write out the list of mapped network drives on the system along with the UNC path Save all that in a CSV file for easy sorting etc using Excel. Delete the drive maps Restart the machine. In parallel to this, I'm going to target drive maps at their groups so that during the next log in they will get a standard set of maps for their home drive, section share and any specific application drives that they might need based on the groups that their account is a member of. I have more work to do on defining groups based on application requirements but that's a job forMonday morning. -----Original Message----- From: Blind-sysadmins [mailto:blind-sysadmins-bounces@lists.hodgsonfamily.org] On Behalf Of Andrew Hodgson Sent: Friday 27 May 2016 15:03 To: Blind sysadmins list <blind-sysadmins@lists.hodgsonfamily.org> Subject: Re: [Blind-sysadmins] Migrating to a new file server. Hi, You're in the worst situation for this with the current file server, unfortunately most file servers or legacy file servers have similar configurations. I did this twice in my life, once by downing the file server during a weekend, copying the data across then renaming the new server to the old name. Permissions were levelled and I didn't put new permissions any deeper than the second level of folders. I also created individual groups for each time I restricted access. The second time I did this, I used DFS. DFS means that you can effectively extend the namespace of the file server across multiple servers, and it has a lot of other benefits too. I am a big fan. I also was largely successful in removing drive letter mappings, opting instead for shortcuts on the desktop etc. Andrew. ________________________________________ From: Blind-sysadmins [blind-sysadmins-bounces@lists.hodgsonfamily.org] on behalf of Darragh Ó Héiligh [d@digitaldarragh.com] Sent: 27 May 2016 11:50 To: Blind sysadmins list Subject: [Blind-sysadmins] Migrating to a new file server. Hello, I'm looking for a fresh perspective on this. I'm migrating a few hundred users over to a new file server. The paths will be different. It's not just the server name that's changing. I have run into several problems. 1. Although I'm a domain admin, I don't have access to most of the folders. In the worst case scenario I need to take ownership to gain access. 2. Inheritance is disabled on some of the sub folders. 3. Permissions are sometimes configured on the fifth or even tenth sub folder. 4. There are drive paths distributed using group policy but 99% of the paths are mapped directly on the PC. 5. Five minutes of down time causes untold problems. 6. The tool that is used to replicate the files isn't replicating the permissions in all cases. It is also having the same problem that I'm encountering in terms of access to some files and folders. 7. Permissions aren't given to groups. Each person is added to the folder directly. 8. There are often eight different drive maps. Some of these are even pointing to duplicate locations. Here's what I've tried. 1. Section shares will be mapped to S. However, the policy is set to update. IT isn't changing locally mapped drives. This is ok. It allows users to come to support if they can't access their files. The benefit of this is support are noting down what S was previously mapped to. 2. I'm using powershell to level the permissions on all sub directories. 3. I'm talking to section heads to determine the permissions that each person needs. 4. I'm adding these people to groups based on the section and directory name and applying access to the group. 5. I'm marking the old files as hidden. Mainly so that if someone continues using the old path they will think the drive is empty. That will result in a call to support where they can tell the user to use the new drive and then also delete the old map. There are far too many manual steps in this. There's also too many remaining drive maps that aren't needed. I'm thinking of doing something like the following: Write a script that will be run at log in. 1. Remove all drive maps 2. Check the groups that the user is a member of. 3. Map drives based on those groups. That way I don't need to touch the old file server. The problem is that if I move Drive Q that is used by ApplicationX to the letter Y, all the users who used the old letter will probably have problems opening files. I'm a bit stressed. I don't know how I can do this without down time or causing problems for some users. Thanks Darragh _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins _______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org https://lists.hodgsonfamily.org/listinfo/blind-sysadmins