Weisheiten - der Netz-Weise Blog

Wenn Ihnen der Taschenrechner unter Windows 10 fehlt, könnte das daran liegen, dass Sie alle Windows Apps deinstalliert haben. Denn der Taschenrechner ist seit Windows 10 keine Anwendung mehr, sondern wird als Universal App ausgeliefert. Wenn Sie weiterhin Zugriff auf den Windows Store haben, können Sie den Taschenrechner direkt daraus installieren.

https://www.microsoft.com/en-us/store/apps/windows-calculator/9wzdncrfhvn5

Wenn Sie auch keinen Zugriff auf den Store mehr haben, aber der Taschenrechner vor dem Entfernen bereits bei einem anderen Benutzer installiert war, können Sie mit dem Cmdlet "Get-AppxPackage" die App aus dem fremden Benutzer reinstallieren.Öffnen Sie hierzu eine Powershell mit Admin-Rechten und starten Sie die folgenden Kommandos:

$calc =  Get-AppxPackage -AllUsers -Name Microsoft.WindowsCalculator
Add-AppxPackage -DisableDevelopmentMode -Register $calc.InstallLocation)\AppXManifest.xml

Sollte auch das nicht funktionieren, hilft Ihnen nur, die Store-App von einem funktionierenden Windows zu kopieren und neu zu installieren.

Die Active Directory Domänen-Funktionsebene (Domain Functional Level, DFL) und die Forest-Funktionsebene (Forest Functional Level) sind zwei Begriffe, die oft missverstanden werden. Ich werde hier versuchen, ein wenig Licht ins Dunkel zu bringen.
Die Funktionsebene einer Domäne bzw. eines Forest bestimmt, welche AD-Funktionen genutzt werden können. Mit jeder neuen Version von Windows wurden auch neue AD-Funktionalitäten implementiert, von denen einige durch eine Schemaerweiterung aktiviert werden können, während andere voraussetzen, dass alle Domänencontroller des AD sich auf dem gleichen oder einem höheren Betriebssystemstand befinden. Um sicherzustellen, dass alte und neue DCs miteinander kommunizieren können, muss das System sich auf den kleinsten gemeinsamen Nenner einigen. Daher werden neue Funktionen nicht automatisch freigeschaltet, sondern müssen nach dem Herunterstufen aller alten Domänencontroller manuell aktiviert werden. Dabei unterscheidet man zwischen der Funktionsebene einer einzelnen Domäne - um sie zu ändern, müssen alle Domänencontroller der Domäne auf dem gleichen minimalen Stand sein - und der Funktionsebene des Forest, für dessen Änderung alle Domänencontroller des Forest (also alle Domänen) den Versionsstand erreicht haben müssen, der aktiviert werden soll. Um die aktuellen Funktionsebenen abzufragen, öffnen Sie auf einem Computer, auf dem die AD-Verwaltungstools installiert sind, eine Powershell-Konsole und geben folgende Befehle ein:

(Get-ADDomain).DomainMode
(Get-ADForest).ForestMode

Um sich alle Domänencontroller Ihrer Domäne mit Betriebssystemversion ausgeben zu lassen, verwenden Sie

Get-ADDomainController -Filter * | Select-Object Hostname,Operatingsystem

Für alle Domänencontroller aller Domänen verwenden Sie

Über wenig Dinge liest man so viel falsches wie über den PXE-Netzwerkboot und wie man den DHCP-Server korrekt konfigurieren muss, um einen Computer aus dem Netzwerk zu starten. Für die ungeduldigen hier zuerst die Konfiguration, die Erklärung folgt danach.

Richten Sie einen DHCP-Server ein. Installieren Sie den WDS-Server auf dem DHCP-Server und lassen Sie den WDS-Server die Konfigurationsarbeit auf dem DHCP-Server erledigen. Der WDS-Server wird dann auf dem DHCP-Server selbständig die Option 60 (PXE-Client) setzen. Wenn Sie den WDS-Server auf einem separaten Server installieren, müssen Sie _NICHTS_ weiter tun. Sie müssen auf dem DHCP-Server weder die Option 60 setzen, noch die Option 66 (TFPT-Server) und 67 (Bootfile). Wenn der WDS-Server und die zu installierenden Clients sich nicht im gleichen Netz befinden, muß der WDS-Server allerdings wie ein DHCP-Server im DHCP-Relay-Agent oder bei Cisco als IP-Helper konfiguiert sein. Der Client findet den WDS-Server dann von selbst und bootet aus dem Netzwerk. Tut er das nicht, liegt es nicht an den DHCP-Optionen!

Was genau passiert beim DHCP-Boot?

Wenn Sie einen Computer über das Netzwerk booten möchten, benötigen Sie einen DHCP-Server und einen TFPT-Server. TFPT ist das Trivial File Transfer Protocol, das im Gegensatz zu FTP Daten per UDP überträgt und ohne Authentifizierung funktioniert. Wenn ein Client einen PXE-Boot initialisiert, schickt er einen DHCP-Request ins Netzwerk, zusammen mit der Information, dass er per PXE booten möchten. Der DHCP-Request wird, wenn er einen DHCP-Server erreicht, mit einem DHCP-Offer beantwortet. Die Antwort beinhaltet die angebotene IP-Adresse, sowie weitere DHCP-Optionen. Prinzipiell kann der DHCP-Server über die Option 66 und 67 dem Client auch einen Bootserver sowie ein Bootfile mitschicken, und das wird auch funktionieren, ist aber nicht notwendig und verursacht zusätzlichen Konfigurationsaufwand. Denn der WDS-Server fungiert als DHCP-Proxy. Das bedeutet, dass er die Anfrage des PXE-Clients ebenfalls beanwortet, allerdings schickt er keine IP-Adresse zurück, sondern nur die Option 66 und 67 mit den Bootfiles, die er zur Verfügung stellt. Das Bootfile ermittelt er selbständig aus seiner Konfiguration. Wichtig ist nur, dass der DHCP-Request beim WDS-Server ankommt. Da der DHCP-Request als Broadcast vom Client verschickt wird, muß die Anfrage also, sofern der WDS-Server nicht im gleichen Netzwerk steht wie der Client, ein DHCP-Weiterleitungsdienst wie der IP-Helper auf dem Router das Datenpaket per Unicast an den WDS-Server weiterleiten. Der WDS wird also genauso auf dem IP-Helper eingetragen wie der DHCP-Server selbst.
Die Option 60, die der WDS-Server bei einer gleichzeitigen Installation im IP-Scope des DHCP-Servers setzt, hat eine andere Funktion. Der DHCP-Proxy funktioniert nämlich wie der DHCP-Server und nutzt auch den gleichen Port ( UDP 67). Wenn der WDS und der DHCP auf dem gleichen Server laufen, muß der WDS-Server einen anderen Port verwenden. Er verwendet dann UDP-Port 4011. Damit der Client auch auf Port 4011 hört und die Konfiguration des DHCP-Proxys akzeptiert, wird die Option 60 vom DHCP-Server gesetzt.

Sollte Ihr Client trotz allem nicht vom WDS-Server booten, kann diese eine andere Ursache haben.  Lesen Sie dafür auch den Artikel "Der PXE-Client startet nicht von WDS-Server - No UEFI-compatible file system found"

Gestern bin ich auf ein merkwürdiges Phänomen gestossen. Nach der Installation eines WDS-Server (Windows Deployment Server) wollte der UEFI-PXE Boot nicht funktionieren. Das BIOS gab nur eine Meldung "TFTP-Error" und "No UEFI-compatible File system was found" aus. Der Boot per Legacy-Boot funktionerte aber einwandfrei. Nach einigem Hin- und her habe ich vor Verzweifelung Wireshark installiert. Untenstehend ein beispielhafter Mitschnitt:

Man sieht hier sehr schön, wie der Client eine IP-Adresse angeboten bekommt und auch annimmt (DHCP Ack). Danach startet der Client einen Read-Request per TFTP auf das Boot-File wdsmgfw.efi, das vom Server mit einer File Not Found Fehlermeldung beantwortet wird. Auf unserem Firmeneigenen WDS-Server ist das File vorhanden, wie ich nach kurzer Kontrolle feststellen konnte. Eine kurze Google-Recherche bestätigte dann die Vermutung - das File ist bei der Installation nicht in den Boot-Ordner kopiert worden, wo es aber hätte sein müssen. Ich habe das Phänomen noch nicht bis zum Ende verfolgt, aber ich vermute, der Fehler tritt bei einer Windows Server 2016 RTM-Installation auf.

Um das Problem zu lösen, müssen Sie nur die Datei wdsmgfw.efi in den Ordner "RemoteInstall\Boot\x64" Ihres WDS-Servers kopieren. Sie finden Sie unter %windir%\System32\RemInst\boot\x64\wdsmgfw.efi

Um den Computernamen zu ermitteln, kann man den Kommandozeilenbefehl Hostname verwenden. Es gibt in Powershell aber keine direkte Möglichkeit, den DNS-Namen eines Computers abzufragen. Hier hilft die DNS-Klasse aus dem .Net Framework aus:

Hostname # Zeigt den Netbios-Computernamen an
$ComputerSystem = [System.Net.Dns]::GetHostByName(($env:computerName))

Das zurückgelieferte Objekt hat drei Eigenschaften, Hostname, Aliases und Addresslist

HostName          Aliases AddressList
--------          ------- -----------
DC1.netz-weise.eu {}      {10.1.0.200}

Unter Windows 10 kann es vorkommen, dass das Herunterfahren des Systems einen Neustart auslöst, anstatt das Gerät auszuschalten. Die Ursache ist vermutlich ein fehlerhafter Treiber, der Windows daran hindert, in den Energiesparmodus zu wechseln. Es handelt sich hierbei um eine neue Funktion, die mit Windows 8 eingeführt wurde, und die als Schnellstartmodus bezeichnet wird. Anstatt das System vollständig herunter zu fahren, wird der aktuelle Benutzer nur abgemeldet und das System dann in den Hibernation-Mode (Ruhezustand) versetzt. Im Ruhezustand wird der Inhalt des Arbeitsspeichers in die Datei hiberfil.sys geschrieben und beim Einschalten wieder gestartet. Dadurch muß beim Hochfahren des Systems nicht mehr das Gerät initialisiert werden, sonden es wird nur noch der letzte Zustand geladen, was deutlich schneller geht.

Wenn ein Fehlerhafter Treiber, eine Fehlerhafte Datei oder ein Bug in Windows das Herstellen des Ruhezustands verhindert, schaltet sich der Rechner nicht ab, sondern öffnet sofort wieder das Anmeldefenster. Um das Problem temporär zu lösen, können Sie den Rechner zwingen, komplett herunter zu fahren, indem Sie beim Klicken auf den Eintrag "Herunterfahren" die Shift-Taste gedrückt halten. Alternativ können Sie den Rechner mithilfe der Kommandozeile ausschalten. Erstellen Sie sich dazu ein Batch-Datei (eine Textdatei mit der Endung .cmd oder .bat) und schreiben Sie folgenden Befehl in die Datei:

Shutdown /s /t 0

Der Shutdown-Befehl fährt den Rechner immer komplett herunter, es sei denn, sie geben explizit den Parameter /hybrid mit an.

Um den Fehler zu beheben, stehen Ihnen, je nach Ursache, mehrere Möglichkeiten zu Auswahl. Wenn es sich um ein Problem des Betriebssystems handelt, dass nach einem Update aufgetreten ist, hilft es vielleicht schon, die neuesten Windows-Updates einzuspielen. Hilft das nicht, versuchen Sie die Gerätetreiber zu akutalisieren. Übliche Verdächtige sind die Netzwerkkarte, die Grafikkarte oder die Chipsatztreiber.

Eine Datei umzubenennen ist mit Powershell mit Hilfe des Cmdlets Rename-Item relativ einfach möglich. Sie müssen nur den Namen der Datei und den neuen Namen angeben:

Rename-Item -Path C:\temp\Test.txt -NewName Produktion.txt

Es gibt aber auch die Möglichkeit, mehrere Dateien in einem Rutsch umzubenennen. Hierfür können Sie die umzubennenden Dateien per Pipeline an Rename-Item weiterleiten und neuen Namen über einen Skriptblock definieren:

Get-ChildItem -Path C:\Skripte\*.ps1 | Rename-Item -NewName { $_.basename + ".txt"  }

In diesem einfachen Beispiel werden alle Dateien mit der Endung .ps1 im Ordner c:\Skripte in .txt umbenannt - $_ ist ein Platzhalter für die einzelnen Dateien, .basename beinhaltet den Dateinamen ohne Dateiendung.

"Ein Überblick darüber, wie Powershell Daten ausgibt, und wie sie dieses Verhalten steuern können. Wenn Sie in Powershell Daten an der Konsole ausgeben wollen, stehen Ihnen eine ganze Reihe von Commandlets zur Verfügung. Die wichtigsten sind:

Außerdem gibt es noch das gerne genutzte, aber leider böse Write-Host. Warum Write-Host böse ist, werden Sie gleich verstehen. Die 5 vorgestellten Commandlets haben alle eigene ""Ausgabeströme"" oder Kanäle, in denen die Daten ausgegeben werden. Man kann sich das vorstellen wie 5 parallele Straßen, auf denen der Verkehr geregelt wird. Die Linke Spur ist für LKW vorgesehen, die 2. Spur für Busse, die 3. für Taxen, die 4. für normalen Personenverkehr und die 5. für Einsatzfahrzeugt. Normalerweise sind die Spuren komplett voneinander getrennt, kommen sich also nicht in Gehege. Der normale Ausgabestrom wird auch von der Pipeline genutzt. Daten, die mit Write-Output in den Ausgabestrom geschrieben werden, landen in der Pipeline und können dort weiterverarbeitet werden. Alle anderen Ausgaben (Fehler, Debugmeldungen usw.) landen nicht in der Pipeline, da die Pipeline nur am Standard-Ausgabestrom hängt. Dadurch können alle in der Pipeline nicht benötigten Daten aus Ihr heraus gehalten werden. Genau wie auf einer Straße die Spuren gewechselt werden können, kann man in der Powershell auch Daten umleiten. Dafür gibt es den Umleitungsoperator >&. Vor dem > steht der Strom, der umgeleitet werden soll, hinter dem & steht der Strom, auf den umgeleitet werden soll. Die Ströme sind eindeutig durchnummeriert: 1 Output 2 Error 3 Warning 4 Verbose 5 Debug Das Kommando

$VerboseMessage = Write-Verbose -message "Dies ist eine Ausgabe" -verbose 4>&1

schreibt die Ausgabe des Write-Verbose-Befehls in eine Variable. Geben Sie nur

$VerboseMessage = Write-Verbose -message "Dies ist eine Ausgabe" -verbose

ohne den Umleitungsoperator an, wird die Nachricht ausgegeben, aber nicht in der Variablen gespeichert. (Der Parameter -verbose ist übrigens dafür da, ausführliche Nachrichten überhaupt erst auszugeben. Write-Verbose Ausgaben werden nur angezeigt, wenn die Variable $VerbosePreference auf Stop, Inquire oder Continue gesetzt ist, oder im Commandlet explizit der Parameter -verbose gesetzt wurde.) Das die Ausgabe nur mit dem Zuweisungsoperator 4>&1 gespeichert wird, liegt daran, dass in Variablen immer nur der Standard-Ausgabestrom gespeichert wird. Dadurch werde Fehlermeldungen usw. aus den Variablen heraus gehalten. Wollen Sie alle Ausgaben in eine Datei speichern, so hilft Ihnen die Umleitung *> c:\outputfile.txt Diese Ausgabe leitet sämtliche Ausagen in die Zieldatei um. Aber dummerweise nicht die Ausgaben, die write-host generiert. Write-Host nutzt nämlich keinen der Ausgabeströme, sondern schreibt direkt in die Konsole. Dadurch geht sämliche Kontrolle über die Ausgabe verloren. Nutzen Sie daher am Besten, soweit möglich, immer write-output für Ihre Ausgaben. "

*Update*: Microsoft unterstützt die Verschlüsselung in Hardware seit Windows 10 1903 nicht mehr, da es zu häufig Probleme mit der Implementierung der Hersteller gab.

"So verschlüsseln Sie Ihre Festplatte performant, aber zentral verwaltet Seit Windows 8 unterstützt Bitlocker die Möglichkeit, direkt die Hardwareverschlüsselung der Festplatte zu nutzen. Diese Technik wird von Microsoft als edrive bezeichnet. Dadurch, dass Bitlocker die Daten nicht mehr verschlüsseln muß, bevor er sie auf der Festplatte speichert, bekommt man die Verschlüsselung quasi komplett ohne Performance-Einbußen. Im Gegensatz zur reinen FDE-Verschlüsselung (Full Drive Encryption), also der Verschlüsselung direkt durch die Festplatte ohne Bitlocker, kann man die Verschlüsselung aber zentral administrieren. Leider ist das Feature mal wieder bescheiden dokumentiert. Daher habe hier nach einer langen Leidens- bzw. Experimentierphase mal alle Erkenntnisse zusammengetragen. Um Bitlocker mit FDE nutzen zu können, benötigt man zum einen eine Festplatte (SSD), die FDE unterstützt und OPAL 2.0 kompatibel ist. Zwei Modelle, von denen ich das definitv weiß, sind die Crucial M500 und Nachfolgemodelle, sowie die Samsung Evo 840. Zum anderen muß der Computer bereits über UEFI-Bios (ab UEFI 2.3.1) verfügen und UEFI muß aktiviert sein. Der Secure Boot Mode darf laut Crucial nicht aktiviert sein! Um die Hardware-Verschlüsselung nutzen zu können, muß Windows im UEFI-Modus installiert werden. Das passiert automatisch, wenn das BIOS auf UEFI-Boot gesetzt ist. Eine große Stolperfalle: Die Festplatte muß leer und blank sein, wenn Windows die Installation startet. Dafür reicht es NICHT aus, die Partitionen auf der Festplatte im Installationsmenü zu löschen - das habe ich auf dem harten Weg gelernt. Löschen Sie stattdessen die Festplatte mit Diskpart, falls die Platte bereits initialisiert war. Dazu können Sie im Installationsmenü von Windows 8 die Tastenkombination shift-F10 drücken. Dann öffnet sich ein Kommandozeilenfenster. Geben Sie folgende Befehlskombination ein:

List Disk 
-> Finden Sie aus der List Ihre SSD 
Select Disk 
-> Geben Sie die Nummer Ihrer Festplatte an 
Clean
-> löscht die Festplatte ratzekahl leer 

Achtung! Clean heißt, dass die Festplatte komplett komplett gelöscht wird. Die Partitionen genauso wie die Partitionstabellen werden entfernt. Kontrollieren Sie also 3 mal, ob sie den richtigen Datenträger ausgewählt haben. Nun können Sie Windows 8 installieren. Nach der Installation können Sie Bitlocker installieren. Wenn Sie kein TPM (Trusted Platform Module) in Ihrem PC haben, müssen Sie Windows explizit erlauben, die Verschlüsselung mit USB-Datenträger oder Kennwort zu sichern. Starten Sie hierfür GPEdit.msc und öffnen Sie ""Computerkonfiguration -> Administrative Vorlagen -> Windows Komponenten -> Bitlocker Laufwerksverschlüsselung -> Betriebssystemlaufwerke -> Zusätzliche Authentifizierung beim Start anfordern"" und setzen sie den Radiobutton bei aktiviert. Anschliessend klicken Sie auf OK. Um sicher zu gehen, dass Sie wirklich die Hardwareverschlüsselung nutzen, verwenden Sie zur Aktivierung am Besten die Powershell. Starten Sie dafür ein Windows Powershell-Fenster mit Administrativen Rechten und starten Sie folgenden Befehl:

$password = ConvertTo-SecureString -String "Passwort" -AsPlainText -Force
Enable-BitLocker -MountPoint "C:" -HardwareEncryption -PasswordProtector -Password $Password

Wobei Mountpoint dem Laufwerk entspricht, dass Sie verschlüsseln wollen. Gibt es ein Problem mit Ihrer Konfiguration, meldet der Befehl, dass eine Hardwareverschlüsselung nicht möglich ist. Um Bitlocker per GUI zu aktivieren, starten Sie die Systemsteuerung, wählen ""Bitlocker Laufwerkverschlüsselung"" und dann aktivieren für das zu verschlüsselnde Laufwerk. Geben Sie ein Kennwort ein und wählen Sie, wo Sie den Wiederherstellungsschlüssel speichern wollen (Achtung! Wenn Sie den Wiederherstellungsschlüssel verlieren und Ihr Kennwort vergessen, kann bestenfalls der NSA noch Ihre Daten wiederherstellen, wobei selbst das eher unwahrscheinlich ist!). Danach wird eine Systemüberprüfung durchgeführt. Wenn Ihnen Bitlocker da"

"So mounten Sie eine VHD oder VHDX-Datei beim Systemstart von Windows automatisch Windows kann seit Vista virtuelle Festplatten wie normale Datenträger bereit stellen. Um das zu bewerkstelligen, können Sie in die Computerverwaltung -> Datenspeicher -> Datenträgerverwaltung gehen, das Kontextmenü der Datenträgerverwaltung öffnen und auswählen "virtuelle Festplatte anfügen". Alternativ können Sie auch das Powershell-Commandlet Mount-VHD verwenden:

mount-vhd -path C:\vhd\daten.vhdx 

Leider ist der Datenträger nur so lange eingehängt, bis der Computer neu gestartet wird. Wenn Sie die virtuelle Festplatte aber gerne bei jedem Systemstart verfügbar hätten, müssen Sie tricksen. Variante 1: Nutzen Sie das Tool vhd attach. VHD Attach stellt eine grafische Oberfläche für die Verwaltung von VHD-Dateien zur Verfügung, installiert aber auch einen Dienst, der beim Systemstart eine vhd-Datei einhängen kann. Dafür starten Sie VHD Attach, mounten die Festplatte, die sie benötigen, und klicken dann im Menü auf ""Auto-Mounted"". Variante 2: Wenn Sie mehrere Maschinen mit einem Auto-Mount einrichten oder ohne Installation auskommen wollen, hilft Ihnen der Task-Scheduler weiter (Aufgabenplanung im Deutschen). Hier können Sie eine Aufgabe anlegen, die beim Systemstart ausgeführt wird und ein Powershell-Script mit mount-vhd startet. Und als kleine Fingerübung machen wird das gleich mit Powershell und einem geplanten Task. (Mehr zu geschedulten Tasks und Jobs in meinem nächsten Tipp).

$user = new-object -typename System.Management.Automation.PSCredential -argumentlist $Username,$Password 
$action = $jobtrigger = New-JobTrigger -AtStartup 
New-ScheduledTaskAction -Execute 'powershell.exe' -Argument "-noprofile -command mount-vhd -Path 'C:\vhd\daten.vhdx'"
Register-ScheduledTask -TaskName Mount_VHD -Trigger $jobtrigger -Action $action -User "system" -RunLevel Highest

Der Jobtrigger -AtStartup legt fest, dass der Task beim Systemstart ausgeführt werden soll. Mit Register-ScheduledTask wird die Aufgabe im Taskplaner registriert. Die Action ist der Powershell-Aufruf, der das Befehl "Mount-VHD" startet. Erwähnenswert ist noch, dass der Task als Benutzer "System" gestartet wird und damit automatisch administrative Rechte hat. Um den Task als System zu starten, benötigt man allerdings administrative Berechtigungen.