1) Does anybody know of a way (particularly within Windows Explorer, but global would be even better) to emulate a mouse right-click using just the keyboard?

2) Fairly frequently, the time-of-day displayed by my computer skips forward by an hour and three minutes. I have the "Daylight Savings Time Automatic Adjustment" setting enabled. I have gone so far as to set the time in BIOS. I have set it in Control Panel. One of the servers that I access daily has a program that automatically re-sets my computer to the correct time every time I access that program. But nonetheless, several times a week my computer will change its clock time by an hour and three minutes. Re-booting has a good chance of making this happen; but it doesn't happen every time I reboot; and sometimes it happens without rebooting. But wait... there's more.

There are between 50 and 60 networked computers in my building... and possibly 20 of them are exhibiting this behavior. Probably it's just coincidence, but the ones with the problem are all on the North side of the building -- the side where all the Studio-Transmitter link microwave transmitters are located. (The ones that send our studio output up to the transmitter location about 10 miles away on top of the big hill.)

Am I overlooking something obvious here?

tanstaafl.

there are a few TSRs out there which will keep you clock time in synch with the atomic clock

as for some way of "emulate a mouse right-click using just the keyboard?" have a look for AutoIt, I used it regularly for abusing windows.

Not sure about 2 but on my keyboard with the funky Windows keys, there is a button for the context menu. Or if you've got a keyboard without the extra buttons then press shift-F10

- Trevor

One of the servers that I access daily has a program that automatically re-sets my computer to the correct time every time I access that program......Re-booting has a good chance of making this happen; but it doesn't happen every time I reboot; and sometimes it happens without rebooting. But wait... there's more.

I don't understand Windows time synch in any great depth, but my experience with domain-controller-dependent Windows time and "NET TIME" isn't very positive. I've had more predictable results by setting clients up with Windows-independent time services using NTP/SNTP along with a Win-capable client like Tardis .

If my memory serves and you have a boundary router like a Cisco 25xx, you can set that up to serve NTP time to your internal network. For a small network, that makes things simple. NTP Server == default gateway.

No idea on issue #1!

my experience with domain-controller-dependent Windows time and "NET TIME" isn't very positive

To solidify Jim's implication, is it possible that your domain controller (assuming you have one) has its clock off? Or maybe that its time zone is wrong? Or maybe that its time zone is off and its clock is wrong by three minutes?

Windows has this neat feature of being smarter than you, and part of that is distributing its time from the domain controller (and possibly the browse master, in a domain-less environment) to all of its clients. I believe that you can disable this at both the server and at the client. To see if that's the problem, you might try disabling the client's time service. Don't know what OS you're running, but if it's an NT-type system (that is, NT, 2000, or XP), try stopping the Windows Time service. You can do this GUI-ly, or you might be able to run ``net stop w32time''.

Tman.... Shift-F10 does the trick, thanks. It's what Doug was looking for.

Now that I think about it, this question came up before on the BBS, in a thread that I participated in, and I'd forgotten the answer. I believe we were discussing it in relation to Internet Explorer, but it seems to apply to the Windows Desktop and Explorer as well. Don't know why I didn't remember it when Doug asked me this question privately earlier today.

And Doug, I agree that it sounds like your network's main "time server" computer has an incorrect clock. I forget how to set up the time server on the network (we're not using one on our network), but start looking at servers.

To solidify Jim's implication,

Much more solid, thanks!

is it possible that your domain controller (assuming you have one) has its clock off? Or maybe that its time zone is wrong? Or maybe that its time zone is off and its clock is wrong by three minutes?

Windows has this neat feature of being smarter than you, and part of that is distributing its time from the domain controller (and possibly the browse master, in a domain-less environment)

Yes, what Doug describes makes it sound like there are two different time domains -- like one controller with the correct time zone and another with the wrong time zone -- and that the client computers are switching back and forth. With a strict domain controller setup, you'd think that couldn't happen, but with workgroup/browser setup, who knows??

Don't want to point out the obvious, but most M$ enabled keyboards (the ones with the little windows 'flying panes' icon) also has a key that does this. It's the second key to the right of the space bar and has a little 'icon-arrow and menu' graphic. It won't work on the desktop (ie to set display properties) but it does work in IE and windows file explorer, the same as Shift+F10.

-Zeke

It works on the desktop. Assuming you don't have any icons selected. Course, without a mouse there's no way to NOT select an icon, however, ctrl-esc, s, c will get you there right quick.

aaah. I did not know that. I just put my cursor over the desktop (with my mouse of course) clicked then tried the 'right click' key. I thought it did nothing because the menu popped up on my 1st screen (multi-head) and I didn't notice it, as it was no where near my cursor.

-Zeke

It definately sounds like one of the DCs is an hour and three minutes out. Can you poll the DCs for their time?

Go to Start/Run, and start a DOS box with CMD (for NT/2000/XP machines) or COMMAND (95/98 machines)

At the command prompt, just type NET TIME and it should tell you what the time is and the name of the time server you are pointing at. That should allow you to carry out a little detective work on your network to find out which machines are time servers (running NTP or some such). When you know which ones they are, then you should be able to set them correctly. There should really be only one time server in a LAN bounded by a router as the gateway.

To check if your machine is running an NTP client to listen to time change broadcasts, from the prompt type NETSTAT /a and look for a socket on your own machine listing to the NTP service somewhere on your LAN, identified by (I think) port number 123 (NTP).

Bitt, you nailed it.

Once again (as expected) the very smart people on the empeg bbs have come through for me.

My time problem was on the Novell server that supplies the music to the radio stations. Not sure exactly how/when my workstation accesses that server, but its time was off by some number of hours + 3 minutes -- a smoking gun if I ever saw one. Interestingly enough, that server's time may not be reset -- if we do so, then all four radio stations will be off the air immediately. Apparently the server (pretty much a black box to us -- we are not allowed to tamper with it in any way, it is controlled entirley by Corporate Headquarters) carries its own [corporate] timestamp and must remain synchronized with corporate and literally thousands of identical servers throughout the country. When I called Prophet tech support (Prophet is the provider of the music management/playing software, and is owned by Clear Channel, the company that owns us) the very knowledgeable lady was almost in a panic making sure that I did not attempt to change the time.

Anyway, the solution to the problem is to go into Novell management on each workstation, delve down about five submenus deep, and change a "Set Time" setting from "On" to "Off". Then the problem will no longer occur.

Just to make it even more fun, it turns out that our billing/traffic software for the radio stations has a failsafe in its licensing agreement whereby if the system clock on the workstation is ever set to a time earlier than the most recent access to the software, the program thinks I am Long John Silver or someone trying to pirate the software and it destroys the license file, requiring a call to technical support and a reload of the software.

Don't you just love it?

tanstaafl.

Bitt, you nailed it.

...

the solution to the problem is to go into Novell management on each workstation ...

It looks like I did, except I used a screwdriver instead of a hammer. Didn't know that you were using Novell.

Clear Channel, the company that owns us

Truer words have never been said.

Ah, Yes. If you'd said there was novell somewhere around, things would have been easier.

At least you've identified the problem.

At least you've identified the problem.

Is that a subtle dig??

Client time synch in the Novell client is about the same as Windows NET TIME, IIRC -- fire and forget. Synch time at logon then that's it. PCs that logon and off more frequently tend to have more accurate time! PCs that remain logged in for long periods risk more drift.

Server time synch used to be a big weak point on Novell -- very weak tools to get external time, people had to rely on odd assortments of (sometimes unsupported) NLMs to do it.

With Netware 4/5, time synch is critical to correct NDS replication. If servers get seriously out of whack, VERY BAD THINGS (tm) are likely to happen as Doug's contact suggests. Nowadays, the process for inter-server time synch in Netware is very good; it has to be. However, the important thing is not that the servers have the correct time, but that they *agree* on the time. Sounds like this is either an older Netware config or that someone didn't take appropriate measures to synch to a correct time source outside of their immediate domain. My guess would be 3 minutes off across the domain and wrong time zone on Doug's server.

Doug, given what you said about timestamp-dependent licensing, one risk of unsynching time from your (incorrect) server or of synching independently to an NTP source would seem to be that your clients could be either ahead or behind of that server's time. Is that (incorrect) server the ultimate authority on the licensing thing?

FYI, I stumbled across Prophet's download page

My guess would be 3 minutes off across the domain and wrong time zone on Doug's server.

The 3-minutes off is true. But the time zone is the the time zone they want to use -- one time zone for everybody. Mountain Standard Time without daylight savings, I think. Since the idea was to have time synchronization to the workstations turned off, it really doesn't matter what time the server is set to.

Doug, given what you said about timestamp-dependent licensing, one risk of unsynching time from your (incorrect) server or of synching independently to an NTP source would seem to be that your clients could be either ahead or behind of that server's time. Is that (incorrect) server the ultimate authority on the licensing thing?

The timestamp dependent licensing is a completely separate software system, running on a different server, and does not interact with the Prophet (Novell) software or server in any way, other than once a day creating a set of text files containing logging information that is uploaded to the prophet server. I am guessing that it was during this upload process that the time on my workstation was being reset to the Novell time. But it only happened occasionally. I am sure that now we know what is causing the problem, we will be able to find a common thread linking all of the "problem" workstations (about 20 out of the 50 or 60 in the building) that are/were having timestamp problems.

tanstaafl.

the time zone is the the time zone they want to use -- one time zone for everybody

The whole point of time zones is so that you can have a coordinated universal time and still keep your local time. You need network engineers that know what they're doing.

Nowadays, the process for inter-server time synch in Netware is very good

Until you throw a PIII based server into the mix. For some reason, NW5 out of the box screws it's time up badly on a PIII box until a patch is applied. Working for the hardware vendor that has a 50% market share of Novell running servers led to some very predictable support calls. "I need the (battery/system board) replaced, my time is (ahead/behind) x amount of minutes every hour." "Does the time correct it's self for a while after a reboot?" "Yes..." "Then go read TID (current TID number of the week for the time issue)."