We are beginning to contemplate purchasing Casper Suite. Documentation states JSS can be installed on either Windows Server or Mac OSX. My question is, what would the community recommend? Our enterprise server group is Windows only (but setting up a Mac server is not out of the question for us), so who is running on Windows server and would you do it again?
Advantages/disadvantages for each platform?
Solved
New JSS Install: Windows or Mac Server?
+9Best answer by admin13
Both should work out just fine for a JSS and, generally, it’s a matter of personal preference and what you (or the person who will be the JSS admin) are more comfortable with using in your environment. In my test environment, I've got a 2012 server and a 2008 server both running a JSS (8.x and 9.x) and they both perform just fine.
I’m sure others who have JSS servers that aren’t support test environment servers will have a better list of pros/cons along those lines
Speaking as support, however, there are some caveats to a Windows server to keep in mind.
The issues we tend to see the most often both with new installs, re-installs on a new VM, or upgrades/updates to the JSS:
- Our installer conflicts with most Antivirus/Internet Security software out there. By conflicts, I mean the installer sometimes will completely fail until the AV software is either completely disabled or temporarily uninstalled. When it rolls back, it breaks Tomcat in the process, and then it's usually a call to support to get it untangled and running again. The issue seems to be with the AV software flagging the ROOT.war file as malware. In some cases, whitelisting .war files can get you around it, but that leaves the door open for any malware that’s using .war and is probably not the best of ideas.
- Sometimes, the installer doesn’t play nice with domain admin accounts vs. local admin accounts. Not a huge deal, just switch over to a local account and it tends to work fine.
When that happens, it’s usually because, while the domain admin account does have domain admin rights it doesn’t always have a full set of local admin rights.
Even then, we find we have the best luck by running the installer at an elevated privileges command prompt (right click, run as administrator) using msiexec /i.
- UAC can occasionally cause the installer to fail, and we sometimes find we need to disable it for the duration of the install.
The errors the installer gives won’t be that exact, they’re kind of vague: “A script required by the installation has failed to run.” or “Error changing log paths.”, but those of us in support have seen both messages often enough to know it means one or more of the above three things.
The most common cause out of the three is anti-virus software: Sophos, Symantec Endpoint, McAfee, and Cymphonix (which is usually domain based, and does NOT show a tray icon, it just shows up as cymdir in task manager) are four that I’ve run into frequently that tend to kill it.
They're also issues that development is aware of, mostly because I never stop talking about it when I run into one of them. :)
All of the above can be avoided entirely by going the Manual Install route instead of using our Windows installer, however, so it’s not too difficult to avoid those issues.
Initial setup with a Manual Install involves a little more legwork, but on Windows servers, it’s typically easier in the long run, especially if your server is running AV software.
- Paths for Java need to initially be set in the system variables, or the installer may throw an error about java not being installed.
This thread has more instructions on what needs to be done to avoid/fix that.
- On that note, sometimes we need to add the path to the MySQL bin directory in the PATH variable for the JSS Database Utility to work.
- Currently, a JDS will not run directly on Windows. Not a deal breaker, necessarily, as if you want to run a JDS in your environment you can do so by using a Mac or a Linux box/VM to set it up instead. However, if you’d planned on having a JDS on the same server as the JSS, Windows wouldn’t work out for that.
- Minor and cosmetic, but still worrisome when noticed: There is a cosmetic defect (D-005575) in the JSS Database Utility for Windows. No matter what you set Tomcat's maximum memory allocation to, it will always appear to reset to 512MB. This is not accurate and is a cosmetic/visual only. If you run tomcat7w.exe and look at the Java tab, you'll see the correct amount of memory allocated.
- When you first upgrade/install a JSS, use any browser other than IE to open it.
Sometimes, IE will appear to hang on "initializing database" and it will stay there forever.
It isn't actually locked up in most cases, it's something to do with IE; open it up in any other browser on any computer that is able to reach the JSS, it will go through the initialization, and you'll be able to use it in IE again.
None of the above things tend to be show stoppers for most people, but knowing about them ahead of time can certainly help keep you from running into them during an install or an upgrade of a Windows JSS.
Hopefully that was a bit helpful.
Thanks!
Amanda Wulff
JAMF Software Support
+12It all depends upon your requirements, what you are comfortable with, and support options.
I am more comfortable with the Mac OS, however, i have been running a multi-JSS environment on Windows servers for the past two years or so. One requirement we had was enterprise redundancy. Since our server group is primary Windows; combined with the fact that Apple does not make an enterprise server, then the choice of Windows was a natural. (Besides, if something goes wrong with the server in the middle of the night, the server team will be the ones called, not me. *smile*). It also helps that our team has a good relationship with the server team.
I have worked with JAMF in supporting a JSS on both Windows and Macintosh and, in my experience, JAMF does well on both. Having the server team responsible for the Windows server (hardware and OS) allows me the time to concentrate on the JSS and other tasks as well.
+17Both should work out just fine for a JSS and, generally, it’s a matter of personal preference and what you (or the person who will be the JSS admin) are more comfortable with using in your environment. In my test environment, I've got a 2012 server and a 2008 server both running a JSS (8.x and 9.x) and they both perform just fine.
I’m sure others who have JSS servers that aren’t support test environment servers will have a better list of pros/cons along those lines
Speaking as support, however, there are some caveats to a Windows server to keep in mind.
The issues we tend to see the most often both with new installs, re-installs on a new VM, or upgrades/updates to the JSS:
- Our installer conflicts with most Antivirus/Internet Security software out there. By conflicts, I mean the installer sometimes will completely fail until the AV software is either completely disabled or temporarily uninstalled. When it rolls back, it breaks Tomcat in the process, and then it's usually a call to support to get it untangled and running again. The issue seems to be with the AV software flagging the ROOT.war file as malware. In some cases, whitelisting .war files can get you around it, but that leaves the door open for any malware that’s using .war and is probably not the best of ideas.
- Sometimes, the installer doesn’t play nice with domain admin accounts vs. local admin accounts. Not a huge deal, just switch over to a local account and it tends to work fine.
When that happens, it’s usually because, while the domain admin account does have domain admin rights it doesn’t always have a full set of local admin rights.
Even then, we find we have the best luck by running the installer at an elevated privileges command prompt (right click, run as administrator) using msiexec /i.
- UAC can occasionally cause the installer to fail, and we sometimes find we need to disable it for the duration of the install.
The errors the installer gives won’t be that exact, they’re kind of vague: “A script required by the installation has failed to run.” or “Error changing log paths.”, but those of us in support have seen both messages often enough to know it means one or more of the above three things.
The most common cause out of the three is anti-virus software: Sophos, Symantec Endpoint, McAfee, and Cymphonix (which is usually domain based, and does NOT show a tray icon, it just shows up as cymdir in task manager) are four that I’ve run into frequently that tend to kill it.
They're also issues that development is aware of, mostly because I never stop talking about it when I run into one of them. :)
All of the above can be avoided entirely by going the Manual Install route instead of using our Windows installer, however, so it’s not too difficult to avoid those issues.
Initial setup with a Manual Install involves a little more legwork, but on Windows servers, it’s typically easier in the long run, especially if your server is running AV software.
- Paths for Java need to initially be set in the system variables, or the installer may throw an error about java not being installed.
This thread has more instructions on what needs to be done to avoid/fix that.
- On that note, sometimes we need to add the path to the MySQL bin directory in the PATH variable for the JSS Database Utility to work.
- Currently, a JDS will not run directly on Windows. Not a deal breaker, necessarily, as if you want to run a JDS in your environment you can do so by using a Mac or a Linux box/VM to set it up instead. However, if you’d planned on having a JDS on the same server as the JSS, Windows wouldn’t work out for that.
- Minor and cosmetic, but still worrisome when noticed: There is a cosmetic defect (D-005575) in the JSS Database Utility for Windows. No matter what you set Tomcat's maximum memory allocation to, it will always appear to reset to 512MB. This is not accurate and is a cosmetic/visual only. If you run tomcat7w.exe and look at the Java tab, you'll see the correct amount of memory allocated.
- When you first upgrade/install a JSS, use any browser other than IE to open it.
Sometimes, IE will appear to hang on "initializing database" and it will stay there forever.
It isn't actually locked up in most cases, it's something to do with IE; open it up in any other browser on any computer that is able to reach the JSS, it will go through the initialization, and you'll be able to use it in IE again.
None of the above things tend to be show stoppers for most people, but knowing about them ahead of time can certainly help keep you from running into them during an install or an upgrade of a Windows JSS.
Hopefully that was a bit helpful.
Thanks!
Amanda Wulff
JAMF Software Support
+18Agreed, this is a great post Amanda, and I copied it to a text file for reference.
As to the OP, we have a Wintel server team that takes care of our Win 2008 JSS, but not the JSS software. We have had good luck with it and it's nice to not have to support the servers themselves.
That said, we attempted to upgrade two weeks ago from 8.73 to 9.31 and failed. Our servers are locked down tight, and the errors we got are pretty generic. We are using AD Admin accounts, so we are looking at seeing how to knock out as many of the variables that Amanda has posted above.
We had previously done two minor updates with no problems, so we don't know if something changed on the server, or if it lies elsewhere. At this point, we're still on 8.73. Given Apple's history on servers, I'd probably opt for the method that gets the most enterprise support - and Mac Servers generally get zero.
Scott
+16@donparfet][/url, I use an enterprise server as well running Windows Server 2008 R2 and it's been extremely reliable for us. I just set up a test VM to see how the JSS plays with Server 2012 as well and it seems to be running fine. I'm glad to see @amanda.wulff][/url is testing with 2012 as well. We are planning to upgrade our server's OS once we are confident there are no conflicts in running the JSS on the new OS.
As far as JSS upgrades go, as mentioned by Amanda already, I ran into the issue where our AV interrupted and failed the upgrade. What has worked for every update since then is disabling the active scan component of the AV and performing the upgrade. It's been smooth sailing ever since.
+17We do have 2012 now listed in the documentation as a supported OS (Page 12 of the JSS Installation and Configuration Guide for Windows) ; I know development and QA have been testing with it longer than I have.
The main roadblock I ran into with 2012 was just getting used to the Metro interface, and undoing the locked down IE just enough to allow me to grab Firefox.
That does remind me of one more small caveat: When you first upgrade/install a JSS, use any browser other than IE to open it.
Sometimes, IE will appear to hang on "initializing database" and it will stay there forever.
It isn't actually locked up in most cases, it's something to do with IE; open it up in any other browser, it will go through the initialization, and you'll be able to use it in IE again.
Think I'll edit the above post to add that one to the list; it's such a silly little thing, but it causes a lot of panic when it happens as it appears that the JSS is frozen after an upgrade.
I sort of cheated with my Win8 laptop (personal machine, not a work machine) and slapped Classic Shell on it after about ten minutes of use, so I never really got used to the Metro interface and all of its shortcuts.
Most of the minor complaints about 2012 that I've heard while working on cases or on WebExes had mostly to do with the Metro interface and not the OS or its stability/behavior itself.
As far as the JSS is concerned, I haven't noticed much of a difference between how it runs on 2008R2 vs 2012. The same caveats I listed above apply to both versions, and they are both supported for running a JSS.
Amanda Wulff
JAMF Software Support
+16Ok, as a word of caution, even though Server 2012 works great with the JSS I did run into a problem upgrading from 2008 R2 to 2012. When the upgrade completed, all MySQL services were deleted and communication to the database was broken. Thankfully, it was a relatively simple fix. I uninstalled MySQL completely and reinstalled, only configuring the root password. Then, I was able to reconnect to the jamfsoftware database as if nothing ever happened.
+17Good to know! Not so good that it was figured out that way, but still good to know it's an easy fix when it happens.
I know that something similar happens with Java between 10.8 and 10.9 updates, and that there are issues with MySQL and Tomcat when going from 10.6.8 server (which came with both MySQL and Tomcat already installed) to a newer version of OS X.
In both cases, reinstallation of the affected services/programs is required; in the case of MySQL and Tomcat, we have to remove the old and put the new on or we get all sorts of bizarre behavior and failures.
This is the first one I've come across where a Windows upgrade caused something similar.
Thanks for that update!
Amanda Wulff
JAMF Software Support
+14We have been running our JSS on a Windows Server (2008 R2 later upgraded to 2012) and it has worked fine. We even tested it in Server Core mode and it worked great. Luckily I have run into none of the issues Amanda described with the standard installer.
My advice once the contract is set and you have access to the installers is to try the install on both and see which platform you prefer.
You'll also find there's some hardcore Unix people like myself, @localhorst and others who think that RHEL is the one true solution! Certainly it needs far less resources to do the same job but at the expense of ease of setup.
Where I am is a virtual RHEL 6.3 environment for both JSS and MySQL servers. It works really well with excellent uptime.
+5Another proponent of running the JSS on Linux, here.
I had the JSS running off a Mac Mini until we outgrew it, and it worked reasonably well. However, I have had many problems out of the Apple OS X Server software in the past in other cases, such as randomly shutting down services, control panels locking up on configuration changes, and control panels disappearing completely (I kid you not.) Couple this with a lack of real Apple server hardware, and it was something of a no-brainer to move away from Apple server-side. If you're going to have a decent number of devices in the JSS your only real option for new Apple hardware is a Mac Pro, and it's powerful in all the wrong ways.
Like @franton I've been running my JSS and MySQL on separate Linux servers (though in my case, Ubuntu rather than RHEL) and it has been exceptionally stable and reliable, as well as scaling nicely. Since we're heavily virtualized anyway, it also had the benefit of unifying my server OS-level management, which was nice.
+9@donparfet, we're running JSS 9.61 on 2008R2 here and have been since 8.73 with minimal issues and just hit 700 clients (no mobile; yet!).
The one gotcha we've noticed is that if you're going to do an 'all on one box' solution, for the love of your and your account manager's sanity, keep everything on the same drive. One thing we ended up discovering is that if your Tomcat instance is on, say, the primary drive and your MySQL instance is on a secondary drive, Tomcat will flip out. For no apparent reason. At all. It can communicate, eat all the memory it wants (I saw it eat 2GB in one shot before it crashed), and still fail. Moving everything onto a single-drive setup cleared all my issues.
Otherwise, my experience on a Windows host has been really positive, and my server team was pleased. The idea of sticking a Mac Mini in our data center wasn't exactly looked upon in a positive light. :)
+16I think running JSS on RHEL is the way to go. We started out this way and all has been good with only a few hiccups updating Java. Storage is easy to manage and services run stable.
Thanks,
Dom
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.