Multi-context JSS versus multiple single-context servers

[spyguitar]

We're an MSP adding Mac management to our product portfolio. We have several existing clients who are interested in having us take over management of their Macs. I've just started playing around with a multi-context JSS to see if it makes sense to use one multi-context JSS, with each client having their own context. We also have our own bare-metal cloud hosting, so spinning up new VMs to host individual, single-context JSSs per client is trivial from a time and cost standpoint.

Are there significant advantages, in this case, to going down the multi-context path?

[blackholemac]

It really boils down to resource allocation on whatever you are hosting it on and whether you are comfortable using a manual install vs the official provided installers.

For instance if storage is at a premium in your world, a multicontext environment is good as you wouldn't have to have the OS installation for multiples taking up space. I would also consider your backup requirements for clients. I will note that JAMFCloud is multicontexted when they host for clients. Also consider uptime requirements...a multicontexted is a single point of failure for multiple client tenants.

In short after you taking a careful stock of the hardware available (VM or physical), client requirements and taking into account who is administering, you can make it go either way.

Multicontexted environment definitely requires a manual install...also note who gets to apply updates to Casper? Can you teach that person how to properly apply them?

Lots of things to take into account...I will give a plug for the CJA class...it gave me a whole new perspective on how to host for differing sets of client requirements/hosting platforms.

[spyguitar]

Kind of my thoughts as well. Storage isn't at a premium, and having a single point-of-failure makes me nervous. Much rather have one client go down than all of them!

I certainly plan on taking CJA - once time and money permit...

[blackholemac]

If physical or virtual resources are totally unlimited, including storage, about the only weakness you'll run into is having the monitor up versus down on multiple servers and maybe not having total optimal use of storage. If you are going VM you still have a single point of failure anyway really. Having multiple MySQL boxes might stink too. We actually separated the SQL part onto its own box to improve communication speed.

I still am plugging CJA but can relate to budget issues. I can get training budget but hardware and storage is my pinch point. Time wise, it's an excellent investment.

Feel free to share your deliberations in detail as you go toward building this up. There are many ways to go about it. In my case I went multi-context but have add clustering and load balancing to the web instances. I did put a web instance on the SQL server but it doesn't get directly hit by clients checking in.

Finally in terms of security...if you use the JSS Installers consider hand tweaking your SQL grant commands and user passwords and running mysql_secure_installation.

[spyguitar]

I've decided, at least for now, to go with multiple VMs. One thing I'm wondering about, though: is there a good way to replicate certain parts of an existing JSS config to a new server? I've got packages covered, as all servers are pointing to a single file-share distribution point. However, we have scripts, policies, and config profiles in place, many of which are needed at all of our clients. It'll rapidly get quite tedious having to rebuild all of these by hand every time we spin up a new server.

[blackholemac]

Very good question...my initial gut says API, but quite honestly, API is probably my weakest area. As for config profiles, those are totally exportable, but importing them in by hand sounds like a joy (again...someone with more knowledge may know how to do that with API...same with policies and scripts. Luckily I only have two servers to manage so it isn't too bad. I would like to hear about how you ultimately do that as I strive to learn where I can. I would guess some of it could probably be exported from MySQL but again, check in with someone whose done this a 100 times before. Probably a better source of info.

[spyguitar]

NOTE: Before doing any of the below, BACK UP YOUR DATABASE.

Made some progress on the above: mysqldump is your friend, here. There are a ton of tables in the 'jamfsoftware' database (pastebin here of the whole dump: https://defuse.ca/b/jGQfIVtL - password: jamfsoftware [note, this will expire 180 days from the date of this post])

[Note: I'm still discovering which tables contain which settings; this list is currently a WIP]
The tables I find useful are:
advanced_searches
categories
computer_dep_prestages
computer_groups
dock_items
enrollment_settings
mac_apps
os_x_configuration_profiles
package_contents
package_objects
packages
policy_dock_items
policy_packages
policy_scripts
policy_self_service_categories
policies
scripts
self_service
smart_computer_group_criteria
software_update_servers

The way to replicate only certain tables is as follows. I realize that putting the mysql root password in plain text isn't the greatest idea; this is for unattended running i.e. in a nightly cron job. Note that this requires the "source" server to have a passphrase-less SSH keypair for authentication to the "target" server; this also assumes you've left the JSS database name default, i.e. jamfsoftware.

mysqldump -u root -p'password' jamfsoftware [TABLE LIST HERE] | ssh -i ~/.ssh/id_rsa USERNAME@TARGET_SERVER mysql -u root -p'password' jamfsoftware

TABLE LIST is simply a list of the tables you want to replicate, separated by a space:

mysqldump -u root -p'password' jamfsoftware categories scripts policies ... | ssh...

Run this code on the source server, then restart jamf.tomcat8 on the target server (sudo service jamf.tomcat8 restart). In my testing, trying to replicate the ldap_servers and smtp_servers tables broke things; JSS wouldn't start properly.

I've just started testing this, but it seems promising. Not sure if I'm going to automate it or not.