Howto:Hosting with V10

Dieses Dokument beschäftigt sich mit der prinzipiellen Funktionsweise der Hosting-Komponenten Ala Cloudkom. Konkrete Konfigurationsdaten finden sich dagegen in Abschnitt Globe Installation.

Gesamtübersicht

Für jeden Kunden wird eine dedizierte PBX (IPVA) aufgebaut. Jeder Kunde hat genau eine solche PBX (also keine Slaves). Weitere Dienste werden durch mandantenfähige Anwendungen bereitgestellt (Shared Services). Jede dieser shared services bedient eine Anzahl von Kunden. Im ersten Ansatz sind das für jeden der Dienste genau gleich viel (was die Verwaltung bzw. Zuordnung vereinfachen sollte). Wie viele Kunden ein shared service bedienen ist for further study.

Den Management Server gibt es je Hoster nur genau ein mal.

Grundsätzlich sind die Kunden-PBXen und die shared services im privaten Netz des Hosters. Somit sind sie von aussen und damit auch aus dem Kundennetz nicht erreichbar. Zwischen Kunde und Hoster wird kein VPN aufgebaut. Um nun den notwendigen Zugriff des Kunden auf PBX und Dienste zu ermöglichen gibt es 2 Dienste, die auch über eine öffentlich zugängliche IP Adresse verfügen (dual homed). Dies sind der SBC und die Media-PBX.

Der SBC leistet zweierlei:

• Proxy Registrierung der Endgeräte des Kunden

Die Endgeräte registrieren sich am SBC, der wiederum eine Proxy-Registrierung zur Kunden-PBX unterhält

• NAT eingehend mit Portmaps für ausgewählte Protokolle (HTTPS/443 und LDAPS/636,714)

Die Media-PBX

• stellt dem Kunden einen öffentlich erreichbaren Übergabepunkt für zentral generierte oder verarbeitete Mediendaten zur Verfügung

Dazu gehören z.B. music on hold, lokal erzeugte Ruftöne, Voicemail, Konferenzen und Faxempfang

Durch die Aufteilung bleibt die Netztopologie des Hosters unsichtbar. Der Hoster benötigt insgesamt nur 2*n+1 öffentliche IP Addressen (wobei n die Anzahl an shared service Gruppen ist).

Kennwörter

Im gesamten Hosting System werden an den verschiedensten Stellen Kennwörter vergeben/verwendet. Um hier die Übersicht zu behalten gilt folgendes:

• Admin Kennwörter

Die Authentifizierung der Admins erfolgt über Kerberos. Admins können daher individuelle Kennwörter haben (im Folgenden als individuelles Admin Kennwort bezeichnet)

alle Boxen haben als Fallback ein supergeheimes "local admin" Kennwort, dass man in der Regel aber nicht benutzt (im Folgenden als systemweites Admin Kennwort bezeichnet)

• PBX Kennwörter

Die PBX Kennwörter müssen auf allen PBXen im gesamten Verbund gleich sein (und müssen niemals irgendwo eingegeben werden nach der Grundkonfiguration) (im Folgenden als PBX Kennwort bezeichnet)

• Objektkennwörter. Hier gibt es zwei Arten:
  • Kennwörter, die dem Kunden bekannt gemacht werden. Das sind z.b. Registrierungskennwörter für Endgeräte (im Folgenden als Kunden-Registrier-Kennwort bezeichnet) und Initialkennwörter für myPBX (also Userkennwörter, im Folgenden als Kunden-Login-Kennwort bezeichnet). Für jeden Kunden wird ein eigenes Kunden-Registrier-Kennwort festgelegt, dass in der Regel nie geändert wird. Ebenso wird ein anderes Kunden-Login-Kennwort generiert, das für alle User Objekte als Initialwert verwendet wird, von den Nutzern aber verändert werden kann
  • Kennwörter, die dem Kunden nicht bekannt gemacht werden. Für z.B. interne Objektregistrierungen (z.B. ein lokales GWxx an ein PBX-Objekt) wird immer das PBX Kennwort verwendet
• Kerberos Kennwort

Hier wird das PBX Kennwort verwendet (es macht wenig Sinn, da etwas anderes als das PBX Kennwort zu verwenden)

Die Linux AP hat keine Kerberos Unterstützung. Es werden hier also eigene Kennwörter benötigt. Dabei wird unterschieden, ob es sich um Kennwörter handelt, die im normalen Betrieb benötigt werden oder nicht

• Linux Admin Kennwort

das ist das Kennwort, dass im normalen Betrieb verwendet wird (im folgenden Linux Admin Kennwort genannt). Findet Verwendung als web server credentials, webdav access credentials, application access credentials, 'innovaphone Reporting access credentials, innovaphone Fax access credentials etc.

• Linux System Kennwort

das ist das Kennwort, dass im normalen Betrieb nicht verwendet wird. Hier wird das PBX Kennwort verwendet. Findet Verwendung als root credentials

Die Datenbank Kennwörter bleiben wie sie im Standard jeweils sind (z.b. postgresql admin password, da man auf den DB Server eh nur von 127.0.0.1 kommt

NTP

Alle Geräte benötigen eine korrekte Zeit (alleine schon wegen Kerberos). Es muss also überall ein korrekter SNTP Server (und am besten auch ein zweiter) eingetragen sein.

Zertifikate

Der gesamte HTTP und LDAP Verkehr zum Kunden hin ist verschlüsselt. Dies betrifft einen eventuellen Admin Zugang zur Kunden-PBX (durch den Reseller z.B.) und den Reporting und myPBX Zugang des Endkunden. Um hier die Benutzung durch den Endnutzer zu ermöglichen, werden auf den Geräten in jeder Hinsicht "passende" Zertifikate benötigt (also Hostname und Authority Trust). Die eingebauten Zertifikate können nicht verwendet werden, da sie zum einen nur auf den NetBIOS Namen ausgestellt sind (z.b. IPVA-a8-5a-38) und zum anderen im Falle der IPVA self-signed, also nicht von einem gemeinsamen Stammzertifikat abgeleitet sind.

Dazu wird je Hoster ein signierfähiges Zertifikat benötigt (RootCA) von dem die jeweiligen Device-Certificates abgeleitet werden. Als RootCA wird eine dedizierte IPVA verwendet, auf der eine RootCA generiert wurde (General/Certificates/RootCA). Die Geräte-Zertifikate werden immer auf dieser IPVA generiert und dann von der CF Karte (/DRIVE/CF0/CA/certs/) auf die Geräte exportiert.

RootCA

Als RootCA wird eine zentrale IPVA verwendet, die auch das zentrale Kerberos realisiert. Die Erzeugung der Device-Certificates auf der RootCA hat mit aktueller Firmware den Seiteneffekt, dass das Gerätezertifkat des generierenden Gerätes überschrieben wird. Das ist zwtr unschön aber auch nicht tragisch und beeinflusst die Funktion des Kerberos Servers nicht.

In der RootCA-VM generiert man zunächst eine eben solche (general/kerberos). Sie wird mit folgenden Daten angelegt:

C=Germany, O=hoster, CN=hoster Device Certification Authority, Key-length 4096, Lebensdauer 20 Jahre

Dieses neue RootCA zertifikat trusted man dann auf der Box selber.

Device Certificates

Individuelle Gerätezertifikate erzeugt man dann mit dieser RootCA wie folgt:

Key 4096, Common Name=NetBIOS Name des Geräts, Organization=hoster, Country=Germany, DNS Name 1=externe IP des Gerätes, DNS Name 2=interne IP des Gerätes, IP Address 1=externe IP des Gerätes, IP Address 2=interne IP des Gerätes

Hat das Gerät nur eine interne IP Adresse, muss man unbedingt als externe IP Adresse die IP Adresse des Gerätes angeben, über den der NAT Zugriff erfolgt (also z.B. bei einer Kunden-IPVA den zugehörigen SBC). Man gibt nur die IP Adresse, nicht das Port Mapping an.

Wenn man für die Geräte auch noch DNS Namen vergibt, kann man natürlich auch diesen als DNS Name 3 mit angeben.

Man muss das Häkchen Backup on CF setzen, da das die einzige Möglichkeit ist, ein Zertifikatsdatei mit dem private Key zu bekommen.

Das Erzeugen des Zertifikates bewirkt zum einen, dass es auf der CF-Karte als serialno.pem abgespeichert wird und zum anderen das aktuelle Device Certificate der VM die als RootCA verwendet wird ersetzt. Letzteres ist nur verblüffend, aber nicht weiter schlimm. Beim Zugriff auf diese VM per HTTPS wird in der Folge de Browser immer wieder darüber klagen, dass das zertifikat nicht für diesen Host ausgestellt wurde. Da auf dieses Gerät aber niemals ein Kunde zugreifen wird, kann man das ertragen. Um das Zertifikat aber auf das Zielgerät zu bekommen, muss man es sich zunächst von der CF Karte herunterladen. Man schaut also, was für eine Seriennummer gerade erzeugt wurde und lädt dann die Datei /DRIVE/CF0/CA/certs/serialno.pem von der CF-Karter herunter (und speichert es sich zweckmäßig als NetBIOS Name des Geräts.pem. Von dort kann man es dann als neues Device Certificate auf das Zielgerät laden (General / Certificates / Device certificate / Upload).

Installation der Zertifikate im Client

Firefox

• Das Stammzertifikat (nicht das individuelle Gerätezertifikat) im PEM Format runterladen
• Extras / Einstellungen / Erweitert / Zertifikate anzeigen / Zertifizierungsstellen / Importieren
• die .crt Datei importieren
• Dieser CA vertrauen, um Websites zu identifizieren

Internet Explorer

• Extras / Internetoptionen / Inhalte / Zertifikate / Beabsichtigter Zweck Clientauthentifizierung / Vertrauenswürdige Stammzertifizierungsstellen / Importieren
• die .crt Datei importieren

Kerberos

Die Authentifikation aller Admins auf Geräten, die sich innerhalb der Hoster-Infrastruktur befinden (also nicht die Endgeräte der Kunden) erfolgt über Kerberos. Daher muss jedes dieser Geräte eingebucht sein in die Realm. Als Realm soll die DNS-Domain des Hosters (z.b. hoster.tld) verwendet werden. Dadurch wird es möglich, die Kerberos Server über den DNS zu finden.

Die zentrale IPVA die auch die RootCA realisiert stellt ebenso die zentrale Kerberos Instanz zur Verfügung.

Es wird ein eigenständiger Kerberos Server (also der im Gateway Level verwendet). Die (mutmaßlich überschaubaren) Admins werden dort von Hand eingetragen.

Eine Doppelung des Servers ist über den üblichen Mechanismus möglich (Replikation auf einen zweiten). Ob das allerdings so besonders sinnig ist bleibt dahin gestellt, da die Ausfallsicherheit an sich durch den Hoster (auf VMWare Level) gewährleistet werden sollte. Fällt der Kerberos Server aus gibt es eine gewisse Wahrscheinlichkeit, dass der Backup-Server (der ja auf der gleichen Infrastruktur laufen dürfte) auch ausfällt.

Trust Relationships sind nicht erforderlich. Werden doch welche gewünscht (z.B. zur Unterstützung weitere Realms) so wird als shared secret für die Vertrauensstellung das 'systemweite Admin Kennwort verwendet.

Die Clients (also die Geräte, deren Zugriff per Kerberos abgesichert wird) finden Ihre Kerberos Server per DNS. Dazu müssen im autoritativen DNS der Hoster Domain (die auch als Keberos Realm Name fungiert, s.o.) Einträge erstellt werden:

# hoster.tld is the hosters domain used as kerberos realm name
A kerberos1.hoster.tld x.x.x.x
A kerberos2.hoster.tld y.y.y.y

SRV _kerberos._udp.hoster.tld
    priority       = 0
    weight         = 0
    port           = 88
    svr hostname   = kerberos1.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 10
    weight         = 0
    port           = 88
    svr hostname   = kerberos2.hoster.tld

SBC

PBX

• Port9, IPVA9 und SBC9 Lizenzen benötigt
• PBX Password Fx67abkc42, muss auf allen Kunden-PBXen gleich sein
• Für jedes Telefon ein Session Border Objekt
  • Long Name: HW Id des Telefons
  • Für Registrierung dieser Telefone von extern individuelle passwords
  • Registrierung der Telefone nach intern mit PBX Admin Password. Die Idee dabei ist, dass man auf allen PBXen das gleiche PBX Admin Password verwendet (Fx67abkc42), das man auch dem Reseller/Kunden nicht gibt (braucht der auch nciht zur Administration). Das kann also nicht verändert werden, ohne dass alle Telefone die Registrierung verlieren
• SBCs agieren als Kerberos Server für die Admins aller cloudkom inno "Boxen"
• SBCs leisten auch das HTTP (und LDAP) inbound NAT um den Zugriff auf die IPVAs im privaten Netz zu ermöglichen. Jede IPVA nutzt "ihren" SBC eben auch als NAT Server.

Medienserver

• Lizenzmaster für alle Kunden PBXen. Port9 und IPVA9 Lizenzen
• PBX Objekt für jeden Kunden (Long Name, Name: Name des Kunden, Nummer 90+<Port im NAT Mapping>)
• Gateway Objekte mit Name <Kunden Name>-media. Daran können sich die Kunden PBXen registrieren für Media Daten
• Objekt MOH mit Nummer ###10. Dort kann sich die MOH Quelle registrieren
• Objekt TONE mit Nummer ###11. Dort kann sich eine Tone interface registrieren
• Objekt HTTP-OUT mit Nummer ###12. To offload the announcements of WQ and VM object.

Kunden PBX

Die Kunden-PBX steht im privaten Hoster Netz. Sie kann daher keine Medien zum Endkunden spielen. Dazu wird die ihr zugeordnete Media-n PBX verwendet, die dual-homed ist.

• SBC als Time Server (Zeit notwendig für Kerberos)

Update Server

Aufgaben:

• Staging (z.b. aufspielen geeigneter Trust Lists)
• Update der Firmware auf den Kundengeräten und der Kunden-PBX
• Sicherung der Configs von allen Kundengeräten und der Kunden-PBX

Die Sicherung findet auf die CF der Kunden-PBX statt. Das macht Sinn, da es hier nicht um Desaster Recovery geht (die wird vom Hoster gewährleistet), sondern um das Recovery nach Fehlkonfigurationen. Das kundenspezifische Update Script befindet sich ebenso auf der Kunden-CF. Es gibt kein gerätespezifisches Update-Script.

Struktur

/DRIVE/CF0/
  update/
    update.txt
    backup/
      backup-mac-datum.txt

Soll die Firmware eines Kunden aktualisiert werden, dann muss das update.txt des Kunden angepasst werden.

Die Firmware liegt auf einem zentralen Verzeichnis.

Struktur

/DRIVE/CF0/
    update/
      firm/
        nnnnnn/
          bootxxx.bin
          ipxxx.bin
      firmupdate.txt

Die initiale Update URL kann nicht über die normalen Mechanismen (DHCP) erfolgen (da man den DHCP Server des Kunden nicht beeinflussen kann). Die langfristige Idee ist, dass man in der inno Logisitik weiß, welches Telefon zu welchem Hoster geht. Geräte, die überhaupt zu einem Hoster-Kunden gehen bekommen eine spezielle manufacturer-id die wiederum eine spezielle update URL in der config hat: http://config.innovaphone.com/staging.txt. Dahinter steckt eine Anwendung, die aus der Seriennummer ermittelt, zu welchem Hoster das geht und ersetzt die URL durch ein http://config.hoster.com/staging.txt (oder was immer für den Hoster bekannt gegeben wurde). Bei dem Hoster wiederum kann entweder ein statisches Staging Script dahinter stehen (unlikely) oder eine Hosterspezifische Anwendung, die das Staging für den Kunden (den dann die Anwendung vom Kunden wissen muss) macht.

Bis dahin muss allerdings jemand (Hoster oder Kunde) die passende URL nach einem langem Reset ins Kundengerät eingeben.

Staging Tasks

• Zertifikat in die Trustlist
• Zentralisierung von Logs, Alarm&Events (auf die Kunden-PBX)

Support / debugging von Kundenproblemen

• Alarms & Events Zentralisierung
  • wie, was kann man daraus erkennen
• syslog
  • wie, wo, was sichern
• wer macht support
• zusammenarbeit mit toplink bei SIP-Trunk Probleme
• mantis <mantis-issue id=95379/>

Reporting (Multiple PBX)

VM sollte von Anfang an eine Plattengröße von 50GB haben!

V10 Linux Image und Reporting Files von der linux-10 (also der neuen ) Version werden benötigt, nur die enthalten die Mandantenfähigkeit. Gebraucht wird die Linux-AP und das Reporting. Eine solche Linux-AP kann mehrere (viele) Kunde bezüglich der Ruflisten und des Reportings bedienen.

<dfslink>\\inno-sifi\dfs\build\linux-10</dfslink>

Konfiguration PBX

• CDR0: Remote-AP-S, 10.30.100.2, 443
• Call List Service myPBX: Remote-AP-S, 212.124.38.120:8102, user:innovaphone-reporting, pass: reporting

Konfiguration Reporting

• PBX-Name
• Filter für PBX VM9 und VM10 erstellt
• User angelegt die diesen Filter verwenden
• Reportin Login Page
• Mit user/passwd:ckl_report/callme38 anmelden, dann sieht man nur calls aus PBX VM10
• Mit user/passwd:inno_report/callme38 anmelden, dann nur calls aus PBX VM9 sichtbar

Fax Server

VM sollte von Anfang an eine Plattengröße von 50MB haben!

Da das FAX-Interface im Öffentlichen Netz stehen muss, um T.38 Pakete empfangen zu können, wird dieses von der CustomerPBX auf Media1 Gateway ausgelagert. Die SOAP-Verbindung wird trotzdem auf die CustomerPBX aufgebaut.

Mail to Fax Gateway

Für Kunden, auf deren POP3 Server aus Cloudkom Netz nicht zugegriffen werden kann, wird ein SMTP Server auf Basis von IP-AP aufgestellt. Dort können die Kunden dann per E-Mail die Faxe anliefern. (<mantis-issue id=89710/>)

Use Case "Fax verschicken":

• Kunde schickt aus dem E-Mail Programm ein Mail mit PDF-Anhang an z.B. +497031730099@fax.cloudkom.com
• Rufnummer für Zielfax muss im User Part der To: Mailadresse stehen (im Beispiel ist es +497031730099)
• Das passende Postfach für Fax Server des jeweiligen Kunden wird anhand der From: Mailadresse bestimmt.

Damit die From: Adresse nicht gefaked werden kann, werden nur authentifizierte SMTP-Verbindungen zugelassen. Der Kunde muss dazu bei sich im Exchange einen "SMTP Send Connector" für die Domäne fax.cloudkom.com einrichten ([1]) mit Basic Auth over TLS.

Als SMTP-Server kann man ein Postfix mit Postgresql Erweiterung nehmen, damit man die Kunden Daten (Domains, Postfächer, Logins) direkt aus der Fax Server Datenbank lesen kann.

Als POP3-Server (damit Fax Server die Mails lesen kann) wird dann Dovecot eingesetzt.

Beschreibung der Implementierung: E-Mail_Fax_Server_Gateway_(Project_Cloudkom).

Adressbücher

Directories - PBX

• pro Kunde wird im SBC ein NAT-Port-Map für LDAP zur entsprechenden Kunden-IPVA konfiguriert. Das Telefon hat die Möglichkeit ein Port in der PBX-Directories anzugeben und benutzt daudrch den LDAP-Server der PBX(und nicht den des SBC).
• Es wird LDAPS verwenden, das Zertifikat der Kunden-IPVA muss jedoch nicht extra in der Trustlist des Telefons aufgenommen werden. Das Telefon überprüft nicht ob das SSL - Zertifikat gültig ist(cn, Ablaufdatum, etc) sondern verwendet einfach das erhaltene Zertifikat nur zur Verschlüsselung.

Directories - External LDAP Server

• pro Kunde gibt es einen LDAP-Knoten (dc=kundennr.), ein Replikator. Es wird LDAPS verwendet.
  • Replikator:
    • Kunde exportiert seine Outlook - Kontakte in eine CSV Datei (Kommagetrennte Werte(Windows)). Die CSV Datei sollte nur folgende Spalten/Felder enthalten: "Nachname","Vorname","Firma","Telefon geschäftlich","Mobiltelefon". Die Telefonnummern sollten im E164 Format vorliegen, also +49703173009123. Als Dateiname immer Kontakte.csv verwenden, damit Replikator immer relativ einheitlich konfiguriert werden kann.
    • die CSV Datei wird via https und webdav - client (z.B. BitKinex) auf der CF-Karte der Kunden PBX kopiert. Hier sollte man den Unterordner "Ext-Dir" verwenden (falls nicht vorhanden anlegen)
    • der Estos Metadir Server greift via http/webdav auf die CF-Karten aller Kunden-IPVAs zu und importiert die CSV Dateien
  • LDAP-Knoten:
    • Authentifizierung für den Zugriff auf LDAP-Knoten erfolgt per Username/Passwort, keine Einschränkung auf IP-Netze.
    • als Profil wird immer das "Default" Profil verwendet. Man braucht durch unsere "Dialing Location" am Telefon keine Kundenspezifischen Profile.
    • als Vorlage ist im Metadir Server ist ein Template eingerichtet "dc=template"
• kurze Anleitung zum exportieren von Kontakten in Outlook 2010:
  • man kann nur eigen Kontakte exportieren. Hat man nur eine globale Kontaktliste, muss man diese Kontakte erstmals in die eigene Kontakte kopieren. (IP Kontakte -> Rechtsklick -> kopieren -> eigene Kontakte auswählen)
  • in Outlook Datei -> Öffnen -> Importieren -> In Datei exportieren -> Kommagetrennte Werte(Windows) -> Kontakte/IP Kontakte auswählen -> "Benutzerdefinierte Felder zuordnen" -> Nachname, Vorname, Firma, Telefon geschäftlich, Mobiltelefon auswählen -> Fertigstellen
• LDAPS
  • Selfsigned Zertifikat auf den Metadir Server installiert. Da LDAP-Client auf dem Telefon das Zertifikat nicht überprüft, sollte es hier keine Probleme geben.
  • Metadir Server verwendet port 714 für LDAPS, SBC1 hat dafür ein NAT-Map für Port 9007
• die Directories Einstellungen sollten per config - template verteilt werden, auf der VM10 gibt es dazu als Beispiel das config-template "default"

myPBX

• hier gibt es das Problem dass normalerweise die PBX die LDAP - Anfrage des myPBX - Clients macht, dazu verwendet man normalerweise die am User gespeicherte phone-config. Da die PBX im internen Globe Netz ist, kann es mit der darin enthaltenen public-IP(externe IP des NAT Routers) nicht anfangen. durch ein Hack von Matthias kann man im PBX0 modul fest konfigurieren welcher LDAP Server genutzt werden soll.

config add PBX0 /ldap-default-addr 10.30.0.2 /ldap-default-port 714

Voicemail

Konfiguration Kunden PBX

• voicemail-object:
  • Hardware-ID = vmrelay
  • Script-URL (auf lokaler CF Card vm installiert) = https://10.30.x.x/DRIVE/CF0/vm-de/vm.xml?$_divconn=false

• Gateway-config

• • Media GW1, Register as Gateway, 212.124.38.123, Name= innovaphone-media
  • HTTP-INT GW3, Register as Gateway, 127.0.0.1, Name= HTTP-INT
  • HTTP-EXT GW4, Register as Gateway, 212.124.38.123 (Media1), Name= HTTP-EXT
  • vmrelay GW5, Register as Gateway, 127.0.0.1, Name= vmrelay

• Routes
  • GW3 HTTP-INT --> ###12 GW4 HTTP-EXT
  • GW5 vmrelay --> ###12 GW4 HTTP-EXT

• https Zertifikate trusten auf Media1.

Datensicherung

Thomas Leone 16:50, 8. Jan. 2013 (CET) Datensicherungskonzept überlegen.

Ausser uns auf globe zu verlassen, dass IPVAs wieder hergestellt werden können, sollten configs extra gesichert werden.

1. Wie am 17.12. besprochen, Datensicherung der PBXn lokal. PBX Admins können dann configs selbst einspielen. --> IPVA kaputt (warum auch immer), ist die Sicherung weg.

2. Configs der Kunden-PBXn auf Michael Khayats Windows Server (zusätzlich) sichern. Server ist im auch im privaten Netz. Configs könnten auch von Michael K. wieder upgeloadet werden.

3. Eine IPVA als Reserve. Kann von uns schnell gestartet und konfiguriert werden. Globe wird dann noch nicht benötigt.

Thomas Leone 11:38, 23. Jan. 2013 (CET) Desaster Recovery von Globe

1. Jede VM wird 2 Wochen Montag -Freitag + 1 x Monatlich gesichert. Es gibt also von jeder VM 11 separate Generationen die auf Wunsch wiederhergestellt werden können.

2. Die Aussage, dass unsere IPVA nicht VSphere konform sind ist obsolet (kam vorschnell aus der Technik da unsere VM nicht bei VSphere aufgelistet sind).

3. Recovery wurde mit VM8 (IPVA) und VM12 (LAP) erfolgreich getestet.