Verwaltete Azure Monitor SCOM-Instanzen – Häufig gestellte Fragen

Um die Latenz aufrechtzuerhalten, empfehlen wir Ihnen, das VNet in derselben Region wie Ihre anderen Azure-Ressourcen zu verwenden.

Der mindeste Adressraum ist /27 (d. h. /28 und höher würde nicht funktionieren).

• Das VNet benötigt zwei Subnetze.
  • Für die verwaltete SCOM-Instanz
  • Für die verwaltete SQL-Instanz
• Das Subnetz für SQL Managed Instance ist ein delegiertes (dediziertes) Subnetz und wird nicht von der verwalteten SCOM-Instanz verwendet. Benennen Sie die Subnetze entsprechend, um spätere Verwechslungen zu vermeiden, wenn Sie die verwaltete SQL-Instanz/SCOM-Instanz erstellen.

Der Adressraum muss mindestens /27 für das SQL MI-Subnetz und /28 für das Subnetz der verwalteten SCOM-Instanz sein.

Nein, beide Optionen können leer gelassen werden.

Nein, Sie können alle deaktivieren oder sie basierend auf den Einstellungen Ihrer Organisation aktivieren.

Wenn Sie mehrere VNets erstellt haben, müssen Sie Ihre VNets peeren. Wenn Sie zwei Netzwerke peeren, stellen Sie sicher, dass sie von beiden Netzwerken miteinander peeren. Wenn Sie also drei Netzwerke peeren, benötigen Sie sechs Peerknoten. Weitere Informationen zum Peering finden Sie unter Peering virtueller Azure-Netzwerke.

• Sie müssen einen Peeringnamen (im Feld Name des Peeringlinks) angeben.
• Der erste Name wird verwendet, um das Peernetzwerk vom aktuellen Netzwerk in das andere Netzwerk zu benennen. Der zweite Name wird verwendet, um das Peernetzwerk aus dem anderen Netzwerk in dieses Netzwerk zu benennen.
• Geben Sie im Abschnitt Virtuelles Netzwerk den Namen des VNet an, das Sie peeren. Wenn Sie das VNet nicht finden können, können Sie mithilfe der Ressourcen-ID danach suchen. Behalten Sie die restlichen Optionen als Standard bei.

1. Wenn die Region, die Sie auswählen möchten (USA, Westen oder Europa, Westen), in der Liste der Regionen nicht angezeigt wird, wählen Sie Region nicht vorhanden und dann Kontingenterhöhung für Ihr Abonnement anfordern aus.
2. Geben Sie die erforderlichen Felder in Allgemeine Informationen ein, und wechseln Sie zu Details, um die Problemdetails einzugeben.
3. Wählen Sie Details eingeben aus. Die Seite Kontingentdetails wird im rechten Bereich geöffnet. Wählen Sie unter Region die gewünschte Region aus, und ändern Sie die Grenzwerte nach Bedarf (10 Subnetze und 500 vCores sollten ausreichen). Wählen Sie Speichern und Fortfahren aus, und wählen Sie dann Weiter: Überprüfen + >> erstellen aus, um das Ticket zu erstellen. Es kann 24 Stunden dauern, bis das Ticket gelöst wird. Warten Sie, bis sie gelöst ist, bevor Sie mit dem Erstellen der SQL MI-Instanz fortfahren.
   Weitere Informationen finden Sie unter Welche Azure-Regionen werden unterstützt?

Azure RBAC ist das rollenbasierte Zugriffskontrollsystem, dem Azure bei der Vergabe von Berechtigungen folgt. Weitere Informationen finden Sie unter Rollenbasierte Zugriffssteuerung (RBAC).
Azure RBAC ist in Azure-Rollen und Microsoft Entra-ID-Rollen unterteilt. Grob gesehen werden mit Azure-Rollen Berechtigungen zum Verwalten von Azure-Ressourcen gesteuert, während mit Microsoft Entra ID-Rollen Berechtigungen zum Verwalten von Microsoft Entra-ID Verzeichnisressourcen gesteuert werden. Die folgende Tabelle enthält einen Vergleich einiger Unterschiede. |Azure Rollen| Microsoft Entra-ID-Rollen| |---|---| |Verwalten des Zugriffs auf Azure-Ressourcen|Verwalten des Zugriffs auf Microsoft Entra-ID-Ressourcen| |Unterstützt benutzerdefinierte Rollen|Unterstützt benutzerdefinierte Rollen| |Bereich kann auf mehreren Ebenen angegeben werden (Verwaltungsgruppe, Abonnement, Ressourcengruppe, Ressource)|Der Bereich kann auf Mandantenebene (organisationsweit), administrative Einheit oder für ein einzelnes Objekt (z. B. eine bestimmte Anwendung)| |Auf Rolleninformationen kann im Azure-Portal, azure CLI, Azure PowerShell, Azure Resource Manager-Vorlagen, REST-API|Auf Rolleninformationen kann im Azure-Verwaltungsportal, Microsoft 365, Admin Center, Microsoft Graph, Microsoft Entra ID PowerShell zugegriffen werden|
Unten finden Sie eine allgemeine Darstellung zur Beziehung der Rollen „Admin für klassisches Abonnement“, „Azure“ und „Azure AD“.

Bei der Bereitstellung einer verwalteten SCOM-Instanz kann aus mehreren Gründen ein Fehler auftreten. Es kann auf falsche Eingaben beim Erstellen oder einem Back-End-Fehler zurückzuführen sein. Erstellen Sie ein Supportticket, falls Sie weitere Unterstützung benötigen. Im Falle eines Fehlers bei der Bereitstellung ist es am besten, die Instanz zu löschen und eine neue zu erstellen. Weitere Informationen finden Sie unter Beheben von Problemen mit verwalteten Azure Monitor SCOM-Instanzen.

Sie können die Instanz entweder aus der Instanzansicht selbst oder aus der Ressourcengruppenansicht löschen.
Wählen Sie in der Instanzansicht im oberen Menü Löschen aus, und warten Sie auf die Bestätigung, dass die Instanz gelöscht wurde. Alternativ können Sie auch die Ansicht Ihrer Ressourcengruppe aufrufen (suchen Sie in der Azure-Suchleiste nach „Ressourcengruppe“, und öffnen Sie in der Ergebnisliste Ihre Ressourcengruppe). Wechseln Sie zu der Ressourcengruppe, in der sich die verwaltete SCOM-Instanz befindet, und löschen Sie die Instanz.
Nachdem die Instanz gelöscht wurde, müssen Sie auch die beiden Datenbanken löschen, die in SQL MI erstellt wurden. Wählen Sie in der Ressourcenansicht die beiden Datenbanken aus (je nachdem, welchen Namen Sie ihrer SCOM verwalteten Instanz gegeben haben), und wählen Sie Löschen aus.

Wird derzeit nicht unterstützt. Heute können Kundinnen und Kunden unabhängig von System Center Operations Manager einen Arc-Agenten auf einer lokal laufenden VM installieren und die Ressource im Azure-Portal anzeigen lassen. Sobald sie die Ressource im Azure-Portal sehen, können sie die Azure-Dienste für diese Ressource nutzen (dabei fallen die entsprechenden Kosten an).

Die verwaltete SCOM-Instanz und System Center Operations Manager haben den gleichen Funktionsumfang. Sie können dieselben Verwaltungspakete verwenden, die Sie lokal einsetzen, um die Netzwerküberwachung über die verwaltete SCOM-Instanz durchzuführen.

• Die verwaltete SCOM-Instanz ist nativ für Azure, während die Ausführung von System Center Operations Manager in Azure-VMs keine native Lösung ist. Das bedeutet, dass die verwaltete SCOM-Instanz nahtlos in Azure integriert ist und alle Azure-Updates für die verwaltete SCOM-Instanz verfügbar sind.
• Die SCOM verwaltete Instanz bereitet die gesamte Infrastruktur für hohe Verfügbarkeit durch Bereitstellen von VMSS, Load Balancer, MSI usw. vor. Um diese Einrichtung manuell vorzubereiten, dauert es monatelang (und erfordert fundiertes technisches Wissen).
• Die verwaltete SCOM-Instanz verwendet standardmäßig SQL MI als Back-End für die Datenbankverwaltung.
• Die verwaltete SCOM-Instanz verfügt über integrierte Skalierungs- und Patching-Funktionen sowie integrierte Berichte.

Sie befinden sich im selben privaten Netzwerk, so dass die jeder Komponente im Netzwerk zugewiesenen IPs eine private IP sein können.

Da diese Instanz erfordert, dass Sie die SCOM-Instanz in Ihrem Abonnement erstellen, sind alle Ressourcen der verwalteten SCOM-Instanz (einschließlich der VMs) für Sie sichtbar. Sie sollten jedoch während des Betriebs der verwalteten SCOM-Instanz keine Aktionen an den VMs und anderen Ressourcen vornehmen, um unvorhergesehene Komplexitäten zu vermeiden.

Nein
SCOM Managed Instance Managed Gateways können auf jedem Azure- und Arc-fähigen Server konfiguriert werden, auf dem keine Operations Manager Gateway Software installiert ist. Wenn Sie Operations Manager Gateway-Server vor Ort mit verwalteter SCOM-Instanz wiederverwenden möchten, deinstallieren Sie die Operations Manager Gateway-Software darauf. Informationen zum Konfigurieren des verwalteten SCOM-Instanzgateways finden Sie unter Konfigurieren der Überwachung von Servern über verwaltete SCOM-Instanzgateways.

Nein Multi-Homing auf verwalteten SCOM-Instanzgateways ist nicht möglich.

Die Zertifikate werden von Microsoft zugewiesen und von der Zertifizierungsstelle signiert. Die manuelle Verwaltung von Zertifikaten auf verwalteten Gateways ist nicht erforderlich. 

Ja, wenn eine direkte Verbindung (Sichtverbindung) zwischen der verwalteten SCOM-Instanz und dem lokalen Rechner über VPN/ER besteht, können Sie diese Rechner überwachen. Weitere Informationen finden Sie unter Konfigurieren der Überwachung lokaler Server.

Sie können keine Aktionen mit den lokal überwachten Ressourcen durchführen, sie aber anzeigen. Wenn die überwachten Objekte gelöscht werden, entfernt das Portal diese lokalen Objekte automatisch nach fünf Minuten.

Die überwachten Ressourcen und der Konnektivitätsstatus der verwalteten Gateways werden minütlich aktualisiert und können im Kontextmenü „Eigenschaften“ eingesehen werden.

Der Agent wird vor Ort (falls erforderlich) aktualisiert und auf die SCOM Managed Instance verwaltet.

Die Fähigkeit wird mit der verwalteten SCOM-Instanz-Erweiterung > = 91 aktiviert.

Sie können die Liste der Eigenschaften einer überwachten Ressource oder eines verwalteten Gateways über das Kontextmenü Eigenschaften einsehen.

Die verwaltete SCOM-Instanz ermöglicht die Überwachung von Azure- und Arc-fähigen Computern. Außerdem werden Informationen über lokale Computer angezeigt, die direkt mit der verwalteten SCOM-Instanz verbunden sind.

Der erste Abruf von Integritäts- und Verbindungsstatus auf dem Portal dauert etwa fünf bis sieben Minuten. Danach erfolgen die Takte jede Minute.

Die erforderliche Mindestversion von .NET Framework ist 4.7.2.

Auf dem Agent/Gatewayserver, der eingebunden werden soll,

• Überprüfen Sie, ob die ausgehende Konnektivität zu *.workloadnexus.azure.com besteht.
• Überprüfen Sie, ob die Firewall für diese URL geöffnet wurde.
  Beispiel: Test-NetConnection westus.workloadnexus.azure.com -Port 443 (Region muss die Region der SCOM verwalteten Instanz sein)

Überprüfen Sie auf dem Agent/Gatewayserver, der eingebunden werden soll, ob er über eine ausgehende Verbindung zum Endpunkt des Load Balancers des Verwaltungsservers verfügt.
Beispiel: Test-NetConnection wlnxMWH160LB.scommi.com -Port 5723

Auf den Agent- und Gatewayserver-Computern muss TLS 1.2 oder höher aktiviert und TLS 1.1 deaktiviert sein, damit das Onboarding und die Überwachung erfolgreich durchgeführt werden können.
Weitere Informationen finden Sie unter Prozess zum Aktivieren von TLS 1.2.

Derzeit unterstützen wir die Überwachung von Azure- und Arc-fähigen Linux-Computern nicht. Sie können jedoch über die Arc-fähigen Gatewayserver verwaltet werden.

Nein Sie können einen Agent nicht so konfigurieren, dass er mit mehreren verwalteten SCOM-Instanzen kommuniziert, aber er kann eine Multi-Home-Konfiguration für den lokalen System Center Operations Manager und eine verwaltete SCOM-Instanz haben.

Derzeit sind nur Arc-fähige Computer als Gatewayserver zulässig.

Derzeit wird Multi-Homing für Gatewayserver nicht unterstützt.

Nächste Schritte

Lesen Sie die anderen häufig gestellten Fragen:

Übersicht über verwaltete SCOM-Instanzen