@ESensenbrenner Will there be a new version of the client?

@ESensenbrenner I am experiencing the same thing. I can't get S1 version 3.0.4.2657 to install with a policy via Jamf cloud (10.15.1), but I have no problems installing it locally on the mac. There is first a Configuration Profile on the mac to approve the kernel extension. Then, I have a policy set to install the package via our network File Share Distribution Point (no spaces in file path). Package name also has no spaces. After the package is installed I run an Execute Command to set the registration token. However, I get an error message that the package failed to install and to contact the manufacturer, but only on some Macs not all. I've even downloaded a fresh pkg of the S1 agent and it's a no go.

So we are now using version 3.2.1.2800 which seems to be running fine on Catalina and I am still using the same command line as I was above.
I am interested in seeing the script you mentioned @rpayne to inject the site ID post install, please.
Next problem is that I am trying to update existing versions of the client to the latest we have (3.2.1.2800). Currently using the same install method but getting "The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)"

@edullum Have you tried my method? Package with the installer and token to somewhere like /var/tmp and then a command to run the installer? It automatically reads the registration token then as it is in the same folder as the installer.

@awginger I tried your method locally on a Mac running Catalina and it worked flawlessly. Now I'm going to put it into place with Jamf Pro and let you you what happens.

I give up. I keep getting this error message when I try to install the package via Jamf Remote or via custom policy trigger. I even gave the package 777 rights: installer: The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)

Are you installing it on a device that already has SentinelOne?

@awginger Yes. But I've been able to upgrade an agent before that was already installed on a Mac.

@edullum Can you not pass the management of upgrades/updates to the SentinelOne console?

@awginger I can on some of the agents. There is an agent version of S1 that has a bug, where the S1 admin console cannot see the Mac. So the Macs that are on the buggy agent is a whole other process to get them updated.

Just seen this on one of customer's estate - They are using a simple one liner...

sudo sentinelctl upgrade-pkg /<file_location>/<package_name>.pkg

@awginger can you please share the script to install the SentinelOne.

@Santosh I'm not using a script, just the method I mentioned in the post above (here)

Hey, the configuration profile works but I'm wondering is there a way to build a Smart Group that selects the Macs that have this config profile installed? I don't want to push the Sentinel One package without the config profile first.

Thanks!

What scripts is everyone using? How you are getting the token installed?

These instructions worked perfectly for us.

Installing and Upgrading macOS Agent with Jamf

Agents: macOS 2.6+
Jamf is macOS software to build packages, manage inventory and images, and run remote updates. You can use Jamf, or other MDM software, to install the SentinelOne macOS Agent.
During the installation, you must add Agents to a Site with the Site Token.
From version Grand Canyon SP4, you can use a Group Token during installation, instead of a Site Token, to add Agents directly to a static Group in a Site. Get the Group Token from one Site > one Group > Network > Group Info.
To get the Site Token:
1. In the sidebar, click Scope and select a scope.
Select one Site. If you are in any other scope, the Site Token does not show.
2. In the Network toolbar, click Packages.

1. In the Site Token section, click Copy.

To install with Jamf:
1. In the Network toolbar, click Packages.

1. Download the PKG of the macOS Agent version to install.


2. Launch Jamf and log in.



3. Create a configuration profile with these values in the Approved Kernel Extensions:
   Kext Bundle ID: com.sentinelone.sentinel-kext
   Developer ID: 4AYE5J54KN




4. Click Computer Management.



5. Add the SentinelOne Agent PKG file to Jamf.


6. Click Script and enter these lines, with your values for the Site or Group Token and package version:


7. sudo echo "token" > /Library/Application Support/JAMF/Waiting Room/com.sentinelone.registration-token
   sudo /usr/sbin/installer -pkg /Library/Application Support/JAMF/Waiting Room/Sentinel-Release-version.pkg -target /


8. Click Save.


9. In Computers > Policies.



10. Click Packages and change Action to Cache.




11. Click Scripts and change Priority to After.




12. Click Save.
    The Agent installs the next time the selected endpoints connect with Jamf.

@edullum Having the exact same issues with 3.4 and 3.6. I previously put the package into composer and ran the token script in composer then created a package. 3.2.1 and the new 3.2.3 works perfectly still. You can run those via command line. As soon as you run 3.4 and 3.6 via command line, that same error and contact the software manufacturer occurs. I've got a ticket open with Sentinelone but so far they've been less than helpful. Only pointing me to webpages I've already read and saying make sure my kext file is correct. My stuff has worked since March 2019, but doesn't work with 3.4 or 3.6. They haven't said what is different about their installers.

3.2.0, 3.2.1 and 3.2.6 (Jan 31st 2020 release date), will all work if the Kext is installed first, then you install the pkg as downloaded directly from sentinelone and then you do the token afterwards. If you run the pkg in terminal, it works.
My previously created composer pkg worked for these versions but not 3.4 or the 3.6 versions.

The old composer pkg, I copied the file to the /tmp folder. Then my post install said sudo /usr/sbin/installer -pkg /private/tmp/SentinelOne/Sentinel*.pkg

I then added the site token in that same pkg sudo /usr/local/bin/sentinelctl set registration-token --longtokenhere

Used this method for a year. This did not work with 3.4 and 3.6.

I piggybacked off awgingers post from October 29, 2019.

I copied the 3.6.1 pkg as downloaded from sentinelone to the /var/tmp folder. I then used textwrangler to create the "com.sentinelone.registration-token" file. The trick here, is it says a txt file. But when you save it into the same folder (in this case /var/tmp), you must not have it named with a .txt extensions. Remove the .txt from the end. It must only be named com.sentinelone.registeration-token.

Of course make sure your permissions are good to go. Then create your pkg in composer. This time the install will work. 3.4. and 3.6 requires the token to be a part of the install. 3.2.3, 3.2.1 and 3.2.0 and all earlier versions don't care if you put a token during the install. Those are all good to do afterwards.

Despite what sentinelone's instructions state, the way for 3.4 and 3.6 is to pkg together these files and not call them afterward. I didn't try peterjs solution.

Still banging my head against a wall. I've tried the various solutions and haven't had any luck. Maybe I'm not understanding the entire process everyone else is using but why all of a sudden since 3.4 does the method I have been using for over a year just stop working? The policy I have been using is just a simple policy that includes the package for sentinelone and then a Files and Processes with an Execute Command "sentinelctl set registration-token -- enter your token here". Starting to really hate SentinelOne.

.

I've got a package putting the S1 installer and its token file in a folder at /private/var/tmp/SentinelOne.
A post-install script then runs...
installer -pkg /private/var/tmp/SentinelOne/SentinelAgent_macos_v4_1_2_3143.pkg -target /
rm -rf /private/var/tmp/SentinelOne
It works fine from the pkg, and if I run the policy manually sudo jamf policy -id ####. But it never finishes in Self Service. The folder gets removed so I know it gets to that step. And I can see the kext installed.

Why would it hang in SS and run fine as a policy from CLI?

EDIT: I figured it out... The package I built was set to restart. I had restart if package requires it. But that was hanging it up... maybe because the S1 installer is still doing something. I've set "User Logged in Action" to restart (not if package requires it). ‍♂️

Hi,

Do you guys experience that after sentinel one kext was pushed down to Mac devices is blocking some extentions on Mac like Tunnelbrick, parallel desktop for mac and some others? so the allow button disappeared.

Please advise

Thank you

Markie

@zachriver24

we saw similar behavior. Updating S1 agent to v4.2.2 fixed it.

Hi Awginger, can you please share the steps to use this method , thank !

Hi @AMJAD, I have done it 2 ways. The first is a policy that installs the package and required files to a specification location and then using the Files and Processes payload to run the install command  

sentinelctl upgrade-pkg /<file_location>/<package_name>.pkg

The other way I have done it is to cache the installer and then a script to install, the script looks like 

#!/bin/bash
   echo "Creating S1 tenant token"
   sudo echo "<s1-token-code>" > /Library/Application\\ Support/JAMF/Waiting\\ Room/com.sentinelone.registration-token

   echo "Running S1 installer"
   sudo usr/sbin/installer -pkg "/Library/Application\\ Support/JAMF/Waiting\\ Room/<package_name.pkg>" -target /