The only way you could stop them installing it manually would be to block "Installer.app", but then that would mean no installations by the users since Installer.app is used by default when you double click any pkg installer. It can be done by setting that up in Restricted Software, but just wanted to make clear what that would result in.

An even less optimal alternative would be to block the DiskImageMounter process, which is what gets opened when you double click on a DMG. That would also stop it, but might actually be worse since then no disk images could be opened.

Thank you for responding.

So any other updates I want to do, I have to unblock the installer app first.

The problem we are having on are MacBooks is students are updating and we are getting that "Black Screen". I guess it's a bad plist file for the log in window. They sent me a start up key combo and code, but that didn't work, so I'm re-imaging the computers. Im hoping another update will replace that one soon.

If the computers stay on your network a dummy DNS entry would probably be the easiest. Otherwise, if there is a plist problem, have you tried just removing/replacing that plist?

@ahopkins

Regarding the 'black screen at login window' error, do you see a mouse cursor there? We've had a few machines exhibit a problem where they boot to a black screen with a mouse cursor. In our environment we use a Policy Banner at the Login Window, and to fix the issue I SSH into the problem machine and rename /Library/Security/PolicyBanner.rtfd then reboot the machine, it then loads the Login Window normally so I rename the policy banner file back to its original name.

Could this help in your situation?

It may be worth noting that 10.9.5 is required to run Apple's Bash Update 1.0 to patch the recent Bash vulnerabilities on Mavericks.

Although, maybe you have worked around this in some other manner.

Good luck.

It's also worth noting that 10.9.5 addressed a major issue causing Adobe Premiere CC to crash, if that matters to any of y'all. (It certainly mattered to us!)

Do you use a SUS? If so, you could just not enable it there and make sure their Software Update URL on your clients is pointing to your internal SUS only and they won't be able to get it that way.

Otherwise, you could also use restricted software option in your JSS and just block the process for the combo updater package. This is similar method used to block an OS X installer and will probably be used to block the Yosemite installer once that is public and released for free.

You can't block the Combo or delta update installers like that with Restricted Software. When you open those the only process that shows up is "Installer.app" as I mentioned above. Unlike full OS installers which are actually applications with an executable, double clicking a package installer simply opens the installer app, so that's the only process that could be blocked. But any other valid packages that are double clicked on would also be blocked with that method. If its set up to only block "Installer.app" and you enable the option for exact matching, it should ignore the command line "installer" process, meaning scripted installs or Casper Suite pushes shouldn't be affected. (not tested)

Personally though, I would try to address the black screen issue. Its possible a simple PRAM reset might resolve some of those cases. It has for us in many situations. Have you tried that?
Also, are you sure the students are installing the "Combo" update and not just the regular or delta update. The former will update anything from 10.9.0 through 10.9.4, and the latter will only update a system already on 10.9.4.
We avoid installing the latter 'delta' updates because they traditionally tend to be more problematic. You may want to see if the Combo update actually installs OK and doesn't cause the black screen problem. If so, consider actually posting that into Self Service for your students to install. That way you get to control what gets installed and they get to install something they obviously want to install. Otherwise you're really playing a game of whack-a-mole. Since they're able to install it at all I assume they have admin rights on their Macs, which means its really kind of impossible to stop them from installing it if they are determined to.

@mm2270 I stand corrected! ha.

But if using a SUS, that is still valid. Just don't enable it. Also maybe block Apple's support site? You probably don't want your students going there anyway.

Pardon, but may I respectfully ask why we're trying to solve the wrong problem? DON'T BLINDLY BLOCK UPDATES. Test releases, yes. Fix your loginwindow issue by FIXING YOUR LOGINWINDOW ISSUE. There is no strong information(maybe since we've been spending time barking up the wrong tree, the subject of this thread should be different IMO) that your symptom is shared by many others besides the report of a policy banner CAUSING the issue. If you want your login window (ARE you applying management to it?) to work after applying the update, fix it, because it doesn't seem like Apple considers this a bug. If you REALLY believe 10.9.5 is the problem, share your radar number, maybe put it on open radar so others can review your symptoms. This may also be relevant: https://discussions.apple.com/message/25193908#25193908 Sorry to sound harsh, hope this sounds reasonable.
Allister

@Banks,
Definitely reasonable, which is kind of why I suggested in the second half of my last post that I personally would try to solve the black screen issue and also offer the update in Self Service to ensure the proper update is being applied, rather than attempting to block it. I would agree with your assessment that just blocking things because of an initial problem isn't the best approach. I sometimes have a bad habit of jumping in and providing an answer or possible solution without actually stopping to ask what the real need is for the request.

That said, we also have to take into account everyone's individual skill level here. People like yourselves are experienced master technicians and solving a black screen at boot issue is probably like a walk in the park. Same would be true for many folks here.
But take a quick look at ahopkins' profile here and you'll see he's been a teacher for the last 20 years and only in the last year took on a technology role, so he's still learning this stuff. Maybe he was under pressure from teachers and students to prevent the systems from booting into a black screen and it wouldn't have been unreasonable for him to conclude that blocking the update until he was able to spend the time figuring out the issue was the quickest course of action.
I guess all I'm saying is that while I agree troubleshooting and solving the actual problem is best, lets try not to be too harsh and judge those that don't (yet) have expert troubleshooting skills.

@Banks,

It is a valid troubleshooting step to block software (perceived source of problem) to provide time to figure out a problem.

In my opinion, you failed in your attempt to "respectfully" ask.

Hello all,

I agree with some of what @Banks mentioned and I agree even more with @mm2270 point of view.

For most of us, it's all about the environment and the people who you work for. And most of the time, it's all about minimizing the noise and putting out some fires, because that's what the people and the environment are requiring.

Yes, from an efficient and productive IT operation, you would want to fix something well and not rely on a bandage approach... but again, at time, a bandage can give you some breathing room for you to later concentrate and devote time to find and implement that ultimate, best solution.

So, @ahopkins, if blocking 10.9.5 is what would work for you now, go ahead and minimize that noise and put out that fire. Once things settle and there's some calm in your environment, you can concentrate on fixing the "Black Screen" window. Best of luck!

@Banks,
I just looked at it as standard troubleshooting... Start with what you know, then go to what you don't know.

You know that the update is causing the computers to become unusable... So stop the update so you can give yourself some time to explore the unknown... The plist or configuration issue that is causing the 10.9.5 update to blow up the computer. That obviously does need to be fixed, but in the meantime, it's nice to not have a slug of unusable computers so you have some time to investigate the root cause.

The big fix for update management will be to get a SUS in place to be able to control version releases, but the analogy of it's hard to plant trees in the middle of a forest fire seems to fit this case.

So I can take the 'not respectful' and supposedly masterful labels ;) I know I overdid the all-caps, sorry for yelling.
Controlling updates with a SUS is better than blocking updates. Definitively. No hemming and hawing, but no apologies for asking for the actual issue to be addressed. Refining the possible management of settings, fixing the actual problem rather than reflexively reimaging, is another thing that could use reiterating. I totally respect folks directly answering a question when asked(something my significant other gets peeved about) you just all know the experience of having the thing you SHOULD be fixing appear later than we'd like, when we could've been both effective and appropriate earlier on. Especially for beginners, yes, first you have to learn the 'how' of 'fixing', but as soon as possible you need to learn WHY.
Allister

Hi:

Hopefully this will be helpful.

On a test machine you can run

sudo softwareupdate --list

to get a text list of the available software. On my 10.9.3 machine this was the result:

Software Update Tool Copyright 2002-2012 Apple Inc. Finding available software Software Update found the following new or updated software: OSXUpdCombo10.9.5-10.9.5 OS X Update Combined (10.9.5), 959090K [recommended] [restart] iBooksDelta-1.0.1 iBooks Update (1.0.1), 14334K [recommended] JavaForOSX-1.0 Java for OS X 2013-005 (1.0), 65167K [recommended] iTunesX-11.4 iTunes (11.4), 234941K [recommended]

You can then choose to ignore software updates based on the list like this ```
sudo softwareupdate --ignore OSXUpdCombo10.9.5

Now when you run ```
sudo softwareupdate --list

the update will no longer be available. To get the update to show as available again you will need to do the following command ```
sudo softwareupdate --reset-ignored
```

So in theory, in your environment, you could "block" the 10.9.5 update be using the "ignore" flag in the built-in command line softwareupdate tool.

Caveats:

• it's possible if the machines are 10.9.4, the update name may not be a combo update and may be different? Not sure but something to check
• the naming of the updates can be a little strange, for example, the "list" command gives us "OSXUpdCombo10.9.5-10.9.5", but if we ignore with that exact verbiage, the update is not ignored. From the list output I deduced that the ignored flag was probably looking for "OSXUpdCombo10.9.5" and indeed that ignored the update.

@Banks (AKA @Sacrilicious on Twitter) posted:

Pardon, but may I respectfully ask why we're trying to solve the wrong problem?...[snip]...Sorry to sound harsh, hope this sounds reasonable.

Not sure how the JAMF community could think you're being disrespectful towards them?

Twitter...

external image link

IRC...

external image link

We temporarily used the ignore method @bbyleen mentioned to ignore the 10.9.3 update because it was released at a time when we had other critical issues happening, and our help desk was overwhelmed with calls. Because this update was causing the "black screen with cursor on boot" issue for many users, we wanted to limit the number of users impacted because there was no way they were going to get it resolved quickly.

There are completely legit reasons you may want to block certain updates temporarily.

The "classical"/recommended/supported method to control which Apple updates your clients are offered is to run your own Apple Software Update server, either Apple's via OS X Server, or Reposado, or JAMF's NetSUS appliance (which contains Reposado).

This allows you to filter certain updates from being offered to your managed clients. More importantly and usefully, with Reposado and NetSUS you can release updates first to a group of testing users/machines, and later make those same updates available to your fleet in general. This allows you to test updates (or at least limit the damage/find issues) before they affect all of your machines.

If you are also concerned about users manually downloading the updates directly from support.apple.com/downloads and manually installing them, I'd recommend one of two approaches: 1) communication, and/or 2) Don't give those users admin rights.

@gregneagle][/url I think the challenge in some environments, at least some I've seen, is the teams responsible for managing the Macs are unable/unwilling to take away admin rights. So users can/do download updates. But you nailed it, if you can control (vet) the updates, the problem goes away.

[EDIT: Not the OP's problem, obviously]

Lot's of good post! I was training today and didn't check this feed:

We do not have an SUS.. I didn't SSH in, can I do that with ARD?
Apple's directions:

on power up hold down "Command" & "S"
After the text stops, write the following:

mount -uw /
cd /Library/Preferences
mv com.apple.loginwindow.plist com.apple.loginwindow.plist.old
reboot

Today I restricted the Installer.app, no more reports of this. I haven't addresses the issue today, no time.

Thanks for all the great responses!

Well, it doesn't completely control the problem @donmontalvo. The OS X updates (and anything else really) are readily available for anyone with a browser to download. If they have admin rights, its an easy bypass to get and install the update. Blocking it in SUS helps, but isn't a guaranteed way to stop it. And yes, taking away admin rights rarely turns out to be that great of a solution in most cases. In some cases, its simply not even an option.

I would however, second the notion that communication is critical. If we run across an update that we are seeing or suspect issues with, in addition to not enabling it in SUS, we also issue an official "IT" statement on a community board read by lots of clients that we are asking users not to install the update until we've had a chance to properly vet it and approve it. Not every environment has this mechanism of disseminating a notice to everyone, but if not, it would be a good idea to push for that.
To that end, the OP should really be getting a notice out to his students that installing the update at this time might end up causing their Mac not to boot properly. I don't know many people that intentionally want to cause a problem for their Mac unless they are gluttons for punishment.

Then again I don't work in a school.... :)

@mm2270 Point taken, that's sort of what I meant to imply...did a lousy job. :)

Well, it doesn't completely control the problem @donmontalvo.

1. Admin rights = all bets are off
2. SUS = vet updates

#1 is a must, or #2 is moot.

I'll get my act together when I down that first JNUC 2014 beer. :D

Don

So wise allister.

Didn't @Banks present at a NYC JAMF User Conference meeting a few weeks ago?

http://osx.michaellynn.org/freenode-osx-server/freenode-osx-server_2014-10-03.html

external image link