Beim Versuch die Mailbox-Datenbank(en) eines Exchange 2013 Server zu sichern, kann es vorkommen, dass der System Center Data Protection Manager 2012 R2 meldet: “Replikat inkonsistent” bzw. “Replica is inconsistent” Das schaut dann in etwa so aus: Was kann man nun also dagegen tun? Zunächst einmal muss sichergestellt sein, dass die Dateien “ese.dll” und “eseutil.exe” vom Exchange Server auf den DPM Server kopiert wurden – und zwar immer in der auf dem Exchange aktuell verwendeten Version – also nach größeren Updates neu kopieren! Die Dateien befinden sich im Exchange-Verzeichnis unter “Bin”, also z.B. unter “D:\Program files\Microsoft\Exchange Server\V15\Bin” und müssen in den Bin-Pfad vom DPM, also z.B. nach “D:\Program files\Microsoft System Center 2012 R2\DPM\DPM\bin” kopiert werden. Nach Updates sollte unbedingt die Version bzw. das Dateidatum kontrolliert werden! Weiterhin muss eine aktuelle Version des “Visual C++ Redistributable for 2012” auf dem Exchange Server installiert sein! Dieses lässt sich z.B. hier herunterladen: https://www.microsoft.com/de-de/download/details.aspx?id=30679 Zur Sicherheit lässt sich auch eine Reparatur-Installation ausführen. Anschließend ist ein Reboot nötig. Wenn diese Voraussetzungen geschaffen worden, dann kann entweder nur eine Konsistenzprüfung durchgeführt oder direkt die Sicherung fortgesetzt werden (was dann auch zunächst zu einer Konsistenzprüfung führt). Wenn diese Abgeschlossen ist (was eine Weile dauern kann), sollte die Schutzgruppe wieder den Zustand “OK” (grün) annehmen.
Bei der Version 2012 R2 des System Center Data Protection Managers gibt es ein Problem mit der Sicherung von SQL Servern der Version 2012. Es wird nach Erstellen der Schutzgruppe bzw. beim Versuch der Erstellung eines Replikates die Meldung “Der Schutz kann nicht konfiguriert werden” ausgegeben (Im Englischen: “Unable to configure protection”). (Leider hab ich vom Fehler selbst in der Produktiv-Umgebung keinen Screenshot gemacht und ich wollte ihn nicht nochmal nachträglich provozieren – daher ein Shot aus einer englischen Umgebung) Dieses Problem ist scheinbar bei Microsoft bekannt und auch im TechNet dokumentiert: https://technet.microsoft.com/de-de/library/dn281948.aspx Die Lösung ist auch recht einfach, da der Grund ebenso einfach ist: Der Schutz-Agent hat keine SA-Rechte auf der Datenbank, also müssen diese noch vergeben werden! Dazu startet man auf dem zu sichernden Zielserver einfach das “SQL Server Management Studio”: Dort kann man dann in dem Bereich “Sicherheit”, unter “Anmeldungen” das Konto von “NT-AUTORITÄT\SYSTEM” mit einem Rechtklick und der Auswahl von “Eigenschaften” öffnen. Hier muss dann die Rolle “sysadmin” zusätzlich mit ausgewählt werden. Danach sollte sich die Sicherung via DPM auch problemlos einrichten und durchführen lassen:
Mit Hilfe des System Center Configuration Manager 2012 / 2012 R2 ist es sehr einfach möglich, Windows- und Microsoft-Updates an die Clients und Server des eigenen Netzwerkes zu verteilen. Im Hintergrund arbeitet hierzu der bekannte WSUS-Dienst, welcher wiederum mit Microsoft kommuniziert, um die Updates von dort zu beziehen.
Wäre es nicht auch gut, wenn man auf ähnliche Weise auch Anwendungen von anderen Herstellern patchen könnte? JA! Und man kann!
Das einzige was man neben WSUS und dem SCCM braucht, ist der System Center Update Publisher, kurz SCUP. Mit diesem kann man Updates anderer Hersteller aus “externen Katalogen” beziehen. Und das beste: SCUP ist kostenlos!
Im Folgenden möchte ich die Installation und Einrichtung von SCUP zeigen. Ausgangslage ist ein installierter SCCM mit einer einzigen Primary Site (stand-alone), einem installierten WSUS und einem darauf laufenden Software Update Point (SUP).
Installation SCUP
Als erstes muss SCUP heruntergeladen werden. Dies geht über diese Quellen:
https://technet.microsoft.com/de-de/systemcenter/bb741049.aspx
bzw.
https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11940
Nach dem Download kann die Installation durchgeführt werden, welche jedoch Admin-Rechte benötigt:
Wenn es sich bei dem WSUS-Server um einen Windows Server 2008 R2 oder älter handelt, dan ist die Installation eines Patches nötig, der während des SCUP-Setup angeboten wird:
Auf einem Windows Server 2012 / 2012 R2 ist dieses Patch nicht nötig – hier läuft WSUS 4.0!
Konfiguration WSUS-Berechtigungen
Um nun überhaupt Updates via SCUP auf dem WSUS veröffentlichen zu können, ist noch etwas Vorarbeit nötig. Diese Vorgänge sind etwas genauer hier dokumentiert (dies betrifft idR nur den Windows Server 2012 / 2012 R2):
https://technet.microsoft.com/en-us/library/hh134747.aspx#PublishToServer2012
Folgende Schritte sind im Wesentlichen nötig:
Regedit.exe, dort bis HKEY_CLASSES_ROOT\AppID\{8F5D3447-9CCE-455C-BAEF-55D42420143B} durchhangeln und dann den Eigentümer von diesem Pfad ändern sowie für “SYSTEM” und die “Administratoren” den Vollzugriff vergeben (Durch einen Klick auf die Bilder werden diese in größerer Auflösung gezeigt):
Einrichtung SCUP
Nun kann der “System Center Update Publisher” über das Startmenü gestartet werden – dies sollte aber “Als Administrator” geschehen, da es sonst später zu einem Fehler kommt / kommen kann.
Dieser Fehler tritt später auf, wenn man die SCUP-Konsole ohne die nötigen Rechte startet:
Als erstes sind die Optionen zu öffnen:
Dort muss nun die Verbindung zum WSUS-Server konfiguriert werden (dabei Port beachten – WSUS 4.0 läuft auf 8530 (non-SSL) bzw. 8531 (SSL)):
Nun fehlt noch ein Zertifikat zum signieren der Updates. Hier kann auch ein selbstsigniertes Zertifikat erzeugt und verwendet werden. Dies geschieht über den “Create”-Button:
Dieses Zertifikat muss später noch weiter “behandelt” werden. Als nächster Step wird im SCUP die Verbindung zum SCCM definiert:
Zertifikat passend einbinden
Das WSUS-/SCUP-Zertifikat muss nun in die “Trusted Publishers” (Vertrauenswürdige Herausgeber) und die “Trusted Root Certificates” (Vertrauenswürdige Stammzertifizierungsstellen) des Computer-Kontos (WSUS/SCUP-Server) importiert werden, vorher muss es natürlich exportiert werden:
Updates über SCUP an den WSUS veröffentlichen
Nun können die ersten Updates über den SCUP veröffentlicht werden. Dazu muss zunächst ein Katalog hinzugefügt werden:
Beispielhaft verwende ich hier den “Adobe Reader X” Katalog:
Danach können die Updates aus diesem Katalog in den SCUP importiert werden:
Nun können die neuen Updates zu einer neuen Veröffentlichung hinzugefügt werden:
Diese neue Veröffentlichung (Bei mir heißt sie “März 2015”) kann nun veröffentlicht werden. Dazu wird sie unter “Publications” ausgewählt, die jeweiligen Updates markiert und dann auf “Publish” geklickt.
Dabei sollten die Updates vom SCUP signiert werden:
Updates über SCCM verteilen
Nun kann im SCCM eine erste Synchronisierung durchgeführt werden. Diese ist nötig, damit der SUP (SCCM) “erfährt”, dass es nun auch Adobe als neuen Hersteller und Adobe Reader als Produkt gibt:
Um den Vorgang zu beobachten bietet der SCCM ein eigenes Werkzeug, alternativ würde auch CMTrace gegen die WSyncMgr.log funktionieren:
Die letzte Meldung zeigt an, dass die Synchronisierung abgeschlossen ist. Nun kann das neue Produkt (in meinem Fall der Adobe Reader) für die Verteilung durch den SUP aktiviert werden:
Dabei ist auch der Reiter “Klassifizierungen” zu beachten – wenn das gewünschte Update ein “Sicherheitsupdate” ist, SUP aber nur “Wichtige Updates” synchronisiert, dann wird man nicht zu einem positiven Ergebnis kommen.
Nun ist noch einmal eine Synchronisierung des SUP nötig, damit dieser die bekannten Updates vom WSUS “kennenlernt”.
Danach stehen die Updates, in meinem Fall für den Adobe Reader, im SCCM wie ein reguläres Windows Update zur Verfügung und können verteilt und bereitgestellt werden:
Viel Spaß damit!
Sie benötigen weitere Informationen zum SCCM und den Möglichkeiten, Updates zu verteilen? Dann schauen Sie sich unseren Kurs zum System Center Configuration Manager 2012 R2 an!
Da ich in der letzten Zeit immer wieder gefragt wurde, wie man einen Linux-Computer zur Verwaltung von SCCM hinzufügen kann, möchte ich dies hier kurz darstellen. Zunächst benötigt man hierzu die Installationsquellen für den Configuration-Manager-Client für Linux bzw. Unix. Diese lassen sich über den Splash-Screen der SCCM-DVD besorgen: Über diesen Link gelangt man (je nach Sprache) auf einer Microsoft-Webseite, z.B. dieser: http://www.microsoft.com/de-de/download/details.aspx?id=39360 Beim Klick auf “Herunterladen” steht noch die Wahl, welche Version benötigt wird: Die heruntergeladene EXE-Datei muss nun noch mittels Doppelklick entpackt werden: Nach dem Entpacken müssen die Dateien auf das gewünschte Linux-/Unix-System kopiert werden. Beispielhaft verwende ich dazu SSH: Nach dem Kopieren der Dateien muss die Datei “install” noch ausführbar gemacht werden. Dies geschieht mittels chmod +x install bzw. sudo chmod +x install
Nach diesem Vorgang kann die Installation gestartet werden. Als Parameter sind der Name eines Management-Point-Servers, der Site-Code sowie die notwendige Linux-Version anzugeben:
In meinem Fall lautet der Aufruf:
./install –mp srv1.kurs.intern –sitecode PS0 ccm-Universalx64.tar
Sobald die Installation komplett ist, muss der Client noch im SCCM genehmigt werden:
Nun ist der Client im SCCM registriert. Das lokale Logfile des Clients befindet sich unter
/var/opt/microsoft/scxcm.log
Dieses kann z.B. mit Hilfe des Aufrufs
tail -F /var/opt/microsoft/scxcm.log
beobachtet werden.
Will man nun z.B. einen Policy-Abruf oder einen Hardware-Inventur-Zyklus erzwingen, ist dies mit den Aufrufen
/opt/microsoft/configmgr/bin/ccmexec -rs policy
bzw.
/opt/microsoft/configmgr/bin/ccmexec -rs hinv
möglich.
Bei Bedarf kann man sich z.B. noch eine Gerätesammlung für alle Linux-/Unix-Systeme anlegen. Als begrenzende Sammlung verwendet man sinnvollerweise “Alle Systeme”. Die Mitgliedschaft lässt sich mit der Abfrageregel auf “Systemressource / Betriebssystem-Name und –Version” realisieren:
Viel Spaß beim Ausprobieren!
Wenn es während einer Tasksequenz im System Center Configuration Manager 2012 R2 zu einem Fehler kommt, so wird die Fehlermeldung standardmäßig für 15 Minuten angezeigt – danach wird der Client neugestartet. Wenn man nun eine längere Tasksequenz laufen lässt, wird man selten die gesamte Zeit vor dem betroffenen Rechner verbringen und so auch die Fehlermeldung verpassen. Noch schlimmer wird es, wenn der Fehler noch vor dem Abschluss der Formatierung des Laufwerkes geschieht – denn bis zu diesem Punkt ist das Logfile lediglich in einer Ram-Disk abgelegt – und die ist beim Neustart natürlich weg!
Diese Fehlermeldungen sehen dann in etwa so aus:
Dieses Verhalten lässt sich glücklicherweise abändern – mit nicht all zu hohem Aufwand! Dazu muss lediglich in der betreffenden Tasksequenz (es geht leider nicht pauschal) eine Tasksequenzvariable gesetzt werden.
Dazu wird die Tasksequenz geöffnet und direkt an erster Stelle ein weiterer Schritt “Tasksequenzvariable festlegen” eingefügt:
Der Name der Variable lautet “SMSTSErrorDialogTimeout” – der Wert ist in Sekunden anzugeben:
Damit ist die gewünschte Änderung auch schon gemacht. Beim nächsten Start der Tasksequenz ist die gemachte Änderung auch schon wirksam… Und dann kann man im Falle eines Fehler mittels F8 die DOS-Box öffnen und beispielsweise mit “cmtrace.exe” die Logfiles analysieren.
Während einer Betriebssysteminstallation (“OSD” – Operating System Deployment) werden alle Schritte protokolliert. Das Problem dabei ist, dass das Logfile dabei maximal 1MB groß werden darf. Alle älteren Einträge werden überschrieben. Und ein Megabyte ist selbst beim Standard-Loglevel nicht sehr viel…
Um die gewünschten Änderungen zu erreichen, müssen die Boot-Images (“boot.wim”) angepasst werden. Dabei muss eine Konfigurationsdatei erzeugt und in den Abbildern hinterlegt werden. Diesen Vorgang möchte ich hier etwas genauer beschreiben:
Als erstes besorgt man sich die aktuell verwendeten Startabbild-Dateien für 32 Bit und 64 Bit. Wo diese zu finden sind, kann man in den Eigenschaften der Abbilder nachsehen.
Der übliche Speicherort lautet
\\[HOSTNAME]\SMS_[SITECODE]\OSD\boot\i386\
für 32 Bit und
\\[HOSTNAME]\SMS_[SITECODE]\OSD\boot\x64\
für 64 Bit.
Als zweites benötigt man das Windows ADK in einer passenden Version. Dieses kann bei Microsoft heruntergeladen werden. (http://www.microsoft.com/de-de/download/details.aspx?id=39982)
Nun kann mit Hilfe von DISM in einer Eingabeaufforderung mit administrativen Rechten die jeweilige WIM-Datei zum Verändern gemountet werden. Dies geschieht mittels des Aufrufes
dism /Mount-Wim /WimFile:C:\boot.wim\boot.CAS00005.wim /index:1 /MountDir:C:\boot.wim\mount_x64
(Die Pfade sind entsprechend anzupassen.)
Nun kann im Windows-Pfad des gemounteten Images eine Datei mit Namen “SMSTS.INI” und folgendem Inhalt abgelegt werden:
[Logging]
LOGLEVEL=0
LOGMAXSIZE=10485760
LOGMAXHISTORY=3
DEBUGLOGGING=1
CCMDEBUGLOGGING=1
Das LogLevel 0 steht für “verbose”, ist also der höchste Detailgrad. Standard wäre 1…
LogMaxSize erklärt sich sicher von selbst – der Wert wird in Bytes angegeben (hier also 10MB).
LogMaxHistory sorgt dafür, dass nicht nur das letzte LogFile gelesen werden kann, sondern auch die vorherigen. Im Normalfall steht der Wert auf 1 und dabei werden ältere Logs immer durch das aktuelle überschrieben.
DebugLogging aktiviert das Protokollieren von Debug-Meldungen (1 ist “true”, 0 ist “false”).
CCMDebugLogging tut im Wesentlichen dasselbe, Microsoft empfiehlt die Verwendung beider Varianten, ich vermute aus Gründen der Abwärtskompatibilität.
Die Namen der Konfigurationsparameter müssen in Großbuchstaben geschrieben werden!
Nun kann die WIM-Datei zurückgeschrieben werden. Dazu dient wieder DISM mit folgendem Kommando:
dism /Unmount-Wim /MountDir:C:\boot.wim\mount_x64 /commit
Danach muss das WIM-File nur noch zurück auf den SCCM-Server kopiert werden und neu auf die Verteilungspunkte (“Distribution Points”) verteilt werden…
Das Problem
Wenn man im SCVMM 2012 R2 (gilt auch für “R1”) eine VM mit Hilfe einer VM-Vorlage (engl. “Template”) erzeugt, dann bekommt diese neue VM (und zwar unabhängig von dem bereits vorhandenen Betriebssystem in der eingesetzten VHD) alle Regionaleinstellungen auf “en-US”, dazu gehören u.a.:
Tastaturlayout
User-Locale
System-Locale
UILanguage
Die einzige Einstellung bezüglich der Region lässt sich für die Zeitzone einrichten:
Selbst wenn man mit Hilfe einer eigenen Antwortdatei andere Werte setzt, werden diese weitgehend ignoriert, da am Ende in der resultierenden Antwortdatei (Eigene Inhalte + im SCVMM gesetzte Einstellungen + SCVMM-Defaults) die SCVMM-Defaults am weitesten oben stehen und daher Vorrang bekommen.
Dieses Verhalten ist bei Microsoft bekannt und in dem folgenden KB-Artikel beschrieben:
http://support.microsoft.com/kb/2709539
Lösung des Problems
Als Workarround ist folgendes Vorgehen möglich:
SCVMM-Konsole starten
In den “Einstellungen”-Bereich wechseln
Dort die PowerShell über den Button in der Ribbon-Leiste öffnen
Ein angepasstes Script nach folgendem Schema ausführen
PowerShell-Script:
$Vorlage = Get-SCVMtemplate | where {$_.Name -eq "Template_Name"}
$Einstellungen = $Vorlage.UnattendSettings;
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/UserLocale","de-DE");
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/SystemLocale","de-DE");
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/UILanguage","de-DE");
$Einstellungen.add("oobeSystem/Microsoft-Windows-International-Core/InputLocale","0407:00000407");
Set-SCVMTemplate -VMTemplate $Vorlage -UnattendSettings $Einstellungen
“Template_Name” muss hier natürlich durch den Namen der eigenen VM-Vorlage ausgetauscht werden. Das ganze sollte dann so aussehen:
Nun ist die VM-Vorlage entsprechend angepasst, was man per PowerShell abfragen kann:
(Get-SCVMtemplate | where {$_.Name -eq "Name_der_Vorlage"}).UnattendSettings
Weitere Informationen zum Thema System Center 2012 R2 und Windows Server 2012 R2 finden Sie auch unter http://www.ppedv.de/R2
Auf einem Test-Server für eine System Center Configuration Manager 2012 Umgebung lief auch der dazu notwendige SQL-Server. Da die Hardware einen Defekt aufwies, musste ich das System auf eine neue Hardware umziehen. Problematisch: Alte und neue Hardware waren derart verschieden, dass hier Probleme zu erwarten gewesen wären, wenn ich die Platten einfach nur umgesteckt hätte. Also habe ich vorher einen Sysprep inkl. /generalize laufen lassen. Nach dem Umbau der Festplatten in den neuen Server startete dieser Anstandslos. Das Problem: Die SQL-Server-Dienste starteten nicht!
Problem:
Durch den SYSPREP sind die privaten Schlüssel für die SSL-Kommunikation verloren gegangen, da der alte User-Account ja danach nicht mehr vorhanden war. Dies war u.a. im Logfile "C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG" nachzulesen:
"The server could not load the certificate it needs to initiate an SSL connection. It returned the following error: 0x8009030d [...]"
Lösung:
Im "SQL Server Configuration Manager" die Zuordnung zum alten Zertifikat löschen:
Nach einem Reboot des Servers generiert dieser ein neues Zertifikat und trägt dieses hier entsprechend ein (Es existieren dann 2 Zertifikate mit gleichem Namen, man kann sie aber u.a. am Ausstellungsdatum unterscheiden).
Dieses neue Zertifikat muss nun noch zu den "Vertrauenswürdigen Stammzertifizierungsstellen" hinzugefügt werden bzw. evtl. den Clients als vertrauenswürdig bekanntgegeben werden. Danach sollte alles wieder funktionieren, im Logfile steht dann:
"A self-generaterd certificate was successfully loaded for encryption. [...]"