regsvr32 /i kaos.dll – Seite 6 – Windows in an Enterprise

Juli 28 2015

Surface Pro 3: Uninstall Windows 10 Tech Preview

In den letzten Wochen hatte ich Windows 10 Tech Previews auf meinem Surface Pro 3 am laufen. Nun wollte ich, kurz vor Release wieder auf 8.1 zurück um einen sauberen Update Stand zu erhalten. Alle Versuche ein "normales" Win8.1 zu installieren schlugen fehl – egal ob aus Win10 heraus (ISO geöffnet) oder über "Boot from USB".

Nach kurzer Suche fand ich dann doch die Lösung, das Surface Pro kann nur mit dem originalen Microsoft Recovery Image neu installiert werden.

Das Recovery Image kann man HIER bei Microsoft herunterladen (nicht nur für das Pro 3 sondern auch für die anderen Surface Modelle).

Anschließend müssen folgende Schritte durchgeführt werden:

Einen USB Stick mit FAT32 (nicht NTFS) formatieren, der Stick muß mindestens 8GB groß sein
Das heruntergeladene Recovery Image entpacken und auf den Stick kopieren
Das Surface ausschalten und den Stick einstecken
Die Leister Taste (Lautstärkerwippe nach unten) gedrückt halten und das Surface einschalten.
Wenn das Surface Logo erscheint kann die Leiser Taste losgelassen werden
Nun die gewünschte Sprache auswählen und auf über Fehlerbehebung -> Erweiterte Optionen die Eingabeaufforderung öffnen
Festplatte vorbereiten (Achtung Datenverlust!):
diskpart [Enter]
select disk 0 (bzw. die System Disk) [Enter]
clean [Enter]
Diskpart beenden, Eingabeaufforderung schliessen
Surface wie in Punkt 4 beschrieben neu starten
Sprache auswählen, dann über Fehlerbehebung -> Reset your PC auswählen
Im Setup auswählen, dass die Festplatte neu partitioniert werden soll
Warten bis die Installation durch ist
Beim nächsten Reboot bleibt das Surface stehen und fragt, ob der TPM bereinigt werden soll. Dies ist mit F12 zu bestätigen.
Warten bis die Einrichtung abgeschlossen ist

Der ganze Vorgang dauerte bei mir eine gute Stunde gefolgt von einigen Windows/Treiber Updates über WU.

Windows 10 kann nun kommen…. :-)

Katgeorie:Surface Pro 3 | Hinterlasse einen Kommentar

Juni 29 2015

Automatic Client Upgrade nicht aktivierbar

In einer ConfigMgr 2012 SP1 Umgebung kann es vorkommen, dass manche Optionen ausgegraut sind obwohl man als Full Administrator an der Konsole angemeldet sind. Mir ist das bislang in den Site Settings aufgefallen, als ich das automatische Client Update aktivieren wollte:

Um dies zu lösen muss man sich mit dem User an der Konsole anmelden, unter diesem auch die ConfigMgr Umgebung installiert wurde.

Administration \ Security \ Administrative Users \ $EureAdminGruppe –> Properties

Dort dann einma "All Security Scopes" für die Gruppe überschreiben und den Dialog mit OK beenden:

Danach sollten die betroffenen User die benötigten Rechte erhalten haben.

Katgeorie:ConfigMgr | Hinterlasse einen Kommentar

Mai 7 2015

Cumulative Update 5 (CU5) Configuration Manager 2012 R2

Microsoft hat das CU5 für den ConfigMgr 2012 R2 veröffentlicht (KB3054451).

Das CU5 beinhaltet fast ausschließlich Bugfixes in den Bereichen

Software Distribution / Application Management
Reporting
Site Servers / Site Sitems
Endpoint Protection
OS-Deployment
Client

Download: https://support2.microsoft.com/kb/3054451/en-us?sd=rss&spid=1060

Versionsstand mit CU5:

ConfigMgr = 5.0.7958.1604
SCEP Client = 4.7.209.0

Katgeorie:ConfigMgr | Hinterlasse einen Kommentar

Mai 6 2015

Bestimmte Updates nicht verteilen – ConfigMgr 2012

Wenn man die Windows/Office Updates per ConfigMgr 2012 und Automatic Deployment Rules (ADR) verteilt kommt man ggf. in die Situation, dass man spezifische Updates nicht verteilen bzw. zurückhalten möchte. Leider gibt es dafür eine direkte Lösung, gängig ist aber folgender Ansatz:

Unter Software Updates das entsprechende Update suchen, Rechtsklick -> Properties. Dort die Custom Servenity auf "Low" stellen.

Danach müssen alle ADR angepasst werden. DIese werden um das Suchkriterium "Custom Servenity = None" erweitert.

Dadurch fallen diie Updates, die eine eigene Servenity (in diesem Fall 'Low') haben beim nächsten ADR Durchlauf raus.

Siehe: http://blog.danovich.com.au/2012/12/18/decline-exclude-an-update-in-sccm-2012/

Katgeorie:ConfigMgr | Hinterlasse einen Kommentar

April 24 2015

Image Capture Wizard has failed with error code (0x800704CF)

Gerade wollte ich ein neues Referenz Image mit dem Configuration Manager 2012 erstellen wes jedoch mit dem Error Code 0x8070cf abgebrochen ist. Ein neues Image des bisherigen Referenz Computers lief erfolgreich durch.

Die Lösung war mal wieder einfacher als gedacht… Beim neuen Image habe ich Office 2013 inkl. allen Updates mit in das Image gepackt wodurch die Dateigröße des WIM von ca. 4,5GB auf über 10GB angewachsen ist. Dumm nur, dass mein Netzwerkshare für das Image nur noch 9GB freien Speicherplatz hatte… ;-)

Festplatte vergrößert und schon lief das Image durch. Merke: Statt Log Files lesen erstmal die einfachsten Grundlagen prüfen.

Katgeorie:ConfigMgr | Hinterlasse einen Kommentar

März 31 2015

ConfigMgr 3rd Party Anwendungen aktualisieren

Microsoft bietet passend zur ConfigMgr / WSUS Landschaft den System Center Updates Publisher 2011 an mit welchem 3rd Party Anwendungen aktualisiert werden können. Nach der Installation von SCUP läd dieser Update Kataloge herunter und übergibt diese dann an den WSUS bzw. Software Update Point. Beim nächsten Update Sync tauchen diese dann im Configuration Manager als "normale" Software Updates auf, später dazu mehr.

1) Installation SCUP

Nach dem Download des System Center Update Publisher 2011 (SCUP Download bei Microsoft) wird die Installation mit administrativen Rechten gestartet. Ich habe den SCUP parallel zur WSUS Konsole auf dem SUP instaliert. Die Installation dokumentiere ich hier nicht weiters, Standard Vorgehensweise. Allerdings mit einem Punkt der zu beachten ist:

Sofern der Zielrechner nicht Server 2012 / 2012R2 ist (WSUS 4.0) wird das Update KB972455 benötigt.
(generell sollte der WSUS up to date sein)

2) Konfiguration SCUP

Den SCUP immer mit Administrativen Rechten starten sonst kann die Patch-Freigabe schiefgehen.

Nach dem ersten Start muß der SCUP initital konfiguriert werden…

Zuerst wird die Verbindung zum WSUS eingerichtet und mit "Test Connection" überprüft. Für die Freigabe von Nicht-Microsoft Updates wird ein Zertifikat benötigt. Hier kann ein bereits vorhandes Zertifikat verwerndet werden, egal ob Self-Signed oder Public. Alternativ kann über "Create" ein WSUS Publishers Self-signed Zertifikat erstellt werden.

Anschließend wird die Verbindung zum ConfigMgr Management Point bzw. CAS eingerichtet und getestet.

Die Proxy Settings sollten selbterklärend sein.

3) WSUS Publisher Zertifikat verteilen & WSUS GPO anpassen

Das verwendete Zertifikat muss nun verteilt werden. Benötigt wird es auf aus dem WSUS/SCUP Server, dem ConfigMgr Server und allen Rechnern wo später die Updates installiert werden sollen und/oder eine ConfigMgr Console läuft.

Das in Schritt 2 generierte Zertifikat muss zuerst als DER codeded binary X.509 exportiert werden:

Das CER muss nun auf den entsprechenden Maschinen als "Trusted Root Certification Authorities" (Vertrauenswürdige Stammzertifizierungsstellen) und als "Trusted Publishers" (Vertrauenswürdige Herausgeber) Zertifikat eingetragen werden. Die kann wahlweise von Hand (mmc -> Zertifikate) oder per Gruppenrichtlinie global umgesetzt werden:

–> –>

(gleiche Vorgehensweise füt den Trusted Root Certification Authorities Strore)

Als letzter Schritt muss noch der Windows Updater so umkonfiguriert werden, dass selbstsignierte Updates auch installiert werden. Dies kann auch bequem über eine Gruppenrichtlinie verteilt werden:

GPO \ Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Windows Update

Allow signed updates from an intranet Microsoft update service location –> Enabled

Weiter geht es im nächsten Beitrag mit dem Veröffentlichen erster Updates… :-)

Katgeorie:ConfigMgr, Updates Publisher 2011 | Hinterlasse einen Kommentar

März 27 2015

System Center 2012 Configuration Manager Survival Guide

Viel zu lesen gibt es hier: http://social.technet.microsoft.com/wiki/contents/articles/7075.system-center-2012-configuration-manager-survival-guide.aspx

What is a survival guide? It’s a page we created as a pointer to information on the web. You can use the information below to learn the fundamentals and share information with other community members. And, if you think we missed some great article out there, please add it below!

Katgeorie:ConfigMgr | Hinterlasse einen Kommentar

März 19 2015

ConfigMgr 2012: Automatische Update Verteilung

Wenn man alle vier Wochen das selbe tut, dann kann man es auch automatisieren. Dachte ich mir… Daher habe ich seit Anfang des Jahres die Microsoft Patch Thuesdays mit dem Configuration Manager 2012 durch automatisiert. Nach kleinen Anpassungen funktioniert das nun ganz gut weshalb ich hier meinen Ansatz vorstellen möchte. Dies ist natürlich keine Best Practice oder gar "das" White Paper sondern nur einer von vielen Wegen die nach ~~Redmond~~ Rom führen. Kritik ist erwünscht. :-)
In meiner produktiven Umgebung habe ich Windows 7 x64 Clients mit Office 2010 sowie Windows 8.1 x64 Clients mit Office 2013, alles Multilingual.
(Anmerkung: Ich installiere meine Systeme i.d.R. immer auf Englisch die SUP Klassen kommen aber z.B. auf Deutsch. Ich lasse das einfach mal so unkommentiert stehen)

Zuerst wird der SUP konfiguriert, damit dieser die Updates bei Microsoft abholt und in der ConfigMgr Konsole zur Verfügung stellt:

Software Update Point (SUP) Configuration (Administration – Site Configuration – Sites – Configure Site Compinents)
Sync Source: Syncronize from Microsoft Update
Classifications: Definitionupdates, Service Packs, Sicherheitsupdates, Update-Rollups, Updates, Wichtige Updates
Products: Office 2010, Office 2013, Windows 7, Windows 8.1
Sync Schedule: Occurs every 1 hours
Supersedence Rules: Immediately expire a superseded software update
Language: 6 Sprachen ausgewählt

Nun müssen Rechner in Device Collections (Assets and Compliance) zusammengefasst werden, welche später die Updates bekommen sollen. Ich arbeite mit zwei Stufen, einer Pilot Gruppe sowie dem restlichen, produktiven Rechnern. Daher gibt es zwei Device Collections:

PatchMgmt_ADR_Pilot –> Manuell zugewiesene Rechner, welche die Updates zuerst erhalten sollen
PatchMgmt_ADR_Prod –> Alle Clients exklusive der Testgruppe (per Query)

Im nächsten Schritt brauchen wir Deployment Packages (Software Library – Software Updates) wo rein die vom WSUS heruntergeladenen Updates gepackt werden. Diese Packages werden dann auch auf alle Distribution Points verteilt. Damit die Packages nicht zu groß werden (man liest immer wieder, man sollte nicht mehr als 500 Updates pro Package haben) habe ich hier eines pro Produkt angelegt und auf alle Distribution Points verteilt:

ADR_Office_2010_32Bit-2015 & ADR_Office_2013_32Bit_2015
ADR_Windows7_x64-2015 & ADR_Windows81_x64-2015

So und nun wird automatisiert…

Pro Produkt gibt es nun zwei Automatic Deployment Rules (Software Library – Software Updates), wieder am Beispiel Office 2010 erklärt:

Der entsprechenden Collection zuweisen und Add to an existing Software Update Group ^[1]

^[1] Beim ersten Lauf hatte ich das noch auf "Create a new Software Update Group" damit die entsprechende Gruppe angelegt wird. Ich möchte aber nicht jeden Monat zig neue Gruppen haben weshalb ich das entsprechend umgestellt habe. Das ist letztlich eine Design Frage und was am besten ist habe ich noch nicht final entschieden… Hängt in erster Linie immer von eurer Umgebung mit ab.

Ich nehme alle Updates, die in den letzten 3 Wochen für das entsprechende Produkt veröffentlicht wurden und die von mehr als 10 Rechnern angefordert wurden.

Bei den PILOT Gruppen führe ich die entsprechenden ADRs immer am zweiten Donnerstag des Monats durch, d.h. 2 Tage nach dem Patch Tuesday von Microsoft. Bei den PROD Gruppen schaut die ADR ähnlich aus jedoch wird diese immer an jedem dritten Donnerstag des Monats ausgeführt. Dies bedeutet dass die Testgruppe alle Updates mit zwei Tage Verzug erhalten (bzw. bedingt durch die Zeitzone sogar weniger). Wenn innerhalb einer Woche keine Probleme auftreten, werden die Updates dann auf alle Rechner weiterverteilt. Achtung, kleiner Designschnitzer: Sollte in dieser Woche ein Update zusätzlich veröffentlicht werden (i.d.R. nicht!) dann fehlt das in der Pilot Gruppe und würde ungetestet auf alle Prod Rechner verteilt werden.

Die ADR muss dann noch dem entsprechenden Deployment Package zugewiesen werden, damit die Downloads im korrekten Package landen. Alle von mir übersprungenen Einstellungen wählt ihr, wie es in eure Landschaft passt.

Zusätzlich zu den ADR Gruppen habe ich noch eine manuelle Patchgruppe für das Jahr 2015 wo ich alle Updates aufnehme, die durch das Raster gefallen sind bzw. nicht der ADR entsprochen hat. Immer zum Jahresende konsolidiere ich die Update Packages und verwerde die nicht mehr benötigten Updates.

Katgeorie:Application Deployment, ConfigMgr | Hinterlasse einen Kommentar

Januar 28 2015

WMI Cleanup SMS_PackagesInContLib

Im Distribution Point Configuration Status habe ich seit dem löschen vieler Pakete folgenden Fehler drin: Failed to retrieve the package list on the distribution point….

Die betroffenen Packages kann man in dem smsdpmon.log auf dem betroffenen DP-Server finden:

Die Package ID kann dann am einfachsten über den Content Status gesucht werden. Findet man das Paket so, dann am besten neu auf den DP verteilen und schauen ob es durchläuft. In meinem Fall wurde das Paket jedoch schon in der Software Library gelöscht.

In diesem Fall muss auf dem betroffenen Distribution Point im WMI das Paket aus der Content Library entfernt werden.

Dies kann u.a. über die PowerShell schnell und einfach erleidigt werden. Ich übernehme jedoch keine Verantwortung, aufpassen was ihr löscht! :-)

Anzeigen: gwmi -Namespace root\sccmdp -Query "select * from SMS_PackagesInContLib where PackageID = '……….'"
Entfernen: gwmi -Namespace root\sccmdp -Query "select * from SMS_PackagesInContLib where PackageID = '……….'" | Remove-WmiObject

Pakete, die noch in der Software Library vorhanden sind, können einfach mittels "Update Content" neu verteilt werden.

Eine vollständige Content Validation kann mit smsdpmon.exe durchgeführt werden. Wer nicht so lange warten möchte, kann auch gezielt einzelne Pakete validieren: smsdpmon.exe PACKAGE-ID.

Damit sollten die Fehler im DP Configuration Status dann verschwinden…. (Wie immer, SMS = Small Moving Server ;))

Links zum Thema:

Katgeorie:ConfigMgr | Hinterlasse einen Kommentar

Januar 21 2015

Open-E: A success story from the mechanical engineering industry

Ein Jahr später fand "meine" Success Story auch den Weg in das englische Open-E Blog.

OPTIMA is a German leader in manufacturing filling and packaging machines, owning a large redundant data center in one of their headquarters in Schwäbisch Hall. Their main constraint was to centralize all services so that the administration could work directly from the headquarter.
That’s why they set up a centralized system based on Open-E DSS V7 and VMware ESX Server. With the help of Open-E, OPTIMA was able to achieve stability and a redundant system with no single point of failure. Additionally, Open-E DSS V7 provided the scalability and availability they needed, being at the same time hardware-independent.
Manuel Kuss, System Administrator with OPTIMA
“Apart from its flexibility, it was the stability of the Open-E systems that convinced me. We benefit from the hardware redundancy in lieu of not having any technical contact onsite in remote locations. The system keeps running even if hardware components fail, and can easily be rebooted even after power outages. By using commodity servers, we do not face any problems regarding hardware supplies and do not need to use any specific SAN disk drives.”

Read full case study

Katgeorie:Open-E DSS | Hinterlasse einen Kommentar