Uploaded image for project: 'Jira Service Management Data Center'
  1. Jira Service Management Data Center
  2. JSDSERVER-16271

Improve Assets Discovery tool in order to fully support the deployment of agents through SCCM

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • Assets Discovery
    • None
    • 1
    • We collect Jira Service Desk feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      At the moment in order to install agents on multiple target clients and copy over the same customised file (ex. agent.cfg), the available solution is to use the Service tab of the Discovery tool (or the Collector).

      However in Enterprises infrastructure where there are hundreds+ of remote clients which need the agent installed and those are located across highly segmented networks, it become hard to populate the ip range sections to identify the right clients.

      Note that if no ip ranges can be added to whatever reason, you have to use the sftp-transfer to get the scanned data to the Discovery Tool Server and the settings for this need to be provided through the agent.cfg file.

      Therefore many of our customers would like to use the SCCM MS tool to deploy/install the agents and also to copy over agent.cfg and/or patterns files.

      NOTE: The previous JSDSERVER-16271 is fixed with version 7, given that it has been introduced the feature from the agent tab of the Discovery tool to upgrade remote machines agents and copy over configuration files.

      However, customer that are using SFTP transfer to export scan from agent to Collector and do not use the Discovery tool at all, are still facing some challenges. Moreover some features, in regards to the provided installer msi are still highly needed.

      It would be great if the msi would cover the following requirements:

      • Implement silent mode to install the Discovery Agent.
      • Implement the possibility to provide all settings/information to the msi-installer, incl. patterns (which now when using SFTP transfer need to be generated on Discovery tool and moved manually to agents), sftp-settings, tokens before the installation process begins.
      • Implement the possibility to provide additional files, such as agent.bak, agent.cfg, ObjectHashMappings.xml to the msi-installer.

       

            [JSDSERVER-16271] Improve Assets Discovery tool in order to fully support the deployment of agents through SCCM

            Chris added a comment -

            Dear Atlassian-Team,

            here is a description on how to distribute the Discovery Agent on clients via SCCM: https://community.atlassian.com/forums/Jira-Service-Management/Re-How-to-install-Assets-Discovery-Agent-via-SCCM/qaq-p/3056636/comment-id/210002#M210002

            As this is fairly complicated, please re-work the msi-installer.

            Thank you,

            Chris

            Chris added a comment - Dear Atlassian-Team, here is a description on how to distribute the Discovery Agent on clients via SCCM: https://community.atlassian.com/forums/Jira-Service-Management/Re-How-to-install-Assets-Discovery-Agent-via-SCCM/qaq-p/3056636/comment-id/210002#M210002 As this is fairly complicated, please re-work the msi-installer. Thank you, Chris

            Chris added a comment -

            Dear Atlassian-Team,

            I am happy to share some thoughts on SCCM and our use case. I hope this provides some insights on why the current installer is so painful.

             

            SCCM does two things:

            1. first of all, it is used to automatically distribute/install application on our clients (laptops, PCs and all sorts of other computers). During the installation, SCCM wants to be able to verify, if the installation was successful. Usually, this is done by confirming the version of an .exe, the existence of a path or by confirming a value of a registry key.
              In the case of the Assets Discovery Agent installer, there is not only the command to run the msi-installer, but the Discovery Agent Service has to be stopped, the Agent.cfg has to be modified (timestamps, sftp-settings and other values), the ObjectHashSettings.xml and the pattern-file have to be copied to the client and then, the Discovery Agent Service has to be started again. After the start of the Agent Service, the Agent.cfg is modified (e.g. hashing of the sftp-password or the InstanceID is added). SCCM has to verify EVERY STEP in the process to be successful. If not successful, the whole installation process is re-done. As the Agent.cfg is changing during the installation, it is very difficult to verify each step in the process.
            2. Secondly and almost more important: after the successful installation of the application, SCCM verifies every day, that the installation is still correct. There has to be a set of detection rules, which define the state, the installation should be in. If the conditions fail, SCCM will take action to correct the installation on that client.
              In the case of the Assets Discovery Agent, we verify, if the ObjectHashSettings.xml is still in our provided version and if there are still sftp-settings provided in the Agent.cfg. If not, those files are newly copied to the client. (This will currently fail, because of the hash of the sftp-password being wrong... we need to re-create the sftp-settings as well.
               

             

            So, in order to simplify the SCCM-processes:

            1. create an msi-installer, which can take into account all the necessary information. There should be one command to install the application, without the need to stop-adopt-start the application.
            2. provide a simple health-check option, which can be verified by SCCM. e.g. a status.info, where you write some state info. (e.g. sftp credentials wrong, scanning not working, ... or simply "OK")

             

             

            Chris

            Chris added a comment - Dear Atlassian-Team, I am happy to share some thoughts on SCCM and our use case. I hope this provides some insights on why the current installer is so painful.   SCCM does two things: first of all, it is used to automatically distribute/install application on our clients (laptops, PCs and all sorts of other computers). During the installation, SCCM wants to be able to verify, if the installation was successful. Usually, this is done by confirming the version of an .exe, the existence of a path or by confirming a value of a registry key. In the case of the Assets Discovery Agent installer, there is not only the command to run the msi-installer, but the Discovery Agent Service has to be stopped, the Agent.cfg has to be modified (timestamps, sftp-settings and other values), the ObjectHashSettings.xml and the pattern-file have to be copied to the client and then, the Discovery Agent Service has to be started again. After the start of the Agent Service, the Agent.cfg is modified (e.g. hashing of the sftp-password or the InstanceID is added). SCCM has to verify EVERY STEP in the process to be successful. If not successful, the whole installation process is re-done. As the Agent.cfg is changing during the installation, it is very difficult to verify each step in the process. Secondly and almost more important: after the successful installation of the application, SCCM verifies every day, that the installation is still correct. There has to be a set of detection rules, which define the state, the installation should be in. If the conditions fail, SCCM will take action to correct the installation on that client. In the case of the Assets Discovery Agent, we verify, if the ObjectHashSettings.xml is still in our provided version and if there are still sftp-settings provided in the Agent.cfg. If not, those files are newly copied to the client. (This will currently fail, because of the hash of the sftp-password being wrong... we need to re-create the sftp-settings as well.     So, in order to simplify the SCCM-processes: create an msi-installer, which can take into account all the necessary information. There should be one command to install the application, without the need to stop-adopt-start the application. provide a simple health-check option, which can be verified by SCCM. e.g. a status.info, where you write some state info. (e.g. sftp credentials wrong, scanning not working, ... or simply "OK")     Chris

              Unassigned Unassigned
              tmarchionni@atlassian.com Tiziana Marchionni
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: