We have updated our test Splunk infrastructure to 6.3.3 to evaluate this version before updating the production landscape (still running on 6.2.1).
When I take a look into the forwarder management on the deployment server (Apps tab), all apps are shown in the client column as "0 deployed".
The overview in server classes and clients is correct.
Is this a known problem?
Thank you and regards
If you are using a serverclass.conf that you had hand-crafted, and used things like blacklists, I've seen (and IO think it was when we went to 6.3.x), the deployment server not be able to parse things correctly -even though it doesn't complain about the file.
Try this. start with a clean deploymentclient.conf and use the GUI to make a change. Presuming that it works, examine the 'new' syntax, and change your file to match what it does.
If you are using a serverclass.conf that you had hand-crafted, and used things like blacklists, I've seen (and IO think it was when we went to 6.3.x), the deployment server not be able to parse things correctly -even though it doesn't complain about the file.
Try this. start with a clean deploymentclient.conf and use the GUI to make a change. Presuming that it works, examine the 'new' syntax, and change your file to match what it does.
Hi glentes, Based on the current known issues : http://docs.splunk.com/Documentation/Splunk/6.4.0/ReleaseNotes/KnownIssues , this particular one doesn't look to be one of them. I would make a small non-impactful change to one of the apps, and attempt a reload deploy-server to see if that prompts a refresh of the number of deployed apps panel.
Please let me know if this answers your questions 😄
Hi muebel,
we did so already several times during deployment of new and/or changed apps, but the status shown is still the same.
Any further ideas?
If you see the deployment server actually functioning, and the clients pulling down the updated apps, it seems that you have an issue with the Deployment Server console that would require a support ticket.
In the meanwhile, you could investigate the deployment servers internal logs, looking for anything related to the deployment server component that stands out as an error.