Why I chose this:
Education-specific sessions are few and far between, so I picked this one.
What was covered:
Statewide hosted solution with every higher ed institution in the NC system under a single Casper instance.
17 schools plus UNC general admin system.
How can they leverage the system to allow common operation across all systems?
Right Time
Decreased budgets
Taste for streamlined licensing
Desire to not reinvent the wheel (shared packages, etc)
Increased demand for Mac and iOS
VPP and DEP
UNC System handles AD, LDAP, packages, etc.
Use Sites for each school so folks aren't stepping on each other's toes.
Hosted JSS and local JDS
- Best of speed and cost
- Auto sync of the JDS
- Someone else (mostly) does infrastructure
- Allows smaller groups/institutions easy scaling
- Each group maintains security via LDAPS
Admin team does very little work, then hands-off. Can be done on group-level (ex: School of Journalism) as opposed to ONLY the school at large.
The Good
- It works!!
- Shared work packaging and scripting
- Read-only policies for examples
- Communities form group help/Crowdsourcing - need a peer-review system for vetting
Challenging
- Migration from local Casper to Shared Cloud
-- Take time to clean up JSS.
-- Rebuild the JSS
- Web-only interface (takes time getting used to it)
- Casper Admin limited to read-only (take away delete permission wholesale, can change things)
- Politics of LDAP/AD access (run through governance body at university level; takes time to work through admins etc. Help them understand - https, read-only, which ports, etc)
- Technical details of secure LDAP/AD access (self-sign certs, where is root, etc)
- Packages without licenses (who is responsible for licensing? Spell it out. Make sure you have rights to share, etc)
- Change management - get into logs, check details
- Political policies to promote good neighbors (shared section, so had to set/enforce naming conventions with packages and scripts, etc.)
- Shared GSX and APN accounts (who has it? Who is logging in to check? That is global in JSS, not a site setting)
- Disk encryptions are not site specific. Make sure security folks understand it is a shared model
The Bad
- No concept of site for: Categories, packages, scripts, printers, directory bindings, dock items, configurations, and self service plugins. Must plan scope of work, naming, etc.
- Network segment collisions (NAT, subnets, etc)
- Needed prefixes to avoid confusion (naming conventions)
- SCCM Plugin not support (*multiple SCCM could be supported, but who rules the roost on that one!?)
The Cost to Join
- 10 Licenses for either OSX or iOS devices to have their own Casper Site Setup
- Secure (ldaps) access to supported directory site for group of Casper Site Admins
- Firewall changes (443, 636)
- Internal Netboot and/or SUS servers (not provided, must be local)
- Internal JDS (optional, but recommended)
- JAMF training (optional, but recommended)
- Can request packaging rights (create a Directory Service group, which would be added)
- Can request to member of UWCA (Admin) team
- Can request access to APIs
Q&A
How many sites and who are site admins? 41 sites/subsites, don't care who the local admin is so it varies. Purchasing dept adds admin(s) to directory service group.
Packages: Sites can upload packages. Cannot delete packages without requesting from the overall admin.
Security info stored in JDS. Each institution evaluates what they can/cannot store in the cloud.
How about non-Apple devices? At certain sites, use SCCM locally. Not big demand for Android support. Planning for future implementation. Right now, polices and best practices.
Created a template license and got it approved by Attorney General for use among all participating entities.
Easier for schools to come on because they are not installing all the backend.
Helpful to set up a 'kick the tires' account for schools to test the system and see if they want to join.
No comments:
Post a Comment