New Ranks & Badges For The Community!
Notice something different? The ranks and associated badges have gone "Star Fleet". See what they all mean HERE
Highlighted
Cadet 3rd Class
Cadet 3rd Class
395 views

migrate ESM from windows to linux

I currently have an ESM installed on Windows Server 2008 R2 -- I'd like to move it to RHEL. Are there any documented procedures for doing this?

(my searches on this forum for this topic didn't yield anything)

Labels (1)
0 Likes
Reply
10 Replies
Highlighted
Commodore
Commodore

Typically, you install your new instance of ESM 6.x on RHEL on a separate piece of hardware and run it in parallel with the existing Windows server. Create a second destination in all your Connectors and / or Loggers and send the events to the new ESM. When the retention period of the Windows ESM has passed the life of the new ESM and you know everything is working on the new ESM, turn off the old Windows server. Delete the Destinations to the Windows ESM.

There are supported and unsupported ways to migrate content from the old ESM to the new ESM. The supported way is to hire an ArcSight professional. The unsupported way is to do a Package Export / Import from the old ESM to the new ESM. Some things won't come across like Trends. The reason for the unsupported nature is that the backend databases are different between the two ESMs so there is no guarantee. The supported way the content is converted from one to the other. Most of the time, I see people wanting to make a fresh start, just build all their content from scratch that really matters on the new ESM 6.x.

There are some steps in setting up the ESM on RHEL that are not stated in the documentation which are show stoppers. I suggest you engage an ArcSight professional but I am biased since I am one. Follow everything else in the ESM 6.x documentation or you will have performance issues.

0 Likes
Reply
Highlighted
Cadet 3rd Class
Cadet 3rd Class

Thanks for your reply. What if i weren't going to move the ESM instance to a new machine per say.. I'd like to backup the ESM directories, wipe the existing box, install rhel, restore the directories and start the ESM. No changing the connectors at all, ideally.

0 Likes
Reply
Highlighted
Commodore
Commodore

That is not going to work. Everything on the old ESM will be in a different format, different locations, different database, etc. than the new one. The same way you can't reinstall the installed version of LibreOffice from a Windows machine to a RHEL machine. You can move a spreadsheet file (i.e. the content) from one to the other but not the application itself. Even if you could move everything you would still at a minimum have to re-register the connector destinations anyway to import the new certificate. So you would have to touch the connectors.

0 Likes
Reply
Highlighted
Cadet 3rd Class
Cadet 3rd Class

I still plan to use the same oracle backend that i'm currently using -- are you talking about a different local database that the ESM application maintains that is separate from the oracle one?

0 Likes
Reply
Highlighted
Cadet 3rd Class
Cadet 3rd Class

I can't help but keep thinking "It's a JVM, things should be 'sort-of' similar between architectures". I don't think the certificate files will change formats between windows/linux -- they're certificate files. as long as the same files are presented to handshake @ communication time, what's the difference?

0 Likes
Reply
Highlighted
Commodore
Commodore

So what you are really saying is that you want to migrate your Manager from Windows to RHEL and keep the existing Oracle database, correct? I assumed by your question that you wanted to migrate the entire ESM from one to another. Are the Database and Manager on separate servers now? What version of ESM are you running?

A better question might be, why? You should move away from Oracle database to the CORRE database, which requires RHEL.

0 Likes
Reply
Highlighted
Cadet 3rd Class
Cadet 3rd Class

yes. Migrate the manager from windows to linux. The oracle database is on a separate server. v5.2.

I've been considering upgrading to 6.. It's just not in the cards right now.

0 Likes
Reply
Highlighted
Commodore
Commodore

It is probably possible for you to get this to work. No guarantees.

You will need to get at least the cacerts, server.properties, license, jetty directory and keystore off the old Manager and onto the new one. I would backup both servers in a way so complete that if this goes bad you can restore everything.

Then do a new install of the RHEL version of 5.2 Manager. When you get to the point where it asks new install or upgrade hit Cancel. Then copy all the old info to their proper locations. Then start the setup again with arcsight managersetup. I think you might have to Cancel the install at later points in the process as well. It is going to be tricky.

You definitely can't go the other way - if the Database changes, fails, etc. the Manager is shot. The Database can survive a Manager failure and restore thus you might be able to pull this off. You want to look for documentation about restoring a Manager from a backup. That will probably give you all the steps you need.

Good luck. You will need it. Let me know how it turns out.

0 Likes
Reply
Highlighted
Vice Admiral
Vice Admiral

Take a look at Knowledge Base article # KM1271176.  I Think Gregory covered most of it, except for notifications and case customizations.  This process should work for migrating between OS platforms.  The only other thing to be mindful of is owner/group on the files you upload to your Manager, that they have the "arcsight:arcsight" user/group ownership, and not root.

0 Likes
Reply
Highlighted
Commander
Commander

I agree, installing the exact same ESM version on linux and moving crucial parts of the old install to the linux box might work. Best also configure linux box on the same ip as the old ESM or if not possible at least switch the DNS entry over.

I suppose support will start to laugh hysterically if you fail and ask for help though... Or try to get PS on site for this if they dare.

Joachim

0 Likes
Reply
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.