ServiceNow Discovery: woran Projekte in der Praxis wirklich scheitern

Wenn ein ServiceNow-Discovery-Rollout stockt, liegt es nach meiner Erfahrung fast nie an ServiceNow. Die Pattern sind ausgereift, die MID-Server laufen stabil, und die Erkennungsqualität ist bei Standardtechnologien schlicht gut. Es liegt an drei Dingen, und alle drei sind organisatorisch. Wer sie kennt, kann sie einplanen. Wer sie ignoriert, erlebt ein Projekt, das technisch fertig ist und trotzdem nicht liefert.

Blocker 1: Credentials

Discovery braucht Zugangsdaten für die Systeme, die es scannen soll. Klingt trivial, ist aber in den meisten Unternehmen der größte einzelne Blocker. Das Muster ist immer ähnlich: Das Security-Team will keine Service-Accounts mit breiten Leserechten vergeben. Die Serverteams wollen keinen fremden Account auf ihren Maschinen. Die Datenbank-Administratoren erst recht nicht. Und am Ende diskutiert man Wochen über etwas, das im Projektplan als Vorbereitungsaufgabe mit zwei Tagen stand.

Was in meinen Projekten geholfen hat:

Erstens, das Thema vor dem Projektstart eskalierbar machen. Es braucht einen Sponsor, der im Zweifel entscheidet. Ohne den verhandelt das Projektteam monatelang auf Arbeitsebene, wo niemand Ja sagen darf und jeder Nein sagen kann.

Zweitens, technisch sauber argumentieren. Discovery braucht Leserechte, keine Adminrechte. Auf Windows reicht für vieles ein Konto mit eingeschränkten WMI-Berechtigungen, auf Linux genügen definierte Kommandos per sudo. Und mit einer Vault-Integration wie CyberArk müssen die Passwörter nicht einmal in ServiceNow gespeichert werden. Diese Argumente entkräften die meisten Sicherheitsbedenken, aber jemand muss sie kennen und vortragen.

Drittens, klein anfangen. Ein Subnetz, eine Systemklasse, ein Team, das mitzieht. Ein funktionierender Pilot mit sichtbarem Ergebnis öffnet mehr Türen als jede Richtlinien-Diskussion.

Blocker 2: Firewalls

Der MID-Server muss die Zielsysteme erreichen, und zwar auf den Ports, die die jeweilige Erkennung braucht. In flachen Netzen ist das kein Thema. In segmentierten Netzen, also überall dort, wo Security ihre Arbeit gemacht hat, heißt das: Firewall-Anträge. Viele Firewall-Anträge.

Der Fehler, den ich immer wieder sehe: Die Anträge werden reaktiv gestellt, Subnetz für Subnetz, immer wenn Discovery wieder irgendwo nicht hinkommt. Jeder Antrag dauert seine ein, zwei Wochen, und in Summe zieht sich der Rollout über Monate.

Besser: gleich zu Beginn eine vollständige Kommunikationsmatrix aufstellen. Welche MID-Server stehen wo, welche Netzbereiche sollen erfasst werden, welche Ports und Protokolle braucht es je Systemtyp. Das Dokument geht einmal gesammelt an die Netzwerk-Kollegen, idealerweise mit deren Beteiligung erstellt. Auch die Platzierung der MID-Server gehört in diese Überlegung: Manchmal ist ein zusätzlicher MID-Server im abgeschotteten Segment deutlich schneller umgesetzt als zwanzig Firewall-Freischaltungen quer durchs Netz.

Blocker 3: Zuständigkeiten

Discovery findet Dinge. Auch Dinge, die niemandem gehören wollen. Verwaiste Server, deren Besitzer das Unternehmen verlassen hat. Vergessene Datenbanken. Testsysteme, die seit Jahren produktiv mitlaufen. Schatten-IT, die eine Fachabteilung am offiziellen Prozess vorbei aufgebaut hat.

Genau das ist eigentlich der Wert des Ganzen. Aber jemand muss sich darum kümmern, und dieser Teil wird in fast jedem Projekt unterschätzt. Ohne einen definierten Prozess für unklare Funde sammeln sie sich in einem Korb, den niemand leert, und nach einem Jahr ist die CMDB voll mit CIs im Zustand "unbekannt".

Was es braucht, ist kein großes Rahmenwerk, sondern drei klare Antworten: Wer sichtet neue Funde und wie oft? Nach welchen Regeln wird Besitz zugeordnet, wenn sich niemand meldet? Und was passiert mit Systemen, die offenbar niemand braucht? Ein zweiwöchentlicher Termin mit den Plattform-Verantwortlichen und eine einfache Entscheidungsregel reichen für den Anfang völlig.

Und die Technik?

Natürlich hat auch die technische Seite ihre Tücken. Schedules wollen vernünftig geschnitten sein, damit sich Discovery nicht mit sich selbst staut. Load Balancer und Cluster brauchen Aufmerksamkeit, damit die Beziehungen stimmen. Das Verhalten bei Cloud-Ressourcen ist ein eigenes Thema. Aber das sind lösbare, gut dokumentierte Probleme, an denen ein erfahrenes Team selten hängen bleibt.

Mein Fazit nach etlichen Discovery-Einführungen: Plant für Credentials, Firewalls und Zuständigkeiten zusammen mindestens so viel Kalenderzeit ein wie für die gesamte technische Umsetzung. Das fühlt sich bei der Projektplanung übertrieben an und erweist sich fast immer als realistisch. Und es lohnt sich, denn eine CMDB, die niemand nutzt, beginnt oft mit einer Discovery, die nie richtig fertig wurde.