Group Policy

[Brennen]

Hello Again

I feel like this is the millionth topic I have posted this month, but whatever. My question should be simple enough.

[Question: Need to Push Time] I have Server 2003 / Active Directory going, and we have our network split up across America. Needless to say we have PC's checking in from multiple time zones, but I need them to all be on the correct time in accordance to their time zone.

Obviously there are many advantages to maintaining the same date and time on all PC's, and I realize this is a very simple procedure I am sure -- and up until now I have simply had my logon script check groups and set the date and time accordingly. Though it works for our local PC's, this process doesn't do anything to our outlying sites.

I figure I could set a policy per OU, and each OU containing the appropriate users/computers with its corresponding Tim Zone...but sadly when I started at my company a few months back there were no OU's setup aside from the defaults -- which contain about 400 users

I have yet to make THOSE changes, so that is not yet an option...

kthnxbye

[IcemanND]

how are you going to determine what time zone it should really be? You'll have to have some sort of logical grouping. Unless you could do it by IP address range if each site has a unique range of addresses.

[nmX.Memnoch]

The workstations should be sync'ing time with the domain controller (the PDC Operations Master specifically) automatically. I was under the impression that the sync would take the time zone into account...so you wouldn't have to do anything extra/special. Granted, I've never done a geographically seperated setup so I may be wrong.

Also, the only way the time function of your logon script is working would be one of the following scenarios:

1. The user is an Admin on the workstation

2. The user is a Power User on the workstation

3. You've given them the "Change the system time" user right

You may want to give this Knowledge Base article a look as well. cluberti can probably answer this better...I know I've seen Time Server questions on the forum before (couldn't find the particular thread I was looking for though).

Edited August 16, 2007 by nmX.Memnoch

[IcemanND]

The time zone is taken into account, the problem is you are relying on whoever setup the machine to have set it right. And heaven forbid you be in Indiana that can't make up it's mind what time zone to belong to and whether or not to observe daylight savings time.

[Brennen]

I currently have kix32 running the SETTIME to the Server running it. I really need to backpedal this though because I know that it's not a very good procedure.

I was under the same impression -- that it should automatically sync, but I have beeing seeing more and more of our PC's fail to check in or login or what have you due to incorrect time. But I have only seen this problem on our local PC's. Which is why I have it (kix, during login) check for a group that is specific to our local users/computers and then run the SETTIME command.

This is working just fine for all of our local guys -- and I cannot really say if there are any problems with our outlying one, but for thorough and proper administration I wanted to have this controlled without my crappy script.

[nmX.Memnoch]

No, you're right...it should be sync'ing automatically. And are you sure your logon script is working? Like I said, it won't work unless one (or more) of the three situations I mentioned above are true.

Have you checked the Event Viewer on the PDC operations master or any of the workstations for any W32Time entries?

[cluberti]

All time in the OS is done in UTC, and then the offset for the time zone is used when displaying time or timestamping. And everyone is right, in an AD domain time sync should be done to the PDCE, or the closest DC in your site, whichever is closer. You shouldn't have to do anything other than make sure the PDCE for the domain has a valid time source to sync against.

[Brennen]

Ooooookie Doke. I will just clean things up on our DC and then let it be. I am sure you are all right, my PDC probably is just a little on the messy side ----- and, this may be 2000 server I am thinking of, but I thought there was a registry change that needed to be made for it to be the Time Server. (Yes, I am sure the logon script works, we created all the users as "local administrators" to their PC alone** -- so when they login their time snaps back into place.)

**Which is brings up a question of its own. I want to semi-automate the process of adding a new user to a PC while giving their account local administrator access without domain admin access -- or access to other PC's admin shares. I have a tendency to under/over think a process, but I feel like this is a paradox. I cannot seem to do this without giving everyone --- more or less --- Domain Admin privileges.

[IcemanND]

do they need admin rights on every machine, or just the machine they are primary user on? If the latter you could just add that user to the local administrators group. Or add the domain users group to the administrators group if they need it everywhere.

[nmX.Memnoch]

You shouldn't have to do anything other than make sure the PDCE for the domain has a valid time source to sync against.

but I thought there was a registry change that needed to be made for it to be the Time Server

Mainly to make sure it has a valid time source for it to sync against. The rest of the domain sync's against it. See the article I linked further up for more information.

this Knowledge Base article

(Yes, I am sure the logon script works, we created all the users as "local administrators" to their PC alone** -- so when they login their time snaps back into place.)

**Which is brings up a question of its own. I want to semi-automate the process of adding a new user to a PC while giving their account local administrator access without domain admin access -- or access to other PC's admin shares. I have a tendency to under/over think a process, but I feel like this is a paradox. I cannot seem to do this without giving everyone --- more or less --- Domain Admin privileges.

You can do it with scripting but it'll be a NIGHTMARE because you'll have to keep a list of all users and what their primary PC is. Is there a reason for making them an Admin on their local workstation? IMO that has the potential to do more harm than good. And please don't tell me that "application X requires admin privs to work properly".

[Brennen]

lol. The primary reason is simply so that they have access to all their local resources. Since we have so many salesmen come and go, along with programs getting uninstalled/reinstalled, etc. -- giving them local admin access just seems to be the simplest solution. I mean without restricting them to something they would potentially I don't see how I could give them any other amount of permissions. Which is why I would like to be able to control everything from Active Directory -- but with 400+ users that seems kind of hairy.

Unless you have some better suggestions (which I'm sure you guys do.) -- I mean, as I have stated -- I practically still a kid,; I am doing my best to to my best, but if I have no idea what I am overlooking I cannot do any better.

[cluberti]

Unless you have some better suggestions (which I'm sure you guys do.) -- I mean, as I have stated -- I practically still a kid,; I am doing my best to to my best, but if I have no idea what I am overlooking I cannot do any better.

You're doing just fine - and making users administrators is sometimes the only option for traveling users (especially sales personnel). I'm always against it if you can avoid it, and there are always ways to do software installs/management via SMS or Group Policy, but traveling users are challenging to any administrator.