I am growing very tired of being asked to justify my "undocumented" and "bigoted" best-practice of NEVER deploying splunk infrastructure (Search Heads, Indexers, License Manager, Cluster Master, Deployer, Deployment Server, Monitoring Console, etc.) on any Windows OS. I am sure many of you have faced the same challenge. I have created this question so that we can create a canonical list from which we can all share the same URL where the best and brightest of us can share our past pain with the kind intention of helping others avoid the
windows path of perfectly-avoidable regret. If you think that you will use this Q&A as a reference point, then please do
me-too the question. If you have just cause to avoid Windows then P*L*E*A*S*E post your answer. Remember, friends don't let friends deploy on Windows: let's give them the facts that they need to successfully push back. Please include links to documented disasters when possible. Keep in mind that I probably will never
accept any answer to this question (to encourage others to participate in perpetuity). Let's do one objection per answer and vote on the best objections so that the most-important ones will filter to the top.
THERE ARE NOW MORE ANSWERS THAN FIT ON A SINGLE PAGE (NOTE
PAGINATION CONTROLS AT THE BOTTOM)!
Windows is architecturally incapable of dealing with *NIX file permissions as documented here (among MANY other places):
This means that if you ever try to use a Windows-hosted Deployment Server for *NIX-hosted Deployment Clients (Forwarders), you will have trouble that you would not otherwise have if you were deploying from a *NIX-hosted Deployment Server.
Permissions are retained from *Nix DS to *Nix clients, and Windows DS to Windows clients, and a *Nix DS to Windows clients.
However a Windows DS deploying to Linux will not retain permissions file system permissions.
This typically is only a problem in the *Nix world, where you're running your DS as user
splunk (or any non-
root id), and you actually want it to be
root or a different
uid on the client.
In the case where you are deploying to different OS's, it's best to setup a script to
chown the $SPLUNK_HOME/etc/apps and run that frequently as you need to.
Windows works a bit differently, as you can setup the filesystem to inherit from the parent folder and this typically works as designed.
One issue comes to mind regarding Splunk Deployment Server on Windows attempt to deploy to *nix clients.
Here you will find an answer about that challenge: https://answers.splunk.com/answers/70039/windows-deployment-server-to-nix-deployment-client-permissi...
I moved this to to a comment under the other answer because both answers were describing the same thing. Also because we now have so many answers that if there is just one more, we will begin to paginate (merging this brought it back to a single page). No disprespect intended to you, @adonio! We just said the same thing at the same time!
When I ran splunk in a windows environment I used winrm, powershell, and a file share as my deployment server. Worked so good I did a speech on it at .conf 2013 which never made it to print on the website... but i swear it happened.
In the lab i used what i had handy, and had a Windows DS push the Splunk Nix Add-on to an OSX machine.
After the app deployed, and wondering why i wasn't getting data from inputs that were turned on, i found the scripted-inputs weren't set to +x and couldn't be executed.
A chmod +x *.sh in the app's bin directory got things going again, but that wasn't nice..
I suspect it's because Windows doesn't grok UNIX permissions and just deployed them as regular files.
Like it or not, whether Splunk (the company) will admit it or not, Windows is the "afterthought" option. It gets considered last, tested least, deployed rarely, more crash/down-time, and exploited frequently. From a user-base-size perspective, it is very hard to get help anywhere if you are using Windows just because so few people do; I am not normally a "jump on the bandwagon" kind of person, but in this case it very much makes sense.
@woodcock, I would concur to this point because during alpha pre-release testing I had to wait for a week to get windows installer since the package for testing was initially only compatible with *NIX or MAC.
I also faced similar issue with Splunk's Custom Visualization API while working on a Customer requirement for a new visualization and the the API failed to build as per documented step on Windows machine. It was confirmed to be an issue on Windows system. However, fix from Splunk did not come out. I ended up finding a fix myself.
Even app developers may not take time to test on Windows. You can easily find apps like
That say things like this:
Dependencies * Linux, MacOSX or Windows (Windows is untested but should work)
Just the other day I downloaded
OpenDNS Detective and found that it was incompatible with Windows:
I worked with the developer to fix it.