View RSS Feed

synaesthesia

3 weeks with a new system. Oh, and DFS.

Rate this Entry
by , 25th September 2012 at 05:40 PM (8619 Views)
Well, what a busy time. First week was quiet. Second week when people noticed things were not where the thought/used to be, thing's got rather busier!

The little niggles aren't anything that would interest anyone. We've worked through a fair amount of software deployments, and I'm really pleased with SCCM - deployments aren't quite as easy perhaps as RM systems but they're so much better. And so far *all* of the packages created for RM systems just work when imported as applications into SCCM! Bonus

The only real large niggle that's been a thorn in the side is DFS. No "on sale" sofa's though, file replication. In testing, this was a brilliant idea and worked really well. Keeping the two sites synced whilst people access a namespace for their documents seemed a great solution and added a wonderful failover/resiliency level, to the point where I could turn off 2 major servers and noone would ever notice.
But as the network got more and more heavy use, it started to stop. Files got backed up. I found that I had left the staging folders at too small a size which upset things when someone transferred 14GB to their Documents in one go. This broke replication for all users.
So we decided to help this by setting up separate replication groups for each group of users - associate staff, admins, students, teaching staff, governors etc. We did this in a "testing" situation so the replication was live yet the namespace was only pointing to one server. Should have been fool/failproof.

It wasn't.

Today, 2 vital members of support staff lost the majority of their documents. There's no audit trail - DFS hasn't "owned up" to it, and Impero's logs show nothing's been deleted. However DFS is the only logical reason this may have happened. So we've decided to pull DFS-R off user areas and keep it in use only for shared drives that aren't constantly accessed.

This of course brings us in line with Microsoft's recommended best practices - the assumption that testing with a few users would apply to over a thousand users hammering it was a silly one indeed. So we're about to roll back to the "good old" method of splitting users over the servers. Not great for failover purposes but at least shadow copies and decent backups will keep things rolling. People will just have to be a little more patient with it should something happen to a server.
I will be thinking about how best to limit damage in case of a failure. It's all well and good having the backups there, but if something goes wrong to one of the main servers, how quickly could we get everything transferred to another. That's something I need to think about, probably later this week.

Apart from that, things seem to be in line. I still need/want to move printers over to item level targetting instead of printer-per-GPO however as things seem to be working just fine, I'm tempted to leave it be. There's a lot to be said for "don't fix what isn't broken".

All this has gone on in the background and I've been trying to sort out 2 minor niggles this week.
First, folders called "My Documents". It's a PITA for sure, there's plenty of fixes and we've tried one (using FSRM to block desktop.ini works) but another is another "Best Practices" fix. Our home drives are mapped to \\namespace\users\%username% - Best Practices dictates it should be \\namespace\users\%username%\Documents. So that's something we'll implement in a staged approach.
The other issue is seemingly random. Our test users documents library doesnt work for unknown reasons but I can't find any staff who share the problem. They either don't have the problem or haven't noticed. (i.e. Documents from the start menu points to the local "Public Documents" rather than the home drive, but the home drive is mapped in My Computer just fine).
I've no idea why that's the case but needs more investigation.

Joys!

Comments

  1. SYNACK's Avatar
    I believe the solution is clustered servers with shared storage on something like a SAN. That was the SAN should stay up and each of the cluster servers can be dropped for matinence without effecting users too much.

    I too have tried DFS-R and it causes more problems than it solves most of the time when used in a high or heavy transaction environment despite their improvements.
  2. synaesthesia's Avatar
    Indeed. We certainly don't have the budget for anything like a decent SAN or clustered servers. It would be nice but I've no idea how we'd ever be able to convince people of it. Shame really, DFS is a cracking idea - if only it could be made a little more modular. For instance, it'd be good to be able to install a NIC in each machine which is dedicated to DFS-R. Still, storage speed will have a large impact on how well it'd work and that remains the bottleneck. One day, maybe!
  3. themightymrp's Avatar
    With regards your public documents folder in the libraries/start menu, there are a few guides I've seen on here that mention editing the .library-ms XML files to remove the links to public folders. Then deploying those edited files from a central share to each of the client PC's, overwriting the defaults.

    I'm glad I just read your blog actually, we were just about to start trying DFS-R to replicate students homedrives between 2 servers i.e. for failover reasons. But if the traffic generated by lots of users (thinking in the region of 1700) is gonna stuff things up I may have to do something else. I've only tested DFS with small folders and a couple of test accounts to see how it works :/
  4. synaesthesia's Avatar
    Aye, it's a lovely idea but just doesn't work with that amount of use. MS's guidelines suggest it's not ideal for environments with lots of constantly changing files. It was certainly a pain when things started to back up and things started going missing - it's only down to shadow copies being enabled that we didn't lose anything in the process.
  5. zag's Avatar
    Excellently timed Blog post, I was just about to ask about peoples experiences with DFS, there is indeed a lot that can go wrong!

    I'm going to build 2 identical file servers and do a simple scheduled xcopy each night. Hopefully that just means I would have to redirect the files in an emergency and have complete piece of mind I always have a backup ready to be deployed.
  6. oxide54's Avatar
    its really good for read only stuff. like software distribution shares and mandatory profiles.
  7. mavhc's Avatar
    On our 3 site system I only replicate static drives, resources, apps etc. Everything is mapped to DFS, but nothing users can change is replicated.
  8. coldhand's Avatar
    awesome article, very nice write up... any chance of taking a peek at those docs?

Trackbacks

Total Trackbacks 0
Trackback URL: