Manuelles Aktualisieren von Agenten

Jeder Benutzer mit den notwendigen Berechtigungen kann einen Agenten auf eine andere Version aktualisieren.

Hinweise:

  • Verwenden Sie bei der Benennung der Verzeichnisse für die Automation Engine und den Agenten keine Leerzeichen. Weitere Informationen finden Sie unter https://support.microsoft.com/en-us/help/102739/long-filenames-or-paths-with-spaces-require-quotation-marks.

  • Überprüfen Sie die compatibility matrix um zu erkennen, welche Version mit Ihrem System kompatibel ist. Weitere Informationen finden Sie unter Kompatibilitätsinformationen.

  • Agenten, die auf Windows Server 2012 und höheren Versionen ausgeführt werden: Um Probleme beim Ausführen von Aktionen zu vermeiden (Zugriff verweigert), sollten Sie den Wert für Benutzerkontensteuerung: Alle Administratoren im Administrator-Genehmigungsmodus ausführen in den Abschnitten Sicherheitseinstellungen, Lokale Richtlinien/Sicherheitsoptionen der lokalen Sicherheitsrichtlinien-Anwendung (secpol.msc) auf Deaktiviert ändern. Dies stellt sicher, dass der Windows-Agent, der das lokale Windows Administrator-Konto verwendet (in der Administratorgruppe), Aktionen richtig ausführt.

Diese Seite beinhaltet Folgendes:

Erneute Authentifizierung von Agenten nach einer Aktualisierung

Wenn Sie Agenten haben, die bereits mit den Authentifizierungsmethoden LOCAL oder LOCAL-REMOTE authentifiziert wurden und Sie sie aktualisieren möchten, müssen Sie sicherstellen, dass das initalPackage weiterhin verfügbar ist, da Sie die Agenten nach der Aktualisierung erneut authentifizieren müssen. Weitere Informationen finden Sie unter Agenten-Authentifizierung.

Dies gilt nur für manuelle Aktualisierungen von Agenten. Wenn Sie die Centralized Agent Upgrade (CAU) verwenden, ist initialPackage standardmäßig enthalten.

Aktualisieren von GSS auf TLS/SSL-Agenten

Die Kommunikation zwischen der AE und dem AWI sowie zwischen der AE und den Windows-, UNIX- und Java-Agenten verwendet TLS/SSL über ein sicheres WebSocket (WSS). Diese Komponenten richten eine Verbindung mit dem Java-Kommunikationsprozess (JCP) ein.

Der Java-Kommunikationsprozess (JCP) verwendet vertrauenswürdige Zertifikate, um seine Identität anderen Kommunikationspartnern gegenüber nachzuweisen, und benötigt einen Keystore, um mit diesen Zertifikaten zu arbeiten. Deshalb müssen Sie den Java-Kommunikationsprozess (JCP) installieren und konfigurieren und sicherstellen, dass Sie die erforderlichen Zertifikate haben.

Windows-, UNIX- und Java-Agenten können verschiedene Parameter in ihrer entsprechenden INI-Datei verwenden, um zu definieren, wie man die Zertifikate bearbeitet.

Hinweis: Die TLS/SSL-Implementierung gilt nicht für die HP-UX- und ZLINUX (32 Bit)-Agenten, da sie nicht mehr unterstützt werden.

Stellen Sie sicher, dass Sie die Eigenschaften definieren, die erforderlich sind, um eine Verbindung zum Java-Kommunikationsprozess (JCP) herzustellen und die relevanten Zertifikate in der jeweiligen Agent-INI-Datei zu bearbeiten.

Definieren Sie dazu den Wert für die JCP-Verbindung unter Verwendung des Parameters connection= im Abschnitt TCP/IP der INI-Datei. Der Standardwert ist jcphost:8443.

Um einen TLS/SSL-Agenten nach der Aktualisierung zu starten, benötigt der Agent das JCP-Zertifikat (jcp.cer), um eine Verbindung zur Automation Engine herzustellen.

Wenn Sie von einer Zertifizierungsstelle signierte Zertifikate verwendet haben, werden die Zertifikate standardmäßig im entsprechenden Java- oder Betriebssystemspeicher gespeichert: dem Java Trust Store für Java-Komponenten und Java-Agenten, dem Windows-Betriebssystemspeicher für Windows-Agenten und dem TLS/SSL-Speicher für UNIX-Agenten. In diesem Fall müssen Sie nur prüfen, ob die Root-Zertifikate bereits im jeweiligen Speicher sind.

Wenn sich die relevanten Zertifikate nicht dort befinden und Sie sie importieren möchten, können Sie für diesen Zweck für das Betriebssystem oder Java spezifische Tools verwenden, wie zum Beispiel Keytool, cert-manager, OpenSSL usw. Weitere Informationen zur Verwendung dieser Tools finden Sie in der entsprechenden Produktdokumentation.

Wenn Sie nicht den Standardspeicherort für die oben aufgeführten Komponenten und Agenten verwenden möchten, stellen Sie sicher, dass Sie die Parameter trustedCertFolder=, agentSecurityFolder= und keyPassword= (falls zutreffend) in der entsprechenden Konfigurationsdatei (INI) verwenden, um den Pfad zum Ordner zu definieren, in dem die vertrauenswürdigen Zertifikate gespeichert sind.

Dies gilt für die folgenden Agenten:

Nicht-TLS/SSL-Agenten wie BS2000, NSK, OS/400, VMS und z/OS benötigen das TLS Gateway, das den FileTransfer zwischen TLS/SSL- und Nicht-TLS-/SSL-Agenten ermöglicht.

Mehr Informationen:

Liste "Agenten"

Der manuelle Aktualisierungsprozess selbst unterscheidet sich nicht von einer neuen Agenten-Installation. Alle verfügbaren Agenten sind unten aufgeführt. Um die Anweisungen zur Installation zu sehen, klicken Sie bitte auf den entsprechenden Link.

Hinweis: Passen Sie die INI-Datei des jeweiligen Agenten an, wenn Sie einen Agenten auf seine TLS/SSL-Version aktualisieren.

Siehe auch:

Centralized Agent Upgrade (CAU)