Objective:
Move Agents from an existing SentinelOne deployment into the Guardz Managed SentinelOne as part of the Ultimate plan.
Note: Guardz also offer a "Bring Your Own" option to integrate your existing SentinelOne licenses without the need to migrate them. Learn more about BYO.
Prerequisites:
You must have Global or Account permission for the source (existing) SentinelOne Console.
Note: To move Agents to a different site within Guardz, please reach out to our support team.
You must have Admin rights for the Guardz platform to retrieve the token for the new Site.
Endpoints of the Agents to move:
Must run a supported operating system and meet other system requirements.
Must not have unresolved threats.
Must not be in a Full Disk Scan.
To see the status of the scan, in Endpoints, expand Columns and select Full Disk Scan.
Make sure the endpoint is not configured as an AD Connector. Migration of AD Connector from one site/account to another is not supported.
To see if the endpoint is configured an AD Connector, in the Singularity Operations Center side bar click Policy & Settings > Exposure Management > Active Directory.
To migrate Agents:
In the source Management Console, select the endpoint to migrate.
You can select one or more endpoints, a Group or a saved filter set, or all results of a search if they show on one page.
From version Tokyo GA you can run these actions on filter results that include a filter with a CSV file, even if the filter is not saved.
Click Actions > Agent Actions > Migrate Agent.
Copy the Site token from the Guardz deployment drawer and paste it in the site token field.
Target site token can be found in the Guardz platform Security Controls > Endpoint Security > SentinelOne > Deploy > View Site Token
Click Move.
Click Approve and then OK.
The Agent connects to the Management Console and reloads the services. If users see a message from the operating system, such as the
Turn on virus protection, the Agent is not yet loaded and connected. The message will disappear when the reload and connection is done.Local configuration files are kept with the Agent. New management assets are applied after the next keep-alive communication with the new Management Console.
Note: The Agent tries to connect to the new Management Console for 3 minutes. If the Agent cannot connect, it stays in the original Management Console.
If you select an endpoint that cannot be migrated, the endpoint is skipped, but the migration runs on supported endpoints.
To see Agent migration status:
In the sidebar, click Sentinels.
Endpoints opens.
In the filters, scroll right to see the Console Migration Status.
Expand Columns to select the Console Migration Status column, or to make sure it is selected.
If necessary, scroll right in the Endpoints page to see the column.
Migration status values:
N/A - No migration command was sent.
Pending - The Agent is trying to migrate. For Agents that are online, after a maximum of four minutes, the status changes to Migrated or Failed. If the Agent is offline the migration status will stay Pending. The migration status will change if the Agent comes online and handles the migrate command.
Migrated - The Agent moved successfully to the new Management Console. It shows as Offline in the original Management Console.
Failed - The Agent failed to move and stays in the original Management Console.
To see Agent migration in the activity log, filter to Administrative > Move to another console.
To migrate an Agent to a different Console with SentinelCTL:
The source Site Token must be for a Site NOT already provisioned by Guardz in the same region. These commands will fail without indication if the token is for a Site on the source Console. They succeed if the UUID of the Agent is not already registered with the target Console.
Windows
sentinelctl bind SiteToken
Then run the following commands:
sentinelctl unload -m -k “passphrase”
sentinelctl load - m
This will reload the monitor on Windows and allow the agent to move.
macOS
sudo sentinelctl set registration-token -- SiteToken
Linux
sentinelctl management token set SiteToken
Troubleshooting
This section will attempt to covery what to do if you try to move Agents to a different Management Console or Account, but the command fails.
Possible Causes:
There are different possible causes and workarounds. This troubleshooting goes through issues from the simplest troubleshooting steps and solutions to the more complex.
If all the Agents fail to migrate:
Make sure you have Global or Account permissions for the source and admin permissions with Guardz.
Make sure the new Account and Site are valid (not expired and have enough licenses for the new Agents).
Make sure you used the correct Site token.
Note: You can click the download icon in the Activity Log to download a CSV file with a list of endpoints and error messages.
Make sure the failed Agent was not in a Full Disk Scan:
See if there was a scan in progress: Sentinels > Endpoints >show the Full Disk Scan column.
If the value of the column is not Completed, wait for the scan to complete and then run the migration again.
If this was not the issue, go to the next troubleshooting step.
Make sure the failed Agent did not have unresolved incidents:
In Sentinels > Endpoints, select the Agent that failed to move.
Click Actions > Shortcuts > View Threats.
Incidents opens. Click Select filters and then click Incident status > Unresolved.
Mitigate each incident and then set the incident to Resolved.
If there were unresolved incidents, run the migration again when all incidents are resolved.
If this was not the issue, go to the next troubleshooting step.
Test network requirements:
If your network blocks URLs or IP Addresses that are not specifically allowed, it can block the Agent connection to the new Management Console.
Test DNS resolution on the local endpoint for the new Console. On the endpoint, open a command prompt and run:
nslookup <Management Console FQDN>
Example:
nslookup myconsole.sentinelone.netIf the output is at least one IP address, the Agent can communicate with the Management Console.
If the output does not show IP addresses, show the content of Services and Ports for Management to your IT or firewall team.
If there is a proxy between the Agent and the new Console:
If there was a different proxy before migration, change the proxy configuration.
The Agent must reach the proxy through a VPN. Make sure the endpoint has a VPN client installed and that it was authenticated with the VPN during the migration.
If there was not a proxy before but there is one now, open a ticket with SentinelOne Support or your vendor. This might not be the only issue. Continue with troubleshooting, but make a note to get help with Agent updates for proxy configuration after installation.
Make sure the Agent can communicate with the new Console in three minutes or less.
If the Agent cannot connect to the new Management Console in three minutes, it stays in the original Management Console.
If there were network issues, run the migration again when the network requirements are resolved.
If this was not the issue, go to the next troubleshooting step.
Make sure the endpoint shares a cipher suite with the Management Console:
If the endpoint of the failed Agent does not share at least one cipher suite with the server of the Management Console, they cannot communicate.
Run the SentinelOne utility that shows if the Agent and the Management Console share at least one cipher suite.
If there is not a shared cipher suite, add at least two to the endpoint.
Make sure to move the shared cipher suites to the top of the list and reboot the endpoint.
If there were missing cipher suites, run the migration again after the endpoint reboots.
If this was not the issue, go to the next troubleshooting step.
Make sure the endpoint is on a supported operating system:
If the OS of the endpoint is not supported, you cannot migrate the Agent.
We recommend that you update the Agent to the latest possible version and then update the OS.
Contact Support for assistance.