Wer schon mal mit einem “Zentralen Verwaltungsserver” in Microsoft SQL Server gearbeitet hat, wird dieses Feature nicht mehr missen wollen. Insbesondere in sehr großen Serverlandschaften erleichtert es die Arbeit ungemein, da mit wenigen Handgriffen Anpassungen an den verwalteten Servern durchgeführt werden können. Zentrale Verwaltungsserver speichern eine Liste von SQL Server -Instanzen, die in ein oder mehrere Gruppen unterteilt sind. Alle Aktionen wirken sich auf alle Server in der Servergruppe aus.

Eine – bedauerliche – Einschränkung besteht jedoch, seit dieses Feature mit Microsoft SQL Server 2008 zur Verfügung gestellt wurde: “Der Zentrale Verwaltungsserver” kann nicht selbst in die Gruppe der verwalteten Server hinzugefügt werden!

image

Der Versuch, den Server [NB-LENOVO-I\SQL_2016] in die Liste der verwalteten Server hinzuzufügen, schlägt fehl, da Microsoft SQL Server überprüft, ob es sich bei dem Server um den Zentralen Verwaltungsserver handelt. Die Fehlermeldung ist selbst erklärend. Mit einem kleinen Trick kann man aber diese Barriere knacken und den Zentralen Verwaltungsserver in die Liste übertragen.

Hinweis

Die hier gezeigte Lösung ist nicht offiziell von Microsoft freigegeben! Trotz einiger Recherche und Tests ist nicht auszuschließen, dass es zu Problemen kommen kann. Alle von mir ausgeführten Tests (Multi-Server-Abfrage, Policy-Checks, …) verliefen ohne Beanstandungen. Die Analyse der Datenstruktur sowie der Prozeduren ergaben keine Einschränkungen/Probleme. Dennoch der Hinweis, die gezeigte Technik selbst AUSFÜHRLICH zu testen!

Hintergrundinformationen

msdb

Microsoft verwaltet einen SQL Server im Kern auch nur durch die Verwendung von Tabellen, Sichten und Stored Procedures. Insbesondere die Datenbank MSDB ist voll von solchen Verwaltungselementen. Die Funktionalität eines “Zentralen Verwaltungsservers” wird ebenfalls durch Objekte in der Systemdatenbank MSDB bereitgestellt. Hierzu hat das Team von Microsoft folgende Objekte in MSDB implementiert:

image

Systemtabellen

Microsoft SQL Server benötigt für einen “Zentralen Verwaltungsserver” lediglich zwei Tabellen. In der Tabelle [dbo].[SYSMANAGEMENT_SHARED_SERVER_GROUPS_INTERNAL] werden die logischen Verwaltungsgruppen gespeichert, unter denen man seine SQL Server abspeichert. Die Tabelle [dbo].[SYSMANAGEMENT_SHARED_REGISTERED_SERVERS_INTERNAL] verwaltet die Namen der zu verwaltenden SQL Server.

Views

Die Views haben einen “schützenden” Charakter. Es gibt für die Verwaltungsserver zwei Datenbankgruppen, mit denen die registrierten SQL Server verwaltet werden können:

Ausschließlich die Benutzergruppe [ServerGroupReaderRole] besitzt eine SELECT-Berechtigung auf die beiden Views. Damit ist gewährleistet, dass jedes Mitglied dieser Gruppe die zu verwaltenden SQL Server sehen kann.

Stored Procedures

Die Vielzahl von Stored Procedures für die Verwaltung eines Verwaltungsservers sollen hier nicht detailliert beschrieben werden; aus den Namen geht deutlich hervor, welche Funktion diese Prozeduren haben. Ausschließlich Mitglieder der Datenbankrolle [ServerGroupAdministratorRole] besitzen das Recht, die Prozeduren auszuführen.

Eine Stored Procedure wird dennoch etwas genauer unter die Lupe genommen. Hierbei handelt es sich um die Prozedur [dbo].[SP_SYSMANAGEMENT_ADD_SHARED_REGISTERED_SERVER]. Diese Prozedur wird aufgerufen, sobald ein neuer Server zum Verwaltungsserver hinzugefügt werden soll. Gibt man als Namen den Verwaltungsserver selbst ein, wird der oben beschriebene Fehler ausgelöst!

[dbo].[SP_SYSMANAGEMENT_ADD_SHARED_REGISTERED_SERVER]

Es soll nicht der vollständige Code der Prozedur hier beschrieben werden. Vielmehr ist wichtig, wie Microsoft SQL Server überprüft, welcher SQL Server hinzugefügt werden soll und wie darauf reagiert wird!

IF (UPPER(@@SERVERNAME collate SQL_Latin1_General_CP1_CS_AS) = UPPER(@server_name collate SQL_Latin1_General_CP1_CS_AS))
BEGIN
    RAISERROR (35012, -1, -1)
    RETURN (1)
END

INSERT INTO [msdb].[dbo].[sysmanagement_shared_registered_servers_internal]
(server_group_id, name, server_name, description, server_type)
VALUES
(@server_group_id, @name, @server_name, @description, @server_type)

Wenn der eigene Servername (@@SERVERNAME) identisch ist mit dem hinzuzufügenden Namen, wird der Fehler 35012 ausgeführt und die Prozedur beendet. Sollte die Überprüfung erfolgreich sein, wird in die Tabelle [dbo].[SYSMANAGEMENT_SHARED_REGISTERED_SERVERS_INTERNAL] der Eintrag vorgenommen. Na ja, was Microsoft SQL Server kann, kann ich als sysadmin auch.

In meinem Beispiel ist die Instanz [NB-LENOVO-I\SQL_2016] als Zentraler Verwaltungsserver eingerichtet worden. Diese Instanz dem Verwaltungsserver hinzuzufügen, wurde mit der obigen Fehlermeldung beendet. Also wird die Instanz direkt in die Systemtabelle eingetragen! In meiner Testumgebung liefert die Abfrage der beiden Systemtabellen folgende Informationen:

image

Die Instanz [NB-LENOVO-I\SQL_2017] befindet sich unmittelbar im Hauptknoten der Verwaltung während die Instanz [NB-LENOVO-I\SQL_2008] in der Gruppe [Produktion] gespeichert wurde. Soll also die Instanz [NB-LENOVO-I\SQL_2016] ebenfalls in der Gruppe [Produktion] gespeichert werden, muss das folgende T-SQL-Skript ausgeführt werden:

INSERT INTO dbo.sysmanagement_shared_registered_servers_internal
(server_group_id, name, server_name, description, server_type)
VALUES
(
    6,
    N'NB-LENOVO-I\SQL_2016',
    N'NB-LENOVO-I\SQL_2016',
    N'Zentraler Verwaltungsserver',
    0
);

Et voilà!

Vielen Dank fürs Lesen!