Migrate to New Tenant

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Migrate to New Tenant

L3 Networker

Hi XDR Experts, 

 

For reasons, we need to migrate all the agents from existing "tenant A" to a new "tenant B" before the old one expires.

 

Is there any automated/faster way to do so? 

 

Or we need to do it manually with bunch of export and import, change to the new managing server in the old tenant.

 

For manual procedure that come up to my mind,

1) Activate new tenant

2) Under old tenant, Export profiles (malware, exploit, agent setting, device control configuration, Disk Encryption Profile ), policies, exception rules, host firewall rules, global exceptions 

3) Under new tenant, Import the settings from step2.

4) Generate new agent installer (Agent Installation Id) in new tenant 

5) Change managing server with Agent Installation Id (step 4) in the old tenant.

6) Confirm the agents appear in the new tenant.

 

Is there any missing?

 

Your comments are welcome. 

Life is full of surprise,
Just embrace it!
1 accepted solution

Accepted Solutions

L5 Sessionator

Hi @SeanDeHarris ,

 

Thank you for writing to live community!

 

The migration of endpoints and configurations in Cortex XDR is a manual process and involves planning and manual efforts for the same.

Following is being assumed here:

  1. You have no third party/ Pro Per TB license 
  2. You do not have Airgapped systems behind brokers
  3. You do not have Kubernetes agents deployed in your environment
  4. You have already whitelisted all the URLs related to the new tenant required for agent communication.

I am listing the steps down in chronological order for use case and adoption for the same.

  1. Export profiles and policies and associated exceptions.
  2. Add them and create them in new tenant.
  3. Import any custom IOC/BIOC rules created and import them to the new tenant
  4. Create dynamic endpoint groups as in the old tenant
  5. Configure global settings as per recommended practice or replicate the same(recommended to use new practice as the new instance would be on v3.7)
  6. Add hash allowlist/block list using hash exceptions
  7. Create alert exclusions as per the used case or replicate as per the old tenant
  8. Check any global exceptions or exceptions.
  9. Incident Configuration Migrations(Exclusions, Scoring, Featured Fields)
  10. Export/Import Uncommon Host Firewall Rule Groups
  11. Create and append all scheduled queries and library queries
  12. Validate and migrate test batches to see if the behaviour is same.
  13. Migrate Agents using console or cytool commands as and when applicable.
  14. Delete all the existing packages in the old tenant so that the offline existing packages become unusable for agent communication on erroneous installation.

All of this would require some coordination and efforts from your internal teams (IT, servers, infrastructure and network teams) and needs to be handled manually. 

 

Hope this helps. Please mark the response as "Accept as Solution" if it answers your query.

View solution in original post

1 REPLY 1

L5 Sessionator

Hi @SeanDeHarris ,

 

Thank you for writing to live community!

 

The migration of endpoints and configurations in Cortex XDR is a manual process and involves planning and manual efforts for the same.

Following is being assumed here:

  1. You have no third party/ Pro Per TB license 
  2. You do not have Airgapped systems behind brokers
  3. You do not have Kubernetes agents deployed in your environment
  4. You have already whitelisted all the URLs related to the new tenant required for agent communication.

I am listing the steps down in chronological order for use case and adoption for the same.

  1. Export profiles and policies and associated exceptions.
  2. Add them and create them in new tenant.
  3. Import any custom IOC/BIOC rules created and import them to the new tenant
  4. Create dynamic endpoint groups as in the old tenant
  5. Configure global settings as per recommended practice or replicate the same(recommended to use new practice as the new instance would be on v3.7)
  6. Add hash allowlist/block list using hash exceptions
  7. Create alert exclusions as per the used case or replicate as per the old tenant
  8. Check any global exceptions or exceptions.
  9. Incident Configuration Migrations(Exclusions, Scoring, Featured Fields)
  10. Export/Import Uncommon Host Firewall Rule Groups
  11. Create and append all scheduled queries and library queries
  12. Validate and migrate test batches to see if the behaviour is same.
  13. Migrate Agents using console or cytool commands as and when applicable.
  14. Delete all the existing packages in the old tenant so that the offline existing packages become unusable for agent communication on erroneous installation.

All of this would require some coordination and efforts from your internal teams (IT, servers, infrastructure and network teams) and needs to be handled manually. 

 

Hope this helps. Please mark the response as "Accept as Solution" if it answers your query.

  • 1 accepted solution
  • 2223 Views
  • 1 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!