Drücke "Enter", um den Text zu überspringen.

Kategorie: System Center Configuration Manager

SCCM2012: Fehler beim Installieren einer neuen Primary Site in bestehender Hierarchie

Folgender Fehler ist mir heute begegnet, als ich einen weiteren Server als Primary Site zu einer bestehenden SCCM-Hierarchie hinzufügen wollte:

SCCM_Add_to_CAS_Error

 

Der Fehlertext lautet: „Der Benutzer, der Setup ausführt, muss am zentralen Zielverwaltungsstandort über die RBA-Sicherheitsrolle „Infrastrukturadministrator“ oder „Hauptadministrator“ verfügen. Überprüfen Sie, ob der Benutzer über die richtige Rolle verfügt.“

Die englische Fehlermeldung hierzu lautet: „The setup login user does not have sufficient permission to configure replication with specified central administration site“

Da der User bereits vorher an einem anderen Standort zu Installation problemlos genutzt wurde und auch über die Hauptadministrator-Rolle („Full Administrator“) verfügte, musste es ein anderes Problem sein.

Nach einigen Tests und Recherchen konnte ich den Fehler finden und beseitigen. Die beiden Standorte (Standort der CAS und Standort der neu zu installierenden Primary Site) sind über Site-to-Site-VPNs mit Hilfe vom ISA-Server bzw. Forefront TMG verbunden. Hier gibt es eine Filter-Regelung namens „Strikte RPC-Einhaltung erzwingen“ („Enforce strict RPC compliance“):

SCCM_Add_to_CAS_Solution

 

(Zu finden unter „Webzugriffsrichtlinie“ / „RICHTLINIE“ / „Protokolle“ / „Filterung“ / „RPC-Protokoll konfigurieren“)

Nach dem ich diese Option auf beiden Seiten deaktiviert und die VPN-Verbindungen neu aufgebaut hatte, ließ sich die neue Primary Site problemlos installieren, da nun DCOM-Traffic zulässig war.

Schreibe einen Kommentar...

SCCM2012: Fehler beim Setup – SQL-Server Name muss mit dem Namen in „sys.servers“ übereinstimmen

Wenn man auf einem Server bereits den SQL-Server installiert hat und nun vor der Installation des System Center 2012 Configuration Manager den Hostnamen dieses Servers ändert, kommt es am Ende des Setup-Assistenten zu einem Fehler. Der deutsche Fehlertext lautet:

Der beim Setup angegebene SQL Server-Name muss mit dem Namen in „sys.servers“ des SQL Server-Computers übereinstimmen.

SCCM SQL-Error sys.servers

Dieses Fehler lässt sich recht leicht beheben. Dazu muss zuerst die SCCM-Instanz deinstalliert werden.

Danach muss folgende Query im SQL Server-Manager ausgeführt werden:

1
2
3
4
EXEC sp_dropserver "ALTER_HOSTNAME"
GO
EXEC sp_addserver "AKTUELLER_HOSTNAME", "local"
GO

 

Den „alten“  Hostnamen kann man auch dem Setup-Log unter c:\ConfigMgrSetup.log entnehmen. Dort findet sich eine Meldung in etwa wie folgt:

ERROR: SQL server’s Name ‚[ALTER_HOSTNAME]‘ in sys.servers does not match with the SQL server name ‚[NEUER_HOSTNAME]‘ specified during setup. Please rename the SQL server name using sp_dropserver and sp_addserver and rerun setup.  $$<Configuration Manager Setup><03-07-2013 22:07:09.409-60><thread=364 (0x16C)>

Nach dem Ausführen der Query im SQL Server-Manager muss der Server neugestartet werden. Danach kann das SCCM-Setup erneut durchgeführt werden.

Schreibe einen Kommentar...

SCCM2012: Probleme mit Software Update Point unter SP1

Kürzlich hatte ich Probleme, einen SUP auf einem standalone Primary Site System zu installieren. Der WSUS Server mit SP2 war bereits korrekt installiert und konnte von den Clients auch genutzt werden. Die Installation des SUP schlug jedoch fehl. Die Lösung des Problems:

Seit dem Service Pack 1 für System Center Configuration Manager 2012 ist neben dem Patch KB2720211 auch noch folgendes Patch nötig (insbesondere, wenn WSUS unter Server 2012 läuft):

http://support.microsoft.com/kb/2734608/de

Mit diesem Patch sollte es dann funktionieren (den Server, auf dem WSUS läuft nach dem Setup des Patches neustarten!)

Schreibe einen Kommentar...

SCCM2012: SQL-Fehler bei der Installation / Dynamische Ports

Bei der Installation eines Site-Servers ist auch die Verbindung zur Datenbank-Instanz anzugeben. Hierbei kann es zu folgendem Fehler kommen:

Die Fehlermeldung liefert bereits mögliche Ursachen:

  • SQL-Hostname oder Instanzname falsch angegeben
  • Firewall auf SQL-Server blockiert Zugriff
  • Rechte-Problem
  • SQL-Server verwendet dynamische Ports

 

Insbesondere der letzte Punkt tritt recht häufig auf. Das liegt daran, dass sich im Setup-Assistenten des SQL-Server (2008 R2 und 2012) nicht angeben lässt, dass statische Ports verwendet werden sollen. Dies führt dazu, dass der SQL-Server mit dynamischen Ports arbeitet.

Zum Beheben des Problemes verbindet man sich einfach mittels SQL Server Configuration Manager mit dem SQL-Server und aktiviert dort „Named Pipes“ und „TCP/IP“ unter „SQL Server Network Configuration“ / „Protocols for INSTANZNAME„:

 

Abschließend muss die SQL-Instanz neugestartet werden:

Nun sollte das Problem behoben sein. Falls nicht, sollte folgendes geprüft werden:

Schreibe einen Kommentar...

SCCM2012: 0x800705AA bei OSD Installation

In einer Testumgebung bin ich heute auf folgenden Fehler gestoßen:

 

Der Fehler 0x800705AA steht für „Insufficient system resources“. Dies lag in meinem Fall daran, dass die VM, mit der ich das OSD ausgeführt habe, nur über 512MB Arbeitsspeicher verfügt. Davon werden dann nochmal 32MB vom Bootimage für die RAM-Disk abgezogen. Dadurch hat die Maschine weniger RAM. als von Windows gefordert.

Ein Heraufsetzen des minimalen Arbeitsspeichers der VM bringt hier Abhilfe…


				
	
	Schreibe einen Kommentar...			

SCCM2012: Kein Programm wählbar beim Erstellen einer Tasksequenz

Kürzlich bin ich auf das Problem gestoßen, dass ich beim Installieren eines Paketes innerhalb einer Tasksequenz zwar das Paket auswählen konnte, aber das zum Paket gehörende Programm nicht zur Auswahl stand.

Die Lösung des Problems war, dass beim Programm angegeben war, dass dieses nur ausgeführt wird, wenn ein Benutzer angemeldet ist. Das funktioniert aber bei Tasksequenzen nicht. Eine weitere Fehlerquelle wäre, wenn angegeben wird, dass der Benutzer mit der Programm interagieren kann/darf.

Weitere Infos finden sich hier: http://sccm.haas.se/?p=247

Schreibe einen Kommentar...

Den System Center Configuration Manager 2012 kurz vorgestellt

Wenn man sich mit Administratoren über deren Arbeit und die alltäglichen Aufgaben unterhält, wird einem immer wieder bewusst, welch hoher Anteil hiervon selbst heute noch und auch in großen Unternehmen nach dem Prinzip der „Turnschuh-Administration“ erfolgt. Dabei muss das gar nicht sein, vieles lässt sich problemlos vom eigenen Arbeitsplatz bzw. zentral erledigen. Der System Center 2012 Configuration Manager ist dabei ein sehr hilfreiches und mächtiges Werkzeug, welches im folgenden Artikel näher vorgestellt werden soll.

Der System Center Configuration Manager hat bereits eine etwas längere Vorgeschichte, die allerdings oft unbekannt ist. So erschien bereits 1994 der erste „Microsoft Systems Management Server“, welcher damit quasi der Urvater des Configuration Manager ist. Von diesem gab es mehrere Versionen, bevor er 2007 in „System Center Configuration Manager“ umbenannt wurde. Der ursprüngliche Name bzw. dessen Abkürzung „SMS“ findet sich auch heute noch an vielen Stellen im aktuellen Produkt.

Als Mitglied der System-Center-2012-Familie muss der auch als „SCCM“ bezeichnete Configuration Manager in seiner neuesten Version nicht mehr separat erworben werden sondern ist ohnehin Bestandteil der Standard- oder Datacenter-Edition der System-Center-2012-Lizenz. Neben einem Microsoft SQL Server ab Version 2008 SP2 sind neben den Rollen und Features eines Windows Server 2008 bzw. Server 2008 R2 keine weiteren Produkte nötig.

Installation & Standorte

Die Installation des SCCM erfolgt in sogenannten „Sites“. Hiervon gibt es 3 Typen: Die CAS (Central Administration Site), die PS (Primary Site) und die SS (Secondary Site). Dabei hat man die Wahl, ob man entweder eine einzelne Primary-Site (stand-alone) installiert, oder eine größere Hierarchie bestehend aus allen 3 Site-Typen verwendet. Mit dem SP1 für den Configuration Manager wird es auch die Möglichkeit geben, diese Entscheidung nachträglich zu verändern. Die Verwendung mehrerer Sites bedingt zwingend den Aufbau einer Hierarchie (mindestens bestehend aus einer CAS und einer oder mehreren PS – wie bspw. in Abb. 1) und bietet sich vor allem dann an, wenn Clients und Server an mehreren Standorten verteilt sind und zwischen diesen Standorten nicht immer eine optimale Daten-Anbindung vorhanden ist, um die Anzahl der verwaltbaren Clients über 100.000 zu steigern oder Lastverteilung und Redundanz zu ermöglichen. Eine Hierarchie besteht an oberster Stelle immer genau aus einer CAS, der eine oder mehrere Primary Sites untergeordnet sind, denen wiederum Secondary Sites untergeordnet werden können. Diese Hierarchie lässt sich auch nachträglich um weitere Primary und Secondary Sites erweitern.


Abbildung 1: Eine einfach Hierarchie mit CAS und einer PS

Jede Site benötigt hierbei immer eine eigene SQL-Instanz, für die Secondary Sites ist auch eine Express-Version zulässig. Unterhalb der Primary Sites und Secondary Sites lassen sich auch unabhängig von der Installation einer kompletten Site sogenannte „Distribution Points“ (Verteilungspunkte) installieren. Diese fungieren dann sozusagen als „Datenhalde“ für den vom SCCM zu verteilenden Content wie z.B. Applikationen oder Betriebssystemabbilder. Dadurch kann sichergestellt werden, dass diese Daten bereits vor der eigentlichen Installation in den entsprechenden Niederlassungen vorhanden sind, ohne dass hierfür ein kompletter Server nebst SQL-Datenbank nötig ist. Bei Bedarf kann hierfür auch ein einfacher Windows-7-PC verwendet werden, solange dieser dauerhaft online ist. Dies bietet sich vor allem für kleine Niederlassungen an.

Erste Einrichtung

Vor der eigentlichen Installation ist eine Schema-Erweiterung im Active Directory nötig, außerdem müssen ein Container erstellt und für diesen Rechte delegiert werden. Nach der Installation beginnt die Einrichtung des Systems. Dabei sind anfangs insbesondere die als „Discoveries“ bezeichneten Erkennungsmethoden für die zu verwaltenden Server und Clients sowie die als „Boundaries“ bezeichneten Begrenzungen von Interesse. Es existieren sechs verschiedene Discovery-Varianten (siehe Abb. 2), jede mit unterschiedlichen Zielen und Vorteilen. Eine davon erkennt z.B. im AD gespeicherte Computer-Konten, eine andere ist in der Lage, DHCP-Server abzufragen. Außerdem dient die Erkennung dazu, Benutzerkonten aufzufinden, deren Relevanz in SCCM 2012 im Vergleich zum Vorgänger stark gestiegen ist. So ist es z.B. möglich, dass Benutzer festlegen, welches ihr primäres Arbeitsgerät ist, was wiederum bei der Softwareverteilung von Interesse sein kann.

Abbildung 2: Die verschiedenen Ermittlungsmethoden (Discoveries)

Die Begrenzungen haben den Zweck, zu definieren, in welchem Rahmen der SCCM tätig ist. Dabei sind AD-Sites, IPv4-Subnetze, IPv6-Präfixe sowie IP-Adressbereiche möglich, wie in Abb. 3 zu sehen.

Abbildung 3: Einige der zur Verfügung stehenden Grenzen

Ein weiterer Bereich, dem man schon von Beginn an eine gewisse Aufmerksamkeit schenken sollte sind die Sammlungen: Es lassen sich Gerätesammlungen und Benutzersammlungen anlegen. Diese Sammlungen sind dann später die Basis, wo bzw. an wen man z.B. Software verteilen will. Diese Sammlungen haben immer eine übergeordnete Sammlung, lassen sich dadurch also sehr gut in einer Art Hierarchie organisieren. Weiterhin kann man das Befüllen der Sammlungen automatisieren, um so z.B. per WMI das Betriebssystem der verwalteten Geräte auszulesen (siehe Abb. 4) und dann diese entsprechend des verwendeten Systems in entsprechende Gerätesammlungen einzusortieren oder nach verwendeter Hardware zu gruppieren.

Abbildung 4: Eine WMI-Abfrage für eine Gerätesammlung

Der Configuration Manager Client

Damit die Clients wie gewünscht mit dem SCCM kommunizieren und agieren können, ist im Allgemeinen das Vorhandensein des „Configuration Manager Clients“ auf den verwalteten Endgeräten notwendig. Dieser Client stellt eine Sammlung notwendiger Agents zur Verfügung, die dann die einzelnen Aufgaben auf den Maschinen ausführen bzw. die Kommunikation mit dem SCCM übernehmen. Dieser Client lässt sich auf verschiedene Weise auf den Endgeräten installieren, u.a. über die (automatisierbare) Push-Installation, via Software-Update, über Gruppenrichtlinien (GPO) oder auch über ein Startskript. Der Client stellt auch sicher, dass entsprechend gesetzte Einstellungen und Policies des SCCM auf den Clients umgesetzt werden.

Modularität durch Rollen

Nach dem Herstellen einer gewissen Grundkonfiguration lässt sich der SCCM nun mit den verschiedensten Rollen – auch „Points“ genannt –  versehen. Einige davon sind in Abbildung 5 zu sehen. Dabei stehen die Rollen im Wesentlichen für die verschiedenen Möglichkeiten, die der Configuration Manager bietet.

Abbildung 5: Einige bereits installierte Rollen sowie die Möglichkeit, weitere Rollen zu installieren

Eine schnell und einfach installierte, aber in ihrer Wirkung recht große Rolle ist der „Endpoint Protection Point“. Dabei stellt Endpoint Protection eine zentral verwaltete und für die gewerbliche Verwendung freigegebene Version einer Schutzsoftware ähnlich der Security Essentials dar – also eine Suite zum Schutz der Clients vor Schadsoftware wie z.B. Viren und Würmer. Dabei kennt man dieses Produkt bereits schon etwas länger unter dem Namen „Forefront Endpoint Protection“. Aus der Oberfläche von System Center 2012 Configuration Manager lässt sich diese Software nun auf den gewünschten Clients und Servern im Unternehmen installieren, konfigurieren und betrieben werden. Der SCCM stellt hierzu vielfältige Werkzeuge für Management, Reporting, Alarmierung und natürlich Update Management bereit. Dabei lassen sich dann z.B. Updates und Scans für eine größere Gruppe von Endgeräten planen und verwalten, aber auch beispielsweise ein „on-demand Scan“ eines einzelnen Computers auslösen. Ebenso kann man hier auch verschiedenste Alarm-Meldungen konfigurieren, unter anderem für das gehäufte Auftreten einer speziellen Schadsoftware oder von Schadsoftware im Allgemeinen.

Abbildung 6: Der Endpoint-Protection-Client erinnert stark an den Windows Defender bzw. die Security Essentials

Der Application Catalog

Eine zweite Rolle, die eigentlich aus zwei Teilen besteht, ist der „Application Catalog“ (bestehend aus „Website Point“ und „Webservice Point“ – siehe Abb. 7). Dieser bietet die Möglichkeit, die Anwendungen, die dafür im SCCM entsprechend hinterlegt und aktiviert wurden, in einer Bibliothek zur Auswahl zu stellen. Die Mitarbeiter bekommen dadurch also die Möglichkeit, sich Anwendungen auf den PC zu installieren, die nicht Bestandteil der üblichen „Standardsoftware“ des Unternehmens sind. Dabei wäre denkbar, dass alle Mitarbeiter ein Office-Paket haben, aber eben nur die Mitarbeiter, die das möchten, ein Visio installiert bekommen. Dieser Katalog lässt sich mit einer Berechtigungs-Funktion versehen, die dafür sorgt, dass die Mitarbeiter die Installation eines gewünschten Produktes beantragen und ein Administrator dies dann entsprechend genehmigen muss (siehe Abb. 8). Natürlich kann man aber auch ohne diese Bibliotheks- oder Katalog-Funktion Software administratorgesteuert auf den verwalteten Maschinen installieren. Dazu muss die entsprechende Software ebenfalls im SCCM hinterlegt werden und kann dann auf Benutzersammlungen oder Gerätesammlungen zugewiesen werden. Damit lassen sich sehr leicht essentielle Softwarepakete unternehmensweit oder auch nur auf ausgewählte Bereiche ausrollen, beispielsweise ein Flash-Player, Java oder eben Office-Produkte.

Abbildung 7: Installation des Anwendungskataloges

Abbildung 8: Der Anwendungskatalog stellt dem Benutzer Programminstallationen zur Verfügung

Betriebssystem-Installation

Neben dem Deployment von einzelnen Anwendungen lassen sich mit dem SCCM, gestützt auf die „Microsoft Windows Deployment Services“ (WDS) und PXE, ganze Betriebssysteminstallationen durchführen. Dabei werden die gewünschten Betriebssysteme entweder als komplette Installation (quasi von der DVD) oder als WIM-Images (original oder auch angepasst) in SCCM hinterlegt und können dann im Rahmen von sogenannte Tasksequenzen (siehe Abb. 9) genutzt werden. Dabei stellen diese Tasksequenzen sehr einfach zu erstellende Listen von abzuarbeitenden Schritten dar. Diese sehen üblicherweise so aus, dass von einem angegebene Startabbild gestartet wird, die Festplatte partitioniert und formatiert wird, dann das entsprechende Betriebssystem angewendet wird und danach die weiter gewünschten Schritte abgearbeitet werden, zum Beispiel die Installation von Treibern, das Konfigurieren der Netzwerkeinstellungen inkl. Hostname und dem Domänenbeitritt, Installation weiterer Software oder einfach dem abarbeiten hinterlegter Skripte und Kommandos. Dadurch lassen sich fabrikneue PCs ohne größere Handarbeit direkt installieren. Der Aufwand für jeden einzelnen PC besteht dann im Idealfall nur noch im Anschließen der PCs und dem Anlegen der PCs in SCCM (am einfachsten über den Import via Liste). Der PC wird dann entsprechend vom SCCM mittels Wake-on-LAN gestartet, bootet via PXE vom Netzwerk und arbeitet die zugewiesene Tasksequenz ab.

Abbildung 9: Eine Tasksequenz für Betriebssystem-Deployment

Bei Bedarf können diese Tasksequenzen auch im „Application Catalog“ hinterlegt werden, um den Mitarbeitern selber die Möglichkeit zu geben, ihren PC neu installieren zu lassen. Diese Tasksequenzen müssen auch nicht immer zwingend bei der Formatierung einer Festplatte beginnen oder ein Betriebssystem installieren – man könnte u.a. auch „nur“ einzelne Konfigurationsschritte lokal auf den jeweiligen PCs abarbeiten lassen. Bei der Einführung einer neuen Betriebssystemversion kann durch die Einbindung des „User State Migration Tool“ (USMT) der Benutzerzustand gesichert und nach der Installation des neuen System zurückgespielt werden, analog zu einer händischen Migration.

Software Updates

Eine weitere sehr nützliche Rolle, welche sich auf den WSUS stützt, ist der „Software Update Point“. Mit diesem lassen sich Updates automatisch für die einzelnen Geräte bereitstellen. Das ist vom Prinzip nicht neu, greift hier allerdings zum einen direkt auf die bereits im SCCM angelegten Strukturen und Organisation, z.B. die Gerätesammlungen. Ausserdem kann durch die Verwendung eines SUP das Installieren von Updates direkt in den Prozess der Betriebssysteminstallation einbezogen werden und die im SCCM hinterlegten Betriebssystemabbilder können regelmäßig „offline gewartet“ werden, also mit den jeweils passenden Updates versehen werden, ohne dass diese Abbilder auf eine Maschine ausgerollt, gepacht und neu als Image aufgezeichnet werden müssen. Die SUPs stützen sich dabei auch auf die Architektur der SCCM-Umgebung und nutzen deren Verteilungsmechanismen. So bezieht beispielsweise die CAS die Updates direkt von den Microsoft-Servern, die Primary Sites werden von der CAS versorgt und die Secondary Sites wiederum von den ihnen übergeordneten Primary Sites.

Weitere Rollen

Weitere Rollen stellen beispielsweise ein umfangreiches Reporting zur Verfügung, dienen als Anlaufstelle für mobile Endgeräte oder bieten Unterstützung für das Out-of-Band-Management von entsprechend ausgerüsteten Clients (Intel AMT). Eine weitere sehr interessante Möglichkeit bietet „Asset Intelligence“. In Kombination mit dem „Hardware Inventory“ und dem Reporting kann man damit Fragen beantworten, welche Clients ein künftig einzuführendes Softwareprodukt nicht ausführen werden können und wo z.B. das Aufrüsten des Arbeitsspeichers nötig ist. Dazu können Systemanforderungen für diese Softwareprodukte formuliert und dann entsprechend ausgewertet werden. Ebenso ist es hier möglich, die Verwendung eines Softwareproduktes festzustellen. Zum einen kann überprüft werden, ob eine bestimmte Software installiert ist, um zu prüfen, ob die Anzahl der vorhandenen Lizenzen ausreicht, zum anderen lässt sich aber auch messen, welche Software wie oft und wie lange in einem definierten Zeitfenster eingesetzt wurde.

Remote-Zugriff

Zusätzlich zu den eher auf eine größere Anzahl von Clients bezogene Verwaltung bietet der SCCM den Administratoren die Möglichkeit, direkt über Remote-Tools an einem speziellen Client oder Server zu arbeiten. Neben den beiden klassischen Varianten „Remoteunterstützung“ und „Remotedesktop“ steht auch ein eigenes Protokoll zur Verfügung, bei dem der Administrator auf die Maschine zugreifen kann und der User weiterhin alles mitverfolgen kann, ohne dass hierfür der eher aufwändige Weg der Remoteunterstützung mit einer Einladung gegangen werden muss – und zwar direkt aus der SCCM-Konsole heraus.

Abbildung 10: Die Remotezugriff-Möglichkeiten

Rollenbasierte Administration

Bezüglich der Aufgabenverteilung im SCCM stellt die „Rollenbasierte Administration“ eine interessante und praktikable Möglichkeit dar, die einzelnen administrativen Aufgaben im Unternehmen zu definieren und den entsprechenden Benutzerkonten der Administratoren zuzuordnen. Damit kann man u.a. sicherstellen, dass jeder der Administratoren nur in seinem Arbeitsfeld tätig ist bzw. hier Änderungen vornehmen kann. Dazu sind bereits einige Rollen im System von Anfang an vorhanden, z.B. ein „Software Update Manager“ oder ein „Application Deployment Manager“, es können aber nach Bedarf weitere Rollen hinzugefügt werden (siehe Abbildung 11). Diesen werden dann in den jeweiligen Bereichen des SCCM die entsprechenden Rechte zugewiesen. Zusätzlich kann man über sogenannte „Scopes“ noch weiter einschränken, wer mit welchen Objekten, wie z.B. bestimmten Applikationen, Betriebssysteminstallationen oder Software-Updates arbeiten darf.

Abbildung 11: Ein Beispiel für eine Sicherheitsrolle

Zusammenfassung

Zusammenfassend lässt sich festhalten, dass der SCCM nach einer kurzen Aufbau- und Einarbeitungszeit die tägliche bzw. regelmäßige Administration und Wartung aller Clients und Server deutlich erleichtern kann. Dabei werden alle wesentlichen Facetten des „Lifecycle Management“ eines klassischen Clients in einem Unternehmen abgedeckt. Zusätzlich lässt sich der SCCM auch mit dem „System Center Operations Manager“ kombinieren, um eine Überwachung der Dienste und Aufgaben zu ermöglichen. Der modulare Aufbau des Configuration Manager bietet die Möglichkeit, dieses Produkt Schritt für Schritt einzuführen und zu nutzen, so dass man nicht gleich zu Beginn von der riesigen Funktionsvielfalt „erschlagen“ wird.

Schreibe einen Kommentar...

Hyper-V während OSD / TaskSequenz mittels SCCM installieren

Nach verschiedenen Versuchen, wie ich während einer OSD-Installation von Server 2012 mit dem SCCM 2012 auch Hyper-V installieren kann habe ich jetzt eine Lösung gefunden. Das eigentliche Problem rührt daher, dass bei einer Installation von Hyper-V via ServerManager-CMD oder PowerShell 2x ein Neustart erfolgt. Den ersten Neustart kann die Tasksequenz noch verarbeiten, den zweiten nicht mehr –  daher bricht die Tasksequenz dann ab.

Die Lösung: Eine Installation mittels dism.exe!

Dazu sind die beiden folgenden Kommandos notwendig:

cmd /c Dism.exe /image:%OSDTargetDrive%\ /Enable-Feature /FeatureName:Microsoft-Hyper-V /LogPath:%_SMSTSLogPath%\Hyper-V.log

und

cmd /c Dism.exe /image:%OSDTargetDrive%\ /Enable-Feature /FeatureName:Microsoft-Hyper-V-Management-Clients /LogPath:%_SMSTSLogPath%\Hyper-V-Management.log

Beide Schritte sollten NACH der Betriebssysteminstallation, aber VOR der Installation und Konfiguration des SC-Clients ausgeführt werden.

Schreibe einen Kommentar...

SQL-Server auf System Center Configuration Manager 2012 (SCCM) Server startet nach SYSPREP nicht mehr

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. [...]"
Schreibe einen Kommentar...