Mostly Anything

Bei einem Kunden haben wir einen Windows Server als Time Server für die DMZ im Einsatz. Der war bisher Windows 2003 und wurde nun auf 2008R2 aktualisiert. Der Service wurde entsprechend konfiguriert und auf Automatic Startup gesetzt. Trotzdem wurde der Service immer Sonntags 01.00 wieder gestoppt. Ohne Error aber mit Info Eintrag im Eventlog, dass der Service erfolgreich gestoppt wurde.

Windows 7 und 2008R2 haben sogenannte Service Trigger Events. Die Erklärung bei Microsoft fängt mit folgendem Satz an:

"A service can register to be started or stopped when a trigger event occurs..."

D.h. das ein Service so konfiguriert werden kann, dass z.b. wenn das Netzwerk Interface nicht mehr verbunden ist, ein Service gestoppt wird. Macht im Client sicherlich Sinn, im Serverumfeld .. naja, kann sein.

Anschauen kann man die Triggerevents mit dem SC Tool (sc.exe). Dann schauen wir uns mal die Trigger Events zum Timeservice an:

C:\>sc qtriggerinfo w32time
[SC] QueryServiceConfig2 SUCCESS

SERVICE_NAME: w32time

        START SERVICE
          DOMAIN JOINED STATUS         : 1ce20aba-9851-4421-9430-1ddeb766e809 [DOMAIN JOINED]
        STOP SERVICE
          DOMAIN JOINED STATUS         : ddaf516e-58c2-4866-9574-c3b615d42ea1 [NOT DOMAIN JOINED]

Aha. Der w32time Service (Windows Time Service) hat einen Service Trigger Event auf den “Domain Joined Status”. Wenn der Computer in einer Domain ist ([DOMAIN JOINED]) dann wird der Service gestartet, falls nicht ([NOT DOMAIN JOINED]) wird der Service gestoppt.

Der Server in der DMZ ist natürlich nicht in einer Domain. Das ist also das Problem.

Man könnte nun einen entsprechenden Trigger setzen, der dem gewünschten Verhalten mehr enspricht, z.b. wenn der Computer eine IP bekommt. In userem Falle lösche ich aber einfach die Trigger Events

sc triggerinfo w32time delete

Nun hat der Service keine Events mehr

C:\>sc qtriggerinfo w32time
[SC] QueryServiceConfig2 SUCCESS

The service w32time has not registered for any start or stop triggers.

Von nun an wird der Service nicht mehr gestoppt und läuft wie er eigentlich sollte.

Kurzübersicht der 10 wichtigstens Verbesserungen der Konsole in System Center Configuration Manager 2012 in Englisch. Worauf man sich freuen darf, wenn man ein Upgrade plant.

Survival Guide für SCCM 2012 vom TechNet Wiki. Sehr hilfreich Sammlung von Infos. Von Getting Started über Site Admin, Migration und Step-by-Step Guides.

Das Server Management Pack gibts nun in einer aktuallisierten Version 6.0.6958.0.

Das MP kann hier runtergeladen werden.

Was ist neu?

• BPA (Best Practice Analyzer) Rules sind nun per Default disabled
• Korrekte SQL Server Stored Procedure Berechtigungen für Reporting Services (kein manueller Eingriff mehr nötig)
• Updated Knowledge für Logical Disks
• Updated Overrides für Logical Disks
• % idle Time sorting funktioniert nun

Bei einer SCOM Umgebung eines Kunden setzen wir verschiedene Resolution States für die verschiedenen Gruppen (Operations, Application Support, DBAs etc) ein. Die Alerts, die vom SQL Management Pack generiert werden sollen nun direkt den entsprechenden Resolution State bekommen, damit sie in der View der entsprechenden Gruppe landen.

Das ganze können wir folgendermassen lösen. Wir erstellen einen Notification Command Channel, erstellen einen Subscriber und eine Subscription (nur für neue Alerts) und führen dann ein Powershell Script aus, dass den entsprechenden Resolution Code setzt.

Das Script sieht folgendermassen aus:

Param (
	[string]$RMS = "RootManagementServer"
)
# Start the OpsMgr PSSnapin
Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin ;
Set-Location "OperationsManagerMonitoring::" -ErrorVariable errSnapin ;
New-ManagementGroupConnection -ConnectionString:$RMS -ErrorVariable errSnapin ;
set-location $RMS -ErrorVariable errSnapin ;

# Get all new (0) alerts where the MonitoringObjectFullName starts with Microsoft.SQLServer
$alerts = Get-Alert | ?{$_.ResolutionState -eq "0" -and $_.MonitoringObjectFullName -like "Microsoft.SQLServer*"}

foreach($alert in $alerts) {
	#Set the resolution state to DBA Group (15)
	$alert.ResolutionState = "15"
	$alert.Update("")
}

# Remove the OpsMgr PSSnapin
Remove-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client

Wir verbinden uns zuerst mit dem RMS und holen alle Alerts mit Resolutio State von 0 (NEW). Wir können hier auch noch dem MonitoringObjectFullName filtern, der mit Microsoft.SQLServer beginnt (alle Alerts vom SQL Server MP).
Bei diesen Alerts setzen wir den Resolution State dann auf die gewüschte Zahl.

Jetzt müssen wir SCOM noch so konfigurieren, dass dieses Script bei den neuen Alerts ausgeführt wird:

Neuen Notification Channel erstellen: Administration – Notifications – Channels – New Channel Namen und Beschreibung ausfüllen. Unter Settings bei Full Path den Pfad zur Powershell angeben. Bei Command Line Parameters das eigentliche Script aufführen
Dann einen Subscriber erstellen mit dem Channel Type “Command” und useren Channel, den wir vorher erstellt haben.
Nun mit einer Subscription das ganze zusammenfügen. Wir wählen unter Criteria nur die Alerts mit Resolution State 0 aus. Wir wollen ja, dass nur neue Alerts bearbeitet werden.
Als Subscriber und Channel die vorher erstellten auswählen und ohne Alert Aging erstellen

Nun wird bei jedem neuen Alert das Script ausgeführt und falls es ein Alert vom SQL MP ist der entsprechende Resolution State gesetzt. Natürlich können wir im Script auch noch weitere States für andere MPs setzen.

Die DBAs bekommen dann noch eine neue Alert View, bei der nur die Alerts mit dem State 15 angezeigt werden und sind happy, da sie die restlichen Alerts, die sie nicht interessieren nicht sehen.