Another might be to change the time zone back far enough to accomplish both. As I recall, the time sync is by UTC, and if the domain was far enough west and the workstation TZ moved far enough east, then might it not be possible?
No telling what else might have issues though. ;-)
Phillip Windell wrote:
[Quoted Text] > "Kodiac" <Kodiac[ at ]discussions.microsoft.com> wrote in message > news:126CD427-E9AD-40C9-9053-50ED0D6549FA[ at ]microsoft.com... >> I realize the best practice is for time to be synced to domain, >> however, what is the least intrusive way to allow a few workstations >> to change their >> date. > > It is not simply a best practice. > It is an Active Directory requirement for Domain Members. > Having it hold the adjusted time for an hour or so is plenty of time > to do data entry the way they are doing it, and is going to be the > best you will get short of using "workgroup machines" that aren't > domain members. > The real solution is to fix the Application so that you can input the > time rather than picking it up from the System Clock,...or the other > alternate solution is to adjust the human resource situation that is > causing the work to always end up several days behind. > > So you have about 4 choices: > > 1. Live with the "hour" window of time between manual adjustments > 2. Fix the Application > 3. Use Workgroup Machines instead of Domain Members > 4. Fix the human situation that is letting the work get behind > > Additional Concern: > It is possible from an Accounting perspective that what you are doing > by adjusting the clock could actually be illegal because it may be > looked at as falsifying records. This situation has become a lot > more sensitive since the Sarbanes-Oxley Act, HIPPA, and similar > Government actions,...and then it has become even more sensitive > after the recent Government "bail outs" of some businesses where the > government may be watching a lot more closely at how well businesses > are operated since a failing business can cost them money.
-- /kj
|