VMware vCenter: Warum die Standard-Installation oft die teuerste ist

Willkommen bei IT for Business. Ich bin Mirko Peters.

Wir sind IT-Dienstleister für den Mittelstand, und hier geht es nicht um Produkte oder Hypes, sondern um echte IT-Entscheidungen: Infrastruktur, Cloud, Security und Architektur aus der Praxis.

Wenn Sie Verantwortung für IT tragen, Entscheidungen treffen oder Dienstleister bewerten, dann sind Sie hier richtig.

Und wenn Sie sich zu den Themen austauschen wollen, vernetzen Sie sich gerne mit mir auf LinkedIn, ich freue mich über den Austausch aus der Praxis.

Die meisten Teams installieren ein vCenter heute wie eine normale Server-Appliance. ISO mounten, Assistent durchklicken, Netzwerk eintragen, Passwort setzen, fertig. Genau dort beginnt oft das Problem, weil eine Tier–Komponente behandelt wird wie irgendein Management-Server, der halt mitlaufen soll.

Die eigentlichen Kosten entstehen später: bei Day-2-Operations, bei Zertifikaten, bei Identität, bei Recovery und genau dann, wenn ein Sicherheitsvorfall keine Theorie mehr ist. Hier ist die eigentliche Frage: Was passiert sechs Monate nach dem Go-Live, wenn das erste Zertifikat kippt, der Identity Provider hakt oder Sie unter Druck wieder Zugriff brauchen?

Wir schauen uns fünf Architekturentscheidungen an, die über Stabilität, Sicherheit und Betriebsaufwand entscheiden. Wenn Sie die am Anfang falsch treffen, zahlen Sie später mit OPEX, Stillstand und unnötiger Abhängigkeit. Lassen Sie uns das kurz zerlegen, nicht als Installationsfrage, sondern als Risikofrage im laufenden Betrieb.

Abschnitt 1: vCenter ist kein Tool, sondern Ihr Kontrollpunkt im Störfall

Viele Umgebungen sind bei den Workloads erstaunlich ordentlich abgesichert, während das System, das diese Workloads steuert, eher nebenbei behandelt wird. Das ist ein Widerspruch. Sie investieren in Backup, Segmentierung und Monitoring für virtuelle Maschinen, lassen aber bei vCenter oft Standards stehen, die im besten Fall bequem und im schlechtesten Fall fahrlässig sind.

vCenter ist kein nettes Zusatztool für die Administration. vCenter ist der Kontrollpunkt. Dort hängen Hosts, Cluster, Rollen, Netzwerke, Storage-Zuordnungen, Automatisierung, Berechtigungen und häufig auch die Anbindung an Backup- und Betriebswerkzeuge. Wenn Sie dieses System verlieren, verlieren Sie nicht sofort jede laufende VM, aber Sie verlieren Steuerbarkeit, Übersicht und in vielen Fällen genau die Handlungsfähigkeit, die Sie im Störfall brauchen.

Betrachten Sie es wie einen Schaltschrank in einem Produktionsgebäude. Die Maschinen können noch kurz weiterlaufen, aber wenn dort jeder drankommt, wenn niemand die Beschriftung gepflegt hat und wenn Sicherungen nach Gefühl gesetzt wurden, kippt die Lage genau dann, wenn schnell und sauber entschieden werden muss. Da wird es riskant.

Für den Mittelstand ist das keine akademische Frage. Ein kompromittiertes vCenter bedeutet nicht bloß, dass ein Administrator ein paar schlechte Tage hat. Es kann bedeuten, dass Änderungen an Hosts, Netzwerken oder Berechtigungen nicht mehr vertrauenswürdig sind, dass Backup-Prozesse gestört werden oder dass die Wiederanlaufplanung im Ernstfall auf Annahmen basiert, die nicht mehr stimmen. Klartext: Wenn das Management-System fällt, wird aus einem IT-Vorfall schnell ein Betriebsproblem.

Und trotzdem sehen wir in Standard-Setups immer wieder dieselben Lücken. Das Management hängt in einem zu breiten Netz. Der Zugriff erfolgt von beliebigen Admin-Arbeitsplätzen statt über definierte Wege. SSH bleibt aktiviert, weil es irgendwann mal praktisch war. Zuständigkeiten sind diffus, weil Plattformbetrieb, Security und Netzwerk jeweils davon ausgehen, dass der andere den Überblick schon haben wird. Genau aus solchen Konstruktionen entstehen Frankenstein-Integrationen, die im Alltag irgendwie laufen und unter Druck plötzlich unbeherrschbar werden.

Was bedeutet das konkret für Sie? Erstens: vCenter gehört in eine sauber getrennte Management-Zone, nicht in irgendein historisch gewachsenes Verwaltungsnetz. Zweitens: der administrative Zugriff braucht klare Pfade, also Bastion, MFA und nachvollziehbare Verantwortlichkeiten statt stillschweigend verteilter Vollrechte. Drittens: der Betrieb muss dokumentiert sein, nicht nur die Installation. Wer darf ran, von wo, in welchem Fall, mit welchem Rückfallplan?

Die meisten Unternehmen machen den Fehler, bevor sie überhaupt anfangen. Sie halten die Installation für den schwierigen Teil und den späteren Betrieb für Routine. In der Praxis ist es genau andersherum. Die Appliance aufzusetzen ist schnell erledigt. Beherrschbar bleibt sie erst dann, wenn Sie unter Zeitdruck, bei Ausfall oder bei einem Security-Thema noch klare Wege haben und nicht erst diskutieren müssen, wer überhaupt worauf Zugriff hat.

Sobald dieser Grundsatz steht, kommen wir zur ersten Entscheidung, die erstaunlich oft schon am Anfang falsch gesetzt wird: die Anbindung an Identität.

Abschnitt 2: Identity zuerst, OIDC statt gewachsene AD-Gewohnheiten

Seien wir ehrlich: Viele Unternehmen hängen ihr vCenter tief ins Active Directory und nennen das saubere Integration. In Wirklichkeit vergrößern sie damit oft nur den Schaden, wenn später etwas schiefläuft. Denn sobald Identität, privilegierte Konten und Management-Plattform zu eng miteinander verknüpft sind, reicht ein Problem im falschen Bereich, und Sie ziehen das vCenter gleich mit in den Störkreis hinein.

Das Muster kennen wir alle. Historisch gewachsenes AD, ein paar Admin-Gruppen, dazu direkte Zuweisungen, einzelne Alt-Accounts, lokale Sonderrechte, und irgendwann weiß niemand mehr sauber, wer sich worüber anmeldet und warum bestimmte Rechte noch existieren. Das funktioniert erstaunlich lange, bis jemand das erste Mal schnell entziehen, prüfen oder forensisch nachvollziehen muss, wer eigentlich Zugriff hatte. Dann merken Sie, dass Sie keine Identity-Architektur haben, sondern Gewohnheiten.

Sauber gedacht trennt man drei Dinge. Erstens die lokale SSO-Domäne für den Notfall. Zweitens die externe Identität für Menschen, die sich regulär anmelden. Drittens die Rechtevergabe über Gruppen und Rollen statt über persönliche Dauerrechte. Das klingt unspektakulär, ist aber im Betrieb ein großer Unterschied. Wenn ein Administrator das Unternehmen verlässt, dann sollte nicht ein halber Tag in Tickets, Tabellen und Erinnerungen verschwinden, nur um seine Berechtigungen wieder aus dem System zu ziehen.

Das Zielbild ist heute klarer als noch vor einigen Jahren: OIDC-Föderation mit einem zentralen Identity Provider, also zum Beispiel Entra ID, Okta oder einem vergleichbaren Dienst. Was bedeutet das konkret für Sie? Das vCenter verarbeitet dann nicht mehr direkt die Kennwörter dieser Benutzer, sondern vertraut auf Tokens, die vom Identity Provider ausgestellt werden. Die Authentisierung passiert also dort, wo ohnehin Ihre Richtlinien für MFA, Zugriffskontext und Benutzerlebenszyklus liegen. Das ist kein Komfort-Feature. Das ist eine klare Trennung von Zuständigkeiten.

Genau dort liegt der eigentliche Gewinn. Sie bekommen MFA an der richtigen Stelle. Sie können Conditional Access nutzen. Sie entziehen Benutzer sauber zentral, statt in mehreren Systemen hinterherzulaufen. Und Sie reduzieren den Wildwuchs privilegierter Konten, weil nicht jede Plattform wieder ihre eigene kleine Rechtewelt mit Dauerkennwörtern und Sonderlogins aufmacht. Wenn Ihnen das bekannt vorkommt: Sie sind nicht allein, und es ist lösbar.

Aber das ist nur die halbe Wahrheit. OIDC ist nicht automatisch sauber, nur weil das Login moderner aussieht. Da versteckt sich das Risiko an mehreren Stellen. Falsche Redirect-URIs, unvollständige Zertifikatsketten, unstabile Gruppen-Claims oder wechselnde Namensformate reichen schon, damit Anmeldung und Rechtezuordnung im Alltag unzuverlässig werden. Noch unangenehmer wird es, wenn niemand festgelegt hat, wer bei Störungen eigentlich führt: das IAM-Team, das PKI-Team oder das VMware-Betriebsteam. Dann beginnt die übliche Staffelübergabe im Kreis.

Lassen Sie es mich einfach sagen: Wer OIDC nur als bequemeren Login betrachtet, verfehlt den Punkt. Es geht nicht darum, dass sich Admins hübscher anmelden. Es geht darum, dass die Plattform nicht selbst zum Kennwortspeicher und Identitäts-Sonderfall wird. Authentisierung gehört in ein zentrales Identitätssystem. Der Plattformbetrieb muss darauf aufsetzen, aber davon nicht chaotisch abhängen.

Deshalb gehört ein Break-Glass-Prinzip weiterhin dazu. Die lokale SSO-Domäne, also etwa vsphere.local, sollten Sie nicht abschaffen, nur weil externe Föderation eingerichtet ist. Sie brauchen diesen Weg für klar definierte Notfälle, wenn der Identity Provider ausfällt oder die Föderation klemmt. Aber genau dieser Zugang muss streng dokumentiert, stark geschützt und sehr selten genutzt werden. Kein Alltagskonto, kein stiller Zweitweg, kein bequemes Hintertürchen für alle Fälle.

AD oder LDAP haben trotzdem noch ihren Platz, wenn Legacy-Zwänge da sind. Nur dann bitte bewusst und klein geschnitten. Mit LDAPS, mit begrenztem Scope, mit sauberem Gruppenmodell und ohne direkte Sonderrechte auf einzelne Personen. Was Sie vermeiden wollen, sind Mischformen ohne Ordnung: mehrere Identitätsquellen parallel, lokale Alt-Accounts, persönliche Ausnahmeberechtigungen und Gruppen, deren Zweck niemand mehr sicher erklären kann. Genau so entstehen Frankenstein-Integrationen, die im Audit harmlos aussehen und im Vorfall teuer werden.

Für Entscheider ist das keine technische Fußnote. Das Identity-Design rund um vCenter ist Teil von Zero Trust, Teil Ihrer Revisionssicherheit und Teil Ihrer Angriffsfläche. Wenn Sie Identität hier unsauber bauen, haben Sie später kein Authentisierungsproblem, sondern ein Governance-Problem mit direkter Wirkung auf Security und Betrieb.

Sobald dieser Teil sauber steht, kommen wir zu dem Thema, über das Anbieter im Presales gern hinweggehen: Zertifikate und die Vertrauenskette dahinter.

Abschnitt 3: Zertifikate sind kein Einmalprojekt, sondern Betriebsaufwand mit Ausfallpotenzial

Bei Zertifikaten beginnt oft das stille Elend. Nicht am Tag der Installation, sondern Monate später, wenn jemand feststellt, dass zwar alles einmal sauber aussah, aber niemand mehr genau sagen kann, welche Zertifikate im vCenter eigentlich wofür zuständig sind, wer ihre Laufzeiten im Blick hat und welches Team im Fehlerfall den ersten Schritt macht. Die echten Kosten stehen nicht im Installer. Sie tauchen im Zertifikats-Lifecycle der nächsten Jahre auf.

Das Problem ist: Unter dem Begriff „vCenter-Zertifikat“ wird in vielen Häusern alles in einen Topf geworfen. Dabei reden wir über verschiedene Bausteine mit verschiedenen Aufgaben. Sie haben das Machine-SSL-Zertifikat für den Zugriff auf das System selbst. Sie haben interne VMCA-Zertifikate, also die Vertrauensbasis innerhalb der VMware-Welt. Sie haben Solution User, die Dienste untereinander absichern. Und Sie haben das STS-Umfeld, das für Authentisierung und Token-Themen mit im Spiel ist. Dazu kommen gegebenenfalls Zertifikate aus Ihrer externen Unternehmens-PKI. Wer das nicht trennt, arbeitet im Blindflug.

Hier ist die eigentliche Frage: Welche Vertrauenskette schützen Sie intern, und welche wollen Sie nach außen sauber präsentierbar machen? Das ist nicht dasselbe. Viele Probleme entstehen genau dort, wo interne VMware-Vertrauensbeziehungen mit externer PKI vermischt werden, als wäre das ein austauschbarer Satz an Dateien. Ist es nicht. Wenn Sie an der falschen Stelle kreativ werden, brechen Dienste, Registrierungen oder SSO-Abläufe an Punkten, die in keinem schönen Assistenten auftauchen. Dann ist das Zertifikat formal erneuert, aber die Plattform läuft nur noch halb.

Warum wird das gerade schärfer? Weil Laufzeiten kürzer werden, weil Prüfpflichten steigen und weil Zertifikatsänderungen heute häufiger an angrenzende Systeme andocken als früher. Browser-Vertrauen, Identity Provider, API-Zugriffe, Security-Policies, all das hängt mit dran. Was früher alle paar Jahre jemand mit ruhiger Hand nach Feierabend erneuert hat, wird heute zu einem wiederkehrenden Betriebsprozess. Wenn dieser Prozess nicht definiert ist, bekommen Sie keine Ruhe in den Betrieb.

Dazu kommen die unspektakulären Voraussetzungen, über die im Projekt gern hinweggesehen wird: DNS und NTP. Beides klingt banal. In der Praxis entscheidet es aber darüber, ob Sie einem Zertifikat überhaupt vertrauen können oder ob die Fehlersuche in alle Richtungen ausfranst. Wenn Namen nicht sauber auflösbar sind oder die Zeit nicht stimmt, sehen Sie Symptome an der Oberfläche, obwohl die eigentliche Ursache tiefer liegt. Dann diskutieren drei Teams über das Falsche, während der Betrieb wartet.

Was hinterlassen Standard-Installationen an dieser Stelle oft? Keine Inventur der Zertifikatstypen. Keine klare Zuordnung, welches Team welche Teile verantwortet. Keine Alarmierung vor Ablauf. Keine festen Wartungsfenster für Erneuerungen. Und keine Dokumentation, die einer Vertretung erlaubt, sauber zu übernehmen. Das läuft so lange gut, bis die eine Person im Urlaub ist, die „das immer gemacht hat“. Klartext: Dann haben Sie kein Betriebsmodell, sondern Personenkult.

Sauber wird es erst, wenn Sie eine Zielarchitektur festlegen. Internes Vertrauen bleibt intern klar getrennt vom externen Zugriff. Renewal-Fenster werden bewusst geplant, nicht zwischen Tür und Angel erledigt. Alarmierungen kommen früh genug, damit Sie nicht in den Wochenendmodus rutschen. Und die Rollen zwischen Plattformteam und PKI-Team sind vorher geklärt. Wer beantragt, wer liefert, wer prüft ein, wer validiert nachher die Dienste? Wenn diese Fragen offen bleiben, kommt die Rechnung zuverlässig.

In größeren oder standardisierten Umgebungen sollten Sie unterstützte Workflows nutzen, gerade wenn VCF im Spiel ist oder mehrere Management-Komponenten zusammenhängen. Dort geht es nicht um Eleganz, sondern um Supportbarkeit. In Standalone-Umgebungen gilt dasselbe Prinzip in kleiner: dokumentierte Verfahren, getestete Schritte, keine kreativen Schnellschüsse aus alten Wiki-Seiten oder Forenbeiträgen, die in einer anderen Version vielleicht noch funktioniert haben. Was im Labor improvisiert wirkt, wird im Betrieb schnell teuer.

Und noch ein Punkt, der oft unterschätzt wird: Ein Zertifikat kann technisch erneuert sein, während die Plattform betrieblich schon im degradieren Zustand steckt. Dienste starten vielleicht, aber nicht alle sauber. Trust Stores passen nicht überall. Registrierungen sind nicht konsistent. Anmeldung klappt im Browser, aber Schnittstellen oder angebundene Werkzeuge stolpern im Hintergrund. Genau deshalb reicht „Zertifikat ausgetauscht“ als Erfolgsmeldung nicht aus. Sie müssen danach prüfen, ob der Gesamtzustand wieder sauber ist.

Für den Mittelstand geht es dabei nicht um theoretische Perfektion. Niemand braucht ein überzüchtetes Zertifikatsprogramm nur für die Folie. Was Sie brauchen, ist Wiederholbarkeit. Die Erneuerung muss dokumentiert sein, personell übergebbar und betrieblich so organisiert, dass sie nicht an einer einzelnen Admin-Mailbox oder einem alten Kalendertermin hängt. Sonst sparen Sie heute an Struktur und bezahlen morgen mit Ausfallzeit.

Und wenn Identität und Zertifikate in dieser Form wackeln, dann wird jeder Recovery-Fall unerquicklich. Genau dort taucht der nächste teure Irrtum auf.

Abschnitt 4: Snapshot ist kein Backup, und schon gar kein Ransomware-Konzept

Beim Thema Schutz der vCenter Server Appliance hören wir in Projekten erstaunlich oft denselben Satz: „Wir haben ja einen Snapshot.“ Klartext: Wer vCSA-Snapshots mit Datensicherung verwechselt, verwechselt einen Rückgängig-Knopf mit einer Wiederanlaufstrategie. Das kann für eine kurze Änderung praktisch sein. Als belastbarer Schutz taugt es nicht.

Ein Snapshot ist technisch gesehen erst einmal nur ein Punkt für einen kurzfristigen Rollback vor einer Änderung. Mehr nicht. Er ist kein unabhängiger Datenstand, kein sauber ausgelagerter Sicherungssatz und schon gar kein Ersatz für eine konsistente Sicherung der Appliance. Genau an dieser Stelle wird es in vielen Umgebungen unnötig riskant, weil man aus Bequemlichkeit eine Betriebsannahme baut, die im Ernstfall nicht trägt.

Die vCSA ist keine leere Verwaltungs-VM, die man einfach irgendwie wieder hochzieht. In diesem System stecken Datenbank, Konfiguration, SSO-Zustand, Zertifikate, Registrierungen und die Anbindungen an andere Komponenten. Das ist zustandsbehaftet. Wenn Sie so ein System schützen wollen, reicht kein bloßer Verweis auf einen früheren Zustand im selben Storage-Kontext, vor allem dann nicht, wenn die eigentliche Frage lautet, wie Sie nach einem Fehler oder nach einem Angriff sauber wieder anlaufen.

Was in der Praxis deutlich tragfähiger ist, ist die eingebaute dateibasierte Sicherung über die VAMI. Sie sichern die Appliance auf ein externes Ziel, also entkoppelt vom Datastore, auf dem die VM gerade läuft. Genau das ist der Unterschied. Sie erzeugen eine wiederherstellbare Sicherung, die nicht daran hängt, dass derselbe Infrastrukturpfad intakt bleibt, der vielleicht gerade Teil des Problems ist. Viele Teams leben im vSphere Client und vergessen dabei das Fundament. Die VAMI ist für diesen Teil kein Nebenschauplatz, sondern der saubere Ausgangspunkt.

Das heißt nicht, dass Image-Backups wertlos wären. Als zweite Schicht können sie sinnvoll sein. Aber sie sollten nie die einzige Wahrheit über Ihre Wiederherstellung sein. Wenn die Appliance-eigene Sicherung fehlt und Sie sich nur auf VM-Ebene verlassen, bauen Sie Ihre Recovery auf Annahmen, die Sie unter Druck erst verifizieren müssten. Das ist kein guter Zeitpunkt für Überraschungen.

Noch teurer wird es, wenn Snapshots zu lange liegen bleiben. Dann wachsen Delta-Dateien, die Performance leidet, die Konsolidierung wird unangenehm und im falschen Moment läuft Ihnen der Speicher voll. Aus einer vermeintlich sicheren Vorsichtsmaßnahme wird dann ein zusätzlicher Betriebsfehler. Man sieht das oft nach Änderungen, wenn niemand sauber nachzieht und der Snapshot einfach liegen bleibt, weil „man ja erstmal schauen wollte“. Genau solche kleinen Nachlässigkeiten rächen sich später.

In verbundenen oder gekoppelten Umgebungen kommt ein weiterer Punkt dazu. Ein asymmetrisches Rollback, also nur eine Seite zurückzudrehen, während der Rest der Umgebung weitergelaufen ist, kann Replikation und Vertrauenszustände beschädigen. Das klingt nach einem Detail für Spezialisten, ist aber in der Wirkung alles andere als klein. Sie holen nicht einfach nur eine VM auf einen früheren Stand zurück, sondern greifen in Beziehungen ein, die inzwischen weitergeschrieben wurden. Danach beginnt die Detektivarbeit.

Und nun zur Ransomware-Perspektive, weil genau dort die falsche Sicherheit durch Snapshots besonders gefährlich wird. Wenn vCenter, ESXi und die Backup-Infrastruktur im selben Vertrauensraum liegen, reicht ein kompromittiertes Administrationskonto oft aus, um maximalen Schaden anzurichten. Dann hilft Ihnen der Snapshot wenig, weil auch der Schutzpfad selbst schon unter Kontrolle des Angreifers stehen kann. Das ist der Teil, über den man gern zu spät spricht.

Die Schutzlogik ist deshalb ziemlich nüchtern. Das Management-Netz gehört sauber segmentiert. MFA für administrative Zugriffe gehört erzwungen. SSH bleibt aus und nur temporär an, wenn es einen konkreten Anlass gibt. Lockdown auf den Hosts ist keine Schikane, sondern Begrenzung des Schadens. Und Ihre Backup-Ziele müssen isoliert und im besten Fall unveränderbar sein, damit sie nicht mit demselben Satz Berechtigungen aus dem Verkehr gezogen werden können wie die Produktivumgebung.

Das ist keine akademische Security-Debatte. Das ist eine direkte Frage von RTO, Handlungsfähigkeit und Verhandlungsposition im Ernstfall. Wenn Sie sauber wiederherstellen können, reden Sie anders über einen Vorfall. Wenn Ihr Schutzkonzept am selben Konto hängt wie der Angriffspfad, reden andere mit Ihnen, nicht Sie mit ihnen.

Damit sind wir beim eigentlichen Kostenblock angekommen, nicht bei der Installation selbst, sondern bei dem, was Sie danach jeden Monat zuverlässig betreiben müssen.

Abschnitt 5: Day-2-Operations entscheiden, ob vCenter tragfähig oder nur installiert ist

An dieser Stelle trennt sich ein sauberes Setup von einer bloßen Installation. Die Standard-Installation endet in dem Moment, in dem das Login funktioniert und die ersten Hosts eingebunden sind. Eine tragfähige Architektur beginnt erst dort, wo klar ist, wie dieses System im Alltag betrieben, überwacht, geändert und im Notfall übernommen wird.

Was dokumentiert sein muss, ist erstaunlich banal und genau deshalb oft lückenhaft. DNS und NTP. Die eingesetzten Zertifikatstypen. Die Identity-Flows. Der Break-Glass-Zugang. Die Backup-Ziele. Die Reihenfolge für Recovery. Und vor allem die Zuständigkeiten. Wer übernimmt bei welchem Fehlerbild? Wer entscheidet bei Zertifikatswechseln? Wer darf im Notfall direkt auf die Appliance? Wenn diese Fragen nur in Köpfen liegen, haben Sie kein Betriebsmodell, sondern Glück auf Zeit.

Genauso wichtig ist die laufende Überwachung. Sie brauchen Sicht auf Zertifikatslaufzeiten, auf den Status der Dienste, auf die Gesundheit der Appliance in der VAMI, auf Speicherstände, auf fehlgeschlagene Anmeldungen und auf Konfigurationsdrift. Denn Probleme kündigen sich selten als großes Ereignis an. Meist fangen sie klein an, unauffällig, mit einzelnen Warnungen, die niemand ernst nimmt, bis daraus ein echter Vorfall geworden ist.

Die VAMI wird dabei gern unterschätzt. Viele Administratoren arbeiten fast ausschließlich im vSphere Client und sehen die eigentliche Appliance nur dann, wenn schon etwas schiefgeht. Das ist ein Fehler. Wer nur den vSphere Client nutzt, verwaltet die virtuelle Umgebung, aber nicht das System, das diese Umgebung trägt. Genau dort liegen aber Betriebsthemen wie Backup, Patch-Status, Ressourcenverbrauch und Grundgesundheit.

Ein unscheinbarer Punkt mit erstaunlich viel Sprengkraft ist das Root-Passwort samt Ablaufregeln und Notfallzugriff. Solche Dinge dürfen nicht an der Erinnerung einzelner Administratoren hängen. Wenn ein Passwort abläuft, ein Zugang gesperrt ist oder ein Reset nur mit improvisierten Schritten möglich wird, haben Sie kein technisches Problem, sondern mangelnde Betriebsdisziplin. Das kostet Zeit, Nerven und im falschen Moment Vertrauen in die gesamte Plattform.

Auch Änderungen brauchen ein festes Muster. Vor Änderungen steht eine saubere Sicherung. Das Wartungsfenster bleibt eng. Ein Snapshot, wenn überhaupt, nur bewusst, kurzlebig und mit klarer Bereinigung direkt danach. Dieses Vorgehen klingt nicht spektakulär. Genau das ist der Punkt. Gute Day-2-Operations leben nicht von heldenhaften Rettungsaktionen, sondern von wiederholbaren Routinen.

Für den Mittelstand ist die Entscheidungslogik dabei meist einfacher, als Anbieter es gern darstellen. Lieber weniger Sonderlocken und eine Plattform, die mehrere Leute verstehen und sauber betreiben können, als ein cleveres Konstrukt, das nur ein Spezialist beherrscht. Die Rechnung kommt sonst nicht im Projekt, sondern Monate später im Betrieb.

Was bedeutet das konkret für Sie, wenn Sie ein neues vCenter aufbauen oder ein bestehendes bereinigen wollen? Prüfen Sie nicht zuerst die hübschen Funktionen, sondern die Betriebsfähigkeit dahinter.

Fazit: Vor dem Klick die harten Fragen stellen

Gute vCenter-Konfiguration entscheidet sich nicht im Assistenten. Sie entscheidet sich in Ihrem Identity-Modell, im Zertifikatsbetrieb, im Schutzkonzept und in der Frage, wer die Plattform nach dem Go-Live tatsächlich verantwortet.

Ihr Prüfauftrag ist deshalb einfach. Gehen Sie Ihre Umgebung in vier Punkten durch: Identität, Zertifikate, Backup statt Snapshot und Day-2-Operations mit klaren Zuständigkeiten. Wenn einer dieser Punkte nur auf Zuruf, Bauchgefühl oder Einzelspezialisten beruht, steckt dort bereits Ihr Betriebsrisiko.

Das war IT for Business.

Wenn Sie aus dieser Folge etwas mitnehmen, dann vielleicht das: Gute IT entscheidet sich nicht im Tool, sondern in der Architektur und den Entscheidungen davor.

Wenn Ihnen die Folge gefallen hat, abonnieren Sie den Podcast, um keine weiteren Episoden zu IT-Entscheidungen aus der Praxis zu verpassen.

Und wenn Sie selbst vor einer IT-Modernisierung oder einem Projekt stehen: Stellen Sie die richtigen Fragen früh, nicht erst im Betrieb.

Bis zur nächsten Folge.