Was ist der Unterschied zwischen Managed Services und klassischem IT-Support?
Managed Services sind proaktiv: Wir überwachen, optimieren und handeln, bevor Probleme entstehen. Klassischer Support reagiert erst, wenn etwas kaputt ist. Das spart Ihnen Ausfälle und Stress.
Wie schnell reagiert ihr bei Störungen?
Jeder Vorfall wird nach Auswirkung und Dringlichkeit eingestuft — ein Totalausfall eines geschäftskritischen Systems läuft in einer anderen Bahn als eine Einzelanfrage. Welche Reaktionszeit je Stufe gilt, legen wir im Vertrag fest, weil sie davon abhängt, welche Systeme Sie als kritisch benennen und welches Betriebsmodell Sie wählen. Innerhalb der Servicezeit von Montag bis Freitag, 08:00 bis 17:00 Uhr, erreichen Sie einen festen Ansprechpartner statt einer Warteschleife. Wer eine personelle Reaktion außerhalb dieser Zeiten braucht, wählt Rufbereitschaft oder Managed SOC — das technische Monitoring läuft ohnehin durchgehend.
Ersetzt ihr unser internes IT-Team?
Nein, wir ergänzen es. Managed Services entlasten Ihr Team von Routineaufgaben, damit es sich auf strategische Themen konzentrieren kann. Wir arbeiten als Erweiterung Ihres Teams.
Was kostet Managed Services für unsere IT?
Die Treiber sind: Anzahl der Arbeitsplätze und Server, Zahl der Standorte, Umfang der betreuten Plattformen, gewünschte SLA-Stufe und der Zustand der Umgebung beim Start — eine dokumentierte, gepatchte Landschaft ist im Betrieb dauerhaft günstiger als eine gewachsene. Abgerechnet wird als monatliche Pauschale je Arbeitsplatz und je Server, Projektarbeit außerhalb des vereinbarten Leistungsumfangs nach Aufwand. Getrennt davon laufen Microsoft-Lizenzen und Azure-Verbrauch über Ihre eigenen Verträge: Microsoft Sentinel etwa wird nach eingelesenem Datenvolumen in Gigabyte abgerechnet — ein eigener Kostenhebel, den wir im Quartals-Review mitoptimieren.
Welche SLA-Stufen und Servicezeiten gelten?
Unsere Servicezeit ist Montag bis Freitag von 08:00 bis 17:00 Uhr MEZ, ausgenommen gesetzliche Feiertage in Bayern. Reaktionszeiten sind vertraglich gestaffelt und ergeben sich aus Auswirkung und Dringlichkeit: Ein Totalausfall eines geschäftskritischen Systems wird anders behandelt als eine Einzelanfrage. Sie erhalten einen festen Ansprechpartner mit Vertretungsregelung, erreichbar per Telefon und E-Mail, auf Deutsch oder Englisch, dazu einen monatlichen Servicebericht und ein Quartals-Review. Das technische Monitoring läuft durchgehend. Personelle Erreichbarkeit außerhalb der Servicezeit ist kein Standard, sondern als Managed SOC oder Rufbereitschaft zubuchbar.
Was passiert bei einem Sicherheitsvorfall außerhalb der Servicezeit?
Die technische Erkennung arbeitet durchgehend: Analyseregeln in Microsoft Sentinel und Microsoft Defender XDR greifen rund um die Uhr, und automatisierte Playbooks können ohne menschliches Zutun ein Konto sperren, eine Sitzung beenden oder ein Endgerät isolieren. Die menschliche Analyse und Kommunikation beginnt im Standardvertrag mit dem Start der nächsten Servicezeit; wer eine schnellere personelle Reaktion braucht, bucht Managed SOC oder Rufbereitschaft dazu. Für regulierte Unternehmen wichtig: Besonders wichtige und wichtige Einrichtungen müssen einen erheblichen Sicherheitsvorfall nach § 32 BSIG binnen 24 Stunden nach Kenntnis erstmelden und binnen 72 Stunden nachmelden — diese Fristen laufen unabhängig von Ihren Betriebszeiten.
Betreut ihr auch On-Premises-Server, oder nur Cloud?
Beides, und in der Praxis fast immer hybrid. Wir betreuen Windows-Server, Hyper-V- und Storage-Spaces-Direct-Cluster, Netzwerkkomponenten und lokale Backup-Infrastruktur auf Veeam-Basis genauso wie Azure und Microsoft 365 — dieselbe Infrastruktur bauen wir im Bereich Infrastruktur und Private Cloud auch selbst auf. Technisch binden wir lokale Server über Azure Arc an, damit sie im selben Monitoring-, Patch- und Richtlinienrahmen landen wie Cloud-Ressourcen. Eine klare Grenze: Hardwaretausch vor Ort und Herstellergarantie liegen bei Ihnen oder Ihrem Lieferanten. Wir koordinieren solche Fälle, ersetzen aber keinen Vor-Ort-Hardwaredienst.
Wie läuft der Wechsel von unserem bisherigen Dienstleister?
In einer Übergabephase mit Parallelbetrieb, nicht an einem Stichtag über Nacht. Zuerst nehmen wir auf, welche administrativen Konten und delegierten Zugriffe überhaupt existieren — diese Liste ist beim Wechsel regelmäßig unvollständig. Dann übernehmen wir Dokumentation und Monitoring, richten Alarmierungs- und Eskalationswege neu ein und schalten die Altzugänge erst nach Abnahme ab. Zwei Punkte gehören früh geklärt: Break-Glass-Konten müssen in Ihrem Besitz sein, und der Dienstleisterwechsel ist vom Lizenzvertrag zu trennen, weil platzbasierte Microsoft-Abonnements nach Ablauf der siebentägigen Kündigungsfrist bis zum Laufzeitende weiterlaufen.
Wie lange dauert das Onboarding in den Managed Service?
Typisch zwei bis vier Wochen bis zum Regelbetrieb. Von Ihnen brauchen wir einen Ansprechpartner mit Entscheidungsbefugnis, administrative Zugänge, vorhandene Dokumentation wie Netzplan, Systeminventar und Backup-Konzept, eine Liste der kritischen Anwendungen mit ihren Betriebszeiten, Ihre interne Eskalationskette und die Freigabe, Monitoring-Agents auszurollen. Rechnen Sie in den ersten Wochen mit mehr Alarmen als später: Schwellwerte und Baselines werden erst im laufenden Betrieb scharfgestellt. Am Ende des Onboardings steht ein schriftlicher Leistungsschein, der festhält, welche Systeme betreut werden und welche ausdrücklich nicht.
Wie sieht der Exit aus — bekommen wir Dokumentation und Zugänge zurück?
Beim Vertragsende erhalten Sie die aktuelle Betriebsdokumentation, alle Runbooks, die Monitoring- und Alarmkonfiguration, das Backup-Konzept mit Aufbewahrungsfristen sowie ein Übergabeprotokoll. Zurückzumigrieren gibt es nichts: Ihre Daten liegen ohnehin in Ihrer eigenen Umgebung — im eigenen Microsoft-Tenant in EU-Regionen oder auf Ihren lokalen Systemen — und nie auf einer Alendris-Plattform. Unsere administrativen Konten werden deaktiviert und entfernt, delegierte Zugriffsbeziehungen beendet — das können Sie im Admin Center selbst nachprüfen. Auf Wunsch übergeben wir direkt an den Nachfolge-Dienstleister, inklusive gemeinsamer Übergabetermine. Die Kündigungsfristen stehen im Vertrag und sind nicht an Zusatzleistungen gekoppelt.
Ist Storage Spaces Direct (S2D) dasselbe wie Azure Local?
S2D ist die zugrunde liegende Storage-Technologie, auf der Microsofts Azure Local (vormals Azure Stack HCI) aufbaut. Wir konzipieren Ihre Cluster von Anfang an Azure-Local-kompatibel, damit Sie später nahtlos in hybrides Cloud-Management wechseln können, ohne die Infrastruktur neu aufzubauen.
Warum reicht ein normales Backup nicht gegen Ransomware?
Klassische Backup-Ziele sind vom Produktivnetzwerk aus erreichbar und damit selbst angreifbar. Erst unveränderlicher (immutable) Storage — bei dem selbst Administratoren gesicherte Daten nicht löschen oder verschlüsseln können — schützt zuverlässig gegen Ransomware, die gezielt Backups zuerst angreift.
Wie funktioniert die tägliche Rotation 128 Zeichen langer Passwörter in der Praxis?
Über Fine-Grained Password Policies (FGPP) in Active Directory in Kombination mit automatisierter Passwort-Verwaltung — niemand merkt sich mehr ein Passwort. Für die Alltagsanmeldung an verwalteten Endgeräten nutzen wir Windows Hello for Business (biometrisch oder per PIN, gerätegebunden); für Zugriffe, die nicht an ein einzelnes Gerät gebunden sein dürfen — etwa privilegierte Zugriffe oder wechselnde Arbeitsplätze — kommen YubiKeys als portabler, hardwarebasierter Faktor zum Einsatz. Die zugrunde liegenden Passwörter rotieren täglich automatisiert im Hintergrund und sind für niemanden mehr sichtbar oder merkbar, was klassische Passwort-Angriffe praktisch wirkungslos macht.
On-Premises, Private Cloud oder Public Cloud — was passt wann?
Die Entscheidung fällt je Workload, nicht pauschal für das ganze Unternehmen. Für eigene Hardware sprechen konstante Dauerlast, harte Latenzanforderungen etwa zu Produktionsanlagen, große Datenmengen mit hohem Durchsatz und regulatorische Vorgaben zur Datenhoheit. Für die Public Cloud sprechen schwankende Lasten, kurze Bereitstellungszeiten, geografische Verteilung und der Wunsch, keine Hardware mehr zu betreiben. Zusätzlich zählen die Restlaufzeit vorhandener Hardware, verfügbares Betriebs-Know-how und die Ausstiegsfähigkeit. In der Praxis endet es meist hybrid: ERP und Dateidienste lokal auf einem Cluster, Identität, Kollaboration und die ausgelagerte Backup-Kopie in der Cloud.
Was treibt die Kosten beim Aufbau eines hyperkonvergenten Clusters?
Vor allem die Resilienz-Entscheidung, weil sie die benötigte Rohkapazität bestimmt. Ein Zwei-Wege-Spiegel braucht mindestens zwei Server und erreicht 50 Prozent Speichereffizienz, ein Drei-Wege-Spiegel mindestens drei Server und 33,3 Prozent — für ein Terabyte Nutzdaten also drei Terabyte Rohkapazität. Für produktive Zwei-Knoten-Cluster empfiehlt Microsoft zusätzlich Nested Resiliency, die als verschachtelter Zwei-Wege-Spiegel nur rund 25 Prozent Speichereffizienz erreicht. Dazu kommen NVMe-Anteil und Cache-Auslegung, das Netzwerk mit redundanten 10G- oder 25G-Switches sowie die Lizenzierung: Windows Server wird nach physischen Kernen lizenziert, mindestens acht je Prozessor und sechzehn je Server. Bei Azure Local kommt eine monatliche Abrechnung je physischem Kern hinzu, Gastbetriebssysteme werden separat lizenziert.
Welche Vertrags- und Abrechnungsmodelle gibt es für Infrastrukturprojekte?
Assessment und Architektur laufen als Festpreis, ebenso Aufbau und Migration je Phase mit definierter Abnahme. Als Abnahmekriterien vereinbaren wir überprüfbare Tests statt weicher Formulierungen: erfolgreicher Failover eines Clusterknotens im laufenden Betrieb, dokumentierter Restore aus dem unveränderlichen Backup, gemessener Durchsatz. Offene Altlasten rechnen wir nach Aufwand ab. Hardware und Lizenzen können Sie über Ihren gewohnten Einkaufsweg beziehen; unsere Sizing-Empfehlung ist davon unabhängig. Der spätere Betrieb ist optional als Managed Service je Server und Cluster buchbar.
Wie lange dauert der Aufbau, und was müssen wir bereitstellen?
Assessment ein bis zwei Wochen, Architektur und Sizing zwei bis vier Wochen; danach bestimmt fast immer die Lieferzeit von Servern und Switches den Termin, nicht die Konfiguration. Von Ihnen brauchen wir Rack-Platz mit ausreichender Stromversorgung, idealerweise zwei Kreisen und USV, Kühlung mit Reserve, freie Switch-Ports und Uplinks, ein IP- und VLAN-Konzept oder die Freiheit, eines zu entwerfen, Zutritt zum Serverraum sowie freigegebene Wartungsfenster für den Cutover. Ergänzend eine Liste der Anwendungen mit Ansprechpartnern, damit Abhängigkeiten vor der Migration bekannt sind.
Bekommen wir Dokumentation und Zugänge, und läuft die Umgebung ohne euch weiter?
Ja, beides. Zur Abnahme gehören eine As-built-Dokumentation mit Cluster-Layout, Volumes samt gewähltem Resilienz-Typ, VLAN- und Firewall-Übersicht, Backup-Jobs mit Aufbewahrungsfristen sowie das Protokoll des Restore-Tests. Administrative Zugänge einschließlich Break-Glass-Konten liegen bei Ihnen, nicht bei uns. Die Umgebung basiert auf Standardtechnologien — Windows Server mit Storage Spaces Direct, marktübliche Switches, Veeam für Backup — und nicht auf proprietären Alendris-Komponenten. Sie können den Betrieb selbst übernehmen, an einen Dritten geben oder uns beauftragen; wir übergeben in allen drei Fällen dieselben Runbooks.
Bleiben unsere Daten in der EU, auch wenn der Cluster an Azure angebunden ist?
Die Nutzdaten Ihrer virtuellen Maschinen und Dateidienste liegen physisch in Ihrem Rechenzentrum und verlassen es auch bei einer Azure-Anbindung nicht. Was an Azure fließt, sind Verwaltungs- und Abrechnungsdaten: Inventar, Zustandsmeldungen und die Zahl der physischen Kerne, nach denen Azure Local monatlich abgerechnet wird. Diese Daten gehen in die Region, in der das System registriert wurde — Azure Local unterstützt dafür nur eine begrenzte Liste an Regionen, innerhalb der EU derzeit West Europe. Wir registrieren dort und dokumentieren es. Gleiches gilt für die ausgelagerte Backup-Kopie: Eine unveränderliche Kopie bleibt vor Ort, die zweite liegt in einer EU-Region mit vertraglich fixierter Aufbewahrungsfrist.