"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.

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.

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.

@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.

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.

"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".

"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.

@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.

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.

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

external image link

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

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.

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..

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.

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