Dead Battery = Date/Time Reset & no WiFi

[DVG]

When a laptop battery dies, after it's revived, the Date/Time is reset to 1/1/01 and the WiFi connection is lost. We've found that if the machine is plugged into ethernet & allowed to do a time sync that way, the issue is resolved after a reboot. These are all MacBook Pro/Unibody models, 2010 or newer, 10.6+.

Is there any way to resolve this without having to set out patch cables at random locations & educate our users how to self-heal, so to speak? We have all Cisco APs/switches, but I think it's more OS/machine-based than a network time issue.

Gracias--DVG

[bajones · Accepted solution]

The newer Apple portables with the non-removable batteries don't have a backup battery on the MLB. I don't think there is a fix for your issue other than educating your users to avoid letting their computers reach an absolute zero charge. This shouldn't be too difficult for them since the computers save a "reserve" amount of power to allow the computer sleep or hibernate for a period of time once the battery reaches 0%.

[bajones · Accepted solution]

The newer Apple portables with the non-removable batteries don't have a backup battery on the MLB. I don't think there is a fix for your issue other than educating your users to avoid letting their computers reach an absolute zero charge. This shouldn't be too difficult for them since the computers save a "reserve" amount of power to allow the computer sleep or hibernate for a period of time once the battery reaches 0%.

[tlarkin · Accepted solution]

Yup this is a problem I see every day. Moving to 802.1x profiles I think should fix this, since the machine will authenticate via the profile to the wireless, then the NTP server should update the time/date once it gets back on line.

Currently we are just running WPA 2 enterprise here at my work and I am trying to convince the powers that be to move to 802.1x profiles or RADIUS or something of the like.

-Tom

[DVG]

I appreciate the help...that's what I was afraid of. I'm a little bummed about Apple just using a transistor to hold a trickle charge for what I would consider essential system information, but who am I to question. :)

Thank you for your time & for affirming my assumption.

DVG

[nortonpc]

We have this issue with users who have taken their laptops away from the corporate network.

I have a self service policy that calls an apple script app on their computer. To change it back to Apple's Time Server. Then after they have synced with the apple time server they are able to change it back to the corporate server and connect via vpn.

I compiled the script into an app so that they cannot get at the admin credentials required to use the script.

Self service:

open /Library/Application Support/JAMF/ChangeTimeServer.app

Apple script:

do shell script "/usr/sbin/systemsetup -setusingnetworktime off" user name "admin" password "######" with administrator privileges

display dialog "Please Select the Time Server to Use" buttons {"Cancel", "Kohls", "Apple"} default button 2

if the button returned of the result is "Apple" then
    do shell script "/usr/sbin/systemsetup -setnetworktimeserver time.apple.com" user name "admin" password "#######" with administrator privileges


else if button returned of the result is "Kohls" then
    do shell script "/usr/sbin/systemsetup -setnetworktimeserver ###########.corp.timeserver" user name "admin" password "#######" with administrator privileges
end if


do shell script "/usr/sbin/systemsetup -setusingnetworktime on" user name "admin" password "#########" with administrator privileges

[John_Wetter]

Unfortunately, I don't think 802.1x will save you here either Tom. The clock falling back to 2001 will make your certificates invalid, so you won't be able to do the 802.1x handshake or RADIUS authentication... Unless you're doing a self-signed cert that would be valid for more than 10 years (yikes!). Interesting solution nortonpc. We've had issues with this too on older computers. The usual issue is just when someone tries to go to a SSL-secured website and Firefox scares the heck out of them with the invalid cert page.

[lisacherie]

The flat battery problem is real hassle with 1000+ laptops after summer holidays when the students have been away for 6 weeks and most don't use or bother to charge them.

I have the following script as an offline policy on startup that sometimes is able to correct the date/time by forcing the date to a value the NTP server is able to correct. Downside it forces a reboot and doesn't always work.

#!/bin/sh

DATE="04:19:11"
YEAR=`/usr/sbin/systemsetup -getdate | cut -d '/' -f 3`

if [ $YEAR == "2001" ]
then
  echo "we have a match"
  /usr/sbin/systemsetup -setusingnetworktime off
  /usr/sbin/systemsetup -setdate $DATE
  /usr/sbin/systemsetup -setusingnetworktime on
  reboot
fi

[sean]

Maybe you could force the correct time during boot if you are having problems with time server settings taking and then a reboot wouldn't be required. E.g.:
ntpdate -q time.euro.apple.com
to get the date and then with a bit of messing, use the date command or systemsetup to set the date.
After setting a manual date, you could then set the time server and until the reboot takes place the time should be close enough anyway.
Possibly better than using a random date from the past.

[lisacherie]

Can't reach a network time server as with the date set back to 2001 the computers are unable to join wireless. The computers are unable to join wireless until after the reboot, when they pick up the correct time from the time server.

[sean]

And that is why you shouldn't reply to this kind of thing after midnight!

[DVG]

Sounds like we're having all kinds of fun with this. Unfortunately, the "Easy" button would require the installation of a CMOS battery, and Apple isn't doing that any time soon. I'll give the scripting a shot and we'll keep the door open on 802.1x.

[chonso]

I know this is probably off time but what if you use automator to connect automatically to certain WiFi Networks (Home/Work) when you start the laptop. After the laptop is connected to WiFi run another code to fix the date and time. I've found the first part at https://magp.ie/2012/07/09/mac-osx-shell-script-to-automate-connecting-to-wifi-network/ and for the second part use http://osxdaily.com/2012/07/04/set-system-time-mac-os-x-command-line/
Currently, I don't have a macbook pro to try it, but I came up with that until now, lol.