Quick and Dirty Referenz PC für OSD
Aktuell baue ich an einem neuen Referenz Image für Windows 10 mit Office 2016 in mehreren Sprachen. Hier gibt es viele Wege die ans Ziel führen können, den automatischen Build and Capture Prozess vom ConfigMgr, eine MDT Task Sequenz oder das ganze manuell durchzuführen. Aus unterschiedlichen Gründen baue ich eine Referenz PCs derzeit noch von Hand, dazu eine kleine Quick and Dirty Vorgehensweise:
- Eine neue VM mit möglichst wenig Hardware erstellen (SATA, kein Sound, keine Drucker, …)
- Windows 10 aus dem aktuellesten Image in Englisch installieren, einen Dummy User anlegen
- Windows 10 aktivieren
- Alle benötigten Sprachpakete aktivieren und herunterladen
- .NET 3.5 Feature und Middleware installieren (VC++ Runtimes)
- Office 2016 inkl. Sprachpaketen installieren (dazu verwende ich die Source der SCCM Application)
- Windows Update inkl. Office
- Den Builtin Administrator Account aktivieren, sich mit diesem anmelden
- Den Dummy User inkl. Profil löschen, Cleanup durchführen
- Einen VM Snapshot erstellen und das Referenz Image abziehen
Braucht man nun ein Update dann kann man quasi mit den Windows Updates beginnen, das Cleanup durchführen und das Capture durchführen.
Client Cleanup Schritte:
- Festplatten Bereinigungstool laufen lassen (cleanmgr.exe)
- hyberfil.sys entfernen (powercfg -H off)
- Windows Updates löschen (net stop wuauserv ; del %windir%\SoftwareDistribution /q /s ; net start wuauserv)
- dism.exe /online /Cleanup-Image /RestoreHealth
- dism.exe /online /Cleanup-Image /StartComponentCleanup /ResertBase
Das so erzeugte Image hat mit Win10/Off2016 und 6 Sprachen derzeit 9,8GB.
In-Console Update SCCM 1702 -> 1707 breaks OSD
Nach dem In-Console Update des ConfigMgr 1702 auf 1706 funktionierten bei mir die PXE Task Sequenzen nicht mehr. Fehlermeldung:
Failed to Run Task Sequence
There are no task sequences available for this computer
Nach längerer Suche fand ich einen SCCM Bug, welcher eigentlich schon in 1702 behoben sein sollte, siehe KB4019926
Die Ursache ist so banal wie auch fatal: Die GUID des Objektes „x64 Unknown Computer (x64 Unknown Computer)“ wurde von einem anderen Client verwendet. Das kann, laut KB, wohl vorkommen wenn man mal den „Zurück“ Button während einer Task Sequence verwendet hat. Interessanterweise trat der Fehler bei mir Wochenlang nicht unter 1702 sondern erst nach dem Upgrade auf 1706 auf….
Lösung:
In der SQL erstmal die GUID der zwei Unknown Computer Objekte suchen:
select ItemKey, Name0,SMS_Unique_Identifier0 from UnknownSystem_DISC
Bei mir war das Objekt schon zum löschen markiert (Decommissioned=1) aber eben noch in der Datenbank vorhanden. Anstatt auf den Purge Prozess zu waren entschloss ich mich die zwei Unknown Objekte neu anzulegen:
Dazu brauchen wir die ItemKeys der zwei Objekte
select * from UnknownSystems
danach können beide aus der Datenbank gelöscht werden:
delete from UnknownSystem_DISC where ItemKey in (%ITEMKEY%)
Anschliessend muss man in der Registry auf dem Primary Site Server folgenden Key ändern:
HKLM\Software\Microsoft\SMS\Components\SMS_Discovery_Data_Manager
CreatedUnknownDDR: Von 0 auf 1 ändern
danach den SMS Executive Dienst durchstarten.
In Folge werden dann die zwei Objekte mit neuer GUID angelegt. Nachdem ich dann meine Task Sequenzen neu deployed hatte funktionierte alles wieder wie gehabt.
Vielen Dank an syswow64
Update for System Center Endpoint Protection 2012 Client – 4.10.209.0 (KB3209361)
Microsoft hat das Update KB3209361 vom September 2016 am 24.01.2017 neu veröffentlicht. Wer es also, wie ich, in einer Update Gruppe freigegeben hat wird feststellen, dass dieses Update mit einem roten X gekennzeichnet ist und sich nicht mehr herunterladen/installieren lässt…
Einfach aus der Verteilung nehmen, neu herunterladen und neu deployen…
OSD HP ZBook 17 G3
Wir setzen bislang das HP ZBook 17 G2 ein weshalb ich sehr optimistisch an das Thema Treiber für das G3 heran ging, Business as Usual… Sollte man meinen…
Treiber heruntergeladen, Package erstellt, erster Test und dann festgestellt dass sich der CCM Agent nicht installiert und das Gerät nach dem ersten Reboot (nach „Setup Windows and ConfigMgr“) hängen bleibt. Da alle Treiber sauber installiert wurden und das Gerät sogar den Domain Join schaffte, schloss ich ein Treiberproblem aus.
Selbst das smsts.log gab nicht viel her, ein Indiz war lediglich die Zeile
The action (Setup Windows and Configuration Manager) requested a retry
Nach viel Try & Error fand ich heraus, dass es an der Konfiguration von SSD (per MSATA) und HDD (per SATA) liegt. Wird die HDD ausgesteckt läuft die Task Sequence sauber durch. Dies ist insofern komisch weil die ZBook 17 G2 Geräte bei uns die selbe Konfiguration aufweisen und es hier zu keinen Schwierigkeiten kommt.
Eine endgültige Lösung habe ich leider noch nicht, allerdings einen Workaround:
Direkt nach dem Start in WinPE deaktiviere ich die SATA Ports per Script und starte den Rechner nochmals neu. Danach folgt das reguläre OSD und als letzten Schritt aktiviere ich die SATA Ports wieder vor dem finalen Neustart.
Inhalt der BCU_zbook17g3_sata_on.cmd:
pushd %~dp0
„%~dp0BiosConfigUtility64.exe“ /set:“%~dp0zbook17g3_sata_on.REPSET“
popd
Zum HP BiosConfigurationUtility schreibe ich vielleicht mal noch etwas mehr, dieser Beitrag ist erstmal eine Kurzinfo…
Wenn jemand das selbe oder ähnliche Probleme hat würde ich mich über einen Kommentar freuen.
Windows ADK Versionsnummern
Aktuelle Windows 10 ADK Versionsnummern:
- ADK for Windows 10 1607 -> 10.1.14393.0
- ADK for Windows 10 1511 -> 10.1.10586.0
- ADK for Windows 10 RTM -> 10.0.26624.0
- ADK for Windows 10 -> 10.0.10240.0
Nur falls ich das mal wieder suche muss… ;-)
Quelle: http://renshollanders.nl/2016/12/download-windows-adk-the-numerous-versions-of-microsoft-windows-adk-assessment-and-planning-toolkit-and-where-to-find-them/
ConfigMgr 1610 bug leaves orphaned objects in ccmcache
### Fixed by Microsoft (see below) ###
It looks like that I found a bug in Configuration Manager version 1610. After update my clients from version 1606 some folders/files are orphaned in %windir%\ccmcache.
Example:
C:\Windows\ccmcache contain a bunch of folders, lates is an SCEP defintion from 12/14/2016.
The update from 1606 to 1610 was installed on 12/06/2016.
After I try to cleanup manually using „Delete Files…“ from CM Properties (with checked „Delete persisted cache content“ to be sure) folders newer than 12/06/2016 are removed:
If I check the content of folder 41 (in this specific machine) I can see, it’s the one with ccmsetup.exe from version 1610:
All my clients have the same issue. I will report this to Microsoft and some people at Twitter and TechNet Forums confirmed the same behavior in their environments. This is no big issue, ConfigMgr still works and I can deploy software. Maybe I will cleanup this orphaned files using Compliance Settings in a later step…
Edit:
I did another test -> Client Cache is set to 8GB. After 1610 was installed, I had ~5GB orphaned stuff in ccmcache but it was no problem to deploy a package with 5GB total size… At this point I think it will be no problem to cleanup the old stuff by script.
Edit 22. Dec.:
Microsoft released an update for this bug: KB3124042
After clients upgrade to Configuration Manager, version 1610, the contents of the CCM Cache folder (%windir%\ccmcache by default) are orphaned. Although the files are still present on disk, they are not available for application installations and will not be managed or deleted by the client.
Installing this update prevents the cache issue on future client upgrades. Previously upgraded clients will redownload applicable content, and any expired content can be manually deleted as needed.
Update 2 für ConfigMgr 1610 (Early Wave)
Kurz und knapp, es ist noch ein zweites Update für den ConfigMgr 1610 unterwegs. Auch hier sind wohl nur die Binaries betroffen, welche vor dem 01.12. heruntergeladen wurden.
Update 2 for System Center Configuration Manager version 1610, early wave (KB3211925)
Das Update behebt wohl einen (weiteren?) Fehler bei den Task Sequenzen wenn ihr folgende Fehlermeldung beim verteilen erhaltet:
The selected task sequence uses an invalid package or application reference. Use task seuqence editor to correct the error or select a different task sequence.
Ob Update 2 eine neue Console oder einen neuen Client bringt kann ich noch nicht sagen reiche ich aber nach.
Update 1 für ConfigMgr 1610 kommt
Für den Configuration Manager Current Branch gibt es im Fast Ring das erste Update welches u.a. folgende Fehler beheben soll:
- Softwarecenter startet nicht
- SMS Agent Host verbraucht 100% CPU
- Beim Win7 OSD wird er Schritt „Setup Windows and ConfigMgr“ nicht ausgeführt
- Der „Update and Servicing“ Node fehlt nach dem Update
Details siehe KB3209501.
Nicht betroffen sind Systeme, wo die Update Files nach dem 01.12. heruntergeladen wurden. Prüfen kann man das im „Update and Servicing“ Node wenn man sich dort die Package GUID anzeigen lässt. Betroffen ist das ConfgMgr1610 Update mit der GUID „C43A89E4-B642-4FC8-ABF0-255BF5D88D82“.
ConfigMgr 1610 = Version 5.00.8458.1000 + Client Version 5.00.8458.1000
ConfigMgr 1610 Update 1 = Version 5.00.8458.1500 + Client Version 5.00.8458.1007
In meiner Umgebung sind von den genannten Fehlern bisher (noch) keine aufgetreten werde aber das Update 1 auch relativ zeitnah einspielen.
Gesperrte Objekte in der CM Console
Welcher CM Admin kennt es nicht auch? Die Console stürzt (warumauchimmer) ab und das gerade bearbeitete Objekte ist gesperrt:
Hier gibt es drei Möglichkeiten:
- Warten… :-)
- Den LockState direkt in der Datenbank löschen
- PowerShell
Leider hatte ich in dem konkreten Fall mit PowerShell keinen Erfolg, das entsprechende cmdlets ist jedoch „Unlock-CMObject„. Ich konnte den Lock jedoch problemlos in der Datenbank entfernen. Der ConfigMgr verwaltet Locks in der Tabelle „SEDO_LockState“ (SEDO = Serialized Editing of Data Objects), die entsprechende Abfrage ist demnach:
select * from SEDO_LockState where LockStateID <> 0
die entsprechende Zeile kann dann mit
delete from SEDO_LockState where LockID = ‚……‘
gelöscht werden.
Wie immer bei Datenbank Eingriffen: Unsupported, Backup, Think first…… ;-)