synaesthesia

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!