BitLocker-Wiederherstellungsschlüssel aus ActiveDirectory auslesen

Veröffentlicht f.puernerVeröffentlicht in Computer

Seit Windows 8 ist die Laufwerksverschlüsselung BitLocker auch in den üblicherweise verwendeten Pro bzw. Professional Versionen von Windows enthalten. Aus Sicherheitsgründen sollte sie auf jeden Laptop aktiviert werden!

Um BitLocker vernünftig verwenden zu können ist ein Laptop mit integrietem TPM-Chip erforderlich. Dies ist bei Business-Laptops immer der Fall (evtl. muß TPM einmalig im BIOS aktiviert werden), bei Laptops für Home User fehlt der TPM-Chip normalerweise. In diesem Fall kann zwar per Gruppenrichtline ein Modus aktiviert werden in dem BitLocker auch ohne TPM-Chip verwendet werden kann, aber dann muß direkt nach jedem Einschalten/Neustart ein zusätzliches BitLocker-Kennwort eingegeben werden. Dies ist auf Dauer sehr nervig und daher nicht wirklich praktikabel.

Die Aktivierung von BitLocker ist sehr einfach: Rechtsklick auf das zu verschlüsselnde Laufwerk im Windows Explorer, „BitLocker aktivieren“ wählen und durch den Assistenten klicken. An einer Stelle wird man dabei aufgefordert den Wiederherstellungsschlüssel entweder auszudrucken oder als Textdatei auf einem anderen Laufwerk zu sichern. Nach einem Neustart startet die Verschlüsselung, die je nach Festplattengröße schon einige Zeit erfordern kann. Im Normalbetrieb hat man anschließend keine spürbare Verlangsamung durch BitLocker. Moderne SSDs verschlüsseln außerdem durch Hardwareunterstützung in Echtzeit!

Wenn man jetzt z.B. bei einem Defekt des Laptops von extern auf die verschlüsselte Festplatte zugreifen muß, benötigt man zwingend den BitLocker-Wiederherstellungsschlüssel. Diesen hat man zwar bei der Verschlüsselung gedruckt bzw. gesichert, aber im Zweifelsfall ist er nicht da wenn man ihn braucht! Da wäre es schon sehr praktisch wenn man den BitLocker-Wiederherstellungsschlüssel einfach aus dem AD auslesen könnte. Dies ist auch sehr einfach möglich, allerdings muß dies vorab in mehreren Schritten manuell eingeschaltet werden:

Angezeigt wird der BitLocker-Wiederherstellungsschlüssel in einem zusätzlichen Reiter in den Eigenschaften des Computers in „Active Directory-Benutzer und -Computer“. Damit dieser Reiter angezeigt wird, muß einmalig mit dem Server-Manager das Feature „Verwaltungsdienstprogramme für die BitLocker-Laufwerksverschlüsselung“ inkl. der beiden Unterpunkte hinzugefügt werden. Zusätzlich wird dadurch auch der Befehl „Kennwort für BitLocker-Wiederherstellung suchen …“ im Kontextmenü des Domänennamens in „Active Directory-Benutzer und -Computer“ hinzugefügt.

Damit in diesem Reiter auch etwas angezeigt werden kann, muß der BitLocker-Wiederherstellungsschlüssel vorher im AD gesichert worden sein. Das wird er nur wenn man die Gruppenrichtlinie „Computerkonfiguration -> Richtlinien -> Administrative Vorlagen -> Windows-Komponenten -> BitLocker-Laufwerksverschlüsselung -> Betriebssystemlaufwerke -> Festlegen, wie BitLocker-geschützte Betriebssystemlaufwerke wiederhergestellt werden können“ aktiviert und darin die beiden Punkte „BitLocker-Wiederherstellungsinformationen für Betriebssystemlaufwerke in AD DS speichern“ und (sinnvollerweise) „BitLocker erst aktiveren, nachdem Wiederherstellungsinformationen für Betriebssystemlaufwerke in AD DS gespeichert wurden“ markiert.

Wenn man jetzt an einem Laptop BitLocker aktiviert, wird der BitLocker-Wiederherstellungsschlüssel automatisch im AD gesichert und kann über den oben beschriebenen Reiter einfach wieder ausgelesen werden.

Stellt sich natürlich die Frage wie man bereits existierende BitLocker-Wiederherstellungsschlüssel nachträglich ins AD bekommt: Dies ist über PowerShell möglich, allerdings muß man dazu an dem entprechenden Laptop sitzen. Wie auf dieser Seite beschrieben, kann man sich mit dem Befehl

manage-bde -protectors -get c:

den verwendeten BitLocker-Wiederherstellungsschlüssel inkl. dazugehörigem BitLocker-Bezeichner (wird als „ID“ in geschweiften Klammern ausgegeben) anzeigen lassen. Mit

manage-bde -protectors -adbackup c: -id '{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}'

und der mit dem ersten Befehl ausgelesenen ID kann der BitLocker-Wiederherstellungsschlüssel ins AD geschrieben werden und ist dann auch sofort im oben beschriebenen Reiter sichtbar.

Windows-Helpfiles (.chm) zeigen keinen Inhalt an

Veröffentlicht f.puernerVeröffentlicht in Computer

Dieses Problem hat mich mal wieder viel länger beschäftigt als gedacht: Bei einem unter RemoteDesktopServices („Terminalserver“) genutzen Programm wird in der Hilfe nur der Index in der linken Spalte des Hilfefensters angezeigt, die eigentliche Hilfe im rechten Teil bleibt leer.

Das Programm ist nicht auf dem Terminalserver selbst, sondern in einer Share im DFS installiert. Es liegt nur eine Verknüpfung zur exe auf dem Desktop des Terminalservers. Das Programm selbst funktioniert wunderbar und zeigt auch obwohl es nicht lokal installiert ist bei Start keine Warnung („Diese Datei befindet sich an einem Speicherort …„) an, nachdem ich den Pfad zu der DFS-Share zu Systemsteuerung -> Internetoptionen -> Sicherheit -> Lokales Intranet -> Sites -> Erweitert hinzugefügt habe.

Nur der Hilfeinhalt wird nicht angezeigt. Weder über das Hilfemenü aus dem Programm heraus noch wenn ich die cfm-Datei direkt im Explorer öffne. Bei der Recherche bin ich relativ schnell zu dem Artikel KB892675 gekommen der das Problem beschreibt. Da ich aber die Share bereits zur „Lokales Intranet“ Zone hinzugefügt hatte und der im Artikel beschriebene Key „MaxAllowedZone“ mit dem Wert „1“ (also „Lokales Intranet“) per Default vorhanden war, hat mich dies nicht weitergeführt.

Den ersten Hinweis zur Lösung hat mir ein Artikel auf WinFAQ gebracht: Es gibt im Zusammenhang mit den Zugriffsbeschränkungen auf cfm-Dateien zwei Registry-Keys

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\HHRestrictions
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions

wobei nur der erste Key per Default vorhanden ist. Sobald ich den zweiten Key manuell (inkl. „MaxAllowedZone“) hinzugefügt hatte, wurde beim Öffnen der chm-Datei aus dem Explorer endlich der Hilfeinhalt angezeigt. Nur beim Aufruf der Hilfe über das Hilfemenü im Programm blieb der Hilfeinhalt immer noch leer.

Hier hat mich ein TechNet-Forumseintrag auf die richtige Idee gebracht: Das Betriebssystem auf dem Terminalserver ist 64 Bit und das Programm aus dem ich die Hilfe aufrufen möchte 32 Bit. Daher muß der „MaxAllowedZone“ Key zusätzlich im Wow6432Node-Ast der Registry hinzugefügt werden. Nachdem ich das erledigt hatte wurde der Hilfeinhalt endlich auch beim Aufruf über das Hilfemenü angezeigt.

Letztlich mußte ich diese beiden REG_DWORD Keys zur Registry hinzufügen (die beiden HHRestrictions Keys sind per Default bereits vorhanden):

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000001

Windows Lizenztypen: OEM, Retail, Volume, …

Veröffentlicht f.puernerVeröffentlicht in Computer

Vor kurzem hat ein Kunde für den Betrieb von geplanten virtuellen Maschinen (VMs) eine Handvoll Windows-Keys (Windows 7 und Windows 10) bei einer mir unbekannter Quelle gekauft. Ich habe die VMs vorbereitet und wollte diese mit den gekaufen Keys aktivieren. Das hat aber nur mit den Windows 10 Keys funktioniert, die Windows 7 Keys wurden als ungültig zurückgewiesen.

Auf der Suche nach einer Begründung bin ich auf den Befehl „slmgr“ gestoßen: Nach Eingabe von „slmgr -dli“ in eine Eingabeaufforderung erscheint nach einer unerwartet langen, mehrsekündigen Wartezeit ein kleiner Dialog mit Lizenzinformationen über

  • den Windows-Typ (Home, Pro, Enterprise, …),
  • den Lizenz-Typ (Typ des verwendeten Installationsmediums: OEM, Volume, Retail, ….),
  • die letzten 5 Zeichen des Productkeys,
  • den Lizenz-Status (Lizensiert, Initial Grace Period, …).

Mit „slmgr -dlv“ bekommt man einen größeren Dialog mit ausführlicheren Informationen, die man aber üblicherweise nicht benötigt.

Auf diesem Weg habe ich herausgefunden, dass die von mir installierten Windows 10 VMs vom Lizenz-Typ „VOLUME_MAK channel“, die Windows 7 VMs aber vom Lizenz-Typ „RETAIL channel“ waren. Wahrscheinlich waren die gekauften Windows-Keys alles Volumenlizenzen, mit denen sich keine Windows-Installation aktivieren läßt die mit einem Retail-Installationsmedium erzeugt wurde.

Hinzufügen eines Benutzers zu einem MS SQL-Server bei unbekanntem SQL-Administrator

Veröffentlicht f.puernerVeröffentlicht in Computer

Seit dem Update 3a für Veeam Backup & Replication 9.5 muß der für das „Guest Processing“ verwendete Benutzer die sysadmin Rolle auf einem zu sichernden SQL-Server besitzen. Da dies bis jetzt häufig nicht der Fall war, hat Veeam nach dem Update eine Warnung für jede VM mit einem SQL-Server ausgegeben. Nach dem Hinzufügen des entsprechenden Benutzers (inkl. sysadmin Rolle) mit dem „SQL Server Management Studio“ treten die Warnungen nicht mehr auf.

Wenn allerdings keine Zugangsdaten eines SQL sysadmin bekannt sind, ist das natürlich nicht möglich. In einem Microsoft Artikel habe ich eine Anleitung gefunden, wie man trotzdem einen neuen Benutzer (auch mit sysadmin Rolle) anlegen kann. Man muß dazu im „SQL Server-Konfigurations-Manager“ zu der entsprechenen SQL-Server Instanz den Startparameter „-m“ hinzufügen und den Dienst neu starten. Durch diesen Parameter startet die Instanz im Single-User-Mode. In diesem Zustand konnte ich mich mit meinem Windows-Administratorkonto ganz normal am „SQL Server Management Studio“ anmelden und den neuen Benutzer hinzufügen. Der in dem Microsoft Artikel beschriebene Weg den Benutzer über eine SQL Query hinzuzufügen war nicht nötig. Anschließend den Startparameter „-m“ wieder entfernen und den Dienst neu starten, damit die SQL Instanz wieder normal läuft.

Danach konnte ich mich mit dem hinzugefügten Benutzer normal am „SQL Server Management Studio“ anmelden und auch Veeam bringt keine Warnungen mehr.

Installation eines kumulativen Updates für Windows 10 schlägt dauerhaft fehl

Veröffentlicht f.puernerVeröffentlicht in Computer

Da ich dieses Problem in letzter Zeit mehrfach hatte: Die automatische Installation des monatlichen „kumulativen Updates“ für Windows 10 (das Problem ist sowohl bei 2018-02 als auch bei 2018-03 aufgetreten) schlug wiederholt mit Fehler 0x80070bc2 fehl. Und obwohl es in der Zwischenzeit bereits das Nachfolgeupdate des Folgemonats gab, hat er immer wieder vergeblich versucht das inzwischen veraltete Update zu installieren.

In diversen Forenpostings (z.B. hier) wird der Tipp verbreitet gleich bei 4 Diensten die Startart auf „automatisch“ zu ändern und dann die Installation neu zu versuchen. Ich habe dies nur beim „Windows Modules Installer“ (=TrustedInstaller) gemacht, was sich als ausreichend herausgestellt hat. Zuerst hat er endlich das problematische Update installiert und nach dem dazugehörigen Neustart auch gleich das aktuelle kumulative Update gesucht, geladen und installiert. Beide Updateinstallationen haben auffallend lange gedauert.

Merkwürdigerweise wird das ursprünglich problematische Update im Updateverlauf immer noch mit dem Updatefehler 0x80070bc2 angezeigt, obwohl die Installation ja letzlich doch geklappt hat. Darüber wird aber das aktuelle kumulative Update korrekt als erfolgreich installiert aufgelistet.

Der „Windows Modules Installer“ Dienst läuft jetzt natürlich dauerhaft was aber wohl kaum spürbar sein dürfte. Evtl. könnte man die Startart des Dienstes jetzt auch wieder auf „manuell“ zurückstellen.

Inplace Upgrade von Windows 10 Home auf Enterprise

Veröffentlicht f.puernerVeröffentlicht in Computer

Als Microsoft Partner haben wir Windows 10 Enterprise Lizenzen für die interne Benutzung zur Verfügung. Heute wollte ich einen neuen Laptop der mit Windows 10 Home geliefert wurde mit einer dieser Lizenzen auf Windows 10 Enterprise upgraden.

Dieser Vorgang wird von Microsoft als „Editionsupgrade“ bezeichnet und ist über „Einstellungen ->  Update und Sicherheit -> Aktivierung“ erreichbar. Dort kann man mit „Product Key ändern“ den Product Key der neuen Edition eintippen und damit das Upgrade durchführen.

Nur kann man auf diese Weise Windows 10 Home nur auf Windows 10 Pro upgraden aber nicht auf Windows 10 Enterprise. Wenn man an dieser Stelle den Windows 10 Enterprise Key eintippt, bekommt man eine Fehlermeldung mit dem Fehlercode 0xc004f050.

In einem Blog-Posting habe ich die Lösung gefunden: Man muß tatsächlich zuerst das Windows 10 Home auf ein Windows 10 Pro upgraden. Hierzu kann man den offiziellen Standardkey VK7JG-NPHTM-C97JM-9MPGT-3V66T verwenden, muß allerdings um einen „Aktivierungsfehler“ 0xc004f014 zu vermeiden vor dem Start des Upgrades alle Netzwerkverbindungen unterbrechen, also Netzwerkkabel abziehen bzw. WLAN deaktivieren. Der Upgradevorgang dauert einige Minuten und beinhaltet einen Neustart.

Anschießend hat man ein nicht aktiviertes (!) Windows 10 Pro. Jetzt kann man (nachdem man die Netzwerkverbindung wiederhergestellt hat) an der gleichen Stelle wie vorher erneut auf „Product Key ändern“ klicken und den Windows 10 Enterprise Key eintippen. Dieser wird ohne Verzögerung akzeptiert und man hat endlich ein aktiviertes Windows 10 Enterprise.

Automatische Installation von Windows Updates auf Server 2016 aktivieren

Veröffentlicht f.puernerVeröffentlicht in Computer

Auf einem neu installierten Windows Server 2016 ist die Standardeinstellung bzgl. der Windows Updates „Herunterladen und zur Installation auffordern“, die Updates werden also nicht automatisch installiert. Das ist bei einem Server auch gut so, denn normalerweise will man hier keine unbeaufsichtigten Neustarts haben.

Ich wollte die Windows Updates an einem Server aber bewußt auf „automatisch“ ändern und hatte das Problem, dass es in den Einstellungen keine Möglichkeit gibt die Installationsmethode zu ändern. Eine Suche hat mich zu einem TechNet-Artikel mit der Lösung gebracht:

Diese Einstellung kann nur mit dem Commandline-Tool „sconfig“ geändert werden! Einfach sconfig in einem Eingabeaufforderungs-Fenster eingeben, kurz warten bis die aktuellen Einstellungen angezeigt werden und dann die Option 5 („Windows Update-Einstellungen„) auf „Automatisch“ ändern. Anschließend sconfig mit der Option 15 („Zur Befehlszeile wechseln„) wieder beenden.

Datei per Gruppenrichtlinie auf alle PCs kopieren

Veröffentlicht f.puernerVeröffentlicht in Computer

Das hat mich jetzt länger als gedacht beschäftigt: Die Aufgabe war, eine Verknüpfung auf eine Datei in einer Serverfreigabe auf allen PCs in der Domäne auf den „öffentlichen Desktop“ zu legen.

Die Vorgehensweise ist eigentlich klar und wird auch z.B. in diesem Blogposting gut beschrieben: Ein neues Gruppenrichtlinienobjekt (GPO) anlegen und darin unter „Computerkonfiguration -> Einstellungen -> Windows-Einstellungen -> Dateien“ den Kopiervorgang definieren. Dabei habe ich die Quelldatei als UNC-Pfad („\\SERVERNAME\Freigabename\Dateiname.lnk„) und die Zieldatei als lokalen Pfad  („%PUBLIC%\Desktop\Dateiname.lnk„) angegeben. Bei der Zieldatei ist es wichtig nicht nur den Pfad, sondern den kompletten Pfad inkl. Dateiname anzugeben!
Anschließend noch das neu erzeugte GPO mit einer passenden Organisationseinheit verknüpfen und mit „gpupdate“ sofort aktivieren.

An einem Client-PC ist die Verknüpfung nach manuellem „gpupdate“ aber nicht auf dem Desktop erschienen, sondern im Ereignisprotokoll/Anwendung wurde ein Event 4098 (Warnung) „Group Policy Files“ eingetragen. Im Text dieses Events ist von “ … 0x80070005 Zugriff verweigert …“ die Rede. Eine entsprechende Suche hat mich zu einem weiteren Blogeintrag gebracht in dem die Lösung erklärt war: Da ich den Kopiervorgang als Computer-GPO und nicht als User-GPO definiert habe, muß die Gruppe „Domänencomputer“ Lesezugriff auf die Quelldatei haben, was sie normalerweise nicht hat. Nachdem ich diese Berechtigung (NTFS und Freigabe) vergeben hatte, funktionierte die GPO endlich wie geplant.

 

„Ihr Mac wird konfiguriert“ hängt bei Neuinstallation

Veröffentlicht f.puernerVeröffentlicht in Computer

Gestern habe ich ein MacBook Pro neu aufgesetzt das im Lauf der Jahre durch viele Hände gegangen war. Dazu habe ich es im „Recovery Mode“ (Cmd + R) hochgefahren, mit dem Festplattendienstprogramm die Festplatte gelöscht und anschließend mit „macOS erneut installieren“ eben dies gemacht.

Die Installation lief normal durch und am Ende wurde wie immer der „Setup Assistent“ gestartet, der Informationen wie gewünschter Benutzername, Kennwort, Apple-ID usw. abfragt. Nach dem letzten OK wird ein grauer Bildschirm mit der Überschrift „Ihr Mac wird konfiguriert“ eingeblendet. Darunter ist ein stilisierter Mac zu sehen, auf dessen Bildschirm in drei Schritten Zeilen eingeblendet werden. Anschließend ist die Neuinstallation abgeschlossen – theoretisch.

Tatsächlich blieb der Setup Assistent aber auf dem „Ihr Mac wird konfiguriert“ Bildschirm nach der zweiten Zeile hängen. Die dritte Zeile, die normalerweise nach wenigen Sekunden erscheint, kam nie. Nach einer Stunde Wartezeit habe ich das MacBook Pro abgeschaltet und die komplette Installation erneut durchgeführt, nur um wieder an dieser Stelle hängen zu bleiben.

Die Lösung habe ich in einem Posting im Apple Support-Forum gefunden: Man muß das MacBook Pro an dieser Stelle ausschalten und dann mit Shift+Control+Option+Power einen „SMC-Reset“ durchführen. Diese Vorgehensweise wird auch auf einer Seite der Apple Support-Website beschrieben. Anschließend das MacBook Pro einfach wieder einschalten. Der Setup Assistent wird automatisch erneut gestartet und läuft jetzt ohne Probleme durch.

Probleme mit „Internet Newsgroups“ bei der Deinstallation von Exchange 2010

Veröffentlicht f.puernerVeröffentlicht in Computer

Vor einigen Wochen haben wir einen größeren Kunden zu Office 365 umgezogen. Die bisherigen beiden „on premise“ Exchange 2010 liefen seitdem mit gestoppten Exchangediensten weiter, um bei Bedarf schnell darauf zugreifen zu können.

Jetzt habe ich die beiden Server sauber deinstalliert (und nicht einfach heruntergefahren), um im Active Directory keine ungültigen Verweise auf die ehemalige Exchange-Organisation zu behalten. Entsprechende Anleitungen gibt es im Internet viele, wobei diese oft nicht auf die potentiellen Probleme eingehen. Dieser Blogeintrag war zum Beispiel sehr hilfreich, um die „Arbitration-Mailboxes“ loszuwerden, die das Löschen der Mailbox-Database am letzten Server verhindert haben.

Wirklich problematisch war es am letzten Server die Public Folder Database zu löschen. Dies war nicht möglich, weil ich den letzen öffentlichen Ordner „Internet Newsgroups“ nicht löschen konnte. Diesen Ordner gibt es nur wenn die Exchange Organisation von älteren Exchange-Versionen upgegradet wurde und laut vielen Google-Fundstellen gibt es keinen offiziellen Weg diesen in Exchange 2010 zu löschen. Es wird immer auf „ADSI Edit“ verwiesen um die dann eben nicht leere Public Folder Database aus dem Active Directory zu löschen. Anschließend wäre dann eine Deinstallation von Exchange 2010 möglich.

Ich wollte aber unbedingt vermeiden mit ADSI Edit „per Hand“ im Active Directory Veränderungen vorzunehmen. Letztlich bin ich auf eine ganz banale Lösung gestoßen: Einfach die bis auf die „Internet Newsgroup“ leere Public Folder Database unmounten und dann mit dem Windows Explorer alle Dateien im Verzeichnis der Public Folder Database (hauptsächlich .edb und .log) löschen oder an einen anderen Ort verschieben. Das (dann leere) Verzeichnis selbst muß erhalten bleiben! Anschließend die Public Folder Database wieder mounten. Es wird eine Warnung eingeblendet, dass die benötigten Dateien fehlen und ob man eine neue, leere Database erzeigen möchte. Wenn man das mit „Ja“ beantwortet, erhält man eine leere Public Folder Database, die man problemlos mit der Exchange-Konsole löschen kann. Daraufhin kann dann Exchange 2010 sauber deinstalliert werden.