Time/Date Control Panel doesn't save time zone in registry if using Remote Desktop

[Mark K Vallevand]

I found it! The bug!

Try this folks: Open registry to
HKLM\System\CurrentControlSet\Control\TimeZoneInformation then use the
date/time control panel applet to change and apply the time zone. If you
are using a local kb/display, the registry is updated. If you are using
remote desktop, the registry is not updated.

The date/time and network time setting are updated, but its illegal to
change the time zone using remote desktop? What gives, Microsoft? Is there
a security setting someplace?

I bet this is a bug in XP Pro, too. Yes, it is. I just checked.

 

[Mark K Vallevand]

Anyone have any ideas?
Anyone?

 

[Doug Hoeffel \(eMVP\)]

Mark:

Maybe you should try asking this question to the
microsoft.public.windows.terminal_services NG?

HTH... Doug

 

[Mark K Vallevand]

I did this. I haven't heard anything yet.

However, I've gotten information that this is the known, correct behavior if
the machine is in a workgroup. If you are in a domain, you can set the
timezone using remote desktop.

 

[Doug Hoeffel \(eMVP\)]

Mark:

Yea, I saw your post in the other NG. I was hoping someone there could help
you out.

I don;t use Remote Desktop since I had problems disconnecting with auto
logon enabled. The machine would stay in a locked state. I'm sticking with
pcAnywhere.

Seems strange to me that you can't do this when just a member of a
workgroup. Did this info come from MS?

.... Doug

 

[Mark K Vallevand]

Yes, it came from Microsoft by way of one of our contacts there. She is
still researching the issue. Here is a snippet of what she said:

If you are trying to do this in a workgroup, it won't work due to the

updates in Security. If you are doing this in a domain and are still

having a problem after looking at the Local Policy settings - User

Rights Assignment, then let's open a case.



I'm not sure if she will chase down XPe problems, but since its also in XP
Pro, I think we might get some answer.

 

[Mark K Vallevand]

Here is the problem report I'm maintaining in our database:
======
XPe Problem Report.
Time/Date Control Panel doesn't save time zone in registry if using Remote
Desktop to XPe.

Try this folks: Open registry to
HKLM\System\CurrentControlSet\Control\TimeZoneInformation
then use the date/time control panel applet to change and apply the time
zone. If you are using a local kb/display, the registry is updated. If you
are using remote desktop, the registry is not updated. But, the daylight
savings checkbox in the applet is always updated into the registry.

Any program that uses SetTimeZoneInformation() will succeed, but the
registry update works or fails as described above.

The date/time, daylight savings, and network time settings are updated, but
its illegal to change the time zone using remote desktop? What gives? Is
there a security setting someplace?

I bet this is a bug in XP Pro, too. Yes, it is. I just checked. I've also
been told that if the target machine is in a domain, you can set the time
zone. Apparently workgroup security does not allow the time zone to be
changed.

Remote Desktop is a variant of Terminal Services. I think Terminal Services
supports the idea of each remote client having its own time zone setting.
Somehow, this has been broken in either Remote Desktop or Terminal Services.
If you remote into a system, and change the time zone, the registry is not
updated, but the time zone is changed for that instance of the desktop. The
control panel applet continues to display the new time zone. Any program
that uses GetTimeZoneInformation() gets the new time zone. If you leave the
desktop windows open, move to the local kb/monitor and logon, you'll see
that the control panel applet now is using the old time zone, and any
program that uses GetTimeZoneInformation() gets the old time zone. Moving
back to the remote, programs see the new time zone. But, both local and
remote can change the daylight savings flag and that is written into the
registry. You can have local and remote in different time zones, but they
both will be forced to have the same daylight savings flag. It seems like
someone had a grand vision of time zones for each client, but broke the
implementation in Remote Desktop (if it was ever implemented correctly in
Terminal Server).

This is a top-priority for us. The only work-around is to set the time zone
on an XP Pro machine, export the registry time zone settings, copy them to
the XPe machine, and import them into the registry. This work-around is not
acceptable.

I'm working on a program that will set the time zone information in the
registry based on the data returned by GetTimeZoneInformation(), which has
the correct information for the remote session. I've proven this concept,
but need to finish some things before considering it as a work-around.
======