MCX for Time Server

[ToriAnneke]

Hi all,

I have an MCX Managed Preference I called "Internal Time Server"
User Level Enforced
Domain: ~/Library/Preference/com.apple.MCX
Key: timeServer
Value: myjss.server.com

And it works great. All my Macs point to myjss.server.com and the JSS points to our AD Controller for its time.

The above MCX Preference 'grays out' the field (in Date & Time) to enter in a time server address and keeps the myjss.server.com in there. The actual config file is /etc/ntp.conf and reads as such
server myjss.server.com

Now here is the situation.
Laptop users go abroad somewhere else on the planet with a different time zone. They are knowledgeable enough to change the Time Zone settings and that keeps the System and Office apps (Entourage 14.. I mean Outlook 2011) in order but again, if the battery dies complete as they let it do, and of course being on the outside of our hallowed network the clock never fixes until they come back to the office. Which can be a while.

So I tried to edit with pico /etc/ntp.conf to read as such:
server myjss.server.com prefer
server time.euro.apple.com

Awesome!!! I got 2 Time Servers to ping to. Internally preferred and externally as a backup. The Date & Time Control Panel reads both entries separated by a comma. But after reboot, my serious pico edits are gone gone gone and revert to what the MCX says.

Bummer.

So I edited the above MCX Managed Preference's (from within the JSS) to read:
Value: myjss.server.com prefer, time.euro.apple.com

After reboot I can read the /etc/ntp.conf but all inline as:
server myjss.server.com prefer, time.euro.apple.com
Then looking at the Date & Time Control Panel shows only myjss.server.com so it seems that didn't work.

I also tried using a semi-colon thinking that as the 'escape' character but nope.
Guess I can make a local shell script that will ensure the ntp.conf file is written correctly. But I was hoping it to be done via MCX. I like MCX.. Give me a God Complex!
Lol

Thanks in advance!

-pat

[ImAMacGuy]

I'm also interested in this, we seem to have a rash of people letting
their batteries completely drain and the system no longer able to sign
in due to the time server sync.

John Wojda

Lead System Engineer, DEI & Mobility

3333 Beverly Rd. B2-338B

Hoffman Estates, IL 60179

Phone: (847)286-7855

Page: (224)532.3447

Team Lead DEI: Matt Beiriger
<mailto:mbeirig at searshc.com;jwojda at searshc.com?subject=John%20Wojda%20Fe
edback&body=I%20am%20contacting%20you%20regarding%20John%20Wojda.>

Team Lead Mobility: Chris
<mailto:cstaana at searshc.com;jwojda at searshc.com?subject=John%20Wojda%20Fe
edback&body=I%20am%20contacting%20you%20regarding%20John%20Wojda.> Sta
Ana

Mac Tip/Tricks/Self Service & Support
<http://bit.ly/gMa7TB>

"Any time you choose to be inflexible in your approach to an
unpredictable project you are already building failure into your plan"

[SeanA]

My initial thought is having two different MCX, each with a different scope. It would work in any case where the buildings are defined by subnets.

Sean
~~~~~~~~~
Sean Alexander
Desktop Analyst
Macintosh Services Delivery
Lockheed Martin - Enterprise Business Services
~~~~~~~~~

[talkingmoose]

Untested: Try separating the values using a space rather than a comma.
On 11/10/11 9:54 AM, "Pat Camporeale" <Pat.Camporeale at wk.com> wrote:

You can enter multiple time server addresses manually in the time server
field if you use a space between them. Close and open the preference pane
and you'll see the commas appear between each server.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

[#5]

we seem to have a rash of people letting their batteries completely drain

On 11 November 2011 02:00, Wojda, John <John.Wojda at searshc.com> wrote: and the system no longer able to sign in due to the time server sync.

We have the same issue from time to time causing students' MacBook Pros to
not accept our CA and as a result don't connect to our wireless network.

I *had* a thought about writing a script that runs on boot to record the
date/time to a file. Before that, in that same script, if the machine's
current year is less than that of the file, the script can safely assume
the battery has been bled dry and therefore set the date/time to that of
the file; it should at least be within a close enough range to accept the
CA for wireless authentication then be corrected via NTP.

But, to be honest, this is a human problem, so I haven't actually tried
this. The students need to learn to take responsibility for the machines.

Just a thought.

Cheers,
Doug