Posted on 02-04-2011 08:29 AM
I'm curious what this list has to say about my ideas...
Any comments? Questions? Critiques?
Posted on 02-06-2011 03:59 AM
Hi Benjamin,
I must say, I would like to see some future requests coming from your suggestions in Casper Suite.
Only Senior Casper Admin/s would know what packages or scripts to use with what and when...so it makes sense that the senior admin/s creates and sets the access restrictions to the policies for juniors to use with ease to avoid error and complexity.
However I am not quite sure, that this might change suite development and strategy a lot.
Cem
Sent from my iPad
Posted on 02-06-2011 04:37 PM
Add to the list...
Add master/replica redundancy to JSS (currently it's a single point of failure enterprise infrastructure solution)
Add "import" function...ability to import tab separated or csv into a static or smart list.
Add "exclusions" to the list...so we can add Macs to JSS and ONLY pull inventory data (no policies, etc.)
On the granular administration levels side...ability to provide read-only access to all or some of JSS.
Modal dialog box capability...an out-of-box ability to prompt users for input.
Thanks,
Don
Posted on 02-06-2011 06:31 PM
Agreed to all. Specially number 1 is a must-have.
Cem
Sent from my iPad
Posted on 02-06-2011 08:36 PM
I can see the point of different levels of admin access however, if you
only want your junior admins to use Casper Imaging, Casper Remote, and
Recon, then just don't grant them permissions to use the parts of the JSS
you don't want them to, and then just create a package with the basic
utilities? The latter is what I do, because I find it handy to have certain
utilities on our client machines (without a login they don't help you
anyway) but there are some that I don't want the users to even have access
to at all.
--
Christopher Kemp
CNN-BEST Central Engineering
Posted on 02-06-2011 11:02 PM
I spoke to jamf support about replica's a couple of weeks ago they said they'll add as a feature request.
So maybe we'll see it soon!
Regards,
Ben Toms
Posted on 02-07-2011 12:09 AM
I would also like to add a feature that would disable package priority when imaging. I currently have done sort of a hack around using asr scripts for imaging because I want one compiled image to act as a parent item and then have smart configurations on that parent item and be able to do modular package based deployments.
I really don't want to compile 8 different configurations because of packaging differences between users/groups and while my scripts work now with manual trigger policies I would like someday to migrate everything over to Casper in case I am sick, on vacation, or find a new job my co-workers don't look at all my code and just scratch their heads.
Posted on 02-07-2011 12:47 AM
Just to add to the user/admin ideas.
I'd like you to be able to create policies that can be pushed out via casper remote.
like installing office 2011 14.0 then installing the updates. Or cs4 & then the acrobat self heal.
Regards,
Ben Toms
Posted on 02-07-2011 06:42 AM
I would like to see a self replicating database on the back end so you could have multiple instances of the JSS. Just make one parent and then add as many children as you want as read only replicas. That way if you have a large campus deployment, you can set up local JSS boxes and a client won't have to check in across town. I think MySQL can do this, but maybe not. Which would mean like migration to postgre or something else.
As for nested groups, I don't do nested groups anymore. I just simply create groups by what management/policies are needed. Before I created a group for every department and did nested groups and found out that in reality, I only have 4 levels of management, and that I was basically repeating the same thing 50x times just to create nested groups.
I would also like selecting sync services. Not all of our distribution points are on a 3TB RAID 5, so I cannot always sync every package. I would like to group them into categories and set sync rules, or have Casper read the meta data about a package and sync it according to that.
Posted on 02-07-2011 06:43 AM
I agree with you Tom
Criss Myers
Senior IT Analyst (Mac Services)
iPhone / iPad Developer
Apple Certified Technical Coordinator v10.5
LIS Development Team
Adelphi Building AB28
University of Central Lancashire
Preston PR1 2HE
Ex 5054
01772 895054
Posted on 02-07-2011 07:14 AM
Agreed, any changes should only be possible on the master. If the master fails, clients would seek nearest replica (ala OD). A way to bring the master back up without disrupting the JSS infrastructure is a must...promoting a replica to become the new master might not work in some global environments (where you want the master to be in a specific geographical location).
Don
Posted on 02-09-2011 07:40 AM
We would like a feature that sends a notification when and if any replications to distribution points fail. We have ongoing issues with new packages not replicating to some of our distribution points and have to manually check the packages folders on each server to verify that full replication took place. Who knows why it's happening, but if we were notified that replications failed we might be able to get a better handle on why and when they are failing.
Janice Hill
PC Support Manager
Sheboygan Area School District
920.459.4032
Posted on 02-10-2011 10:36 AM
One remark to this I just noticed. You can check the box that says make policy available offline and it will cache to the machine and you do not have to be online to execute policy
Posted on 02-10-2011 10:53 AM
But you still have to be online to cache the policy. For instance, someone who keeps a laptop at home (long-term), and has a desktop at the office, would still need to get updates on the laptop.
On Feb 10, 2011, at 1:36 PM, Thomas Larkin wrote:
One remark to this I just noticed. You can check the box that says make policy available offline and it will cache to the machine and you do not have to be online to execute policy
Posted on 02-10-2011 11:00 AM
Well, no matter what you would have to check into the JSS at some point to cache policy. You can also put your JSS on a public IP and have your clients connect to it over the network. I cannot think of any way possible to do this remotely except if it was online, or you mailed them a DVD of the updates or something.