Author: Andreas-Knoor
Publication Date: 5/2/2012 15:50
In diesem Dokument werden die notwendigen Schritte für ein Update von FirstSpirit 4.2R4 auf FirstSpirit 5.x beschrieben. Ein direktes Update von FirstSpirit 4.2R4 auf FirstSpirit 5.0, 5.1 oder 5.2 wird also unterstützt.
Hinweis: Das hier beschriebene Vorgehen wurde in der Präsentation FirstSpirit5 – Upgrade und Migration noch mal aufbereitet.
I) Migration des Servers:
Der empfohlene Weg für ein Update von FirstSpirit 4.2 auf 5.x ist:
- Neue (parallele) Installation von FirstSpirit 5.x
- Export der Projekte in 4.2 und Import auf 5.x
In bestimmten Fällen ist dieser Weg nicht möglich, da ein Export/Import die Funktionsfähigkeit von Projekten beeinflusst. Dies ist beispielsweise beim Einsatz von CorporateContent der Fall, da sich hier ein Master-Projekt nicht per Export/Import transportieren lässt.
Für diese Fälle ist auch in "Inplace-Update" eines bestehenden 4.2er Servers möglich. Allerdings sind in diesem Fall einige manuelle Schritte durchzuführen (z.B. Aktualisierung des Suchindizies oder Update des Java-Wrappers). Ein simpler Austausch der Datei "fs-server.jar" reicht hier in jedem Fall nicht aus.
- Details: siehe Release-Notes 5.0
II) Umstellungen im Projekt
Beim Update von FirstSpirit 4.2 auf 5.x sind im Projekt einige Anpassungen durchzuführen. Dabei wird zwischen "zwingend notwendigen" und "optionalen" Umstellungen unterschieden.
Bei den aufgeführten Umstellungen im Projekt ist zu beachten, dass manche Anpassungen bereits im jetzt bestehenden 4.2er Projekt im Rahmen der üblichen Projektwartung durchgeführt werden müssen. Dies hat den Vorteil, dass die verbleibenden notwendigen Schritte bei der 5.x Migration minimiert werden. Einige Aspekte können allerdings nur direkt auf FirstSpirit 5.x durchgeführt werden. Welche Anpassung wo möglich ist, wurde jeweils vermerkt.
Zwingend notwendige Anpassungen:
Folgende Schritte sind nacheinander durchzuführen:
- Prüfen, ob eine Datenmigration notwendig ist:
Wenn in einem FirstSpirit-Projekt Daten aus älteren FirstSpirit Versionen (3.x, 4.0, 4.1) stammen und somit ein altes Format haben, müssen diese zuerst auf die Migration "vorbereitet" werden.
Ob dieser Schritt notwendig ist, kann man prüfen indem man im bereits bestehenden 4.2R4 Projekt (>=4.2.468) eine Vollgenerierung ausführt und die Auftragslogs untersucht.
Wenn eine der folgenden Meldungen auftaucht, dann muss unbedingt Schritt 2 (und am Ende Schritt 5) ausgeführt werden, andernfalls kann bei Schritt 3 fortgefahren werden:INFO 22.11.2012 12:03:26.180 {...} (de.espirit.firstspirit.client.access.editor.LinkEditorValueImpl):
Deprecated FirstSpirit-3.1 data found. Try saving your data with FirstSpirit4 once.’ Tag=null FormName=imageWithLink' (project=..., project_id=...)
Die alten Datenformate können von FirstSpirit 5.x nicht mehr gelesen werden. Dies hat zur Folge, dass Versionen mit dem alten Datenformat in FirstSpirit 5.x nicht mehr zuverlässig wiederhergestellt und editiert werden können. Es kann sinnvoll sein, die inkompatiblen Daten mit Hilfe einer Projektarchivierung zu entfernen.
Umstellung in: 4.2R4 - Initiales Ausführen des Skripts "DataMigration" - nur notwendig, wenn Deprecated Meldungen im Log erscheinen:
Daten, welche aus älteren FirstSpirit Versionen stammen, müssen für die Migration erst vorbereitet werden. Hierfür ist das Skript "DataMigration" zu verwenden, welches über den Helpdesk der e-Spirit AG bezogen werden kann.
Die genaue Vorgehensweise ist in der Dokumentation des Skripts beschrieben.
Umstellung in: 4.2R4 - Umstellung alter Eingabekomponenten:
Bereits mit FirstSpirit 4.2R4 wurden neue Eingabekomponenten eingeführt, die mit dem Namenskürzel FS_* beginnen (z.B. FS_LIST oder FS_REFERENCE) und andere (alte) Eingabekomponenten ablösen (z.B. CMS_INPUT_PICTURE).
Die Verwendung der neuen Eingabekomponenten ist in FirstSpirit 5.0 Pflicht. Projekte die noch mit alten Komponenten arbeiten, müssen auf die neuen Komponenten umgestellt werden.
Insgesamt sind folgende Komponenten betroffen: CMS_INPUT_FILE, CMS_INPUT_PICTURE, CMS_INPUT_PAGEREF, CMS_INPUT_OBJECTCHOOSER, CMS_INPUT_CONTENTAREALIST, CMS_INPUT_CONTENTLIST, CMS_INPUT_LINKLIST, CMS_INPUT_SECTIONLIST, CMS_INPUT_TABLIST- Umstellung in: 4.2R4
- Details: https://community.e-spirit.com/docs/DOC-1141 (Kapitel 5)
- Zu beachten ist insbesondere die ggf. aufwändige Umstellung, die hier in den Kommentaren beschrieben ist:
FS_REFERENCE um Kommentarfeld erweitern
- Umstellung alter Linkvorlagen auf generische Links:
Schon seit der Einführung von FirstSpirit 4.0 besteht das Konzept der "generischen Verweisvorlagen". In FirstSpirit 5.0 sind nur noch diese Art von Verweisvorlagen erlaubt. Evtl. vorhandene alte Verweisvorlagentypen müssen auf die generischen Verweisvorlagen umgestellt werden.
Die Verwendung von alten Link-Templates kann über das Generierungslogfile ermittelt werden. Die passende Meldung ist "usage of deprecated old link template <name>". - Finales Ausführen des Skripts "DataMigration" - nur notwendig, wenn Schritt 2 notwendig war:
In diesem Schritt werden die Daten endgültig ins neue Format konvertiert. Hierfür wird das Skript "DataMigration" erneut ausgeführt (siehe Schritt 2), welches über den Helpdesk der e-Spirit AG bezogen werden kann.
Die genaue Vorgehensweise ist in der Dokumentation des Skripts beschrieben.- Umstellung in: 4.2R4
Individuelle Schritte ohne Reihenfolge:
- Einbau von Content-Highlighting und WebEdit:
In FirstSpirit 4.x konnten die Konzepte "Content-Highlighting im Java-Client" und "Support von WebEdit" über passende Template-Konstrukte aktiviert werden.Mit der Einführung von FirstSpirit 5.0 wird dies deutlich einfacher, da beide Konzepte sich mit einem gemeinsamen (neuen) Template-Markup aktivieren lassen. Die alten Tags müssen somit aus dem Projekt entfernt und das neue Konstrukt eingebaut werden.
- Umstellung in: 5.x
- Details:siehe dazu 5.0er Release-Notes, Kapitel 5.2 "Vorlagenanpassung für Content Highlighting und WebEdit 5.0"
- Anlegen von "Snippets" in Templates:
Mit FirstSpirit 5.0 werden für Templates sogenannte "Snippets" eingeführt. Snippets sind Kurzdarstellungen eines Content-Elementes, z.B. in Suchergebnissen oder in Übersichtslisten. Besonders der 5er WebClient nutzt diese Technik ausgiebig. Alle bestehenden Templates müssen mit passenden Snippet-Definitionen ausgestattet werden.- Umstellung in: 5.x
- Details: siehe dazu 5.0er Release-Notes, Kapitel 5.5.2 "Gestaltung von Suchtreffern (Register "Schnipsel")
- [für eigene Module] Neu-Compilierung gegen FirstSpirit 5.0 API:
Alle selbst entwickelten Module müssen vor einem Einsatz im FirstSpirit 5.0 einmal gegen die 5er-API neue gebaut/compiliert werden.
Zusätzlich ist noch darauf zu achten, dass FirstSpirit 5.0 sowohl für JDK 1.6 als auch JDK 1.7 freigegeben ist. Für Modulentwicklungen bedeutet dies, dass das Modul sowohl unter JDK 1.6 als auch JDK 1.7 getestet werden muss.- Umstellung in: 5.x
- Umstellung in: 5.x
- [für eigene Skripte/Module] Prüfung auf Deprecations:
Wie in jeder Major-Version können in FirstSpirit 5.0 Funktionen, die in 4.x als "deprecated" markiert waren, entfallen.
Bei der Verwendung der FirstSpirit API in Beanshell Skripten oder Modulen muss geprüft werden, ob keine Deprecated-Funktionen verwendet worden sind. Falls doch, muss stattdessen die passende neue API-Funktion verwendet werden. Insgesamt wurde bei FirstSpirit 5.0 darauf geachtet, diese API-Änderungen so minimal wie möglich zu halten.- Umstellung in: 5.x
- Umstellung in: 5.x
Optionale Anpassungen:
- Verwendung von dynamischen Formularen:
Ab FirstSpirit 5.0 gibt es das Konzept der dynamischen Formulare, welches mehr Interaktivität und Logik in den Eingabemasken erlaubt. Falls diese Funktion verwendet werden soll, sind passende Formularlogiken ins Projekt zu integrieren.- Umstellung in: 5.x
- Details: 5.0er Release-Notes
- Umstellung von allowEmpty auf dynamische Formulare
Das allowEmpty="no" für Eingabekomponenten verhält sich unter FirstSpirit 5.1 strenger als unter FirstSpirit 4.2R4. In mehrsprachigen Projekten kann unter 4.2 das Formular gespeichert werden, obwohl noch nicht alle Felder in allen Sprachen gefüllt sind. Das Speichern wird erst verhindert, wenn mindestens ein Feld in einer Sprache gefüllt wurde. Unter FirstSpirit 5.0 ist diese Spezialbehandlung entfallen. Hier wird das Speichern verhindert, bis alle Felder in allen Sprachen gefüllt sind. Ist dies nicht gewünscht, so sollte auf die Verwendung von allowEmpty="no" verzichtet werden. Stattdessen kann das gewünschte Verhalten über dynamische Formulare und Regeln abgebildet werden. Siehe dazu den vorherigen Punkt.- Umstellung in: 5.x
- Verwendung von SEO-URLs:
FirstSpirit 5.0 verfügt über eine (optional wählbare) neue Logik bei der Erzeugung von URLs. Neu sind Funktionen wie sprachabhängige URLs, Short-URLs oder sprechende Dateinamen bei Datenquelleninhalten.- Umstellung in: 5.x
- Details: 5.0er Release-Notes
III) Weitere Hinweise
Index-Aktualisierung:
Es ist zu beachten, dass nach einem Update auf FirstSpirit 5.0 der FirstSpirit-interne Suchindex komplett neu aufgebaut wird. Das gilt für den Fall eines Projekt-Exports und Imports nach 5.0 ebenso wie für ein Inplace-Update.
Dauer der Indizierung: Diese Index-Aktualisierung kann bei großen Projekten einen langen Zeitraum in Anspruch nehmen (viele Stunden bis wenige Tage). Dies gilt insbesondere für Projekte, die viele oder große Datenquellen beinhalten oder lesend angebunden haben.
Während einer kompletten Neuindizierung ist das System ggf. so stark belastet, dass ein redaktionelles Arbeiten nur eingeschränkt möglich ist.
Es wird daher unbedingt dazu geraten vor der Umstellung des Produktionssystems die Aktualisierung (inkl. Neuindizierung) auf einem Testsystem mit identischen Datenmengen zu überprüfen. Nur so kann der notwendige Zeitraum für die Neuindizierung sinnvoll abgeschätzt und eingeplant werden.
Optimierung der Indizierung:Im FirstSpirit ist konfigurierbar, welche "Index-Tiefe" bei der Indizierung von Datenquellen mit Fremdschlüsselverbindungen verwendet werden soll. Per Default ist dieser Wert auf "so tief wie möglich" eingestellt. In Projekten mit vielen verschachtelten Fremdschlüsselbeziehung ist es häufig sinnvoll, diesen Wert zu reduzieren. Unser Helpdesk hilft gerne bei der Festlegung des richtigen Wertes für ihr Projekt.
Performance-Optimierung für Datenquellen:
Ab FirstSpirit 5.0 werden wird in den Datenquellen eine neue technische Spalte für Tabellen eingeführt (GID-Spalte). Gegen den Inhalt diese Spalte werden viele Anfragen gestellt. Für Migrationsprojekte ist es daher sinnvoll, auf alle GID-Spalten manuell einen Datenbank-Index zu setzen, da dies nicht von FirstSpirit eigenständig übernommen wird. Unser Helpdesk unterstützt sie dabei gerne.
Für in FirstSpirit >= 5.0 neu angelegte Tabellen ist dieser Schritte nicht notwendig. In diesem Fall erzeugt FirstSpirit eigenständig die notwendigen Indizies.
IV) Check-Liste für die Migration
Hier noch mal die Migrationsschritte als Checkliste:
| Migrationsschritt | Erledigt für mein Projekt? |
|---|---|
| Prüfung und ggf. Durchführung einer Datenmigration | |
| Umstellung alter Eingabekomponenten | |
| Umstellung alter Linkvorlagen auf generische Links | |
| Einbau von Content-Highlighting und WebEdit | |
| Anlegen von "Snippets" in Templates | |
| Neu-Compilierung gegen FirstSpirit 5.0 API [nur für eigene Module] | |
| Prüfung auf Deprecations [nur für eigene Skripte/Module] | |
| [optional] Verwendung von dynamischen Formularen | |
| [optional] Umstellung von allowEmpty="no" auf dynamische Formulare/Regeln | |
| [optional] Verwendung von SEO-URLs | |
| Einplanung der notwendigen Zeit für die Index-Aktualisierung (nur bei sehr großen Projekten) |
Tags: fs5.0, migration, update
Kommentare
35 Kommentare
Hallo.
Zwei Fragen hierzu und ein Hinweis, dass der Umbau der FS_* Komponenten nur erforderlich ist, wenn man WebEdit5 nutzen möchte. Es muss also nicht immer zwingend umgebaut werden wie es oben beschrieben steht!
Siehe https://community.e-spirit.com/message/9487#9487
Ist der Umbau des Content-Highlighting zwingend notwendig oder funktioniert die alte Syntax, wenn man nur den JavaClient benutzt weiter?
Bekome ich eine Warnung in den Logs, wenn ich Funktionen verwende die deprecated sind?
Viele Grüße,
Daniel
Der Umbau des ContentHighlighting ist zwingend notwendig, auch wenn kein WebClient verwendet wird.
Bei alten Links gibt es eine Warnung, wenn noch das alte Format verwendet wird. Bei API-Aufrufen ist dies ebenfalls so. Das ist aber sicherlich nicht für alle Funktionalitäten der Fall, die mit Version 5 depracted sind. Ein Beispiel wären Eingabekomponenten. Es gibt für den Entwickler keinen Warnhinweis, wenn er die in ein Formular einfügt.
Sehr geehrte FirstSpirit Community,
wie verhält es sich mit den als "Snippets" benannten Funktionen? Sind diese zwingend bereitzustellen oder vielleicht doch nur optional?
Wenn wir die Liste oben richtig verstehen und interpretieren, müsste es sich aus unserer Sicht um Teile handeln, die Voraussetzung für einen Betrieb und Einsatz von FirstSpirit 5.0 sind.
Hallo Herr King,
genau, die Snippet sind fuer WebEdit-5 zwingend notwending. Nicht jedoch fuer den JavaClient.
Hallo,
Sie schreiben, dass das Anpassen der Eingabekomponenten unter 4.2 oder 5.0 möglich ist.
Folgende Frage dazu:
Wäre es möglich einen inplace-Update des Builds zu machen von 4.2 auf 5.0 ohne die Komponenten anzufassen um zu sehen wie sich all unsere Templates, Skripte und sonstigen Komponenten verhalten.
Danke für die Antwort !
Grüße Torsten Kupetz
Hallo Herr Kupetz,
das kann man einzeln beantworten:
Interessant ist vermutlich noch dieses Dokument, wo ein paar weitere Migrationsaspekte beschrieben sind:
FirstSpirit5 – Upgrade und Migration
Hallo Herr Knoor,
das Dokument scheint in einem geschützten Bereich zu liegen. Teilen Sie uns die Zugriffsmöglichkeiten mit?
Ich habe jetzt den korrekten Link eingefügt (s.o.).
Hallo,
bei der Update-Schulung haben wir gehört, dass nach der Konvertierung der alten Verweisvorlagen jede Seite/Datenquelle, wo ein Link vorkommt einmal entsperrt, gespeichert und wieder entsperrt werden muss; es wird hierfür seitens e-Spirit ein entsprechendes Script bereitgestellt;
ist es tatsächlich so und wenn ja, wann ist damit zu rechnen ?
Danke & Gruß,
Michael
Hallo Michael,
ja, das ist für "alte" Verweisvorlagen korrekt. Die notwendigen Datenmigration kann entweder manuell (sperren/speichern/entsperren) oder per Skript ausgeführt werden.
Das Skript wird im Laufe des Januars verfügbar sein.
Das beschriebene Skript für die Datenmigration ist inzwischen beim Helpdesk erhältlich.
Hallo Herr Knoor,
ein Kunde von uns möchte von FS 4.2 auf 5.0 updaten.
Neben dem Migrationsaufwand im Projekt, welche Kosten entstehen weiterhin z.B. für Lizenz oder ähnliches?
Vielen Dank vorab!
Mit freundlichen Grüßen
Betty
Hallo,
das kommt auf den Wartungsvertrag des Kunden an.
Fast alle Kunden haben einen Wartungsvertrag mit dem Recht auf neue Major-Versionen zu gehen, ohne neue Lizenzgebühren dafür bezahlen zu müssen.
Falls neue Module gewünscht oder notwendig sind, sind diese natürlich wie gewohnt zu lizensieren.
Bitte gehen Sie für eine konkrete Aussage auf den zuständigen Vertriebsmitarbeiter von e-Spirit zu.
Angenommen man will eine Migration von 4.2R4 auf 5.1 durchführen - wären dann die gleichen Schritte wie bei der Migration von 4.2R4 auf 5.0 durchzuführen?
Oder gibt es zusätzliche 4.2R4-Features, die in Version 5.0 noch funktionieren aber in Version 5.1 nicht mehr unterstützt werden?
Ich benötige die Info für eine Kalkultaion.
Hallo in die Runde,
meines Erachtens gibt es ein Problem bei der Reihenfolge der Checkliste.
Um eine CMS_INPUT_LINKLIST in eine FS_LIST umzubauen, muss ich zuvor die Verweivorlagen konvertiert haben, oder? Somit wären Punkt 3. und 4. zu tauschen?!
Des Weiteren stellt sich uns die Frage, ob das Skript zur Datenmigration in jedem Fall angewendet werden muss, wenn statische Link-Editoren im Rahmen der Migration auf generische Links umgestellt wurden?
Außerdem sieht es so aus, als würden bei der Umstellung die Vorgabewerte nicht übernommen werden.
Gibt es, wie bei der Projektkonvertierung von FS 3 nach FS 4 ein Skript zur Übernahme der Vorgabewerte?
Vielen Dank und viele Grüße
Sabrina Schneider
Solange man die Komponente nicht speichert, kann die Konvertierung später gemacht werden.
Es kommt auf die Historie (3.1/4.0) des Projektes an? Generell empfehlen wir daher das Skript zu starten.
Leider gibt es das nicht. Da man das Formular eh anpassen muss, können auch die Vorgabewerte von Hand übernommen werden.
Seitens e-Spirit wird eine Anwendung zur Datenmigration angeboten. Die Frage, die wir uns gerade stellen:
Interne Datenquellen werden mit konvertiert. Dies ist technisch auch notwendig, damit die Migration funktioniert.
Externe (Readonly-) Datenbanken bleiben natürlich unangetastet.
Ist das ein Schritt, welcher Zwingend in Version 4.2R4 erledigt werden muss. Ggf. man hat ein dreistufiges System (DEV, QAS und Prod) und hat diese Änderung im DEV-System bereits durchgeführt. Könnte man dann die QAS und PROD Projekte "einfach" exportieren und in eine 5.1 Version importieren und die Vorlagen inkl. Eingabekomponenten via "Externe Synchronisierung" aktualisieren?
So hätte man die Arbeit der Aktualisierung von Eingabekomponenten nur einmal gehabt.
Viele Grüße
Jörn
Hallo zusammen,
ich habe noch eine Frage zu Kapitel II) Umstellungen im Projekt, konkret geht es dabei um die Datenmigration.
Da die Ausführung der bereitgestellten Applikation - bei entsprechend viel Content - eine Weile braucht, würde ich gern verstehen warum wir das Tool zwei mal ausführen müssen. Gibt es da ggf. einen Weg drumrum?
Vielen Dank und Gruß
Martin
Hallo Martin,
das kommt auf das Alter des Projektes an. Ist das Projekt noch aus 4.0 Zeiten? Wenn noch alte Link-Daten in den Datensätzen sind, müssen diese zuerst migriert werden.
Gruß
Gerrit
Hallo Gerrit,
erstmal vielen Dank für das Feedback!
Ich glaube ich habe mich in obigem Post etwas unklar ausgedrückt, ich versuche mal etwas mehr Kontext zu geben. Es geht um Projekte die bereits seit FS3 bestehen und wir haben die Linkvorlagen um Zuge der regelmäßigen Wartung bereits vor langer Zeit auf generische Linkvorlagen umgestellt. Da nun die FirstSpirit 5 Migration ansteht haben wir die Notwendigkeit einer Datenmigration positiv aufgrund von "deprecated..." Logmeldungen in den Generierungslogs festgestellt.
Was mich an der Stelle verwundert ist, dass wir die Datenmigration einmal vor (Schritt 2) und einmal nach (Schritt 5) dem Update der Formularkomponenten (Schritt 3) auf das neue Format (FS_*) ausführen müssen.
Vielen Dank und Gruß
Martin
Hallo Martin,
der Grund sind die Daten innerhalb von FirstSpirit. Das Datenformat muss erst in eine neues Format überführt werden, bevor auf eine neue Eingabekomponente umgestellt wird.
Gruß
Gerrit
Hallo Herr Knoor,
bezugnehmend auf Ihren Kommentar vom 22.05.
möchten wir nachhaken. Besteht für externe Datenquellen welche aber durch FristSpirit verwaltet werden der Bedarf einer Datenmigration?
Kleine Randinformation: Das betreffende Projekt wurde uner FirstSpirit 4.2 angelegt.
Danke für eine kurze Rückmeldung hierzu.
Hallo Herr Kloppmann,
externe Datenquellen sind bei Ihnen dann "readonly Datenquellen", die aber in einem (anderen) Projekt schreibend eingebunden sind?
In diesem Fall ist aus Sicht des Projektes, welches die Daten lesend einbindet, nichts zu tun.
Aber aus Sicht des Projektes, welches die Datenquelle beschreibt, muss eine Konnvertierung durchgeführt werden.
Hallo Herr Knoor,
danke für die prompte Rückmeldung! An und für sich ist diese auch klar - allerdings möchte ich nochmals explizit darauf hinweisen, dass das betreffende Projekt unter FirstSpirit 4.2 angelegt wurde.
Ist dennoch eine Datenmigration notwendig?
Ja, auch in diesem Fall.
Hallo Herr Knoor,
wir haben jetzt wiedersprüchliche Aussagen. In der Dokumentation zur Datenmigrations-Anwendung "linkdatamigration" steht einleitend die Aussage:
Auch Herr Leinich sah den Zwang einer Datenmigration in diesem Fall bisher nicht.
Könnten Sie das intern nochmals klären und begründen, warum die Datenmigration hier notwendig wird? (bitte für den Fall, dass in einem unter FS 4.2 aufgesetzten Projekt initial durch die Datenmigration migrierte Eingabekomponenten "CONTENTAREALIST" bzw. "LINKLIST" benutzt wurden?)
Hallo Herr King,
wir haben beide Recht :smileywink:
Die Datenmirgration muss ja potentiell 2x durchgeführt werden:
a) 1x vor der Umstellunge der Eingabekomponenten (um alte 2.x und 3.x Formate in das 4er Format zu überführen)
b) 1x nach der Umstellunge der Eingabekomponenten
Herr Leinich sprach von Schritt a). Den kann man sich bei einem 4er Projekt sparen.
Ich sprach von Schritt b). Dieser ist immer durchzuführen.
Hallo Herr Knoor,
In der Update-Checkliste haben Sie freundlicher Weise daraufhingewiesen, dass ein direktes Update auf 5.1 unterstützt wird.
"Ein direktes Update von FirstSpirit 4.2R4 auf FirstSpirit 5.1 wird also unterstützt."
Ich nehme an, dies gilt auch für ein direktes Update von 4.2R4 auf die neue Version 5.2?!
Freundliche Grüße
Carsten Noetzel
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.