Wie Migriert man einen Epolicy Orchestrator 3 Schritt für Schritt auf einen Epolicy Orchestrator 4 ohne Active Directory.
How to Migrate Epo 3.x to Epo 4.x step by step without AD (active directory)
( Need this in English? Mail me -> marcodifeo [AT] gmx.de)
Wer von dem Produkt McAfee Epolicy Orchestrator auf eine neue Version migrieren will hat mehrere Möglichkeiten dies zu bewältigen.
Am einfachsten geht es mit einem Microsoft Active Directory um die vorhandenen Clients Schritt für Schritt umzuziehen. Hat man keine AD zur Hand so ist eine Schritt für Schritt Migration scheinbar nicht möglich.
Hier kann man, laut dem McAfee Support nur den großen Schalter umlegen und den Dns Eintrag auf den neuen Server leiten. Das es an manchen Ecken knallt läßt sich vorab kaum im großen Umfang testen.
Es gibt aber doch einen Weg, eine Schrittweise Migration ohne ADS durchzuführen.
Hierbei handelt es sich aber um ein undokumentiertes “Feature”, deshalb sollte man dies nur im außersten Notfall durchführen und nur dann, wenn Sie wissen, wie Sie im Notfall einen Epo Server neu installieren können.
Ich habe dieses Verfahren schon an zwei Servern erfolgreich getestet (einmal ~100 Clients und einmal knapp 4.500 Clients. Beides lief problemlos und reibungslos).
Folgende voraussetzungen sind dafür nötig:
- Einen funktionierenden Epo 4 Server
- Einen funktionierenden Epo 3.6.x Server (letzter Patchstand)
- Diverse Clients an beiden Servern
Was haben wir vor?
Der Orchestrator bietet leider keine Möglichkeit über die GUI ein zweites Master Repository hinzuzufügen. Dies wollen wir mittels kleinerer Eingriffe bewerkstelligen.
D.h. wir fügen einen zweites Master Repository hinzu und steuern dann komfortabel über die Richtlinien, welches Verzeichnis/Clients sich auf dem neuen Server melden soll.
Wie geht das?
Der erste Schritt ist auf einem Client der schon mit dem Epo4 Client Kommuniziert, oder auf dem Epo4 Server selbst nachzusehen, wie der Eintrag für das Master Repository des Epo4 lautet.
Hierfür muss man in den entsprechenden Sitelist.xml/Sitemgr.xml nach dem
Dieser Eintrag könnte wie folgt aussehen:
Diesen Eintrag kopiert man aus dem entsprechenden XML heraus und speichert diesen erst einmal zwischen.
Nun meldet man sich (Remote/Lokal) am Epo3 Server an und sucht nach den Dateien Sitelist.xml und Sitemgr.xml.
Diese befinden sich normalerweise unter:
- C:\\Programme\\McAfee\\ePO\\3.6.1\\Sitelist.xml
- C:\\Programme\\McAfee\\ePO\\3.6.1\\Sitemgr.xml
- C:\\Programme\\McAfee\\ePO\\3.6.1\\DB\\Sitelist.xml
- C:\\Programme\\McAfee\\ePO\\3.6.1\\DB\\Sitemgr.xml
Um diese Einstellungen zu überschreiben muss der Epo3 Service kurzzeitig abgeschalten werden.
Der neue “SpipeSite” Eintrag, der zuvor zwischengespeichert wurde muss nun in alle vier der oben genannten XML Dateien eingetragen werden und zwar direkt hinter(!!!) den vorhandenen SpipeSite Eintrag, der für den alten Epo3 Server zuständig ist.
(Logischerweise muss man hier beachten, dass man das XML File nicht zerstört, weil geöffnete Tags nicht korrekt geschlossen werden. Der neue Eintrag muss hinter den schliessenden Tag eingefügt werden).
Nun kann der Server wieder gestartet werden. Bevor wir nun zum nächsten Schritt gehen und allen Clients mitteilen, dass es ein neues Master Repository gibt sollte in allen Richtlinien unter “Epo Agent 3.6.0” der Haken beim neu hinzugefügten Master Repository entfernt werden.
Somit stellen wir sicher, dass der Client sich auf jeden Fall beim Epo3 Server meldet und den Epo4 Server ignoriert.
Hat man dies erledigt können wir nun den Clients berichten, dass es eine neue Sitelist.xml und sitemgr.xml gibt. Hierfür genügt es ein neues verteiltest repository gibt. Hier kann ein nicht vorhandenes Repository eingetragen werden. Nach dem das neue verteile Repository angelegt wurde
können wir dies wieder löschen. Der Epo3 Server hat im Hintergrund den Timestamp für den Catalog aktualisiert (genau das, was wir wollten) und gibt somit den Clients das Zeichen sich die neuste Version der Sitelist.xml und Sitemgr.xml herunterzuladen.
Die Grundvoraussetzungen wären somit erledigt.
Was passiert nun und welche Probleme gibt es?
Probleme gibt es eigentlich keine. Bisher ist nur aufgefallen, das Epo Agenten, die sich zwar am Epo3 Server melden, aber keine Richtlinien erhalten sich am Epo4 Server melden.
Da diese Computer aber sowieso niemals Richtlinien erhalten haben ist das eher unproblematisch. Die Anzahl “defekter” Agenten sollte sich im einstelligen Prozentbereich bewegen.
Warum diese Agenten sich auf dem neuen Server melden hat folgenden Grund. Der Agent bekommt eine neue Sitelist.xml mit zwei Master Repositories. Da der Agent keine Richtlinien
erhält weiss er auch nicht, dass er sich nicht(!) am Epo4 melden soll und versucht sein Glück dort.
Richtet man eine neue Agent 3.6.0 Richtlinie für ein Verzeichnis ein, oder bearbeitet die bereits verfügbare so muss man nun das “alte” Epo3 Repository deaktivieren und das “neue”
Epo4 Repository aktivieren. Dann melden sich die Clients (evt. nach einer Agentenreaktivierung) bei dem neuen Server und erhalten dort wiederum ein neues, sauberes Sitelist.xml / Sitemgr.xml.
D.h. die migration verläuft nach dem sich der Agent am neuen Server meldet sehr sauber.
Melden sich nun Agenten, die bereits längere Zeit Ausgeschaltet waren am Epo3 Server bekommen Sie erst die neue Sitelist.xml/Sitemgr.xml und melden sich dann im zweiten Schritt am neuen Epo4 server.
Information: Dieses Verfahren geht nur von einer 3.x/3.6.x Version zu einer 4.x. Will man Clients von einem Epo4.0 auf einen anderen Epo4.0 umstellen bekommt man hier schwierigkeiten, weil der Client ab der Epo4 Version die Kommunikation gegen “Man in the Middle” Attacken über den Server Schlüssel absichert und dann die Verbindung verweigert.
Wichtig [Nachtrag]: Da ab der Version 4 (Orchestrator) die Kommunikation zwischen Server und Client über ein Key Verfahren funktioniert kann dieser Schritt nur von einer Version < Orchestrator 4 auf die neue Version erfolgen. Für zukünftige Wechsel zwischen zwei Orchestrator 4 Servern kann dieses Verfahren nicht angewandt werden.
Zur Sicherheit sollte man im Übrigen die Serverkeys eines Orchestrator 4 Servers exportieren, damit man nicht etliche Clients neu installieren muss, falls der Server einmal crashen sollte. Ein funktionierendes Backup sollte es allerdings auch tun.
Englisch Version:
We used Novell directory services in the past and had a extreme decentralized structure with many novel servers and many “local” admins.
The main problem was, that we had ~5k clients but no administrative access to all computers and no software
distribution up and running, that could do the installation process of a new mcafee agent for us, so the only (usefull) similarity on every computer was a working EPO 3.6.1. client, nothing else.
(If you have a software distribution for all clients you can just export a new agent from the epo console and deploy the file to all Clients.)
We talked to McAfee support and they told us that the only way to migrate the old agents to a new
epo server was changing the dns server or upgrading the old epo server 3.6x to 4.x, but this “big bang”
solution wasnt the solution we want to try out in our productive environment with 5k+ agents.
If something went wront we would have spent the next month with fixing all agents.
What we want to do is a smooth migration of ~100-1000 clients per day to see if everything works fine without killing every mcafee agent.
After some testing and playing around with the xml files on the epo server, we found out that we can add a second
master repository, which is impossible via the epo console (and probably not wanted either). After adding a second master repository to the epo server you can control which client connects to which master respository by policy.
What we need to get started:
- A working Epo 4 Server
- A working EPO 3.6.x Server (latest patches/hotfix installed)
- Clients on every Server
How can i add a master repository?
The first step is to copy the spipesite string from Sitelist.xml/Sitemgr.xml (@ %appdata%) from a running epo agent that is connected to the epo 4 server.
Next, you connect to your epo server, stop all running epo services and find all Sitelist.xml/Sitemgr.xml files (at my server it was C:\Programme\McAfee\ePO\3.6.1).
Now put the spipesite entry from step one in every sitelist/sitemgr.xml file (also sitelist/sitemgr.xml in the C:\Programme\McAfee\ePO\3.6.1\DB\ folder).
Please make some backups of the files before overwriting them and prevent the xml structure from becoming corrupt. Enter the spipesite entry directly after the existing one, save it, redo step 1-(hmm)3 for each file and you are done.
Now you can restart the server or your services.
To prevent the clients from falling back (if epo3.x it timed out) to the new epo4 repository i recommend to deactivate the second epo4 master repository in every available policy (epo console).
Now, you have a second master repository for epo4 that is deactivated in every policy, but the clients didnt know anything about that,
because the catalog file (file with a timestamp of the last changes) that is responsible for letting the client know that they have to download something, hasn’t changed.
So the next step is adding a new, non existing distributed (not master) repository, save it and delete it afterwards. The catalogfile is updated and every client gets the new sitelist/mgr.xml files from the server, YAY.
Now you can start to migrate your clients by changing the policy. We had a huge folder structure within the epo console, so every folder with ~100 clients was migrated manually by hand by changing the primary master repository.
We deactivated the epo3.x master repository and activated the epo4.x master repository and every client who received this policy connected to the new server, received the new xml files and policies and deleted the downloaded “patched” xml files from the epo3.x server.
We created some testing environments (2x 2 Server, 10 clients) to see if there was a problem, but everything worked fine so we migrated our dev environment and afterwards our productive environment successfully.
The point is that you can do this only with a 3.6 client/server structure. With version 4 (or 4.5) they use a keysharing mechanism to prevent such a “man in the middle attack” (thats what it is more or less).
With the 4.5 version you can easily add a second Epo 4.5 server to the console and migrate agents to another server.
Disclaimer:
I’m not responsible for any problems/damage caused by this tutorial. These features are all undocumented and only usable, because of some security/programming issues of the client/server communication.