How to install Assets Discovery Agent via SCCM?

[Christian Schneider]

Dear community,

I have 1200+ clients and I should install the Assets Discovery Agent. Atlassian happily says to do this manually. The installation routine of the Agent is so bad that distributing the application via SCCM is very difficult. 

I need some advice on how to uninstall the existing Discovery Agents (Version 3.1.4) and how to install the new version 3.2.0 with SCCM. What are the exact steps to do?

Thank you,

Chris

EDIT: Anybody stumbling on this: please fote for [JSDSERVER-12441] improve Discovery tool in order to fully support the deployment of agents through SCCM - Create and track feature requests for Atlassian products.

EDIT2: vote for this as well: [JSDCLOUD-12326] improve Discovery tool in order to fully support the deployment of agents through SCCM - Create and track feature requests for Atlassian products.

[Rafal Binkowski]

Hi Chris, we were able to accomplish that after many failed attempts. The biggest problem were credentials that are kept in the agent.cfg file. Had to create two steps for the SCCM installation. First step was to deploy the package using SCCM and and later run post installation script which was configuring the agent. The command "Discovery_Agent.exe -setupsftp" generates the password in encoded form and puts it into the "agent.cfg" file. There are also few other options needed in the script to be passed beforehand. 

First attempt was to deploy the package with the "agent.cfg" preconfigured but it turned out it cannot be done that way, "-setupsftp" command need to be run on each endpoint after the installation. 

[Rafal Binkowski]

I just reminded, in the post installation script I passed sftp location, username and password to the ftp share where scan results should be uploaded.

[Christian Schneider]

Hi @Rafal Binkowski ,

Thank you for your help. Our post-installation script currently stops the Agent service, exchanges the agent.cfg and the objectHashSettings.xml and then restarts the service.

(We do this vor version 3.1.4.) This seems to work for most of the clients. There were a couple of clients, where de un-install of version 1.18 did not work properly and therefore the new version couldn't be installed. -> manual work needed.

So, for version 3.2.0: 

• How do you properly un-install version 3.1.4?
• How do you run the -setupsftp on every client? Can you pass the needed values via script?
• Did you change the ObjectHashSettings.xml? How did you distribute it to the clients? (just copy/paste or is there a need to stop the service?)

your help is very much appreciated!

best regards from Switzerland,

Chris 

[Simen Vågsæter]

We did not need to run setupsftp on the client, we simply have a script that edits the content inside Agent.cfg and Agent.bak file with the correct SFTP settings, this works fine. 

[Rafal Binkowski]

That is great news Simen it works for you as in the previous version of the tool it was not working properly, we had to run the command to generate unique password for each client. @Christian Schneider I did not need to uninstall previous version, can't help here. We were doing fresh roll out. 

[Christian Schneider]

Hi @simeh

Thank you very much. As far as I remember, when rebooting the device, the config gets reset to what it was before. Hence, we had to stop the service, delete agent.bakt and replace Agent.cfg and then restart service. How to you ensure, the procedure was successful?

Chris

[Christian Schneider]

Hi @Marek Parfianowicz

could you please elaborate on how to properly un-install version 3.1.4?

I need to update the ObjectHashSettings.xml on every client after the fresh installation of version 3.2.0. Can I simply copy the new file into the folder?

As far as I understood @Rafal Binkowski , I can add the sftp-settings via command line on each client? Is there a documentation for that? Does this restart the service and then, the new ObjectHashSettings.xml will be taken into account as well?

 Thank you,

Chris

[Christian Schneider]

Hi @Rafal Binkowski

you have mentioned earlier, that you have a script that can add the sftp-settings to the Agent.cfg. I just had a short look at the command Discovery_Agent.exe -setupsftp. How do you provide the necessary information to that command in a script? Do you mind sharing that part of your script?

Thank you,

Chris

[Simen Vågsæter]

Hi Chris,

I use Intune and not SCCM, but for uninstall it should be fine to do it via Config Mgr: 

Create the uninstall application for an Application model deployment

1. Navigate to your product application in Configuration Manager.
2. Click the product application, then right-click and select properties.
3. Click Deployment Types.
4. Select the deployment type for the product and click Edit.
5. Click the Programs tab.
6. Under Specify The Command To Uninstall This Application, click Browse (next to Uninstall Program).
7. Select Show All Files, and then select the Uninstall.bat file you created.
8. Click OK until the wizard finishes.

To install the app it should be the same as any other app but use /quiet as argument so it runs silently.

Installation Help | Uninstall deployed products with Configuration Manager | Autodesk

[Baldeep Gill]

Hey Simen, I am just about to embark on this journey of deployment via Intune - are there any pointers which you followed/ found helpful?

We’re using Atlassian cloud so will have to store the cloud token in the config for each machine to report back to our instance.

[ruth budu]

For installing 3.2.0, make sure your SCCM distribution points are in top-notch shape. Prepping your environment is half the battle! Then, you can create a deployment package in SCCM and craft a neat deployment script.

Remember to test it on a smaller scale first to catch any unexpected hiccups. And, oh, don't forget to document your steps; it'll make your life easier in the long run.

If you need more detailed guidance, check out the learnmesccm channel for some golden nuggets of wisdom. Happy deploying!

[Christian Schneider]

In case you have already done it: would you mind sharing your script?

[Marek Parfianowicz]

Hi Chris.

I really understand your pain of upgrading 1200 agents, it's not easy to automate it at the moment. Our development team is working on improvements in this area.

In the Assets Discovery 3.1.11 we added the "Update" tab in the GUI, so that you can easily check if there is newer version available.

In the Assets Discovery 3.2.0 we added a new '-update' command-line option for agents. Running an agent with this option will trigger download of the latest binary from Atlassian Marketplace, shutdown of a running agent, updating binaries/dlls and startup of a new one. This option has not been documented in the release notes, because it will work for version 3.2.0 and later, so it's not possible to use it for older agents.

We are currently working on centralized agent management via Assets Discovery GUI. It will be possible to see online/offline status of all agents, their versions as well as trigger an update for all of them. You can expect this feature in next major release, ETA Q1 2024.

I can assure you that we will review your feature request JSDSERVER-12441 and check how can we adjust agent update mechanisms to be compatible with SCCM.

Kind regards

Marek Parfianowicz

Assets Discovery team

[Rafal Binkowski]

Hi Marek, thanks for your reply and sharing details about command line enhancements. This is actually sth what would make like easier for many people as IMHO it looks like GUI was much more promoted in the past when it comes to this asset discovery tool. For smaller entities it is perfect but for bigger companies with SCCM/Intune deployments it may become problematic. Happy to hear you are moving forward with the product development. Cheers  

[Christian Schneider]

Hi @Marek Parfianowicz ,

good to here, that Discovery Service/Collector/Agents gets some much needed love from your side.

"centralized agent management" sounds good but to be honest, that's what we have SCCM for. Big companies don't need another tool for centralized management of clients, they already have SCCM or other tools.

It would be nice, if there was a silent mode, when installing Agents:

• I would like to have the *.msi ....
• .... and the option to add a config-file with all the company specific details for the installation.
• And we need an un-install routine, which properly removes everything.

A GUI for updating a single Agent is nice for small companies with less then 10 devices, everybody else needs command line features.

Chris

[Baldeep Gill]

@Christian Schneider   interested to know how you got on with the deployment?

[Christian Schneider]

Hi @Baldeep Gill

thank you for asking. Well, still work in progress. I will have a meeting tomorrow with a co-worker and we will then decide on how to proceed.

Chris

[Baldeep Gill]

ok @Christian Schneider I too am spending the day on this! Hopefully making some progress. I will keep you updated if I move forward. Hoping you might do the same

[Christian Schneider]

Hi @Baldeep Gill ,

I tested the un-install of the version 3.1.4 on my laptop. Then installed the new version 3.2.0. I used discovery_agent.exe -setupsftp to create the new settings, as the encryption of the sftp-password changed.

copied the agent.cfg/agent.bak somewhere else and added comments into the files. same with ObjectHashSettings.xml.

I added something like this:  <!-- customVersion=3.2 -->

I had to stop the service (discovery_agent.exe -u), then I copied all three files back into the folder and restarted the service. (discovery_agent.exe -i)

After the installation, I realized that the service will be started delayed by default (?).

next steps:

My co-worker will try to remove the discovery agent with the *.msi -x command. that should remove the service and all the rest.

He will then use the new installer to install the new version. After the installation, he will copy the 3 files from above into the folder.

He will use my comments within the files to verify, if the correct version is present on the target laptop. With luck, SCCM can copy the new files onto the computer, before the service is started. (Otherwise, there is some kind of safety mechanism, that resets the cfg to the previous version.)

Let's hope, this all is successfull.

How about your progress?

Chris

[Baldeep Gill]

I have created a MSI which will drop the "Discovery" directory into program files and then kick off the install of the Discovery_Agent.

I also have a batch file which copies our Discovery.cfg and ObjectHashSettings.xml into the correct location after install.

We're using Atlassian Cloud so have our cloud token with in the Discovery.cfg settings.

Problem im facing at the moment is that the password configured initially doesnt seem to work on other machines once the MSI is installed.

[Christian Schneider]

AFAIK: when discovery agent is installed, it resets the agent.cfg to default. You have to install the agent, stop the service, update the agent.cfg, agent.bak & ObjectHashSettings.xml and restart the service.

[Baldeep Gill]

Thanks Chris, did you come across any issues with the password for the interface not working?

[Christian Schneider]

Well, our Agents send their data via sftp to a server. From there, we use the 'Assets Collector" service to push the data into the cloud. As we migrated from an old agent version, I had to re-create the sftp password, because the encryption changed between versions.

Is it that password, you are asking about?

[Baldeep Gill]

Right ok, no I was referring to the password to access the interface for the settings when running "discovery.exe -s"

[Christian Schneider]

ok, no, I never had an issue with opening the GUI of the Discovery Service on the server.

[Baldeep Gill]

Thanks Chris, can I check the steps your following with mine below:

Place Discovery Directory in C:\Programs Files
Install discovery service
Install Discovery_Agent.msi
Copy config files into directory (discovery.cfg, ObjectHashSettings.xml, Agent.cfg/ .bak)
Restart discovery service to pick up custom config files

Issues:

I'm finding I cannot open the discovery.exe settings as the password isnt being picked up, I have to use the -resetpassword to reset it and open

I also find that I have to manually set the agent token before it runs correctly and syncs the data into Jira Cloud.

[Christian Schneider]

Hi @Baldeep Gill ,

Place Discovery Directory in C:\Programs Files
Install discovery service
Install Discovery_Agent.msi
Copy config files into directory (discovery.cfg, ObjectHashSettings.xml, Agent.cfg/ .bak)
Restart discovery service to pick up custom config files

As far as I know, installing the discovery agent automatically starts the agent-service. you need to stop the service, before copying the config-files.

I'm finding I cannot open the discovery.exe settings as the password isnt being picked up, I have to use the -resetpassword to reset it and open

Is there an Discovery Agent GUI? I don't remember, ever opening this one. The config files should provide everything that is needed.

I also find that I have to manually set the agent token before it runs correctly and syncs the data into Jira Cloud.

As I sad: our agents on the client push there data via sftp to an internal server. The agent does not communicate directly with the cloud. (I did not know that this is possible? I remember seeing a feature request for this...)
Atlassian support explained to me that the token is used for the webservice-comunication between Assets Discovery Service (on the server) and the Assets Discovery Agent (on the client). As my clients are distributed over many VLANs, I did not want to use that, but use sftp instead.

[Baldeep Gill]

Yes there is a GUI if you run "discovery.exe -s"

Uploaded with a cloud token works, we've done a few manual installs and the data flows through nicely.

I spoke with support today and they advised the issue is that the agent token gets encrypted so copying the config files wont work. We found that we have to manually set the agent token in the GUI before it successfully scanned.

They are going to get back to me with further info with regards to setting the token via cmd like we can for the discovery agent via "Discovery_Agent.exe -token XXXX-XXXX-XXXX-XXXX"

[Christian Schneider]

Hi @Baldeep Gill

I am confused: "discovery.exe -s" is used for the Assets Discovery Service GUI on the local server. With the Assets Discovery Agent on the client, there is no "discovery.exe". There only is a "Discovery_Agent.exe".

[Baldeep Gill]

In our environment we are having to install the Discovery Service on each end point along with the Discovery Agent.

In the "Assets Discovery Service GUI" we set the Export tab to "Cloud" and enter our Cloud token which uploads the data straight into Atlassian, rather than going through a collector/ sftp.

Your using the SFTP option to upload your scan data to a server and then using collector to upload into Atlassian?

[Christian Schneider]

Your using the SFTP option to upload your scan data to a server and then using collector to upload into Atlassian?

Yes, that is, what we are doing.

Do some reading: https://support.atlassian.com/jira-service-management-cloud/docs/discover-objects-in-your-environment-with-asset-discovery/

:-)

There seem to be 3 main options on how to use the Assets Discovery.

• You could install Assets Discovery Service on a server and use its scanning capabilities to gather data from your clients. (We do this for our server network, as IP-addresses are more or less fix and in a defined range.)
• You could install Assets Discovery Service on a server and the Assets Discovery Agent on the clients. The clients can sent their scanning data via sftp to the server. The Assets Discovery Service can deliver the data to the cloud. (We use the Assets Discovery Collector, otherwise, the scanning data from our servers and the scanning data from our clients would get mixed up in Assets Cloud. I like to keep them separated.) Using sftp seems to be "the old way" of doing things.
• There is an option within the Assets Discovery Service, where you can specify the IP-addresses of your clients. Communication is then managed from the server. The server pulls the information from the clients. And you could push files over to the clients. (never tested that, because when I had a look into it, the version was buggy and filled the hard drive with 100MB+ log files daily...) And we don't use this, because my 1000+ clients are distributed over too many VLANs with too many IP-address-ranges to manage.)
• Atlassian is obviously working on some more functionality, yet to be seen.

[Baldeep Gill]

Ideally we'd be able to install the service on multiple machines as we have people working on different networks/ remotely etc, due to acquisition its a little disjointed.

But speaking to support its not possible to set/ generate the token via command line.

Our hope was to be able to package this all up into a MSI and deploy. Which we did manage to do put unfortunately we found we had to enter the GUI and set the token manually which is our only blocker! 

[Christian Schneider]

I still don't understand, why you would install the Discovery Service/Collector on each client. It is not its intended use. You should install the Discovery Agent on the client and you should install the Discovery Service/Collector on one (or a hand full of) servers. Then, you could easily set the Token for the Cloud-upload manually in the Service/Collector-GUI.

Within the Discovery Service-GUI, you should be able to manually create the token for the communication encryption between Client and Server. According the the docs, you should be able to set the token via command line. (Discovery_Agent.exe -token) -> Service | Atlassian Support | Atlassian Documentation

In your case, I would try to use SCCM to set the token on the client via command line.

As we are using sftp (-> Set up Discovery Agent (optional) | Atlassian Support | Atlassian Documentation), we don't need the token on the client.