JSS 9.31: Recon "There was an error creating resources on the JSS" error when VNC'ing

[donmontalvo]

We recently migrated fro 8.73 > 9.31 and one of the minor issues we ran into is our techs who are trying to control a remote Mac with Casper Remote is getting "There was an error creating resources on the JSS" errors.

Looks like there is already a thread about the error, but slightly different in that the tech is trying to push a policy:

https://jamfnation.jamfsoftware.com/discussion.html?id=8235

In our case, techs are set up using "Auditor" role as a template, plus the following Casper Remote rights...are we missing anything?

external image link

[were_wulff · Accepted solution]

@donmontalvo

After doing some peeking at past cases with that error, it does look like it’s a permissions based error, so we’re on the right troubleshooting track.

My first question, just for verification, is does the error pop up when they initially try to control or screen share or when they try to do something after getting the remote control going?

If it’s after, what is it that they’re trying to do?

In the linked thread, it looks like they were attempting to push packages via Remote, which requires the Create privilege for Policies since deploying packages or using Casper Remote is technically a policy but instead of it being saved in the JSS it is instead never saved; it’s sort of like a “temporary” or “one off” policy in the JSS’ view.

I did notice that, without the permission of “Screen Share with Remote Computers Without Asking” it wouldn’t start until, on the remote computer, I clicked ‘Allow’ on the dialogue box that popped up. If I clicked Deny, or just let it sit for a few minutes and time out on its own, it failed.
Is it possible that’s what’s happening on your case?
We can easily check by granting that permission or, if you’d rather look at log files, it will show up in the jamf.log on the remote client; if permission was denied the jamf.log will show a message that specifically says “Permission denied by user for Auditor” (Auditor was the account I set up to mimic your Auditors’ permissions).

Amanda Wulff
JAMF Software Support

[were_wulff · Accepted solution]

@donmontalvo

I wish I could say I'd never had to do that in the past to get something that looked right but wasn't working right to work after a big upgrade, but, I have; I once had an admin account missing random admin rights despite the boxes being checked. Doesn't seem to be any rhyme or reason as to why/when it happens, and I haven't ever been able to reproduce it on demand, which makes it tricky for Dev.

Setting up permissions for an AD group could be a solution for that, though the only thing to watch out for would be users who may be in multiple AD groups; they'll get the most restrictive set of group permissions applied to them which could be a problem in some scenarios.
However, just for full disclosure, D-006815 is causing that to not work right at the moment, and it's not enforcing the most restrictive permissions as it's supposed to; some environments may like that, but it's completely unintended behavior and is in "Planned for Release" status so hopefully it'll be corrected soon.

Amanda Wulff
JAMF Software Support

[donmontalvo]

Here is a screenshot of the error:

external image link

[were_wulff · Accepted solution]

@donmontalvo

After doing some peeking at past cases with that error, it does look like it’s a permissions based error, so we’re on the right troubleshooting track.

My first question, just for verification, is does the error pop up when they initially try to control or screen share or when they try to do something after getting the remote control going?

If it’s after, what is it that they’re trying to do?

In the linked thread, it looks like they were attempting to push packages via Remote, which requires the Create privilege for Policies since deploying packages or using Casper Remote is technically a policy but instead of it being saved in the JSS it is instead never saved; it’s sort of like a “temporary” or “one off” policy in the JSS’ view.

I did notice that, without the permission of “Screen Share with Remote Computers Without Asking” it wouldn’t start until, on the remote computer, I clicked ‘Allow’ on the dialogue box that popped up. If I clicked Deny, or just let it sit for a few minutes and time out on its own, it failed.
Is it possible that’s what’s happening on your case?
We can easily check by granting that permission or, if you’d rather look at log files, it will show up in the jamf.log on the remote client; if permission was denied the jamf.log will show a message that specifically says “Permission denied by user for Auditor” (Auditor was the account I set up to mimic your Auditors’ permissions).

Amanda Wulff
JAMF Software Support

[donmontalvo]

Hi @amanda.wulff, I deleted both accounts and cloned an account that we knew worked, error went away.

After doing some peeking at past cases with that error, it does look like it’s a permissions based error, so we’re on the right troubleshooting track. My first question, just for verification, is does the error pop up when they initially try to control or screen share or when they try to do something after getting the remote control going?

The tech was able to launch Casper Remote, and to select the Mac he/she wanted to connect to, the error came up when the tech hit "Screen Share".

If it’s after, what is it that they’re trying to do?

They weren't able to get past the error.

In the linked thread, it looks like they were attempting to push packages via Remote, which requires the Create privilege for Policies since deploying packages or using Casper Remote is technically a policy but instead of it being saved in the JSS it is instead never saved; it’s sort of like a “temporary” or “one off” policy in the JSS’ view.

Probably unrelated, since techs are trying to remotely control.

I did notice that, without the permission of “Screen Share with Remote Computers Without Asking” it wouldn’t start until, on the remote computer, I clicked ‘Allow’ on the dialogue box that popped up. If I clicked Deny, or just let it sit for a few minutes and time out on its own, it failed. Is it possible that’s what’s happening on your case?

In our testing one tech was remoting in to a test Mac that we had just built. The error prevented Casper Remote from attempting to connect.

We can easily check by granting that permission or, if you’d rather look at log files, it will show up in the jamf.log on the remote client; if permission was denied the jamf.log will show a message that specifically says “Permission denied by user for Auditor” (Auditor was the account I set up to mimic your Auditors’ permissions).

I'll check the log to see if I find anything, hopefully I can remember the date/time the problem occurred. Hopefully it was just a hiccup. :)

It would be nice if we could set up account templates, but I guess the best route would be to set up permissions and assign to an AD group, we'll look into do that.

Thanks,
Don

[were_wulff · Accepted solution]

@donmontalvo

I wish I could say I'd never had to do that in the past to get something that looked right but wasn't working right to work after a big upgrade, but, I have; I once had an admin account missing random admin rights despite the boxes being checked. Doesn't seem to be any rhyme or reason as to why/when it happens, and I haven't ever been able to reproduce it on demand, which makes it tricky for Dev.

Setting up permissions for an AD group could be a solution for that, though the only thing to watch out for would be users who may be in multiple AD groups; they'll get the most restrictive set of group permissions applied to them which could be a problem in some scenarios.
However, just for full disclosure, D-006815 is causing that to not work right at the moment, and it's not enforcing the most restrictive permissions as it's supposed to; some environments may like that, but it's completely unintended behavior and is in "Planned for Release" status so hopefully it'll be corrected soon.

Amanda Wulff
JAMF Software Support

[donmontalvo]

@amanda.wulff Thanks, I think D-006815 is the reason we haven't implemented groups so far with JSS access rights. All in all, not a very disruptive upgrade, far smoother than previous. :)

PS, I went back and responded to the individual questions in your last post. Thanks for all your help, invaluable! :D

Don

[were_wulff · Accepted solution]

@donmontalvo

What they were seeing is certainly a bit stranger than what I was seeing; good to know cloning/recreating the accounts cleared it up.

With mine set up exactly as yours, it took awhile for it to error out if I never clicked 'Allow' on the screen share, but it never did pop up that particular dialogue box.

If you notice anything odd any of the jamf.log files, let us know; it may give some insight as to what went wonky with the accounts, if nothing else.
It's also possible that something might show up in the jamfsoftwareserver.log around the same date/time, so that could be helpful as well.

Thanks for all your help, invaluable! :D

No problem! I've always kind of wanted to see more JAMF support involved in threads here, especially when there's something that also has an open case going at the same time, when possible so--why not do it myself when I have the time and (hopefully) answers? :)

Amanda Wulff
JAMF Software Support

[donmontalvo]

@amanda.wulff It's always good to have your fingers on the pulse of the JAMF community. :)

[scottb]

@donmontalvo: Sorry man, but I saw this today when MacUpdate finally announced Casper 9.32. Thought it was funny - being from 2009 and all ;)
Don't hate me...

reviewed on 03 Nov 2009 I feel compelled to comment here. JAMF is a tool purchased by one of our clients. I'm resistant to tools that replace the standard Apple toolset. For example, packaging, MCX settings, etc. That said, JAMF is simply building on the existing UNIX toolset, and thus leveraging the power of OSX...while providing a centralized GUI and services for central management. Essentially, they're making better use of the standard toolset, and adding layers of additional functionality to what already exists. I'm impressed with JAMF. I wasn't at first, mostly because I didn't see a need for a swiss army knife tool, since there were other proven solutions (Apple's native tools, LANrev, Filewave, etc.). I've slightly changed my opinion in the past couple months. If your company or client wants to spend their money on a Mac-only solution that does everything short of washing your dishes, go with Casper. You'll be extremely happy at the level of control you'll have at your finger tips. If your company or client intend to cut costs and thus implement cross platform solutions, go with LANrev, LanDesk, Filewave or some other cross platform solution. You won't get as much flexibility as you get with Casper, but you'll be able to manage your Mac environment without additional headcount or platform specific tools. It's a great tool, but the decision boils down to money and support model. For best of breed, it doesn't get better than Casper. For cross platform, LANrev is leading the pack. Don Montalvo, TX

[donmontalvo]

@boettchs Yea that was when a big multimedia company farmed out their Mac environment (2,000+) to our company. I didn't have much exposure to it, so didn't think the other solutions got a fair chance. It's amazing how opinions change over time. ;)

[donmontalvo]

@amanfa.wulff so today out we figured out the tech was hitting ENTER after selecting the Mac in Casper Remote. Instead of hitting "Share Screen". That was the cause of the error. Once he knew to hit the right button the problem went away. So I guess we can chalk this up to a GUI/usability issue? :)

[scottb]

@donmontalvo: Sometimes I venture back to a forum and read things with my name on them and I swear I can't recall saying them and it doesn't "sound" like me. Funny stuff...but thank god we do change!