Herding Buffalo

Microsoft takes security seriously. I take security seriously. I don't have simple one-lever locks on my doors that you can open with a hairgrip, and I wouldn't use the name of my cat as my system administrator password. Well, maybe I would if my cat was called "g&e7532%dH$7", but imagine the fun I'd have calling it in for its supper at night if it was. Besides, I've got two cats, so it would only get confusing. That's why I wanted to call them "Bev" and "Kev" (but I was over-ruled by my wife).

Anyway, this article is not about cats, it's about Buffalo. Or, to be more precise, the Buffalo LinkStation network drive. I've used one of these for some time, and I love it. It is joined to my internal domain as a computer, and it's easy to access from any machine while maintaining security and protecting the content. Though now it's not. Why? Because I switched my domain controllers from Windows 2003 Server to Windows Server 2008 (and why are the names the other way round now?).

After the move, I just couldn't manage to connect with my Buffalo. While it might sound like something that demands counseling, I thought I could fix it by reconnecting to the domain - even though none of my other machines complained about the upgrade to the servers. Aha! It seems that the drive remembers the NetBIOS name of the domain controller (why?). So I set it to "WORKGROUP" mode and then filled in the details to connect to Active Directory. Just enter the DNS domain name, the name of the domain controller machine, and the credentials to connect to AD. Press Submit, and you get the message "ERROR: The Administrator password can contain 256 alphanumeric characters, a hyphen, and an underscore." My secure domain admin password is rejected because the guy who built the Web-based admin interface, while he might have been an expert in Linux operating systems, had no idea how to build Web stuff.

So, I create a new domain account named "TEMP" with the password "temp" and give it every permission I can find. But it still fails. So I try the "Join NT Domain" option, but that fails too. As does delegating to an external SMB server. Even though my domain is still in "2003" mode and not "native 2008" mode. In the end, I'm stuck with having to use the built-in admin account to access the content. Oh, and by the way, you can stop trying to hack my server 'cos I did remember to remove the "TEMP" account again.

Later I did the "visit our support forum" thing on the Buffalo Web site and discovered dozens of posts from people with the same problem. Some are of the opinion that Buffalo are "working on a fix", others report that they were told it wasn't due to be resolved and it was their own fault for upgrading to Server 2008. I suppose as the O/S in the drive is Linux, you're supposed to fix it yourself.

As a temporary solution I just created a local user account on the drive with read/write access to the contents and got each machine to remember the login details. It's not ideal but it works. Except that all of my backup batch files now failed because they run under a domain account that accesses the source on the disks to be backed up. Thankfully, I remembered the NET USE command, which allows you to specify the credentials for accessing a remote machine. My batch files look something like this now:

NET USE " \\LinkStoreName\ShareName " password /USER: usernameXCOPY " C:\MyFiles\Data\*.* " " \\LinkStoreName\ShareName\DataBackup\ " /s/y/c/a

You can even get the command to create and use a drive mapping, for example as drive Z:, like this:

NET USE Z: " \\LinkStoreName\ShareName " password /USER: usernameXCOPY " C:\MyFiles\Data\*.* " " Z:\DataBackup\ " /s/y/c/a

However, now all I got was "Access denied" messages when XCOPY tried to access existing folders - though the actual error message is "Cannot create folder", which is a little confusing because it did create new folders where there wasn't one already. After fiddling about for a while, it was obvious. The existing folders were created under the domain account I used to use. I renamed the existing folders in Windows Explorer and XCOPY quite happily created the new ones. Where I knew the server still had all of the data in the backup folders, I just deleted the whole folder tree and allowed XCOPY to recreate it using the credentials of the new local Buffalo drive account specified in the NET USE command.

OK, so it's not a great idea having credentials in the batch file, but at least these files are secured on the server away from public view. And it works. At least, it does until Windows Server 2010 comes out. Mind you, I calculated that I am due to retire the same week that support for Windows Server 2008 ends, so maybe I'll never have to upgrade again! I even asked Dell for a 10 year guarantee on the new servers so I was covered all round, but they seemed a bit reticent about that...

So, the only bad news is that over the next few weeks my blog is likely to be full of boring stuff about the issues involved in moving to Windows Server 2008, configuring Hyper-V, getting your head round Virtual Networks and the Windows Time Service, migrating a domain from Windows 2000 Server (that might be two weeks' worth), and other related stuff.