Apple Allowing Non-Developers to Apply for OS X Beta Program

[jhalvorson]

This might effect your ability to support devices. :)

Should I review all my smart groups and policies to ignore 10.9.3 testers? - Something all admins will be thinking tonight.

[scottb]

But this is OK? Come on fellas (and gals). We're not divulging secrets of a public beta OS, we're talking about keeping clients from hosing Macs by modifying a plist.
...
16:50:45 UTC] gneagle: MS can't complain -- they caused the need in the first place.
[16:51:10 UTC] hfike: and if MS does get mad at me…throw gneagle 's larger install base under the bus!
[16:51:34 UTC] gneagle: "We didn't expect our Volume Licensed software to be installed with an automated process!"
[16:52:06 UTC] gneagle: "We thought everyone just ran around and double-clicked on icons"

[gregneagle]

Sure it's OK. I have a volume-licensed install of Microsoft Office. I'm installing Microsoft Office on machines covered by that license. I'm working around an issue with Microsoft's installation packages. I am not violating the terms of the license.

[gregneagle]

"I see, so some discussion was posted about a utility from Apple that deploys a plist change, which anyone with an Apple ID and a Mac running 10.9 can also obtain for $0.00…"

After agreeing to an NDA.

Noting that the utility modifies the CatalogURL would not violate the NDA. Revealing the contents of that modification does (IMHO) violate the NDA, as it then provides enough info for people who have NOT agreed to the NDA to access the public beta.

[scottb]

Ah, but I'd wager if you broke down the MS SLA it would talk about not reverse or re-engineering their software. Look, I'm not trying to bust anyone's chops, I think everyone here takes the NDA's seriously. But the histrionics over NDA breakage here are unwarranted. My 2¢
You can take all the info posted here and have not been part of any Apple NDA. That's a fact.

[scottb]

Noting that the utility modifies the CatalogURL would not violate the NDA. Revealing the contents of that modification does (IMHO) violate the NDA, as it then provides enough info for people who have NOT agreed to the NDA to access the public beta.

Ah, but the modified CatalogURL is nowhere to be seen here. If it were, I'd agree. But also, it's two-part. The Mac would need a matching Apple ID (having joined the beta) to actually download anything.

[gregneagle]

No histrionics. Just don't reveal information that is not yours to reveal. I have not revealed the contents of my com.microsoft.office.licensing.plist file. Doing that would be a clear violation of our org's agreement with Microsoft.

Same goes with our agreements with Apple.

[mm2270]

It was posted up above, and then redacted. Its the only "real" violation on this thread and it was pulled already. Also just checked Google's cache for this thread and it has only captured the very first post so far, so no-one searching the cache after the fact can find that info here anymore. The only people who would have it now are those signed up for email notifications per post as I have and others. If you receive a digest you likely will not see it there.
Seems overall pretty minor to me. Not saying it wasn't "a" violation, but lets try not to exaggerate things shall we?

[gregneagle]

Great that it was removed! My comments about NDA violation were made before it was removed.

[scottb]

Ah, never saw that it was posted. I get the email digests, but I didn't catch that. Indeed, that was not needed here and glad it's gone.

*Edit: Yup it's in the emails. It was not needed to talk safely about this issue and the fixes. So good that it was removed!

[donmontalvo]

I think everyone understands @gregneagle brings up a valid concern, we need to be careful what we post here, and on ##osx-server IRC:

http://osx.michaellynn.org/freenode-osx-server/

[gregneagle]

and everywhere else that's publicly accessible.

[gregneagle]

"I agree this is a very odd decision on Apple's part to open this to every Joe regular user. Not sure what they're doing here."

Getting wider testing from interested volunteers.

[Matt]

Not sure how I feel about this. People on MR already all updating to Beta software without thinking twice. Getting quality data is better than getting quantity.

[mm2270]

Yeah, I get that, but it seems to me that there isn't much incentive for people not paying to get into the beta program to provide much feedback. Sure, there will be some that will be good citizens and provide Apple useful feedback, but my guess is the majority of people signing up for this will just be looking to get the latest goodies. We've all worked with and helped manage Mac users for years now and we know many of them just want that shiny new thing or new version of something, even if they don't know what it is or what it does for them. I may very well be wrong, but my guess is a huge majority of people signing up here will install the beta releases and then forget about it.
By having even a moderate fee of $99 for the program, it helped ensure those signing up at least had some incentive. While $99 isn't much for anyone with a halfway decent job, its still a big difference from "free" It was just enough to deter those who only had an interest in getting the latest software just for the sake of it.

Also, just to post a follow up, seems MCX does not block the changes to the CatalogURL, which kind of makes sense. Haven't tried it with a Config Profile, but for those of you who have multiple SUSes deployed to different sites, how are you determining which profile and CatalogURL to deploy to your systems based on its location? Scoping to Network Segments? I'm honestly not sure what we'll actually do about this. Reluctant to start pushing Config profiles just for this issue, so we may just ignore it and let users know if they go off the reservation by installing these, we make no guarantee on the health and well being of their Mac, or of any software we install on them.

[Matt]

@mm2270 I agree 100%. By the looks of MR it seems you are correct. People just want the latest and greatest and when its broken they will complain and flood the dev forums with complaints. Beta testing requires some work.

[damienbarrett]

Gotta agree with Matt on this one. I wonder who actually green-lit this Public Seed idea. Surely it wasn't anyone who's spent more than a few days at the front lines of end-user tech support. As much as I'm an advocate for all end-users being admins, I draw the line at giving novices access to unfinished software. It's a tech support nightmare! It's bad enough that OS X has finally been targeted by nefarious crap like MacKeeper, InstallMac, TuneupMyMac.app, and Geneio who all seem to rely on tricking end-users into installing their software; now we have Apple saying, "Hey undereducated end-user, here's some unfinished software we're working on, why don't you go ahead and install it and tell us what doesn't work?"

I mean, what kinds of feedback do they think they're going to get? I can pretty much tell you:

• "I installed the beta and it doesn't work." (nice and specific)
• "The beta broke my 18-year-old AppleLaserWriter's coffee-making hybrid function that I added using Cassidy & Greene's CoffeePrinter Doubler attachment!"
• "Derp"
• "Where did my Internet Explorer icon go?"
• "I updated before backing up and now I want to go back to 10.9.2. How can I do that?"

Not to put too fine a point on it: quality data is better than quantity (thanks Matt).

And I'm awfully glad that I'm not manning the front lines at a Genius Bar during the next few months.

[gregneagle]

"Also, just to post a follow up, seems MCX does not block the changes to the CatalogURL, which kind of makes sense."

No, it wouldn't block the changes.

But Software Update should still ignore them, and use the CatalogURL specified via MCX, if it's managed "Always".

[Matt]

"Could someone please help me! I tried doing this, but I broke my App Store. On my profile, I posted the whole story but no one has replied. I'm desperate to fix it. Please, could someone help me."

Prime example.

[jhbush]

@Matt and @damienbarrett I'm puzzled as well by this considering Apple's other seed programs produce little valuable data at least based on what I read in the forums there.

[scottb]

I agree that it seems kinda crazy. But I was told this, The best thing to compare it to is the “send Apple Diagnostic information”. It gives them a huge pool of data to look for trends. "Trends" can be useful as opposed to dev or seed BR's filed and read by engineers at Apple which provide the "quality" and "detail". But I think it will be short-lived. Once they get calls and visits to the Apple Stores, etc. I believe they will put this one back in the box.

[Matt]

The fanboys are going crazy with "Installed 10.9.3!!!" posts. Good luck with that children!

[jhbush]

external image link

[Matt]

@jhbush1973 - Was its code name Mountain Lion and Lion? LoL

[NowAllTheTime]

I can confirm after more testing today that a device/computer level Configuration Profile will block the beta seeds from showing up in software update. They will continue to be blocked even if a user attempts to run the seed utility again after the profile has been installed

@mm2270 I do have different SUS addresses, and I have buildings/groups/etc. already established to identify the machines that use each one, so I am just scoping separate Config Profiles with each SUS payload scoped to those locations. I have less than a handful to do this for so it's no big deal. I can certainly see how this would be a PITA if you have a dozen or more locations and SUS URLS to scope. For me this actually is a welcome push to get away from using JSS policies to set our internal SUS address (which then could be changed by the user until the next 'once a week' trigger runs). Persistent enforcement with a config profile feels like an improvement over that approach for my environment.

[bentoms]

FWIW, we have some 10 Apple SUS set to clients via Network Segments & all our users are admins.

Luckily we partition the macs with separate User & System data.. so we might leave things as is & just rebuild is someone has an issue with a beta.

Don't want to mess with config profiles setting ASUS depending on nw segment..

[appledes]

Late to the party yes. I was up late thinking about how to block this. I certainly had fun catching up on this thread... especially the testing code in production pic. I am opening a case with Apple to complain as per the recommendation from our Apple Account rep. I think config profiles for devices is the only way here.

[tkimpton]

unenroll i think this may do it

/System/Library/PrivateFrameworks/Seeding.framework/Resources/seedutil unenroll

Blocking the seed can be done with a Config Profile

Apple KB

For the restricted process you can block "Feedback Assistant"

FYI to enroll again for the public seed it is this

/System/Library/PrivateFrameworks/Seeding.framework/Resources/seedutil enroll PublicSeed

to get the status of a machine you can do

/System/Library/PrivateFrameworks/Seeding.framework/Resources/seedutil current

If the Program is greater than 0 then its in a seed. This could be obtained through an ext attribute
and scoped to set it back like

### IS MACHINE ENROLLED TO A BETA OF SOME  KIND? ###

if [ ! -f /System/Library/PrivateFrameworks/Seeding.framework/Resources/seedutil ]; then
echo "<result>"seedutil missing"</result>"
fi

if [ -f /System/Library/PrivateFrameworks/Seeding.framework/Resources/seedutil ]; then
result=$(/System/Library/PrivateFrameworks/Seeding.framework/Resources/seedutil enroll current | grep "Program:" | awk '{print $2}')
if [[ "$result" != 0 ]]; then
echo "<result>"YES"</result>"
else
echo "<result>"NO"</result>"
fi
fi