Jamf Pro 10 Timing Update

Thank you for the update. Better to do it right than to rush a delivery and chase after an endless infestation of bugs.

@deanhager The UI looks great as others have stated, but as someone who works in Agile methodologies and automates as much with infrastructure as we can, handling version control and package ingress ("Simply upload a package") manually is disappointing. I'm hopeful there may be some API features that just aren't easy to demonstrate in a video.

Jamf could really take the lead in package management by creating API integrations with companies like Adobe and Microsoft. Imagine pulling packages directly from Adobe, eliminating the packaging step altogether. You guys have the relationships to make something like that happen.

I do look forward to v10, the users are going to absolutely love the new Self Service. Thanks for the preview Dean.

Let's get this out of the way first: I'd rather your ship a good product than release a buggy one. Owning your projection error is an asset, not a weakness. You are correct to proactively notify customers and prospective customers about this.

I'd be a lot more sympathetic, however, if this were a rare occurrence. I remember when Sites was promised in the next major version of Casper — mentioned openly at the trade fair at a major Mac conference — and that version didn't come for at least a year after that. Patch management was also "coming" for the longest time, and when it was finally released last year at this time, it was very narrow in scope.

It might be time for Jamf to take a more Apple-like approach and not pre-announce features/releases until they are at least at a functioning Beta level. I know at our workplace we waited on moving ahead with certain things — first with patch management, then again with Jamf Pro 10 — that have made us less functional than we should be at this time. We are relatively new Jamf customers, so lack of delivery also leads to lack of lock-in and the increased likelihood that a competitor could come in and take our business from you.

It is certainly in Jamf's best interest to be transparent, but it is also in the company's best interest to not string customers along. Sharing my perspective in the hope that it is useful feedback.

Anthony Reimer

Excellent and thank you for the heads up.

@jake

NICE ONE!!

I'm loving it already :-)

@iaml while I agree with keeping the bugs at bay until something is ready to release, I respectfully disagree on your pre-announcing new features position (focused on the respectfully part) and will also use Apple as my example.

In the K-12 EDU realm, I have four levels of planning and possible maintenance windows in my org:

1. our next weekly maintenance window (we get half an hour to an hour of downtime... which is more than most places, BUT we typically plan very minor upgrades during those times and do not like doing one every week. On average we only use these once a month unless something is just bad.

2. Our next fall break/spring break/teachers institute day. Basically we use these for something that takes more than an hour of planning/implementation (up to 2-3 hours)

3. Christmas break ( we can count on staff/students being out effectively during this time and can do a mid year fix but not a complete overhaul of systems.)

4. Summer break... this is when we prefer to handle major changes to our ecosystem. Though with new state guidelines and summer school programs, this window this year his winnowed down to one month.

Now to get back to Apple... they tend to release their new major operating systems in September/October timeframe. This already breaks our maintenance schedules completely. We've had to learn to deal with them because it is impossible to change their minds. And many times our application software vendors expect us to upgrade whether we want to or not. Then in the spring Apple typically launches new EDU features which come right around spring break but are too late to implement properly until the next summer for the next school year.

In short, the moral of the story for us anyway, we LOVE knowing what is coming even if it doesn't make it into a finished product because we only plan around shipping products/features, not announcements. That effectively gives us veto power over when and what we implement. If nothing else, with pre-announced features, I least come away knowledgeable of how something should work by the time it ships and can plug and chug at the next appropriate maintenance window.

Again I emphasize the respectful disagreement part..your organization may be different and have different needs. Ours on the other hand, the more we know the better.

@iaml, @blackholemac and all Jamf Nation contributors... This discussion is why I love this community. I appreciate your perspectives. Your points are fair and thoughtful. Thank you for helping us get better.

Looks promising. I'm not sure if I miss heard or not, I was hoping that for Patch Management when new definitions were released, it would be able to go and grab that package and have it available (not automatically push, just say it is ready and let the jss admin choose if they want to push). Same concept for showing who is updated and who is not. Just one less step of us having to go out get the package then upload. :)

The new UI looks impressive and Self Service is something our clients will love. The more it resembles the App Store, the better. We've already got our 9.98 Self Service app functioning like the App Store, thanks to IBM. It's more work up front, but it provides a much better user experience.

In response to @sabrina.oconnor, we're working on reducing the number of packages we have to create, download and manage. We're using scripts to curl and install commonly used packages from common vendors. For patch management in Jamf Pro 10, we would really like to see packages automatically uploaded or made available rather than jss admins having to download each package. The video says when a new update is available, simply go download the package, upload it and it will scope. That sounds simple, and it is technically, but it seems antiquated and kludgy now.

@sabrina.oconnor and @ryanstayloradobe - In Jamf Pro 10, the focus for patch management is simplifying the scoping and deployment aspects of the workflow, as well as improving the end user experience. For now, you'll still have to create your own packages and get them uploaded. We'll have a better solution for that in a future release.

@deanhager - here in New Zealand we very much appreciate your approach of fronting up and owning the responsibility of getting our hopes up with regards to Jamf Pro 10. We are looking forward to getting our hands on a robust, feature-complete and polished product when it becomes available. In the meantime, we will be content with testing the betas as we always do!

My own personal preference...

I would always like to wait a little longer for a more stable, less 'buggy release.
We see it so often, when a pre release is available, lots of folk are very quick to point out flaws and rubbish the version.
TOP MARKS to JAMF for your considered approach.

As the old saying goes "All good things come to he who waits"

Evangelism isn't dead.

@deanhager EXACTLY!

@deanhager I appreciate JAMF not releasing version 10 until it's really ready to go, will be worth the wait I'm sure.

No need to apologize...I'd rather it gets done right the first time rather than just rush something out, especially a management program that can mange tens of thousands of Apple devices. I look forward to seeing and using Jamf Pro 10.

Any early indication on whether the API calls will remain the same from 9.9x?

@mrben API calls will remain the same.

Finally install deadlines for policies it appears. can't wait for that.