Konventionelle Konfiguration,
Client: Sekundärserver
Server: Primärserver
Konfiguration für erweiterte Verfügbarkeit,
Client: Anwendungsserver und Standby-Server
Server: Hintergrundserver

Überprüfen Sie die Voraussetzungen.
Änderungen Sie auf CA SDM. Fügen Sie in diesem Beispiel das neue Feld auf der CA SDM-HTMPL-Seite hinzu.
Ändern Sie die Versionskontrolldatei des Servers.
Neustart von CA SDM auf dem Client.
Überprüfen Sie die Anpassungen auf dem Client.

Stellen Sie sicher, dass die Option "ver_ctl" auf den Wert "
Aktualisieren
" festgelegt ist. Wenn ein Versionsunterschied erkannt wird, dann wird versucht, die betroffenen Komponenten auf dem Client zu aktualisieren. Wenn das Upgrade erfolgreich ist, bleibt die Client-Verbindung mit dem Server bestehen. Anderenfalls wird die Verbindung getrennt. Weitere Informationen zur Option "ver_ctl" finden Sie in der
Online-Hilfe
.
Stellen Sie sicher, dass die Datei "server_secondary_custom.ver" im Verzeichnis "$NX_ROOT\site\mods" vom Primärserver oder Hintergrundserver (abhängig von der CA SDM-Konfiguration) erstellt wird. Alle Anpassungen einer Versionskontrollkomponente müssen in dieser Datei vorgenommen werden. Wenn die Datei nicht vorhanden ist, stellen Sie sicher, dass Sie sie am gleichen Speicherort erstellen.

Melden Sie sich abhängig von Ihrer CA SDM-Konfiguration bei folgendem Server an:
Konventionell: Primärserver
Erweiterte Verfügbarkeit: Hintergrundserver
Wechseln Sie in das folgende Verzeichnis:
$NX_ROOT\site\mods
Öffnen Sie die Datei "server_secondary_custom.ver".
Fügen Sie folgende Komponenten hinzu:
[ MY_USP_SERVERS_HTMPL ]
directory="$NX_ROOT/site/mods/www/htmpl/web/analyst/Analyst"
filename="detail_usp_servers.htmpl"
version="2.0 , 20121119"
o_mode="RW"
g_mode="RW"
w_mode="RW"
file_ctl
Weitere Informationen über das Hinzufügen oder Aktualisieren von Versionskontrollkomponenten finden Sie im Abschnitt Versionskontrollkomponenten.
Speichern Sie die Datei "server_secondary_custom.ver".
Die Versionskontrollkomponente wird der Versionskontrolldatei hinzugefügt.

Verwenden Sie folgende Syntax. Elemente in
Kursivschrift
entsprechen Daten, die Sie bereitstellen. Die Parameter
component-name
und Versionsparameter sind immer erforderlich. Andere Parameter sind abhängig vom Wert für "
control-type
" erforderlich. Alle anderen Elemente sind Schlüsselwörter, die Sie genau wie m folgenden Beispiel gezeigt eingeben müssen:
[ component-name ]
version = "x.x, yyyymmdd"
control-type
filename = "filename"
directory = "directory"
link = "link-directory"
source = "source-directory"
effectivity = "effect-spec"
checksum
min_release = "release"
max_release = "release"
component_type = "file-type"
o_mode = "owner-mode"
g_mode = "group-mode"
w_mode = "world-mode"
Weitere Informationen zu den Parametern finden Sie unter Versionskontrollparameter. Weitere Informationen zur Struktur und Syntax der Versionskontrolldateien finden Sie in den ".ver"-Dateien, die im Verzeichnis "$NX_ROOT\site" installiert sind. Diese Dateien enthalten nützliche Kommentare und Beispieleinstellungen, die Ihnen helfen können.

Ändern Sie den Parameter. Ändern Sie zum Beispiel die Versionsnummer.

Bearbeiten Sie die Komponente folgendermaßen:

! uncontrol component-name

[ component-name ]
Gibt den Namen eines Elements unter Versionskontrolle an. Der Name muss eindeutig sein und in eckigen Klammern angegeben werden. Bei
component-name
muss nicht auf Groß- und Kleinschreibung geachtet werden. Dieser Parameter ist für eine Komponentendefinition erforderlich.
Version="x.x. yyymmd"
Gibt eine Versionsnummer (
x.x
) und ein Datum (
yyyymmdd
) an, die die Version der Komponente definieren. Dieser Parameter ist erforderlich und muss in Anführungszeichen eingeschlossen werden. Die Versionskontrolle prüft die Version einer Komponente, indem sie die Versionsnummer und das Datum auf dem Server mit der Versionsnummer und dem Datum auf dem Client vergleicht. Sowohl die Versionsnummer als auch das Datum müssen übereinstimmen, damit die Komponente als synchron zwischen Client und Server betrachtet wird. Wenn die Prüfsummeneigenschaft aktiviert ist, wird die Datei vor ihrer Aktualisierung durch eine Prüfsummenverifizierung geprüft.
control-type
Gibt den Typ der Versionskontrolle für diese Komponente an. Die folgenden Einstellungen sind für "Kontrolle-Typ" gültig:

filename="filename"
Gibt den Namen einer Datei unter Versionskontrolle an. Dieser Parameter enthält keine Angaben zum Verzeichnis. Er ist für file_ctl-Komponenten erforderlich, ist aber für Komponenten mit Verzeichniskontrolle (dir_ctl) optional. Wenn der Dateinamenparameter zusammen mit Verzeichniskomponenten verwendet wird, fungiert er als Dateimaske, um die mit der dir_ctl-Komponente verbundenen Dateien einzuschränken. Wenn zum Beispiel der Dateiname für eine dir_ctl-Komponente *.README lautet, dann schließt ein Upgrade dieses Verzeichnisses nur Dateien ein, die mit „.README“ enden.
directory="directory"
Gibt den Pfad zum Verzeichnis für dir_ctl-Komponenten oder zu dem Verzeichnis an, das die Datei für file_ctl-Komponenten enthält. Dieser Parameter wird für ver_ctl- und nxenv_ctl-Komponenten ignoriert. Der Verzeichnispfad muss in Anführungszeichen eingeschlossen werden und kann Verweise auf Umgebungsvariablen enthalten, wobei $ vorangestellt werden muss.
Um Unterverzeichnisse im Pfadnamen zu trennen, verwenden Sie immer den Schrägstrich (nicht den umgekehrten Schrägstrich), auch auf einem Windows-Server.
link="link-directory"
Gibt ein Link-Verzeichnis auf dem Client im gleichen Format an, das zuvor für Verzeichnisparameter beschrieben wurde. Dieser Parameter ist optional für file_ctl- und dir_ctl-Komponenten und wird für ver_ctl- und nxenv_ctl-Komponenten ignoriert. Wenn er angegeben wird, dann wird bei einem Upgrade auf einem Linux-Client ein symbolischer Link ins Link-Verzeichnis gestellt. Dieser verweist auf die eigentliche Datei, die in die im Verzeichnisparameter angegebene Position kopiert wurde. Bei einem Upgrade auf einem Windows-Client wird die eigentliche Datei sowohl in den Link- als auch in den Verzeichnisspeicherort kopiert.
source="source-directory"
(Optional) Gibt ein anderes Verzeichnis auf dem Server an, aus dem der Server Dateien zur Bereitstellung abrufen kann. Dieser Parameter hat das gleiche Format, das zuvor für den Verzeichnisparameter beschrieben wurde. Er ist nützlich, wenn die dem Client bereitzustellenden Dateien sich von den gleichen Dateien im Verzeichnisspeicherort auf dem Server unterscheiden. Dieser Parameter wird verwendet, um dem Server mitzuteilen, dass die Datei aus dem
source-directory
abgerufen und an dem im Verzeichnisparameter angegebenen Speicherort auf dem Client bereitgestellt werden soll. Der Verzeichnisparameter ist erforderlich, wenn Sie den Quellparameter angeben.
effectivity="effect-spec"
(Optional) Gibt an, ob der Client diese Komponente erhalten soll. Hiermit können Sie den Download zu einigen Clients ausschließen. Wenn ein Client in die Effektivitätsangabe nicht eingeschlossen ist, erhält er die Komponente nicht. Wenn dieser Parameter nicht angegeben wird, erhalten alle Clients die Komponente. Die Effektivitätsangabe verwendet die folgenden Symbole:
+ (Pluszeichen)
Gibt an, dass eine Clientgruppe hinzugefügt werden soll.
- (Minusvorzeichen)
Gibt an, dass eine Clientgruppe ausgeschlossen werden soll.

SUN4SOL
AIX
LINUX
LINUX390
HP
WINDOWS_CLIENTS
UNIX_CLIENTS

effectivity = "+ UNIX_CLIENTS"

checksum
Weist die Komponente zur Aktualisierung an, wenn die Prüfsumme der Komponente auf dem Client nicht mit der entsprechenden Prüfsumme auf dem Server übereinstimmt. Wenn der Parameter für ein Verzeichnis gilt, wird die Prüfsumme auf jede Datei angewandt.
min_release=“release” und max_release="release"
Gibt den ältesten und neuesten Client an, an den diese Komponente verteilt werden soll. Versionen werden durch Anweisungen in der Datei "server_default.ver" definiert. Diese Parameter haben folgende Form, wobei Ga
xx
die Version angibt und die folgenden Werte mit der Version verbundene „genlevels“ sind.
! Release GA50 50MVV000900 50W7T000900
! Release GA45 45MW000900 50WTT000900
Die Reihenfolge gibt an, dass GA50 neuer ist als GA45.
component_type
Gibt den Typ der verwendeten Komponente an. Folgende Typen von Komponenten werden verwendet:

o_mode="owner-mode"
Gibt die Dateizugriffsberechtigungen für den Eigentümer der Datei an.
g_mode="group-mode"
Gibt Dateizugriffsberechtigungen für Anwender in der Dateieigentümergruppe an (wird nur für UNIX-Clients verwendet).
w_mode="world-mode"
Gibt Dateizugriffsberechtigungen für Anwender an, die nicht in der Dateieigentümergruppe enthalten sind (wird nur für UNIX-Clients verwendet).
Mit den drei mode-Parametern können verschiedene Versionen derselben ausführbaren Datei auf dem Server verwaltet werden. Sie geben Zugriffssteuerungen für die Datei an, wenn diese auf den Client kopiert wird. Diese Parameter werden nur während eines Upgrades verwendet. Sie bestehen aus einen bis drei Zeichen, die folgende Bedeutung haben:

Starten Sie für die konventionelle Konfiguration den sekundären Server neu.
Führen Sie für die Konfiguration für erweiterte Verfügbarkeit folgende Schritte aus:
Starten Sie alle Standby-Server neu.
Wählen Sie einen Anwendungsserver aus, der wenig aktiv ist.
Starten Sie den Anwendungsserver neu, der wenig aktiv ist.
Halten Sie den anderen Anwendungsserver an.
Starten Sie den Anwendungsserver.
Führen Sie die Schritte "d" und "e" für weitere Anwendungsserver aus.
Der Client stellt eine Verbindung mit dem Server her, um eine Liste der gesteuerten Komponenten zu senden. Der Server vergleicht die Liste mit seiner eigenen Hauptliste. Die betroffenen Komponenten auf dem Client werden aktualisiert.

 
pdm_webstat 

(Empfohlen) Fordern Sie alle aktiven Support-Automatisierungs-Analysten auf dem Anwendungsserver, den Sie anhalten möchten, dazu auf, ein Ticket in CA SDM mit ihren Sitzungsinformationen zu erstellen. Dieser Vorgang stellt sicher, dass die Sitzungsinformationen nicht verloren gehen. Zum Beispiel ist der Support-Automatisierungs-Analyst in einer Sitzung mit einem Kunden, um einen Hardware-Issue zu lösen. In diesem Fall kann der Support-Automatisierungs-Analyst einen Issue in CA SDM mit den Sitzungsinformationen erstellen, bevor der Anwendungsserver heruntergefahren wird.
Senden Sie eine Benachrichtigung (zum Beispiel eine E-Mail-Benachrichtigung) an alle aktiven Anwender auf dem Anwendungsserver, in der die Anwender aufgefordert werden, zum Anwendungsserver, der am wenigsten aktiv ist und den Sie gerade neu gestartet haben, zu wechseln. Diese Benachrichtigung kann die Details des aktualisierten Anwendungsservers enthalten.
Führen Sie folgenden Befehl auf dem Anwendungsserver aus:
 
pdm_server_control [-h] -q interval -s server_name 
-h
Zeigt die Hilfeseite an.
-q interval -s server_name
Benachrichtigt einen lokalen Anwendungsserver oder einen Remote-Anwendungsserver, eine Stilllegung in einem angegebenen Zeitintervall durchzuführen. Dieses Intervall ist die Anzahl von Sekunden, bevor der Server offline geschaltet wird. Wenn Sie diese Option ohne "Servername" verwendet, dann wird der lokale Server zur Stilllegung benachrichtigt. Diese Option kann für einen Hintergrundserver oder einen Standby-Server nicht verwendet werden.
Eine Pop-up-Meldung wird allen aktiven Anwendern auf dem Anwendungsserver angezeigt. Die Meldung weist auf das Herunterfahren des Servers und auf die verbleibende Zeit bis zum Herunterfahren hin. Die Anwender müssen ihre Arbeit speichern und sich innerhalb dieser Zeit abmelden. Der Anwendungsserver wird nach der angegebenen Zeit angehalten. Die Anwender melden sich auf dem anderen Anwendungsserver an, um ihre Arbeit fortzusetzen. Der Support-Automatisierungs-Analyst kann sich auf das Ticket beziehen und seine Arbeit fortsetzen.
Der Anwendungsserver wird erfolgreich angehalten.

Melden Sie sich abhängig von Ihrer CA SDM-Konfiguration auf folgendem Client an:
Konventionell: Sekundärserver
Erweiterte Verfügbarkeit: Standby-Server und Anwendungsserver
Öffnen Sie die Datei "stdlog" vom folgenden Speicherort:
$NX_ROOT\log
Finden Sie heraus, ob alle auf dem Server vorgenommenen Anpassungen auf dem Client angewendet wurden.