Going to the Dogs

  • Comments 0

I'm starting to worry that I can’t cope with the frantic releases of operating system versions. I just got settled with a couple of Vista machines and, more recently, two Server 2008 boxes, and now I'm being pushed to "dogfood" Windows 7. I wonder if I should install it on the machine I use for all my important work, or on the laptop I depend on when travelling. I know I tend to be somewhat conservative in terms of upgrading to the latest cool software, but neither of these options seems like a really good idea with a beta operating system.

I guess it's OK if you work onsite - you can just throw the machine at the local systems admin guy if it toasts itself, and pick up another from the stores in the meantime. Mind you, I've seen a few of my colleagues using it and they seem happy enough that it does what it says on the Start button. Maybe I should install it in a VPC, or on a machine I don't use for anything important. But what good would that be, unless I also install all the tools and software I use every day, configure everything to work like it needs to, and then put up with using a machine that I had sidelined because it was too old or slow to be practicable? So I'm probably not much help as a dogfooder.

Hmmm... I wanted to write "dogfeeder" there, but that sounds like someone who works in a kennels. Perhaps it should be "...not much help with dogfooding" (but not "dogfeeding"). Is there a conjugation (or declension) for the verb "dogfood"? Something like "I dogfood, you dogfood, he dogfeeds, we dogfed". Probably it’s the same as the one for the verb "impact". And people accuse me of making up words...

Anyway, I'm not sure yet I've even got the knack of the "version 6" stuff. One of my Vista laptops decided to display two account icons on the startup screen when I changed my account password last time, and I haven't managed - despite a great deal of poking and swearing - to get rid of either of them. When it boots, it immediately displays the message "Incorrect password", but then logs in without prompting for a password when I click either of the icons. Despite endless fiddling with account management dialogs and saved password configurations, I can’t resolve it. Maybe I should install Windows 7 on this machine just out of spite.

Though I did solve (partially) a Windows Server 2008 issue this week. Since I moved over to Server 2008, I've had endless problems with batch files and scheduled tasks. I have a series of batch files that use XCOPY to duplicate and mirror data around my network and onto various backup stores. Everything worked fine with Windows 2000 and Windows 2003 Server, but there seem to be some weird things with Server 2008.

For example, my XCOPY batch file uses the /m switch to copy only files with the archive attribute set, and turn off this attribute after copying. But when run from Task Scheduler (either as a timed event or started manually) it copied the files but did not clear the archive bit. The result was that every night when it ran, it copied all the files again. I tried the /d switch, but it still copied files even when they exist on the target drive. I guessed it was because I was using the NET USE command in the batch file to get access to the NAS drive (see my previous blog post "Herding Buffalo" for an explanation). So I created a new separate batch file that just contained the command to clear the archive attributes on the source files:

attrib -a d:\myfiles\backup\*.* /s

When I ran this by double-clicking on it in Explorer, it worked fine. So I created a new scheduled task to execute this batch file a couple of hours after the XCOPY batch file had finished. But, even though I set up the scheduled task to run under a domain admin account, it simply reported "Access denied" for every file. So the fact that the XCOPY command does not work properly is obviously nothing to do with NET USE, or the fact I am accessing a Linux-based NAS drive as the target for the copy. It simply doesn't have permission to update the archive bit on the source files.

Now, I kind of suspected that a domain admin account would be a good choice for doing domain administration stuff. Obviously that's not the case in Windows 2008. So I did what every amateur part-time administrator does in these circumstances - wandered across to TechNet and asked them the question of life, the universe, and why on earth I don't have permission to update files on my own computer. After some exploration, and fortunate choice of keywords (and swear words) I tracked it down to the User Access Control (UAC) feature.

I know I'm a bit vague at the best of times, but I never knew that Windows 2008 had UAC built in. I know that it's been the bane of many people's lives on Vista, but it's not something you'd expect to find lurking in a box where the guy on the keyboard is most likely to be the administrator for most of the time. And it seems that there is a new Admin Approval Mode (AAM) configuration mode as well. If you go off and read the TechNet page "User Account Control" (it's OK to pretend that you understand most of it), you will probably grasp as I did that administrator accounts in Server 2008 get two security tokens. One is a low-trust token used for most activities to help protect against malicious code having full access to the machine. The other token is a full-trust one that is used, according to TechNet, "...when the user attempts to perform an administrative task." It doesn't say when or how the system knows which token to use, or how it knows if the request is a malicious one... but I'll accept that all this just works like it should.

So maybe this is why I don't have permission to update my own files? Does Task Scheduler use the low-trust token for the administrator account I specify to run the task? Or does all this apply to just local administrator accounts and not to domain admin accounts? In fact, AAM is disabled for the built-in Administrator account in Server 2008, but not for other accounts. So Task Scheduler is probably starting all the backup scripts in low trust mode even though its using a domain admin account.

How do I get round this? I did start reading about the Group Policy settings to manage it, and the Registry entries involved, but then noticed the checkbox marked "Run with highest privileges" in the General tab of each scheduled task. I figured it couldn't do that much harm (and I have a recent backup), so I tried it. And, as you probably guessed, it solves the problem. It forces Task Scheduler to start the task using the full-trust token instead. My backup script now works like it should.

Except now I just noticed that the mouse pointer on my Hyper-V VPC has gone back to that stupid "thin up arrow" cursor again (see "Cursory Distractions" ). Oh well, I guess optimism and computers never did mix that well.

Leave a Comment
  • Please add 2 and 7 and type the answer here:
  • Post

Going to the Dogs