We tried to get @gregneagle to speak at JNUC2014. Your's truly offered to walk on stage in a tutu, introduce him, and walk off stage, stoping to curtsy along the way. Such a golden opportunity and he declined (OMG THANK YOU!!!). 😉
Posted to IRC today:
Direct link to image: http://donmontalvo.com/jamf/jamfnation/IRC/valid-constructive-criticism-01.png
external image link
Direct link to the relevant feed: http://osx.michaellynn.org/freenode-osx-server/freenode-osx-server_2014-06-18.html
A couple years ago we had a JNUC session where JAMF sat with some of the large clients and discussed the upcoming version, and what we wanted/needed in the new version. I came prepared, suggesting (1) exclusions and (2) ring fencing. Both requests made it into JSS 9 (as exceptions and sites).
I really hope JAMF does the same at JNUC2014, so we might finally get new patch management functionality in JSS 10. Whether it's something simple like adding is equal to or greater than to Smart Computer Group criteria (not sure that would be reliable in all scenarios), or some other way of determining if an installed piece of software needs to be updated.
@loceee's Patchoo (gesundheit!) got a lot of attention, as it showed, at least conceptually, what might be possible if JAMF could dedicate some time/resources...:
Hello junki! Casper patching done right!
...and it stirred up a lot of discussion; if you're not already on the ##osx-server IRC channel, do yourself a favor and join. Scroll to the bottom of:
Don't miss @tbridge's excellent IRC article:
The more attention this gets, the greater the chances JAMF might pull this off...hopefully without anyone needing to parade around in a tutu at JNUC2014.
The Mac team at Oxford devoted early 2015 a bit of time to develop our own solution. Our goal was to remove the software deployment and updates entirely from the Casper Suite and facilitate a more advanced autopkg + Munki workflow.
As a result we built a bit of middleware (aka glue) to enable inventory information in the JSS to be used to manage Munki clients. Our solution integrates nicely with all tools of the Munki ecosystem: one can use autopkg, MunkiAdmin, MunkiWebAdmin, munki-staging, and all the other great Open Source software out there.
The code is in production in our environment since mid 2015. We are actively maintaining the code, but our focus are still features. So please forgive us not having spent time on a nice UI. Currently one has to rely on the code generated Django admin interface.
I find it important to highlight that this is not a solution for the part-time admin. Migrating all software packages from the JSS to autopkg+Munki takes a bit of time. However, the gained amount of automation dramatically reduces the error rate and potentially frees up resource for other enjoyable development work.
We would be interested in feedback and comments. Bug reports and pull requests are obviously also more than welcome.
I would also like to point out that, this is no longer the right way to manage software on Mac OS X...
With VPP device-based app assignment, we should force our software vendors to use the apps store. If it's not in the store and the vendor won't supply a VPP code then it shouldn't be on the Mac, or in your build.
Apple and it's MDM vendors have built/are building a software delivery and update infrastructure that will be many time more robust than anything we alone can build.
I agree with @gachowski to a point, however, Office 2016, SEP, Firefox, Flash, Java, Chrome, Silverlight, and I am sure the list could go on for many many more lines of things that many of my customers have to have in order to work are still not there. And lets not even start on how painful registering for VPP and DEP are in very large organizations. While its likely the future, its one that is not awfully close would be my best guess, at least until Apple closes the door on OS X merges it with iOS or limits it to the point that iOS is and then will it really matter?
If it's not in the store and the vendor won't supply a VPP code then it shouldn't be on the Mac, or in your build.
I have to disagree. We use plenty of software that's not available in the app store and I am perfectly fine with developers not wanting to fork over 30% to Apple or be limited by restrictions imposed on apps that are available there.
Just to push back a little : ) I think if you look far enough down the road and I am thinking two years..... software not following restrictions imposed on apps in the apps store are going to be consider a security risk.
PS I am also about 50% sure that you can do B2B apps and Apple won't take 30% but I couldn't find any documentation on that..
PSS We should be pushing Apple to about that 30% if that is a road block for the developer.
I think if you look far enough down the road and I am thinking two years..... software not following restrictions imposed on apps in the apps store are going to be consider a security risk.
I can definitely see that being the case but there's a lot of apps that do cool stuff that violates Apple's policies. One example I can think of is Audio Hijack. It's a great little app that allows you to quickly and easily record audio from any app. The developer's website says they don't offer most of their apps in the app store because they violate Apple's policies. I'm still more than happy to take my chances and trust them because I find the app to be useful.
PSS We should be pushing Apple to about that 30% if that is a road block for the developer.
I'm fairly certain that's one of the major reasons large, established companies like Microsoft don't sell software on the App Store. They are more than happy to give away free software there but they will sell millions of copies of Office regardless of where it is available so why would they just give that money to Apple?
I never said that JAMF said they can't do it. I asked the question why can't they do it. They have the engineering resources and the money, what's stopping them?
A couple of guys at Oxford got it done in a few months
JAMF first announced they were "working on it" in 2014
Theres been a feature request for better (any) patch management since 2012.
It's now 2016..... and still nothing from JAMF
@gachowski Lol been hanging out with Miles?
There are an untold number of pieces of software that need to be installed on machines that are not and will never be available in the App store. Just because YOUR environment doesn't use these titles or is able to get buy without them doesn't mean others are. Microsoft looks like its making the right moves to get onto the App Store. Thats great. But do you think Adobe are ever going to get there? Nope. They don't even use Apple PKG's! Atleast Office has been using PKG's for years.
To say that the only way to get software is through Apple' App store is crazy. Have a look at the AutoPKG recipes, there's hundreds of pieces of software that people use every day that is not available on the AppStore or admins wish to manage the version and update cycle of that software themselves. Do you know of a method to control the version of app updates via the MAS? How about a prod, pilot, dev branch style management of app updates? Or do you assume that every app update will be fine and won't break anything and thus no vetting of application updates is required. The old "if its on the store its good to go! attitude"
There are also a whole lot of environments where MDM and VPP can't work due to network configuration and corporate policies. Take the blinkers off, use some imagination. Think outside of your own environment.
As for MS not being able to provide VPP or office, actually yes there are a number of reasons that they are not on the App store yet. If you like, jump on to the Mac Admins slack and read up, Eric from MS (PM for Office) outlined the issues they currently have. They are working towards it but it is still a while away.
There are an untold number of pieces of software that need to be installed on machines that are not and will never be available in the App store.
I'm sure Apple will keep clamping down on security. But it'll be some years before the long-in-tooth companies go out of business because they're too cheap to hire capable/competent coders to get their product(s) for the App Store.
Sketch left the panacea of the all mighty Apple App store for a reason, surely the 30% cut played into that.
Regardless, I agree it's disheartening my original feature request was from 2012 with virtually no (public) movement since. In that time, Autopkg made things much better for us admins. Autopkgr and JSSImporter improved on that...and now what the team at Oxford has done - with crickets from JAMF.
I am sure they regret announcing patch management in their 2014 JNUC. I'm glad it was mentioned by the CEO at JNUC 2015 that they're getting it right (surely they don't need a PR disaster if it is bug filled), but I sure hope we at least get a beta before 2016 JNUC.
Do I agree with the CEO that I want it done right? Sure... but my renewal to JAMF is not chump change... it's getting to be a harder pill to swallow as the months go on and open source is solving the problems my JAMF renewal isn't.
@gachowski why would you talk in such absolutes? just because apple says one thing and prefers one thing does NOT mean that's the only way, should be the only way, and is the 'correct' way to do things. this extends beyond deploying software. anyone that thinks so needs to lay off the kool-aid. there are many ways to deploy software and depending on the environment there may be methods that are better suited based on the needs of the organization.
In fact I'm just going to quote someone else here:
I'm weary of anyone who declares absolutes in any scenario or rule. The precursor to these claims usually is something like "I can't think of why anyone would want/need..". The words never, always, phrase 'can't think of', etc show a lack of imagination more than anything.
@donmontalvo no one is going out of business because they refuse to join or drop out of the mac app store. unless apple suddenly decides that apps that aren't from the mac app store cannot run in which case you will most likely see 1) a lot of vendors look to make their products available on other platforms if they aren't already and/or 2) cripple their current software to work within the confines of the MAS policies.
@CasperSally Sketch left because they couldn't introduce the features they wanted while still following Apple MAS policy. I'm sure the 30% played a factor too, but it wasn't the only reason. make of that what you will.
As for JAMF, I suspect it maybe has gotten harder to implement feature requests and keeping up with the yearly OS releases for both OS X and iOS. Just look at 10.11 and iOS 9. It's taken from 9.80 to 9.82 to add support for most of the new features that Apple introduced with those OSes. And it makes sense that JAMF would focus on these as Apple is a big customer as well. Just sucks for the rest of us as we're left waiting for non-MDM/DEP related features to finally get introduced (patch management being one of many in a long list).
Anyways, I think the Oxford project is rather cool and is just one way to approach the issue. Why not have the best of both worlds? Use the best tool you can find for what you're trying to accomplish (or adapt it or make your own).
Count me in on the long list of folks waiting (and waiting) (and waiting) on non-MDM/DEP related features. And bug fixes...
I get that Apple/JAMF are trying to shore up their mostly EDU focused new features, as Google Chromebooks have kind of been eating Apple's lunch in the classroom. That being said, us non-EDU customers pay significantly more for JAMF licensing and have not really seen much in the way of new features. Some reporting and administration feature requests have been open for 4+ years without movement.
I asked the question why can't they do it.
But they are doing it...why are you asking why they can't do something that they are doing?
A couple of guys at Oxford made it work in their environment in a couple months...that's a far cry from implementing a robust feature in JAMF that will work for (most) everyone.
Business case and all aside, I think it's important to recognize the fact that properly built and secured applications do and will exist completely separate from the MAS. So far as they've got a signed package and no big security holes, I'm A-OK with many types of distribution.
Now, I applaud the work of the various teams and individuals pushing this cause (patch management) forward. Here's to holding a beer in salute of friendly and functional patch management in all of our futures (Yes, the folks successfully using Autopkgr/Munki, etc can snicker). Yet this work will continue to push JAMF and other companies (hopefully Apple) to create robust, friendly and trustworthy solutions. It's the TRUST that I need. While I know that very serious effort and thought went into all of those aforementioned projects, I haven't put any of the existing solutions into production as they require quite a bit of supervision on my part and, because they do, the convenience simply never resolves for me.
@seanbalsiger has the right of it I think. Whatever JAMF put's out, it's going to be pounded not only by all of us, extra large enterprises like IBM/CISCO but by every tech that's gone through a jumpstart and just wants to set it and forget it. I'll agree though. Touting it in 2014 was probably a mistake. At least we know that they're working on it but the clock did start ticking at JAMFs own mention of the project. I do wish that we had a little more of a road map.
I like absolutes, to prove my points : ) I'll go back to that thread that you quoted and quote myself because it's this is the same argument. Keep doing management/security the way it's always been done or move to improved ways...
I am interpreting what you are saying is that that "Organization with heavy hardening requirements" are better at securing the Mac OS than Apple. I think when you say it like that it super crazy... I am not saying Apple is right all the time, but they are better than most orgs. C PS For you sports fans.. it's skating to were the puck was in 1902 not were it is today or tomorrow...
The Mac admin community is full of people still trying to manage the Mac like Windows/the old way and is down right crazy. If you are happy just doing management/security the way it's always been done, that is fine but, I know that we need to push the community to do better.
As much as it sucks, most managers/CIO/CISO don't want to do anything out of the normal so unless we talk about change and and take the risks like Facebook, IBM and Apple push the envelope nothing will get better.
I would also like to point out that doing the same things as those very big and important companies is really not that much risk.
Apple's closest thing to a road map is the newest most beautiful powerful yet, wonderful operating system will be available this fall. Good luck on getting any hardware road map out of them. Therefore, I find JAMF's patch management will be available when its ready to fit quite perfectly in the ecosystem. I just think more time is wasted discussing easier ways of doing patch management than it takes to do it personally.
Just wanted to let you all know that as of the Casper Suite 9.93, we have added some initial patch functionality for 34 supported third-party titles. For each of these titles, you can get automated compliance reports, notifications for available updates, and easier patch scoping. (See https://jamfnation.jamfsoftware.com/featureRequest.html?id=224.) Look for additional supported titles and expanded patch functionality in future releases.
Hey @davidacland, check out the "Patch Reporting Software Titles" section of the 9.93 admin guide. It's largely Adobe titles, web browsers, Microsoft Office titles, Java titles, and a couple anti-virus titles. We based the list off of feedback from Casper Suite admins, and we're looking to continue getting that feedback as we expand the list!