The curious case of the magically changing calendar.

Preamble: When this story's events concluded in real life I might have said some mean things about the users in question, but by the time I got to writing the tl;dr, It occured to me that it's not really their fault.

Background: I've been working in IT in support for some time^tm. A few years back my boss was hired by a multinational that wanted to try their hand at itms. He was told to make a team, and myself and a colleague interviewed and were swooped away from our old jobs under him to our new job under him. This isn't relevant to my story, but he's a great guy. Things have been slow at our new little department, he oversees several teams across different IT related projects, but my colleague and I are the ITMS front, we do remote support 100%. We only have about 10 customers, perhaps 100 endpoints. Most of these customers have entirely preconfigured environments that we've taken on board, no standardisation has ever been attempted, we'll take what you have and support you. Not a hard life by any means.

Story: A user calls up one day, they can't rdp to their ts. These guys use a line of business application that is purely accessed via a ts session, they have a few satellite sites that vpn in and use the ts for this purpose also. Good stuff.

It doesn't take me long to discover the error, client time doesn't match server time, kerberos isn't going to let that slide. OK I thought, perhaps the client time is out. Nope, I can't get on the server either. Same error. Shortly after receiving the call I begin to get several more from satellite sites with the same problem. OK the server's time is out, I can't rdp in myself, and I have no permission to put a vnc-esque solution on these servers. Let's bounce it. Time resynchs on boot and everyone's back to work. Not an ideal solution but up is up to the small business.

When I get some time, I check the dc and ts to see why the time is falling out of synch. No domain heirarchy has been configured, they're each reporting in to the windows time server. Well that wont do, let's put them on the NTP pool. I didn't hear back from them for a few days and I pat myself on the back as hero of the people.

A week or so later: same problem. I kick myself for not sneaking VNC onto the TS and bounce it again. To the event viewer we go. Nothing seems to be amiss, perhaps it's some weird issue with the connection to the time servers. So I put the dc on cmos clock and have the ts grab its time from the dc. Surely there's no way that can go wrong I thought. Hero of the people is back in town.

A week later: still happening. This is three weeks that this problem has now been occuring and I'm damned if I know why. I'm not pretending to be the top gun of IT, this is my first role on a level 2 billing, so I'm getting a bit anxious. Since we're an army of 2 and each of us has similar experience, I'm starting to get out of my depth. This time the user who called is still on the server, but her colleague is having the problem.

"Can you change the time in the system tray?" I ask

"Hmm, yes but the time is right. Oh, the day is set to next month, though. Why is that?"

Then it hits me. If this ordinary user is able to change the time on the ts, who else can? We're talking 03 server here, with the old windows XP and earlier clock interface. No calendar for browsing, just settings.

I hit up adu&c, lo and behold she's a Domain Administrator. I check a few more users, EVERYONE is a member of the Domain Administrators group. After a moment of consideration, I remove the Domain Administrator group from the clock changing GP, and specify domain\administrator so we can still change it. We never ran into this problem again. I anxiously waited for the user in question to call me and ask why they couldn't play with the calendar any longer, but alas they never called.

tl;dr: Users with windows 7 workstations are going to treat the calendar feature the same on their 2003 ts session, causing their tech support guy much pain.