Deploying OS X 10.9 Mavericks upgrade not automated

[martin]

With version 9.2 of the Casper Suite we have the option to add the "Install OS X Mavericks.app” to the Casper Admin to easily create create an upgrade package. This is a great functionality but I’m facing a very strange problem. I followed all the steps in how to accomplish this with Casper Suite:
http://www.jamfsoftware.com/sites/default/files/Deploying-OS-X-v10.7-or-Later-with-the-Casper-Suite.pdf

When I start the upgrade, via Self Service, the computer reboots and starts the OS X Installer I need to manually click continue, agree with the software license agreement, select the disk and click install.

Strange this is that this behaviour is exactly the same with the createOSXinstallPkg package. In the past I have used createOSXinstallPkg to upgrade to 10.7 and 10.8 with succes.

I’ve seen this in all environments and I’ve reached out to JAMF Support and they are experiencing the same thing here in Europe. The U.S. is not seeing this kind of behaviour.

I’m kind of stuck here. Has anyone else seen this kind of behaviour? Has anyone been successful to upgrade to Mavericks fully automated in Europe?

Thanks!

[Chris]

Hi Martin,

we're upgrading to Mavericks using createOSXinstallPkg (in Germany, UK & US) and i've never seen that happening so far...
But we're on 8.73.

What could be different between Europe and the US?
OS language/regional settings of the user running Self Service?
Ours are mostly set to US English, but I can't imagine that this matters to the upgrade process.
Weird...

[winningham_2]

I didn't want to just echo Chris but we haven't had an issue either. I took the /Applications/Install OS X Mavericks.app and dragged it into Casper Admin and sorted out the metadata.
I cached the package out to a target machine and ran Recon on it afterwards.
I created a policy with the app/scope/selfservice that installed from cache. I ran it within SelfService and it rebooted the machine.
Upon reboot it started the installation which took about an hour. Once the machine was back up, it presented a login to the end user, and they logged in without bother, after selecting to sign-in to iCloud.

So that was my experience and, yes, I also referenced the same document to a degree.

[martin]

Thank you both for your information. I'm located in the Netherlands. Computers have Dutch or English as default language and that does not seems to be the issue.

[owen_hael]

Hi Martin,

I experienced the exact same thing in the US using Casper Suite 9.21. Used self-service but the install was not automated and I had to go through the normal process of selecting a disk, agree with the software license, etc. As of yet I haven't been able to resolve the issue. Would really like to know more.

I followed JAMF's new guide specifically for 10.9 here: http://www.jamfsoftware.com/libraries/media/casper-suite-in-place-upgrades_1920x1080.mov

[jomo]

I am seeing the same here in Germany. I was not able to test more on it but would also be interested in a solution or explanation :)

[martin]

I did a clean install of OS X 10.8 and used createOSXinstallPkg to create the OS X 10.9 Installer. I manually installed this one and that worked. The problem could be within the bless command of the Policy because the policy overwrites the bless command the the createOSXinstallPkg uses. I extracted the NVRAM parameters just before the restart:

$ nvram -xp
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
     <key>LocationServicesEnabled</key>
     <data>
     AQ==
     </data>
     <key>SystemAudioVolume</key>
     <data>
     MA==
     </data>
     <key>bluetoothActiveControllerInfo</key>
     <data>
     CAAPDoQ4NVNXLQ==
     </data>
     <key>efi-boot-device</key>    <string>&lt;array&gt;&lt;dict&gt;&lt;key&gt;IOMatch&lt;/key&gt;&lt;dict&gt;&lt;key&gt;IOProviderClass&lt;/key&gt;&lt;string&gt;IOMedia&lt;/string&gt;&lt;key&gt;IOPropertyMatch&lt;/key&gt;&lt;dict&gt;&lt;key&gt;UUID&lt;/key&gt;&lt;string&gt;25B8F381-DC5C-40C4-BCF2-9B22412964BE&lt;/string&gt;&lt;/dict&gt;&lt;/dict&gt;&lt;key&gt;BLLastBSDName&lt;/key&gt;&lt;string&gt;disk0s2&lt;/string&gt;&lt;/dict&gt;&lt;dict&gt;&lt;key&gt;IOEFIBootOption&lt;/key&gt;&lt;string&gt;config="OS X Install Datacom.apple.Boot"&lt;/string&gt;&lt;/dict&gt;&lt;/array&gt;</string>
     <key>efi-boot-device-data</key>
     <data>
     AgEMANBBAwoAAAAAAQEGAAARAQEGAAAEAxIKAAAAAAAAAAQBKgACAAAAKEAGAAAAAACQ
     YOYEAAAAAIHzuCVc3MRAvPKbIkEpZL4CAn//BAA=
     </data>
     <key>fmm-computer-name</key>
     <data>
     TWFydGlu4oCZcyBNYWM=
     </data>
     <key>install-product-url</key>
     <data>
     eC1vc3Byb2R1Y3Q6Ly8wQTgxRjNCMS01MUQ5LTMzMzUtQjNFMy0xNjlDMzY0MDM2MEQv
     T1MlMjBYJTIwSW5zdGFsbCUyMERhdGE=
     </data>
     <key>platform-uuid</key>
     <data>
     AAAAAAAAEACAAAAMKUa09w==
     </data>
     <key>prev-lang:kbd</key>
     <data>
     RW5nbGlzaDow
     </data>
</dict>
</plist>

At this very moment I can not compare these nvram settings with the bless command of the Policy.

Decode of the efi-boot-device key:

<array>
    <dict>
        <key>IOMatch</key>
        <dict>
            <key>IOProviderClass</key>
            <string>IOMedia</string>
            <key>IOPropertyMatch</key>
            <dict>
                <key>UUID</key>
                <string>25B8F381-DC5C-40C4-BCF2-9B22412964BE</string>
            </dict>
        </dict>
        <key>BLLastBSDName</key>
        <string>disk0s2</string>
    </dict>
    <dict>
        <key>IOEFIBootOption</key>
        <string>config="OS X Install Datacom.apple.Boot"</string>
    </dict>
</array>

[gregneagle]

The postflight script of the createOSXinstallPkg blesses the OS X Installer boot files so that on reboot, the machine boots into the OS X Installation environment (which is a fancy boot-from-dmg arrangement). If bless is run again before the reboot and changes parameters, then all bets are off as to what will happen next.

[sggr57a]

Apologies.. This solution suits re-imaging from a NetBoot standpoint and not a Self Service policy.

I was having this issue as well. Casper Imaging was not allowing Greg's package to run as long as a valid system was installed. In the end, I created a package w/postflight which removes the CoreServices folder in order to allow re-imaging. The folder needs to be dealt with in order to allow the formerly blessed 'OS X Install Data' folder to remain as the successor.

[martin]

This is the output of the NVRAM after the Self Service Policy followed by the JAMF Software manual:

$ nvram -xp
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>SystemAudioVolume</key>
    <data>
    Ww==
    </data>
    <key>backlight-level</key>
    <data>
    3wE=
    </data>
    <key>efi-boot-device</key>
    <string>&lt;array&gt;&lt;dict&gt;&lt;key&gt;IOMatch&lt;/key&gt;&lt;dict&gt;&lt;key&gt;IOProviderClass&lt;/key&gt;&lt;string&gt;IOMedia&lt;/string&gt;&lt;key&gt;IOPropertyMatch&lt;/key&gt;&lt;dict&gt;&lt;key&gt;UUID&lt;/key&gt;&lt;string&gt;ACE3324E-F6BC-48F9-A5E9-19F8060FB6CD&lt;/string&gt;&lt;/dict&gt;&lt;/dict&gt;&lt;key&gt;BLLastBSDName&lt;/key&gt;&lt;string&gt;disk0s2&lt;/string&gt;&lt;/dict&gt;&lt;dict&gt;&lt;key&gt;IOEFIBootOption&lt;/key&gt;&lt;string&gt;config=/OS X Install Data/com.apple.Boot.plist&lt;/string&gt;&lt;/dict&gt;&lt;/array&gt;</string>
    <key>efi-boot-device-data</key>
    <data>
    AgEMANBBAwoAAAAAAQEGAAIfAxIKAAAAAAAAAAQBKgACAAAAKEAGAAAAAAAg1RU6AAAA
    AE4y46y89vlIpekZ+AYPts0CAn//BAA=
    </data>
    <key>install-product-url</key>
    <data>
    eC1vc3Byb2R1Y3Q6Ly9CQzg3NTExMy03NUFGLTM2MEUtOTBERS1BRDhFNDMxRUJFNEEv
    T1MlMjBYJTIwSW5zdGFsbCUyMERhdGE=
    </data>
    <key>prev-lang:kdb</key>
    <data>
    ZW46MA==
    </data>
</dict>
</plist>

Decode of the efi-boot-device key:

<array>
    <dict>
        <key>IOMatch</key>
        <dict>
            <key>IOProviderClass</key>
            <string>IOMedia</string>
            <key>IOPropertyMatch</key>
            <dict>
                <key>UUID</key>
                <string>ACE3324E-F6BC-48F9-A5E9-19F8060FB6CD</string>
            </dict>
        </dict>
        <key>BLLastBSDName</key>
        <string>disk0s2</string>
    </dict>
    <dict>
        <key>IOEFIBootOption</key>
        <string>config=/OS X Install Data/com.apple.Boot.plist</string>
    </dict>
</array>

So far I can not see any difference. I do noticed a difference in the minstallconfig.xml file:

createOSXinstallPkg creates:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>InstallType</key>
    <string>automated</string>
    <key>Language</key>
    <string>en</string>
    <key>Package</key>
    <string>/System/Installation/Packages/OSInstall.mpkg</string>
    <key>Target</key>
    <string>/</string>
    <key>TargetName</key>
    <string>Macintosh HD</string>
    <key>TargetUUID</key>
    <string>0A81F3B1-51D9-3335-B3E3-169C3640360D</string>
</dict>
</plist>

Casper Suite creates:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>ChoiceChanges</key>
    <string>MacOSXInstaller.choiceChanges</string>
    <key>InstallType</key>
    <string>automated</string>
    <key>Language</key>
    <string>en</string>
    <key>Package</key>
    <string>/System/Installation/Packages/OSInstall.mpkg</string>
    <key>Target</key>
    <string>/Volumes/Macintosh HD</string>
    <key>TargetName</key>
    <string>Macintosh HD</string>
    <key>TargetUUID</key>
    <string>BC875113-75AF-360E-90DE-AD8E431EBE4A</string>
</dict>
</plist>

After launching the OS X Installer on reboot I opened the Insteller Log and noticed this line:

Ignoring stale automation file /Volumes/Image Volume/OS X Install Data/minstallconfig.xml (time since IA = -3471.239602)

Looking into the OSInstallAttr.plist file (located within the OS X Install Data folder):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>IAEndDate</key>
    <date>2013-12-12T11:13:59Z</date>
    <key>IALogFile</key>
    <string>/OS X Install Data/ia.log</string>
    <key>OSIAutomationFile</key>
    <string>/OS X Install Data/minstallconfig.xml</string>
    <key>OSSourceDiskUUID</key>
    <string>BC875113-75AF-360E-90DE-AD8E431EBE4A</string>
</dict>
</plist>

Compared to the createOSXinstallPkg:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>IAEndDate</key>
    <date>2013-12-11T10:31:13Z</date>
    <key>IALogFile</key>
    <string>/Volumes/Macintosh HD/OS X Install Data/ia.log</string>
    <key>OSIAutomationFile</key>
    <string>/Volumes/Macintosh HD/OS X Install Data/minstallconfig.xml</string>
    <key>OSSourceDiskUUID</key>
    <string>0A81F3B1-51D9-3335-B3E3-169C3640360D</string>
</dict>
</plist>

Changed Target key in minstallconfig.xml to / doesn't make a difference.

[martin]

For now I created a workaround:

1. Create install package with createOSXinstallPkg
2. Cache package on client
3. Install Cached package on client via Self Service
4. Do not reboot the client via the predefined Restart options but configure Files and Processes and Execute Command "shutdown -r now"

[gregneagle]

So that definitely points to something Casper is doing as part of the predefined Restart options -- it's altering the blessed boot in some manner.

This bit:
Ignoring stale automation file /Volumes/Image Volume/OS X Install Data/minstallconfig.xml (time since IA = -3471.239602)

Means it's been too long since the OS X install automation file was created; the machine needs to be rebooted within a few minutes after this file has been created, or the install automation is skipped and you are presented with the Recovery partition-style OS X Utilities window.

I don't know how long counts as "too long". 30 minutes is definitely too long; 5 minutes seems not to be.

[martin]

Thanks for making that clear. The policy was set to restart immediately so the installation will take place within 5 minutes. Due to testing the message was captured at a later time. Will try to capture the log asap the OS X Installer starts for the first time.

[ewettach]

We have seen a similar, but slightly different issue. We have test about 40 machines an it works like we want without user interaction on about 36 of them, but about 4 of them were prompted to agree to terms and select disk to install to. Our configuration is the same with the install cached being the way that the user installs from Self Service.

[martin]

Still trying to find out what is causing this. I started the upgrade (again) as described by the JAMF document:

After launching the OS X Installer on reboot I opened the Insteller Log and noticed this line:

Ignoring stale automation file /Volumes/Image Volume/OS X Install Data/minstallconfig.xml (time since IA = -3493.212313)

Opened Terminal:

-bash-3.2# date
Tue Dec 17 04:53:34 PST 2013

-bash-3.2# ls -la /Volumes/Image Volume/OS X Install Data/
total 10366320
drwxr-xr-x  13 root  wheel         442 Dec 17 04:50 .
drwxr-xr-x  31 root  wheel        1122 Dec 17 04:48 ..
-rw-r--r--@  1 root  wheel        1037 Dec 17 04:50 .disk_label
-rw-r--r--@  1 root  wheel        4157 Dec 17 04:50 .disk_label_2x
-rwxr-xr-x   1 root  admin  5290551900 Dec 17 04:31 InstallESD.dmg
-rwxr-xr-x   1 root  admin         182 Dec 17 04:50 MacOSXInstaller.choiceChanges
-rwxr-xr-x   1 root  wheel         481 Dec 17 04:50 OSInstallAttr.plist
-rwxr-xr-x   1 root  admin        4308 Aug 24 18:40 PlatformSupport.plist
-rwxr-xr-x   1 root  admin      505400 Aug 24 22:31 boot.efi
-rwxr-xr-x   1 root  admin         398 Dec 17 04:50 com.apple.Boot.plist
-rwxr-xr-x   1 root  admin         491 Dec 17 04:50 index.sproduct
-rwxr-xr-x   1 root  admin    16451177 Oct 16 21:27 kernelcache
-rwxr-xr-x   1 root  admin         630 Dec 17 04:50 minstallconfig.xml

These is a time difference of just 3 minutes between the creating of the minstallconfig.xml file and the start of the OS X Installer. Still it's ignoring the automation file.

[martin]

Ok, I finally found what it causing this issue!

It's the IAEndDate key that is located in the OSInstallAttr.plist file.

Date was set to 2013-12-17T15:05:13Z by default.

I set the date to 2013-12-18T15:05:13Z but apparently this just works the other way around because now I got:

Ignoring stale automation file /Volumes/Image Volume/OS X Install Data/minstallconfig.xml (time since IA = -89843.891604)

I set the date to 2013-12-16T15:05:13Z and guess what, it's finally automated! Sent an update to JAMF and hopefully they will fix this soon.

[jomo]

Just a crasy idea - could you try to set the timezone on this computer to MN? Maybe its a storage timezone/timing issue?

[martin]

@jomo, that doesn't seems related as the Pacific Time Zone is used for the configuration files and OS X Installer.

[ewettach]

@martin][/url I altered the IAEndDate and tried setting it to a day before and then tried again with setting it to a day after the current time. Neither worked. I then set the IAEndDate to about 13 minutes before the install attempt and it worked fine. Do we know what the installer considers to be "stale"? 15 minutes, an hour, a day? It doesn't make much sense unless JAMF is running this incorrectly and setting an incorrect date on IAEndDate. The policy we have reboots the computer immediately after it sets everything up, so the longest I can think would be 4 minutes between the policy running and the installer beginning. I can't imagine that this is getting stale. If a work around is to set this via policy to something in the near past we can, but I just need a workable time frame.

[ewettach]

DUPLICATED POST

[ewettach]

I did determine that the time zone (of the OS X Installer) is set to Pacific even though the computers are Central. This means that the current time of the computer when creating IAEndDate is 2 hours off already for us. However, in my tests, I have changed it to 10 hours before current time and it works properly. This doesn't make much since.

[martin]

Have not tried yet this but maybe this is a workaround. Create a script that runs "after" the policy and does the following:

#!/bin/sh
ia_end_date=`date -v-12H +"%Y-%m-%dT%H:%M:%SZ"`
defaults write "/OS X Install Data/OSInstallAttr.plist" IAEndDate $ia_end_date

[nick]

Martin,

I've uploaded a script that's very similar to what you have here that resolves this issue.

I've posted the script to: https://jamfnation.jamfsoftware.com/viewProductFile.html?id=1&fid=679

We've also filed a defect on this and have verified that the impact is that any system that is located in a timezone ahead of UTC would be affected by this issue.

Thanks to everyone on this post for helping us narrow down the issue.

Nick

[martin]

Hi Nick,

Thanks for the update. I downloaded your script and the one thing I noticed it that it does not change the time or day. I have not tried it yet but the script I've posted will set the time 12 hours earlier to make sure we are within the AIEndTime.

[jomo]

hmm.....i just tested it here too. @nick Script doesn't change the date entry and therefore the upgrade still fails.
Then i tested Martin's script and that works for me. automated upgrade is running without asking questions. thanks for all the work you guys have put in this!

[gregneagle]

Not sure why there's any date formatting in the scripts:

bash-3.2$ d=date
bash-3.2$ defaults write com.foo SomeDate -date "$d"
bash-3.2$ defaults read com.foo
{ SomeDate = "2013-12-19 14:07:18 +0000";
}

[nick]

The date formatting in my script was to just keep the format consistent with the format the OS X Installer writes to the OSXInstallAttr plist. I would not recommend offsetting the time, as this will break for others around the world.

The main problem as it is filed in the defect is that the timestamp needs to be set to the current UTC time, and it was instead set to local time, represented as local time with UTC formatting.

When I run this script as part of the policy that performs the installation and reboot to the OS X Installer, the OS X Installer is properly automated.

[gregneagle]

My point is the formatting and the '-u' flag have no effect -- IAEndDate is stored as an NSDate, not a string:

bash-3.2$ one=date
bash-3.2$ two=date -u
bash-3.2$ three=/bin/date -u +"%Y-%m-%dT%H:%M:%SZ"

bash-3.2$ defaults write com.foo one -date "$one"
bash-3.2$ defaults write com.foo two -date "$two"
bash-3.2$ defaults write com.foo three -date "$three"

bash-3.2$ defaults read com.foo
{ one = "2013-12-20 05:26:09 +0000"; three = "2013-12-20 05:26:15 +0000"; two = "2013-12-20 05:26:12 +0000";
}

Note they are all the same (minus a few seconds difference -- I can only type so fast!)

[jomo]

Hi there,
i did some testing here - first in a VM (because its easier) and then on an actual test MacBook Pro (to avoid issues caused by the VM). This way i tested all versions of the script. But it never worked. Only if i manually run the script before rebooting. Could it be that there is anything overwriting this file again after the Policy is done?

Another issue is - the Upgrade starts automatically then - but it never finishes. I left it running for hours.

Now i am confused....maybe its just an issue in my environment. If i don't automate - just run the Installer, then the Upgrade takes place. Could anyone confirm if the Upgrade work for him - automated and in EMEIA?

EDIT: going to download 10.9.1 now and test again with this one.

[jomo]

So - a update on this one. I don't think it is related to the OS X Version. But now, instead of using the script to change the Content of that file - which was not working somehow - i just added on line to set the timezone to America/Chicago

systemsetup -settimezone America/Chicago

Now the Installation runs automatically. Another Policy will run at startup and set the timezone back to my timezone. Thats working for me until its fixed.

Another issue i experience is: even tho i tell the Policy to restart - it does not restart. I get some errors in the Syslog with a launched-error..... still investigating on this one....

[bentoms]

@jomo, are you on 9.22?

From other reports it looks like there may be an issue with restarts & 9.22.