Consolidating file servers

[ddrueding]

The last guy here made a real mess. There are probably thirty major network shares spread out over a dozen machines in the organization. I don't even know where some of them are physically, nor do I have a list of who has or needs access to them. I just put in a beautiful new dedicated file server with plenty of capacity, bandwidth, and speed to handle all the traffic.

The problem is, I can't really just move the data recreate the share and remap the network drives. I don't have a list of who needs what, or what legacy systems still require the old names. The only point where I lucked out was that the last guy never set any permissions besides "everyone/full control", so they aren't there to be lost when I move the data.

Here is my evil scheme: Copy the data to the new server, create the share with the same name as before, and then (after taking the old server offline) alter the old server's DNS record to point to the new server. Could it be that easy? Does anyone see a problem with this approach? I'm too tired at the moment to think clearly.

 

[Mercutio]

You might have some clients doing name lookups via SMB broadcasts or defined in a static hosts or lmhosts file.

Plus, it could take a while for machines to lose old entries in their DNS cache, so who knows how long you would have problems with people updating data in different places.

But hey, if you don't know where these machines are, you could just force the change and then see who complains.

 

[ddrueding]

What about adding the other IP to the new server? Wouldn't do SMB broadcasts, but everyone else might be OK...

 

[Stereodude]

How many people access these servers, and do you have access to their machines? Do they run any sort of login script?

You could just go wild and effectively start from scratch and be prepared for a lot of calls wondering why their old shares no long work. That would be the cleanest solution from a networking end, but probably also the most troublesome in terms of upset people.

 

[ddrueding]

The total number of people is under 300 in about 18 offices in an area 100 miles long and 50 wide. I would love to start from scratch, but I don't have the resources to handle the aftermath. While I may still end up going that way, I want to consolidate sooner, so I can start getting decent backups.

Edit: Sorry I didn't finish answering your questions. I do have access to the machines, but I couldn't even make it to all the sites in a weekend. There is no logon script, but there is no consistency in what gets mapped as what, so that wouldn't help me anyway.

 

[Stereodude]

The total number of people is under 300 in about 18 offices in an area 100 miles long and 50 wide.

I didn't realize it was so many. My best suggestion would be to add all the necessary shares to duplicate what's out there now, and then systematically go around changing the shares people are mapping an office at a time, eventually allowing you to have a much cleaner setup (removing the excess shares) but avoiding having 300 people calling you on Monday.

 

[Mercutio]

What about adding the other IP to the new server? Wouldn't do SMB broadcasts, but everyone else might be OK...

The existing name and address will still be out there. You'll get conflicts, and some of your clients will probably end up talking to the wrong machine.

Another issue: You're centralizing file shares. Are you completely sure that's a good idea? How much WAN traffic is that going to generate? Are you sure you don't have better things to do with your wide area links than make people pull down and send back 50MB .pdf files or whatnot?

You should at least know what facility each of these servers is located at by their IP or subnet.

I'd undertake an effort to travel to each location and find the sharing servers over some reasonable period of time and find out more about them before I went around changing things. The last thing I would want is to find out that Milton with his office in the basement continues to use a retired server and share months after everyone else has been migrated.

 

[ddrueding]

Most of the servers are within the main campus; all connected by gigabit fiber. If there are any servers at the remote offices, I would want to move them here anyway; the remote sites are too dirty/insecure to actually be holding data. And the point to point T1s can handle the load without issue. I would at least like to start with the 5 fileservers that are sitting in the same rack; many are on their last legs and the performance is horrible. I don't know what is on them, whether it is still in use, or who is connected to them. Before they fail I want to get the data and the share onto a reliable machine that is being backed up regularly.


This brings up another set of decisions. In the past, when I have had a clean slate to work with, I would keep the network shares to one company-wide, one per department, and one per person. Each with permissions to match. What do you guys think of this? It looks like I'll be having to relocate and analyze everything anyway to get this resolved.

 

[ddrueding]

The existing name and address will still be out there. You'll get conflicts, and some of your clients will probably end up talking to the wrong machine.

The plan would be to take the old machines offline permanantly, redirecting their name (via DNS), their IP (by having multiple IPs on the new server) and the share names (hopefully there are no duplicates) onto a single machine. By pulling the old ones off the network, I would hope to prevent people talking to the old machines.

 

[Chewy509]

Just my 2cents...

As Merc mentions, you need to find that lone server that Milton is still using, and highly recommend (if financially viable and time permissible) to visit each site. At least the visit should be a meet-greet session with remote office staff so they can put a face to a name. Also a good opportunity to speak to the remote office staff about what help them improve their productivity, either through new applications or better hardware on-site.

You're replacing ~12 odd servers with 1? I wouldn't be placing all my eggs in 1 basket, as they say. What about spread over 2-3 servers and share via DFS (assuming Windows clients)?

Do a slow migration, with 1 share each day. It'll lessen the support load when someone's connection to the file resource fubar's.

If you're thinking about modifying the share structure, what I've seen as common is 1 share for shared data, and a directory for each department within that share. (Permissions set appropriately). And another share for user private data with a folder for each user, with permissions set appropriately. Redirect "My Docs" via GPO to the latter share/directory, and make the users desktop read-only.

And by all means, let your users know about the changes and WHY you are doing them. Try to get them to help you make the migration easier. (Anyway, it makes them feel important in the process, and will earn you brownie points).

 

[udaman]

The total number of people is under 300 in about 18 offices in an area 100 miles long and 50 wide. I would love to start from scratch, but I don't have the resources to handle the aftermath.

Most of the servers are within the main campus; all connected by gigabit fiber. If there are any servers at the remote offices, I would want to move them here anyway; the remote sites are too dirty/insecure to actually be holding data. And the point to point T1s can handle the load without issue. or who is connected to them. Before they fail I want to get the data and the share onto a reliable machine that is being backed up regularly.
.

Why are you limited to 'even' a weekend? If you don't know, you need to find out. IE, you should visit *all* of the sites, if you intend to make a system wide upgrade. Because like Chewy said, you name will be mud if you upset the system, and people can't get work done...those with no patience for any problems you might run into (Murphy's Law applies to all kinds of connectivity problems/incompatibility btw these connections/file structuring/permissions etc).

Best to visit *all* the sites, take a camera to document, as well as other note taking, via written/voice recording. Then when something goes wrong, at least you have your records of what equipment/software is in use @each. All stuff you need to keep track of what is in what office/location, cause you can't remember it all, but you need to have a record of it *all*. Organization skillz.

 

[sechs]

Do a slow migration, with 1 share each day. It'll lessen the support load when someone's connection to the file resource fubar's.

I say, go nuclear, but one share a day may still be too fast.

Figure out what's on each share, who is using, and who is supposed to be using it. Then figure out a better way to set it up, let everyone know that the old share is going down after hours on Friday and, if successful, those who need access to that data should be able to get to it at the new location on Monday.

This will take months, but, I've found that major changes are much easier for folks to swallow when they come little bits at a time -- even if it's a lot more work.

 

[ddrueding]

1 Fileserver is just going to be easier to maintain and backup. Performance really isn't an issue, as what they have now sucks so badly. Reliability is also not so much an issue, the new server has multiple redundant power supplies, drives, and NICs, and the backup server maintains the structure and permissions, so it is a simple task to rename it and turn on the shares.

The problem with getting my users to help is that they are completely useless. I have to provide them with working mapped drives, there is only 1 in all 300+ that I can trust to ping something correctly. If I change a share, I need to be the one that remaps the drive letter, and I need to do it without them knowing something is afoot; or they start doing things differently (in stupid and unpredictable ways). I can't even concieve yet of what it would take to change the structure of the shares, politically or from a user orientation standpoint. I know it really needs to be done, but I have no idea how.

 

[Fushigi]

You need a few power users. One person in each major group/department with above-average skills. That person would be the one to turn to when doing migrations. They can also serve as resident app experts and even level-1 support.

That said, for your migration you definitely want to do a pilot group where you take just a small group & migrate their files/shares to the new server. Note their experiences and use that when doing the next group.

You can also email out links to the new shares or a script to execute to replace the old mapping with the new. Although I'd think better would be a LAN login script that did all of the mapping for them. That way managing shares in the future is vastly simplified. At work, for instance, we've done entire server migrations by moving the data to the new servers (with different names) and then updating the LAN login script to point there. Without telling them, people don't even know they went from SERVER_A to SERVER_B. There's also a shortcut we send to people to save to their desktop; it's a link to the LAN login (\\domain.company.com\NETLOGON\Logongui.vbs) and can be run to establish shares after initiating a VPN connection.

 

[ddrueding]

All great ideas Fushigi. The pilot group would be difficult, since nearly all the groups have substantial overlap. I do need to look more into login scripts, what the best kind are, he best way to deploy them, and the tips and tricks that make them work well. I know there is substantial documentation out there, I just need to take the time.

Regardless, I need to standardise the shares first. Having a unique start-up script per user defeats the purpose.