03-31-2022 03:14 PM - edited 04-02-2022 11:07 AM
Hosted Region | Begins | Ends |
ap-southeast-2 | Apr 3 at 1400 UTC | Apr 3 at 2300 UTC |
ap-northeast-1 | Apr 3 at 1500 UTC | Apr 3 at 2300 UTC |
eu-central-1 | Apr 3 at 2000 UTC | Apr 4 at 0600 UTC |
eu-west-2 | Apr 3 at 2300 UTC | Apr 4 at 0600 UTC |
us-east-1 sandbox/us-west-2-sandbox | Apr 3 at 2230 UTC | Apr 4 at 0830 UTC |
us-east-1 | Apr 3 at 2300 UTC | Apr 4 at 1200 UTC |
us-west-2 | Apr 3 at 2300 UTC | Apr 4 at 1300 UTC |
Posted on 04-01-2022 10:01 AM
@kaylee_carlson - Thank you. Question: should the cloud instances be on 10.37.0 now? I must have missed something as mine are on 10.36.1?
Posted on 04-03-2022 11:12 PM
FYI - When you suddenly change your upgrade schedule from a Saturday to a Sunday with a 13 hour window (us-east-1) that REALLY screws up those with global workforces in APAC/APJ and EMEA! The April 1st comm says "no evidence of any direct risk to our products" and the April 2nd update doesn't say anything besides including a new Spring framework. If your product is not affected then why suddenly reschedule to a Sunday night?! 🙄 If it is/was affected that should be made known, otherwise couldn't this have wait until next Saturday?
Posted on 04-04-2022 07:54 AM
To bounce off of what @brunerd stated above, I'd like to get a more direct statement from Jamf if this upgrade actually addressed a vulnerability in the Jamf Pro product, or if this inclusion of the new Spring framework was done as a precaution only. IOW, how critical is it that we upgrade post haste? We really need to know these things so we can schedule our upgrade accordingly. And I'm not asking if we should or shouldn't upgrade at some point. But it's the difference between a standard change and an emergency change for many organizations and there is a big difference between how those 2 types of changes are submitted. For the latter we often have to provide direct evidence of the need for such an ECHG, usually something from the vendor. Can you help us out here? Was Jamf Pro affected by this or not? It's just so unclear. Not what I expect from a leader in the industry.
Posted on 04-04-2022 06:42 PM
Found with the new version, when I click on the caret to expand a policy, if a script is the first or only thing to be listed in the detail, the policy doesn't really expand to show the detail. There is a thin darker line that underlines the policy, and when I click the caret again the dark line goes away, but the policy never displays the details. Now if it starts with a pkg or a Run UNIX command, it will expand, but no scripts.
Posted on 04-06-2022 08:39 AM
Didn't even see this, but I don't use that all the time. Confirmed, but not in all cases. As below, it's showing the problem. Only the package shows in the drop-down view:
Posted on 04-15-2022 07:06 AM
I can confirm I have the same issue.
04-15-2022 07:28 AM - edited 04-15-2022 07:30 AM
I can confirm as well. I just updated our test Jamf environment to 10.37.2 and I'm seeing similar behavior. It seems to happen on policies that just have a script as the payload as mentioned. Odd bug. It's not a showstopper, but it would be nice to see this get addressed since it seems like a silly issue.
Just to add: I have a decent amount of policies that ONLY have a script in them, so for me this problem is quite pronounced. I'd say around 65-70% of my policies aren't expanding in the main policy view.
Posted on 05-24-2022 12:45 PM
Yep, we're seeing the issue too. I don't see it as fixed in 10.38.0 or 10.38.1, so figuring the dev team are still working on getting it fixed yet, not urgent for us.