scrapeit
asked on
DST 2007 for Windows 2000
We have all the information regarding DST 2007 and what needs to be done for our customer's operating systems. We know the options for how to update Windows 2000 systems and are clear on that.
However, we have one customer who has several Windows 2000 systems and insisting that the Windows 2000 patches don’t need to be applied as the time for these systems is syncing from the Domain Controllers. I watched the presentation that Microsoft issued for Windows 2000 on how to deploy to multiple systems through Group Policy but there was not any mention of this. I cannot find any mention of this anywhere else for that matter.
So I was hoping someone may have some insight into whether you can just let the Domain Controllers update the time for Windows 2000 systems (workstations not servers) or whether each system needs to be updated regardless of syncing time with the Domain Controllers.
I feel that all the systems need to be updated based on our research but thought someone may know otherwise. Thank you .
However, we have one customer who has several Windows 2000 systems and insisting that the Windows 2000 patches don’t need to be applied as the time for these systems is syncing from the Domain Controllers. I watched the presentation that Microsoft issued for Windows 2000 on how to deploy to multiple systems through Group Policy but there was not any mention of this. I cannot find any mention of this anywhere else for that matter.
So I was hoping someone may have some insight into whether you can just let the Domain Controllers update the time for Windows 2000 systems (workstations not servers) or whether each system needs to be updated regardless of syncing time with the Domain Controllers.
I feel that all the systems need to be updated based on our research but thought someone may know otherwise. Thank you .
Im not sure if this is what you are looking for?
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03mngd/26_s3wts.mspx
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/ws03mngd/26_s3wts.mspx
ASKER
The clients should sync to the domain controllers (clients: 2000, XP servers: 2003) after logging in. I guess in theory the 2000 systems could just sync with the domain controllers and the client could avoid patching the 2000 systems. However, it occurred to me that let's say a 2000 system cannot authenticate to the domain for whatever reason would the following take place:
1. Will the 2000 system default to its internal time (which would be off from the server's time)?
2. When the 2000 system tries to log back on to the domain will its internal time clock (more than five minutes apart from the domain controller) prevent Kerberos from authenticating to the domain controllers?
1. Will the 2000 system default to its internal time (which would be off from the server's time)?
2. When the 2000 system tries to log back on to the domain will its internal time clock (more than five minutes apart from the domain controller) prevent Kerberos from authenticating to the domain controllers?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
whenevever a client machine syncs its time with a DC, it is just synching the time (without regard to time zone or DST).
So lets say you have a DC in Central time zone and a PC that authenticates to it on the West coast. Even after the PC synchs its time with the DC there will still be a 2 hour difference betwen the 2 machines (as there should be since they are in different time zones). Basically the same will happen if you don't patch the 2000 machines. They will synch with DC, but the PC will be on different DST time (sometimes) than the DC, so they will have different times.
So lets say you have a DC in Central time zone and a PC that authenticates to it on the West coast. Even after the PC synchs its time with the DC there will still be a 2 hour difference betwen the 2 machines (as there should be since they are in different time zones). Basically the same will happen if you don't patch the 2000 machines. They will synch with DC, but the PC will be on different DST time (sometimes) than the DC, so they will have different times.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Good link and good information.
So essentially a 2000 client that is part of a domain (same time zone, same network let's say) will just synchronize the time with the domain controller initially upon logging in. It will then look to its own time zone and DST configuration to set its own time so its time will then be off from the server by an hour one way or another.
Now when the the 2000 client logs off the domain it will then revert to its own time based on its times zone and DST configuration (correct???).
Now if this is the case, wouldn't the 2000 client have trouble logging on to the domain because its own clock is more than five minutes in time apart from the domain controller? I have read where Kerberos could have issues authenticating a system that is more than five minutes apart in time from the authenticating DC. However, that does not make sense if there is a system that is authenticating to a DC in another time zone (not the case in this instance).
So essentially a 2000 client that is part of a domain (same time zone, same network let's say) will just synchronize the time with the domain controller initially upon logging in. It will then look to its own time zone and DST configuration to set its own time so its time will then be off from the server by an hour one way or another.
Now when the the 2000 client logs off the domain it will then revert to its own time based on its times zone and DST configuration (correct???).
Now if this is the case, wouldn't the 2000 client have trouble logging on to the domain because its own clock is more than five minutes in time apart from the domain controller? I have read where Kerberos could have issues authenticating a system that is more than five minutes apart in time from the authenticating DC. However, that does not make sense if there is a system that is authenticating to a DC in another time zone (not the case in this instance).
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Thanks dugout this is really helpful - seems the solution is to push the patch to the clients as well then.
ASKER
Thank you dugout for the post and the testing. There were a lot of great points to this post so I am going to split points.
>>Now if this is the case, wouldn't the 2000 client have trouble logging on to the domain because its own clock is >>more than five minutes in time apart from the domain controller?
no, you are confusing Universal Time with 'display time'. say you have a DC on the east coast and a client on the west coast,,,their 'display times' will be hours off (as they should be), but they will both be on the same UT (universal time)... assuming their time is synched properly.
no, you are confusing Universal Time with 'display time'. say you have a DC on the east coast and a client on the west coast,,,their 'display times' will be hours off (as they should be), but they will both be on the same UT (universal time)... assuming their time is synched properly.
ASKER
Thanks for clarifying that. Understood on the UT vs the display time. So to recap the 2000 systems that are not patched will share the same UT as the domain controller but then will adjusts its time based on its own time zone settings and DST. These systems will then be able to function on the domain but will be one hour off in time (assuming let's say they are on the same network/domain) for the weeks in question. However, if the 2000 system's clock is manually changed, the 2000 system will not be able to login until it is changed back.
Thank you all for this information and clarifying many points. This customer has probably 50-75 systems still running Windows 2000. What I will do is set up VMWare containers to show the customer what will happen if they do not patch.
Thank you all for this information and clarifying many points. This customer has probably 50-75 systems still running Windows 2000. What I will do is set up VMWare containers to show the customer what will happen if they do not patch.
all you have to do is create the patch and install it via a GPO (see link below)... its no big deal (well that will handle the OS anyway)....
http://support.microsoft.com/kb/914387
http://support.microsoft.com/kb/914387
ASKER
Another good link to a recorded presentation on this subject is:
http://support.microsoft.com/kb/930688
The presentation makes reference to both of these articles is:
http://support.microsoft.com/kb/930688
http://support.microsoft.com/kb/914387
It shows you the options/methods of patching 2000 systems. It is around an hour long but worth a review if you or your customers have 2000 systems and you need to patch them.
http://support.microsoft.com/kb/930688
The presentation makes reference to both of these articles is:
http://support.microsoft.com/kb/930688
http://support.microsoft.com/kb/914387
It shows you the options/methods of patching 2000 systems. It is around an hour long but worth a review if you or your customers have 2000 systems and you need to patch them.
ASKER
Sorry I put the wrong link in. The links corresponding to the presentation are::
http://support.microsoft.com/kb/914387
http://support.microsoft.com/kb/928388
The presentation link is:
http://support.microsoft.com/kb/930688
http://support.microsoft.com/kb/914387
http://support.microsoft.com/kb/928388
The presentation link is:
http://support.microsoft.com/kb/930688
I think there's a wider issue in that unpatched the clients will try to reset according to their previous ruleset.