Nach einem Absturz der SCCM Konsole ist ein Objekt für die Bearbeitung durch den sogenannten SEDO-Lock gesperrt. In meinem Fall war dies heute eine Application (Anwendung):
Neben der früher angesprochenen (und bis heute nicht supporteten) Variante, den Lock direkt auf der Datenbank zu löschen, gibt es zwei Varianten die unterstützt werden (eigentlich drei – die dritte wäre, 30 Minuten zu warten):
PowerShell:
Die erste Alternative (und auch die erste Wahl ) ist die Verwendung der PowerShell:
Alternativ kann einfach der SMS Executive Dienst neugestartet werden, was die Wartezeit von 30 Minuten abkürzt, aber natürlich auch weitere Folgen für den Betrieb des SCCM hat.
Da ich die letzten Tage im Ausland unterwegs war diese Meldung etwas verzögert:
Sowohl Windows Server 2016 als auch System Center 2016 sind seit gestern “General Available” also für die Allgemeinheit verfügbar. Dadurch sind die Produkte nun also auch in der MSDN…
… als auch im VLSC verfügbar:
Natürlich könnt ihr die Produkte auch weiterhin über das Evaluation Center herunterladen. Viel Spaß damit!
Nur als kurze “Randnotiz”: Microsoft hat den Windows Server 2016 auf der Ignite in Atlanta vor nicht ganz 2 Tagen gelauncht. Den Blog-Artikel des Windows Server Teams findet ihr hier:
Leider stehen die Bits noch nicht zum Download zur Verfügung, auch nicht in der MSDN. Allerdings kann man die Evaluation-Version als ISO oder VHD herunterladen, siehe hier:
Das Update wird automatisch, aber erst nach und nach verteilt. Wer zu den Ersten gehören möchte, die es bekommen, kann dieses PowerShell-Skript nutzen:
Seit etwa einer Stunde sind die Technical Preview (TP5) vom Windows Server 2016 sowie von System Center in der MSDN und im Evaluation Center verfügbar:
Was neu ist im System Center TP5 lässt sich in diesem Blog-Artikel vom Engineering-Team nachlesen. Zum Server 2016 gibt es eine solche Übersicht scheinbar noch nicht… Viel Spaß beim Ausprobieren!
Um den Site Code (Standortcode) eines SCCM Clients auszulesen, kann man WMI verwenden. Ich habe dafür ein kleines PowerShell Script geschrieben:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<# .Synopsis Returns the Site Code of a SCCM Client as a String .DESCRIPTION Queries a given computer using WMI and returns its site code for System Center Configuration Manager (Tested on 2012 R2 and 1511) .EXAMPLE Get-SMSSiteCode -MachineName PC1 Get's the site code of the Computer named PC1 #>Function Get-SMSSiteCode
{Param(# The Computername of the machine that you want to query for it's SCCM Site Code[Parameter(Mandatory=$true)][string]$MachineName)Return(Get-WmiObject-ComputerName$MachineName `
-Namespace"root\CCM" `
-Class sms_authority `
).Name.TrimStart("SMS:")}
<# .Synopsis Returns the Site Code of a SCCM Client as a String .DESCRIPTION Queries a given computer using WMI and returns its site code for System Center Configuration Manager (Tested on 2012 R2 and 1511) .EXAMPLE Get-SMSSiteCode -MachineName PC1 Get's the site code of the Computer named PC1 #>
Function Get-SMSSiteCode
{
Param(
# The Computername of the machine that you want to query for it's SCCM Site Code
[Parameter(Mandatory=$true)]
[string]$MachineName
)
Return (Get-WmiObject -ComputerName $MachineName `
-Namespace "root\CCM" `
-Class sms_authority `
).Name.TrimStart("SMS:")
}
Ich habe in den letzten Wochen einige neue Videos zum System Center Configuration Manager 2012 R2 bzw. 2016 (1511) gemacht. Diese könnt ihr hier ansehen:
Nur ein kurzer Hinweis: Seit einigen Tagen gibt es ein kostenloses eBook zum Verteilen von Windows 10 mit Hilfe des System Center Configuration Manager (SCCM). Das fast 100 Seiten umfassende Werk enthält viel Wissenswertes vor allem für SCCM-Einsteiger, die Windows 10 in Ihren Umgebungen ausrollen wollen.
Bei der Prüfung von SCOM-Warnungen fiel mir diese hier besonders ins Auge:
Die Meldung “The Time Skew latency is above the configured threshold” besagt im Wesentlichen, dass die Zeitdifferenz zwischen einem “normalen” DC und dem PDC-Emulator zu hoch ist, in diesem Fall bei 267 Sekunden liegt und damit über der Warnungs-Schwelle von 5 Sekunden. Und tatsächlich, die Server haben eine sichtbare Zeitdifferenz:
Nun ist es ja so, dass alle Server einer Domäne die Uhrzeit beim PDC-Emulator abholen – oder es zumindest sollten. Dieser wiederum sollte so konfiguriert sein, dass er die Zeit von einer gültigen externen Zeitquelle empfängt. Das erreicht man recht einfach mit folgenden Aufrufen:
Im festen Glauben, dass dies auch in meiner Umgebung so ist, habe ich dies dennoch gegengeprüft:
Der Aufruf
netdom query fsmo
liefert die Verteilung der FSMO-Rollen, u.a. erfährt man eben auch, welcher DC aktuell der PDC-Emulator ist.
Nun kann man mit
w32tm /monitor
auf einem der DCs prüfen, welcher DC woher seine Zeit bekommt:
Und siehe da – die beiden DCs, die nicht PDC-Emulator sind bekommen ihre Zeit von irgend einem Server “frei im Internet”. Dies kann z.B. daran liegen, dass diese DCs früher mal PDC-Emulator waren und daher noch auf die Synchronisierung mit einer externen Quelle eingestellt sind. Dies lässt sich sehr leicht auf den betreffenden DCs (also denjenigen, die kein PDC-Emulator mehr sind) beheben. Dazu ist lediglich der Aufruf
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time
notwendig:
Nach kurzer Zeit sollte die Uhrzeit dann wieder passen. Zur Sicherheit kann man dies nun noch einmal mit
w32tm /monitor
überprüfen:
Jetzt sieht man, dass die beiden ersten DCs (beide kein PDC-Emulator) von HVSRV10 (dem PDC-Emulator) synchronisieren und dieser wiederum von einer externen Zeitquelle (stammt aus dem NTP-Pool).
Nun stimmen auch die Zeiten aller DCs wieder überein:
