In letzter Zeit beschäftige ich mich wieder intensiv mit dem MDT, um unsere Schulungs-Rechner mit neuen Windows 10 Images zu versehen. Dafür habe ich ein kleine Powershell-Funktion geschrieben, den den Autologon für einen Benutzer setzt (s.u.). Sie kann den Autologon aktivieren. Leider funktioniert die Funktion nicht innerhalb eines Konfigurationsskriptes im MDT, da nach erfolgter Installation das Aufräumskript Scripts\LTICleanup.wsf den Autologon entfernt. Um den Autologon beizubehalten oder ändern zu können, suchen Sie den Text

     '//----------------------------------------------------------------------------
     '//  Clear the autologon registry keys
     '//----------------------------------------------------------------------------

und kommentieren Sie die nachfolgenden Zeilen bis zum nächsten Kommentarblock mit dem ' aus.

function Set-AutomaticLogon
{
<#
.Synopsis
    Enables Windows Autologon or removes it
.DESCRIPTION
    This function enables Windows Autologon via Registry-Keys or disables it. It is similar
    to the Netplwiz.exe Command
.EXAMPLE
    Set-AutomaticLogon -Enabled -Username Student -Password Password
    Adds an Autologon-Key to the Registry.
.EXAMPLE
    Set-AutomaticLogon -Disabled
    Disables the automatic Logon by removing the User-Password and disabling the Logon-key.
#>
param
(
    [parameter(Mandatory=$True,
               ParameterSetName='Enabled')]
    [switch]$Enabled,

    [parameter(Mandatory=$True,
               ParameterSetName='Disabled')]
    [Switch]$Disabled,

    [parameter(Mandatory=$True,
               ParameterSetName='Enabled')]
    [string]$Username,
 
    [parameter(Mandatory=$True,
               ParameterSetName='Enabled')]
    [string]$Password,

    [parameter(ParameterSetName='Enabled')]
    [string]$DomainName = ( Hostname )
)      

    $winLogonKey = 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon'

    If ( $PSCmdlet.ParameterSetName -eq 'Enabled')
    {
        Set-Itemproperty -path $winLogonKey -Name 'AutoAdminlogon' -Value 1
        Set-Itemproperty -path $winLogonKey -name 'DefaultUserName' -Value $Username
        Set-Itemproperty -path $winLogonKey -name 'DefaultPassword' -Value $Password
        Set-Itemproperty -path $winLogonKey -name 'DefaultDomainName' -Value  $DomainName
        Remove-ItemProperty -Path $winLogonKey -Name 'AutoLogonCount' -Force
    }
    Else
    {
        Set-Itemproperty -path $winLogonKey -name 'AutoAdminlogon' -Value 0
        Remove-ItemProperty -Path $winLogonKey -name 'DefaultPassword' -ErrorAction SilentlyContinue
        Remove-ItemProperty -Path $winLogonKey -name 'DefaultUserName' -ErrorAction SilentlyContinue
        Set-Itemproperty -path $winLogonKey -name 'DefaultDomainName' -ErrorAction SilentlyContinue
        Remove-ItemProperty -Path $winLogonKey -Name 'AutoLogonCount' -Force
    }
}

Send-Mailmessage ist ein sehr nützliches Cmdlet, um Emails direkt aus Powershell an einen Mailserver zu senden. Er steht seit Powershell 2.0 zur Verfügung und vermeidet so, dass man sich direkt mit dem [System.net.mail]-Typ herumschlagen muß. Allerdings zeigt das Cmdlet ein sehr merkwürdiges Fehlerverhalten.

Wenn man versucht, Verbindungsfehler abzufangen, ist ein erster vernünftiger Ansatz, einfach auf den Parameter -Errorvariable zurückzugreifen:

Send-Mailmessage -SmtpServer mail.meineFirma.de -Subject 'Warnung' -Body 'Hier kommt die Maus' -From 'Elefant@netz-weise.de' -to 'Maulwurf@netz-weise.de' -ErrorVariable Fehlermeldung
If ( $Fehlermeldung ) { $Fehlermeldung.Exception.Message }

Tritt ein Fehler auf, wird dieser direkt in der Variablen $Fehlermeldung gespeichert. Achtung, bei der Angabe der Fehlervariablen wird kein $-Zeichen angegeben!

Dummerweise funktioniert diese Herangehensweise nicht. Die Variable $Fehlermeldung bleibt immer leer. Also nächster Versuch, Abfragen der Variablen $Error[0], die alle Fehler als Array speichert und im ersten Eintrag mit dem Index 0 immer den letzten Fehler gespeichert hat. Um herauszufinden, ob Send-Mailmessage einen Fehler geworfen hat oder erfolgreich war, kann man über die Standardvariable $? abrufen. $? ist true, wenn der letzte Befehl erfolgreich war, und false, wenn ein Fehler aufgetreten ist.

Send-Mailmessage -SmtpServer mail.meineFirma.de -Subject 'Warnung' -Body 'Hier kommt die Maus' -From 'Elefant@netz-weise.de' -to 'Maulwurf@netz-weise.de'
If ( -not $? ) {  $error[0].Exception.Message }

Dummerweise klappt auch dieser Ansatz nicht. $? gibt zwar korrekt false aus, wenn Send-Mailmessage eine Fehlermeldung ausgibt, aber wieder ist die Fehlermeldung nicht in der Fehlervariablen. Tatsächlich, und das ist das Problem, hat der Programmierer des Cmdlets geschlampt und das Fehlerobjekt offensichtlich nicht sauber ausgegeben. Was hilft ist, den Fehlerausgabestrom in die Standardausgabe umzuleiten und den Fehler von hier aus abzufangen:

$Fehlermeldung = Send-Mailmessage -SmtpServer mail.meineFirma.de -Subject 'Warnung' -Body 'Hier kommt die Maus' -From 'Elefant@netz-weise.de' -to 'Maulwurf@netz-weise.de' 2>&1
If ( $Fehlermeldung ) { $Fehlermeldung.Exception.Message }

Dieser Ansatz sollte so auch bei anderen Cmdlet funktionieren, die die Fehlermeldung nicht sauber zurückgeben.

Weiterführende Links

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/send-mailmessage?view=powershell-5.1

Der Scriptblock in Powershell stellt standardmäßig einen Param-Block zur Verfügung, über den Parameter an Skripte und Funktionen übergeben werden können. Erweiterte Funktionen bieten darüber hinaus einen ganze Reihe von Parameter-Optionen, um das Verhalten der Parameter steuern zu können. Eine manchmal sehr hilfreiche, unbekannte Parameter-Option ist DontShow, mit der man verhindern kann, dass ein Parameter in Intellisense angezeigt wird.Das kann z.B. nütlich sein, wenn man Hilfsfunktionen baut, die allgemein nutzbar (öffentlich) sind, bei denen bestimmte Hilfsparameter aber nur unter ganz bestimmten Spezialfällen sinnvoll sind. Geben Sie bei den Parameter-Optionen einfach DontShow mit an:

function Test-HiddenParam
{
Param(
   [Parameter(DontShow)]
   [string]$hiddenParameter
)

$hiddenParameter
}

Wenn Sie mit "Fremdapplikationen" wie Multifunkitionsdruckern oder aus einem Skript Mails über die Microsoft-eigenen Office 365 Exchange-Server versenden wollen, haben Sie grundsätzlich drei Möglichkeiten: Den anonymen Mailversand, den Versand über ein authentifiziertes Benutzerkonto oder einen dezidierten Connector. In dieser Beschreibung möchte ich mich auf die ersten zwei, weil vermutlich häufigesten, konzentrieren. Den vollständigen Artikel von Microsoft zur Einrichtung aller drei Methoden inklusive des Connectors finden Sie unter "Links" am Ende des Textes.

Die einfachste Variante, um mails zu verschicken, ist ein Postfach in Office 365 anzulegen, also einen neuen Benutzer. Danach können Sie sowohl interne mails (also innerhalb Ihrer O365-Organisation) als auch externe Mails verschicken. Sie verwenden für den Mailversand den Server smtp.office365.com und müssen eine Anmeldung mit Benutzername und Kennwort des Postfachbenutzers durchführen. Hier ein kleines Beispiel mit Powershell:

$Password = Convertto-Securestring -String 'Passwort' -AsPlainText -Force
$credential = New-Object PSCredential("admin@netz-weise.de",$Password)
Send-MailMessage -SmtpServer smtp.office365.com -Port 587 -UseSsl -Subject 'Ein Fehler ist aufgetreten' -Body 'fehler' -from 'admin@mydom.de' -To 'Empfaenger@myDom.de' -Credential $credential

Alternativ kann für den Versand auch Port 25 verwendet werden, bevorzugt ist aber Port 587, der für TLS-Verschlüsselung verwendet wird.

Der Nachteil dieser Variante ist, dass Sie ein Postfach und damit eine Benutzerlizenz benötigen. Außerdem ist die Menge der mails, die pro Minute verschickt werden können, auf 30 eingeschränkt. Alternativ können Sie aber auch direkt versenden, ohne eine Postfach zu verwenden. Diese Variante funktioniert aber nur für internen Mailversand - Office 365 leitet keine Mails an Benutzer außerhalb Ihrer Organisation weiter.

Um direkt mails zu versenden, benötigen Sie zuerst den MX-Endpunkt Ihrer Organisation, den Sie über nslookup oder Powershell direkt abfragen können, oder indem Sie mit administrativen Benutzerrechten das Office-Portal aufmachen (portal.office.com), um dann unter Setup -> Domains die Domäne auszuwählen, an die Sie senden wollen. Hier werden Ihnen dann die DNS-Records angezeigt, die für Ihre Domäne gesetzt sein müssen. Wenn Sie die Kommandozeile bevorzugen und sich nicht anmelden wollen, gibt Ihnen dieser Powershell-Befehl die MX-Records Ihrer Domäne aus:

Resolve-DnsName -Name <IhreDomäne> -Type MX

Anschließend können Sie direkt an den Mailexchanger Ihrer Domäne senden. Eine Authentifizierung ist nicht notwendig, der Versand erfolgt allerdings immer über Port 25. Achten Sie darauf, dass Sie die Verschlüsselung erzwingen, da Ihre Daten sonst unverschlüsselt übertragen werden!

Send-MailMessage -SmtpServer <IhrEndpunkt>.mail.protection.outlook.com -Port 25 -UseSsl -Subject 'Ein Fehler ist aufgetreten' -Body 'Fehler' -from 'admin@mydom.de' -To 'Empfaenger@myDom.de'

Die direkte Variante hat eine Reihe von Nachteilen. Sie können, wie schon beschrieben, nur direkt an Ihre Domäne versenden. Außerdem behandelt Exchange Online Ihre mail jetzt als externe mail und schickt Sie durch den Spam-Filter. Die Wahrscheinlichkeit ist groß, dass Ihre mali als Spam markiert wird. Das passiert bei Intern verschickten Nachrichten (wie im ersten Szenario) nicht. Wenn der Mailversand immer von einer statischen IP aus erfolgt, können Sie aber einen SPF-Record (Sender Policy Framework) im DNS setzen, der Ihre IP als vertrauenswürdig markiert. Der SPF-Record ist vom Typ TXT und hat keinen Hostnamen (@). Der Text enthält die IP des Senders:

SPF v=spf1 ip4:<Static IP Address> include:spf.protection.outlook.com ~all

Haben Sie den SPF-Record nicht gesetzt, müssen Sie Ihre IP aller Wahrschelnlichkeit nach bei Microsoft erst Authentifzieren lassen (bei mir war es so). Gehen Sie dafür auf die Seite https://sender.office.com/ und geben Sie Ihre Adresse ein. Sie müssen außerdem Ihre email-Adresse eingeben, an die dann eine Verifizierungsmail gesendet wird. Danach kann es noch bis zu einer halben Stunde dauern, aber danach sollte der anonyme Versand möglich sein.

Weiterführende LInks

How to set up a multifuctional device or applcation to send email using office 365

Vor kurzem bin ich auf einen interessanten Artikel von Mike Robbins gestoßen, den ich hier noch einmal kurz zusammengefasst wiedergeben möcht.

Variablen haben in Powershell normalerweise nur eine begrenzten Lebensdauer, die vom Scriptblock definiert ist, in dem Sie deklariert wurde. Sobald der Scriptblock beendet wird, in dem eine Variable deklariert wurde, wird auch die Variable wieder freigegeben. Hierzu ein kleine Beispiel:

$TestVariable = 'Hallo vom Script'
function Test-Scope
{
  $TestVariable = 'Hallo aus der Funktion'
  $TestVariable
}
Test-Scope
$Testvariable

Wie sieht die Ausgabe des Skripts aus und was ist der Inhalt der Testvariablen zu den unterschiedlichen Zeitpunkten?

Das Skript gibt diese Ausgabe zurück:

Hallo aus der Funktion
Hallo vom Script

Das liegt daran, dass die Variable $Testvariable im Scriptblock durch die "neue" Variable gleichen Namens "überdeckt" wird. Ruft man die Funktion auf, gibt die Funktion den Inhalt der Variablen aus, die im Scriptblock definiert wurde. Nach Ablauf des Scriptblocks wird die "neue" Variable entfernt und die alte Variable wird wieder sichtbar. Das geschicht, weil die Variablen auf dem "Stack" abgelegt werden, einem Stapel, der immer das oberste Objekt zurückliefert. Wird in der Funktion eine neue Variable gleichen Namens angelegt, liefert der Stack beim Abrufen die oberste Variable zurück. Das bedeutet im Umkehrschluß, dass die Variable $Testvariable, wird Sie im Scriptblock nicht neu definiert, einfach die "alte" Testvariable zurückliefert:

$TestVariable = 'Hallo vom Script'
function Test-Scope
{
  $TestVariable
}
Test-Scope
$Testvariable

Die Rückgabe sieht dann so aus:

Hallo vom Script
Hallo vom Script

Man kann den Gültigkeitsbereich einer Variablen aber auch eplizit angeben, indem man ihn, mit einem Doppeltpunkt getrennt, vor den Variablennamen schreibt. Dabei kennt Powershell drei Gültigkeitsbereicht: Global, Script und local. Um in der Funktion direkt auf die Skriptvariable zuzugreifen, muß man also nur den Gültigkeitsbereich Script angeben:

$TestVariable = 'Hallo vom Script'
function Test-Scope
{
  $TestVariable = 'Hallo aus der Funktion'
  $Script:TestVariable
  $TestVariable
}
Test-Scope
$Testvariable

Und das ist die Rückgabe:

Hallo vom Script
Hallo aus der Funktion
Hallo vom Script

Spannend ist, was in Modulen passiert, denn Module können aus mehr als einem Skript bestehen, aber es gibt keinen Gültigkeitsbereich Modul. Die Lösung: Hier übernimmt der Gültigkeitsbereich Script die Funktion von Modul. Eine Variable, die in einem Teilskript des Moduls angelegt wird, ist in allen Skripten des Moduls sicht- und benutzbar. Wem das nicht reicht, der kann Scopes auch noch "zählen", wobei das aktuell Scope die Ziffer 0 trägt, der direkt darüberliegende Scope die 1 usw.

Eine ausführliche Behandlung von Scopes findet man in der Powershell-Hilfe unter

Get-Help About_scopes

Weiterführende Links

Mike Robbins: What is this Module Scope in Powershell you speak of?

Wenn man in Powershell ein ausführbares Programm starten möchte, kann man das normalerweise machen, indem man den direkten Pfad in der in der Konsole einfach aufruft. Genauso kann man ein Programm in einem Script direkt referenzieren.

C:\programme\7zip\7z.exe

Problematischer wird das, wenn der Pfad, in dem sich das Programm befindet, Leerzeichen enthält. Der Programmpfad muß dann in Anführungszeichen gesetzt werden, wird nun aber als String interpretiert und kann nicht mehr direkt aufgerufen. Powershell gibt stattdessen einfach nur den String zurück.

'C:\Program Files\7Zip\7z.exe'
C:\Program Files\7Zip\7z.exe

Die Lösung bietet der Ausführungsoperator &, der Powershell anweist, den folgenden String direkt auszuführen:

& 'C:\Program Files\7Zip\7z.exe'

Wenn dem Programm aber Parameter übergeben sollen, verhält sich der Ausführungsoperator erst einmal merkwürdig. Gibt man nämlich den Befehl inklusive der Parameter im String ein, erhält man eine Fehlermeldung:

& "'C:\Program Files\7Zip\7z.exe x -oC:\temp\extract C:\temp\archiv.7z"
& : Die Benennung ".\7z.exe x -oC:\temp\extract 'C:\temp\website test\website.7z'" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt.

Der Ausführungsoperator benötigt die auszuführende Datei als einzelnen String. Die naheliegende Lösung ist also, die Parameter als zweiten String zu übergeben:

& "C:\Program Files\7Zip\7z.exe" "x -oC:\temp\extract C:\temp\archiv.7z"
Command Line Error:
Unsupported command:
x -oC:\temp\extract 'C:\temp\archiv.7z'

Tatsächlich müssen alle Parameter einzeln in einem Array übergeben werden, damit der Befehl korrekt ausgeführt wird. Achten Sie darauf, dass die Parameter Kommasepariert aufgelistet sind!

$arguments = "x","-oC:\temp\extract","C:\temp\archiv.7z"
& "C:\Program Files\7Zip\7z.exe" $arguments

Die Ausgabe des Befehls kann aufgefangen werden, indem man sie in eine Variable umleitet:

$Returnvalue = & "C:\Program Files\7Zip\7z.exe" $arguments

Man kann das Problem auch vermeintlich elegant mit Start-Process lösen:

Start-Process -FilePath C:\Program Files\7Zip\7z.exe -ArgumentList 'x -oc:\temp\extract C:\temp\archive.7z' -NoNewWindow -Wait

Das hat allerdings einen anderen Haken, denn die Rückgabe von 7z.exe kann nicht mehr aufgefangen werden, da Start-Process eine eigene Konsole startet. Möchten Sie die Rückgabe unterdrücken, indem Sie sie z.B. in die Variable $null umleiten, funktioniert das mit Start-Process nicht:

$null = Start-Process -FilePath C:\Program Files\7Zip\7z.exe -ArgumentList 'x -oc:\temp\extract C:\temp\archive.7z' -NoNewWindow -Wait

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21

Scanning the drive for archives:
1 file, 117778 bytes (116 KiB)

Extracting archive: C:\temp\archive.7z
[...]

Beim Übergeben der Parameter müssen Sie außerdem noch den Sonderfall betrachten, dass auch in den Pfaden der Argumente Leerzeichen stehen können. Da der String selber schon mit " (Doppelten Anführungszeichen) markiert ist, kann man nicht einfach Anführungszeichen um den Pfad setzen, sonden muß Sie für Powershell als nicht interpretierbare Zeichen markieren. Das geschieht mit Hilfe des ` (Backtick oder für die Französischfreunde: Der Accent Graph):

$arguments = "x","-oC:\temp\extract","`"C:\temp\mein archiv.7z`""
& "C:\Program Files\7Zip\7z.exe" $arguments

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.

Rename-Item kann aber auch mit regulären Ausdrücken umgehen. Das kann hilfreich sein, um nur Dateien umzubennen, die einem bestimmten Muster entsprechen. Verwenden Sie dazu im Skriptblock den Operator -replace, um den neuen Namen anzugeben. Möchten Sie Beipsielsweise alle führenden Zahlen aus einem Dateinamen entfernen, verwenden Sie folgenden Code:

Get-ChildItem -path C:\downloads\ -File | Rename-Item -NewName { $_.name -replace ^'\d{3,}',''  }

$_.name enthält hier den vollständigen Dateinamen. Immer, wenn mindestens drei Zahlen (\d steht für genau eine Zahl, {3,} ist ein Quantifizierer und gibt das Minimale und Maximale Auftreten der Zahl an) am Anfang einer Zeile (^ markiert den Zeilenanfang) gefunden werden, wird das Suchmuster durch den Wert hinter dem Komma ersetzt, in diesem Fall einfach ein Leerstring. Mehr zum Replace finden Sie in der Powershell-Hilfe:

get-help about_comparison_operators -ShowWindow

weiterführende Quellen:
https://www.regular-expressions.info/

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.

Wenn eine fehlerhafte Sytemdatei Schuld ist, öffnen Sie eine Kommandozeile mit administrativen Rechten (CMD im Startmenü eingeben, das Kontektmenü der Eingabeaufforderung öffnen und "Als Administrator ausführen" auswählen) und starten Sie ein Systemdatei-Überprüfung:

sfc /Scannow

SFC steht für System  File Checker und ersetzt Fehlerhafte Systemdateien wieder durch die Originale.

Wenn auch dieser Ansatz fehlschlägt, können Sie den Schnellstartmodus auch über die Windows Einstellungen deaktivieren. Drücken Sie hierfür die Windows-Taste + R und geben Sie powercfg.cpl in das Ausführen-Fenster ein. Im Energieoptionen-Fenster, das sich nun öffnet, wählen Sie oben Links aus dem Menü "Auswählen, was beim Drücken von Netzschaltern geschehen soll" aus. Es öffnet sich ein neues Fenster mit dem Titel "Verhalten des Netzschaltes definieren und Kennwortschutz einschalten". Hier müssen Sie zuerst die erweiterten Einstellungen aktivieren, indem Sie "Einige Einstellungen sind momentan nicht verfügbar" auswählen. Achtung, Sie benötigen administrative Rechte für diese Aktion!

Entfernen Sie jetzt den Haken beim Eintrag "Schnellstart aktivieren (empfohlen)", um den Schnellstartmodus zu deaktivieren. Nun braucht der Rechner beim nächsten Starten ein wenig länger, aber dafür sollte er sich jetzt normal beenden.

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}

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

Ü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"

Links

https://en.wikipedia.org/wiki/Preboot_Execution_Environment

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

(Get-ADForest).Domains | %{ Get-ADDomainController -Filter * -Server $_ } | Select-Object Domain,Hostname,Operatingsystem

Bei den Funktionsebenen handelt es sich um Funktionen, die den Betrieb des AD betreffen. Clients und Mitgliedsserver sind für die Funktionsebenen völlig unerheblich. Wenn Sie also eine Domäne von der 2008er Funktionsebene auf die 2016er-Funktionsebene heraufstufen wollen, müssen alle Domänencontroller unter Windows Server 2016 laufen. Eine Domäne kann vorher nicht heraufgestuft werden! Dabei ist es völlig unerheblich, welche Betriebssystemversion Ihre Clients oder Mitgliedsserver haben. Die können also auf allen übrigen Rechnern noch Windows XP und Windows Server 2003 R2 betreiben, auf Ihre Betriebsfähigkeit hat die Funktionsebene keinen Einfluss. Ich zitiere an dieser Stelle Microsoft:

The answer to the question about the impact of changing the Domain or Forest Functional Level is there should be no impact. If you still have concerns about any third party applications, then you should contact the vendor to find out if they tested the product at the proposed Level, and if so, with what result. The general expectation, however, should be that nothing will change.
https://blogs.technet.microsoft.com/askds/2011/06/14/what-is-the-impact-of-upgrading-the-domain-or-forest-functional-level/

Selten kann es zu Problemen mit Linux-Clients kommen, wenn man die Domäne immer noch im 2003er-Modus betreibt und auf 2008 oder höher wechselt - mit dem Wechsel wird der Kerberos Verschlüsselungsalgorithmus von 3DES auf AES umgestellt. Das Kerberos-Ticket muss dann eventuell neu erstellt werden, was durch einen Neustart des Dienstes (Demons) behoben werden kann. Auch hierzu ein Zitat von Microsoft:

I have not seen any issues with Windows systems, but I have seen issues with Unix/Linux systems that use 3rd party AD integration software. In that case simply recycling the daemon fixed the issue since this caused the application to retrieve new Kerberos tickets.
https://blogs.technet.microsoft.com/askpfeplat/2012/04/09/a-few-things-you-should-know-about-raising-the-dfl-andor-ffl-to-windows-server-2008-r2/

Mehr zur Kerberos-AES-Unterstützung finden Sie unter https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc749438(v=ws.10)

Außerdem kann es beim Upgrade von der 2003er-Funktionsebene zu Problem mit .NET Applikationen kommen, die die DomainEnumeration-Funktion aus dem .NET-Frameworks 3.51 SP1 oder älter verwenden und die Fehlermeldung „The requested mode is invalid“ beim Verbinden mit der Domäne werfen. Hierfür gibt es einen Fix von Microsoft:
https://support.microsoft.com/en-us/help/2260240/fix-the-requested-mode-is-invalid-error-message-when-you-run-a-managed
Dieses Problem sollte inzwischen aber eigentlich nicht mehr auftreten, da selbst Server 2008 inzwischen 10 Jahre alt ist.

Wenn Sie sich fragen, warum Sie denn die Funktionsebene heraufstufen sollen, da bei Ihnen alles prima funktioniert – es gibt mindestens einen guten Grund, denn mit der 2008er-Funktionsebene hat Microsoft den Dateireplikationsmodus der Domänencontroller, über dessen Mechanismus die Gruppenrichtlinien und Anmeldeskripte repliziert werden, von FRS (File-Replication-Service) auf DFS-R (Distributed File Service Replication) umgestellt. Seit Windows Server 2012 R2 und Windows Server 2016 ist FRS jetzt abgekündigt, seit Windows Server 2016, Version 1709 wird es nicht mehr unterstützt. Wenn Sie also den ersten 2019er-Server in Ihre Umgebung aufnehmen wollen, werden Sie auf DFS-R (und damit den 2008er-Modus) umstellen müssen. Davon ab ist der DFS-R Replikationsmechanismus deutlich weniger fehleranfällig und performanter als der FRS-Modus. Eine Anleitung für die Umstellung finden Sie bei  Microsoft unter https://blogs.technet.microsoft.com/filecab/2014/06/25/streamlined-migration-of-frs-to-dfsr-sysvol/https://blogs.technet.microsoft.com/filecab/2014/06/25/streamlined-migration-of-frs-to-dfsr-sysvol/

Der ganze Prozess ist dabei relativ wenig aufwändig. Die notwendige Zeit hängt dabei primär von Ihren Replikationsintervallen ab. Kurz zusammengefasst aktivieren Sie die DFS-R Replikation zuerst parallel in einen zusätzlichen Ordner, prüfen die zuverlässige Replikation und schalten die FRS-Replikation dann endgültig ab.

Ab Windows Server 2008 R2 können sowohl Forest- als auch Domänenfunktionseben wieder heruntergestuft werden, solange der AD-Papierkorb nicht aktiviert wurde. Er ist ein Showstopper, da der Papierkorb nicht wieder deaktiviert werden kann. Außerdem achten Sie darauf, dass der Forestfunktionalitätsmodus immer die minimal mögliche Version des Domänenfunktionsmodus darstellt, oder anders herum gesagt müssen immer erst alle Domänen angehoben worden sein, bevor Sie den Forest hochstufen können – und das gilt natürlich beim Rollback genauso.

Eine Auflistung aller Funktionsebenen, der neuen Features und der Rollback-Möglichkeiten finden Sie unter https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc754918(v%3dws.10)

Zum Herauf- und Herunterstufen verwenden Sie die Cmdlets Set-ADDomainMode und Set-ADForestmode.

Set-ADDomainMode -Identity fabrikam.com -DomainMode Windows2008R2Domain
Set-ADForestMode -Identity fabrikam.com -ForestMode Windows2003Forest

Alternativ können Sie auch AD-Benutzer und Computer bzw. AD Domänen-und Vertrauensstellungen zum Heraufstufen benutzen.
Eine ausführliche Beschreibung zum Heraufstufen der Funktionsebene finden Sie auch unter
https://support.microsoft.com/en-us/help/322692/how-to-raise-active-directory-domain-and-forest-functional-levels

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.

Heute habe ich das neue Kapitel über Group Policy Preferences für die Neuauflage meines Gruppenrichtlnienbuchs beendet. Dabei habe ich ein sehr schönes Beispiel für den Einsatz der Registry-Einstellungen gefunden.

Die Sprachleiste ist in den meisten Fällen ein sehr überflüssiges Feature, denn sie erlaubt das Umschalten zwischen verschiedenen Tastaturlayouts. Welchen Sinn das haben soll, ist mir bis heute verborgen geblieben, denn ich wechsel eigentlich nie mal zwischendurch für ein frischeres Erlebnis auf eine chinesische Tastatur. Trotz allem dürfen wir dieses tolle Feature seit vielen Windows-Generationen genießen. Wenn die Funktion einfach nur da wäre, wäre das ja nicht weiter schlimm, aber dummerweise implementiert Sie auch noch die unseelige Tastenkombination Shift+Alt, die das Tastaturlayout automatisch umschaltet. Wie viele Helpdesk-Tickets aufgrund eines versehentlich aktivierten englischen Tastaturlayouts aufgemacht wurden, möchte ich nicht wissen. Glücklicherweise hat Microsoft in der aktellen Version 1803 von Windows 10 zumindest eine Option vorgesehen, das hinzufügen weiterer Layouts zu überspringen.

Die Sprachleiste wird über die Registry gesteuert, und zwar über den Schlüssel HKEY_CURRENT_USER\Keyboard Layout\Preload. Hier ist für jede Sprache ein Werte hinterlegt, wobei der Wertname der Priorität entspricht, und der Wert selber den Sprachcode bestimmt. Bei ITProToday finden Sie eine Liste der Sprachcodes. Bei mir finden sich zwei Einträge in der Liste:

Der Wert 407 entspricht dem deutschen Layout, 409 ist das US-Englische Tastaturlayout.

Um die Sprachleiste zu entfernen, müssen Sie lediglich den kompletten Schlüssel Preload entfernen. Dies kann mit einem Powershell-Skript einfach erledigt werden, oder mit Gruppenrichtlinen-Einstellungen.

Legen Sie zuerst ein neues Gruppenrichtlinienobjekt an. Anschließend öffnen Sie Benutzerkonfiguration - Einstellungen -  Windows-Einstellungen und legen unter Registrierung ein neues Sammlungselement mit dem Namen DEAKTIVIEREN SPRACHLEISTE an.

Anschliessend legen Sie zwei Registrierungselemente mit folgenden Werten an:

Aktion: Löschen
Struktur: HKEY_CURRENT_USER
Schlüsselpfad: HKEY_CURRENT_USER\KEYBOARD LAYOUT\PRELOAD

Den Schlüsselpfad können Sie über einen Browser heraussuchen, indem Sie die drei Punkt dem Feld Schlüsselpfad anklicken.

Im Prinzip war das schon alles. Um sicherzustellen, dass bei einer Änderung immer die deutsche Tastatur verfügbar ist, wird die deutsche Tastatureinstellung jetzt wieder angelegt. Erzeugen Sie hierfür im Sammlungselement ein zweites Registrierungselement:

Aktion: Ersetzen
Struktur: HKEY_CURRENT_USER
Schlüsselpfad: HKEY_CURRENT_USER\KEYBOARD LAYOUT\PRELOAD
Name: 1
Werttyp: REG_SZ (entspricht einem String)
Wertdaten: 00000407

Seit Windows 8.1 gibt es das administrative Startmenü (im englischen Power User Menü genannt), das man über Windows-Taste+X oder über das Kontextmenü des Startbuttons erreichen kann. Das Startmenü ist ausgesprochen praktisch, wenn es um das Aufrufen von administrativen Werkzeugen geht. Außerdem hat man hier die Möglichkeit, den Rechner sowohl herunterzufahren als auch eine Abmeldung durchzuführen, ohne unterschiedliche Menüs verwenden zu müssen.

Leider gibt es keine Bordmittel, um das Menü anzupassen. Prinzipiell kann man auf manuellem Weg mit ein paar Tricks die Einstellungen vornehmen, um eigene Tools im Menü zu verlinken. Es gibt aber auch einen angenehmen Weg, nämlich den Win+X-Editor. Er kann kostenlos bei WinAero heruntergeladen werden. Achten Sie darauf, dass Sie den richtigen Link erwischen, er ist ein wenig versteckt. Eine kleine Anleitung inklusiver der Handgriffe, die man ausführen muß, um die Anpassungen manuell durchzuführen, finden Sie bei Digital Citizen: All the ways to customize the WinX menu in Windows 10 (and Windows 8.1).

* Mehr zum Thema Gruppenrichtlinien finden Sie auch in meinem Buch Gruppenrichtlinien in Windows 10 und Windows Server 2019, das voraussichtlich im Oktober in der Neuauflage erscheint. *

Jedes Windows 10 Feature-Release bringt neue Funktionen und neue Gruppenrichtlinien mit. Welche Richtlinien in welcher Version neu dazugekommen sind, können Sie im Group Policy Settings Reference-File nachschauen, das Microsoft zum Download anbietet.

Manche Richtlinien sind leider nicht wirklich kompatibel zueinander. Z.B. hat Microsoft mit dem Feature Release 1607 die Nutzungszeit eingeführt und auf 12 Stunden festgelegt. Ab 1703 sind es aber maximal 18 Stunden. Sie können die Nutzungszeit auch per Gruppenrichtlinie festlegen, aber die Maximalwerte von 1703 kann 1607 nicht verarbeiten. Die Lösung sind zwei Gruppenrlichtlinienobjekte (GPOs), die per WMI-Filter "Ihre" Version aussortieren.

Aber auf welchen Wert kann man filtern? Die offizielle Nummer des Feature-Release kann man per WMI-Filter nicht erfragen. Stattdessen kann man aber die Build-Nummer verwenden, die sich mit jedem Feature-Release ändert. Eine Liste der aktuellen Build-Nummern finden Sie bei Wikipedia unter https://en.wikipedia.org/wiki/Windows_10_version_history. In der ersten Tabelle finden Sie in der Spalte Builds die jeweilige Build-Nummer.

Per WMI ermitteln Sie die Build-Nummer über die Klasse Win32_OperatingSystem und die Eigenschaft BuildNumber.

Select BuildNumber from Win32_Operatingsystem Where Buildnumber = '17134'

Achten Sie darauf, dass die Buildnumber leider ein String ist, ein Vergleich mit > also nicht funktioniert! Wenn Sie auf mehrer Versionen filtern wollen, müssen Sie mit Or arbeiten oder mehrere WMI-Abfragen in Ihren Filter aufnehmen.

Select BuildNumber from Win32_Operatingsystem Where Buildnumber = '17134' or Buildnumber = '16299'

* Dies ist ein Auschnitt aus der Neuauflage meines Gruppenrichtlinien-Buchs "Gruppenrichtlinien in Windows Server 2019 und Windows 10, das vermutlich im Oktober 2018 erscheinen wird *

Übermittlungsoptimierung oder Delivery Optimiziation (DO) ist ein neues Feature, das Microsoft mit Windows 10 eingeführt hat, und das die Menge an Daten, die von Windows Update und dem Windows Store heruntergeladen werden, massiv reduziert. Das Verfahren basiert auf Peer To Peer Technologie, Clients teilen bereits heruntergeladene Daten also mit anderen Clients (Peers) im gleichen Netzwerk (oder auch über das Internet). Dafür werden Dateien in Blöcke aufgeteilt, gehashed (es wird eine eindeutige ID erzeugt), und dann Blockweise verteilt anstatt als Monolithische Datei. Damit ein Client tatsächlich nur Original-Daten erhält, sind die Dateien digital signiert, der Client kann also nach Empfang der kompletten Datei prüfen, ob er ein unverändertes Update erhalten hat.

Wenn ein Client ein Update von einem Update-Server herunterladen möchte und die Übermittlungsoptimierung aktiviert ist, erhält er vom Update-Service über die URL *.do.dsp.mp.microsoft.com eine Liste von Rechnern, die bereits Blöcke der Update-Datei bezogen haben. Auf Windows 10 Pro und Enterprise ist die Einstellung dabei standardmäßig so konfiguriert, dass ein PC Daten nur von Peers aus seinem eigenen lokalen Netzwerk empfängt (s. Bild 1.2). Der Update-Service ermittelt über die IP des sich verbindenden Rechners (normalerweise die öffentliche IP des Routers oder Proxys, über den der Client sich verbindet), mit welchen Peers er Daten austauschen darf. Zusätzlich greift der Dienst auf die AD-Standortdaten zurück oder, wenn diese nicht verfügbar sind, auf die Domäne. Man kann diese automatische Gruppierung aber auch überschreiben und manuell festlegen, welche Clients miteinander Daten austauschen dürfen, indem man eine Group-ID festlegt. Die Group-ID wird dann als einziges Kriterium verwendet, um zu ermitteln, welche Clients Daten austauschen dürfen. Das ist wichtig, wenn man bereits mit IPv6 arbeitet (alle Clients haben eine öffentliche IP-Adresse) oder der Zugriff nach außen über Proxy-Arrays oder Load-Balancing stattfindet, so dass ein Standort nicht über eine eindeutige ID verfügt. Die Group-ID ist eine GUID (Globally Unique Identifier), die man z.B. mit dem Powershell-Cmdlet New-GUID zufällig generieren kann.

Die Übermittlungsoptimierung arbeitet höchst effizient und teilt Daten deutlich schneller als die Alternative Branchcache. Sind die Daten erst einmal im lokalen Netzwerk, dauert es nur Sekunden, bis Clients lokale Peers als Quelle verwenden können. Die Daten werden dann mit voller lokaler Netzwerkgeschwindigkeit geteilt. Der Übermittlungsoptimierungsdienst verwendet hierfür Port 7680 im lokalen Netzwerk, für den Datentausch mit Internet-Peers Port 3544 (Teredo-Protokoll, eine IPv6-Übergangstechnologie).

Übermittlungsoptimierung ist vor allem für große Dateien effektiv und kostet außerdem Client-Ressourcen, weshalb Branch-Cache standardmäßig erst aktiviert wird, wenn der Client mindestens über 4 GB RAM und 32 GB freien Speicherplatz auf dem Cache-Laufwerk verfügt. Alle diesen Daten können über Gruppenrichtlinien angepasst werden, die Sie in der Computerkonfiguration unter ADMINISTRATIVE VORLAGEN - WINDOWS-KOMPONENTEN - WINDOWS UPDATE - ÜBERMITTLUNGSOPTIMIERUNG finden.

Die Übermittlungsoptimierung funktioniert übrigens genauso mit WSUS.

Viele weitere Informationen zur Übermittlungsoptimierung finden Sie im Video "Delivery Optimization - a deep dive" von der Ignite 2017 unter https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK2048 oder kurz https://bit.ly/2uFsYv6. Ebenfalls extrem Hilfreich ist die Website von 2Pint-Softwar (Ich mag schon den Firmennamen :-)) https://2pintsoftware.com.

Mehr zu den Gruppenrichtlinieneinstellungen finden Sie unter https://docs.microsoft.com/en-us/windows/deployment/update/waas-delivery-optimization oder natürlich in meinem Buch.

Mehr zum Thema Gruppenrichtlinien finden Sie auch in meinem Buch Gruppenrichtlinien in Windows 10 und Windows Server 2019, das voraussichtlich im Oktober in der Neuauflage erscheint.

Onedrive for Business ist in Office 365 enthalten und wird ein immer spannenderes Werkzeug für die Verwaltung von Benutzerdaten. Mit der aktuellen Version ist es z.B. möglich, die Ordner Bilder, Dokumente und Desktop automatisch in den Onedrive-Ordner zu verschieben. Dadurch können die Benutzerdaten nicht nur geräteübergreifend synchronisiert werden - was ich mit mehreren Rechnern - PC in der Firma, PC zu Hause und Latpop mache und sehr schätze - sondern durch die Versionierung der Sharepoint-Bibliotheken hat man auch gleich ein integriertes Backup, mit dem es möglich ist, alte Daten wiederherzustellen. Darauf weist inzwischen auch der Windows Defender hin, denn durch die Versionierung können Verschlüsselungstrojaner zwar ein Dokument verschlüsseln, aber der Schaden kann einfach durch rückspielen einer alten Version wieder behoben werden.

Die Onedrive-Features können auch durch Gruppenrichtlinien automatisch aktiviert werden, allerdings sind die Onedrive-ADMX Dateien nicht Bestandteil des Office 2016 ADMX-Vorlagen, die man bei Microsoft herunterladen kann. Stattdessen werden die Vorlagen beim Installieren des neuen Onedrive Sync Clients (Onedrive.exe) lokal im Benutzerprofil abgelegt. Achten Sie also darauf, dass Sie, wenn Sie einen neuen Onedrive-Client bereitstellen, immer auch die Vorlagen aktualisieren. Die Dateien liegen unter %LocalAppData%\Onedrive\<Version>\adm. Um es den Administratoren nicht zu leicht zu machen, sind die Dateien allerdings nicht so abgelegt, dass man sie direkt kopieren kann. Stattdessen liegt die englische .adml-Datei direkt im Ordner .adm, die fremdsprachigen .adml-Dateien liegen in teilweise nicht korrekt benannten Ordnern. Bevor Sie die Dateien also in Ihren Policy-Store kopieren, erstellen Sie zuerst einen Ordner en-us im adm-Ordner und kopieren die Onedrive.adml-Datei hinein, und außerdem benennen Sie den Ordner \de um in \de-de. Danach können Sie die Onedrive.admx inklusive der zwei Unterordner \de-de und \en-us in den PolicyStore-Ordner kopieren.

Mehr zu den Einstellungen finden Sie im folgenden Artikel Onedrive for Business Ordner umleiten, manuell und mit Gruppenrichtlinien.

Windows 10 kennt zwei verschiedene Anwendungstypen - die klassischen Anwendungen und Apps. Apps gibt es seit Windows 8, und sie sind vom App-Konzept von Apple und Google übernommen. Apps unterscheiden sich in einigen grundlegenden Dingen von Anwendungen:

• Apps lassen sich von jedem Benutzer bereitstellen - es werden keine administrativen Berechtigungen benötigt
• Eine App wird normalerweise für einen Benutzer bereitgestellt, nicht für den Computer
• Das App-Berechtigungskonzept bietet mehr Sicherheit, da jeder App der Zugriff auf jedes Gerät explizit gesperrt werden kann.
• Apps haben keinen Installer, sondern werden aus dem Microsoft Store oder per Sideloading installiert

Zumindest der letzte Punkt könnte sich ändern, denn Microsoft hat ein neues Format für die automatische Installation entwickelt, nämlich msix. Trotzdem möchte nicht jeder Administrator Apps in seiner Umgebung bereitstellen. Um die bereits mit Windows mitgelieferten Apps loszuwerden, muß man allerdings einige konzeptuelle Dinge verstehen:

Grundsätzlich werden Apps pro Benutzer installiert. Man spricht von Appx-Paketen. Um Appx-Pakete zu verwalten, können Sie Powershell-Cmdlets verwenden:

• Get-AppxPackage listet installierte Apps auf
• Remove-Appxpackage entfernt installierte Apps
• Get-AppxLog zeigt das Installations- und Wartungslog für Apps an.

Sie können alle Apps entfernen, indem Sie die Ausgabe von Get-Appxpackage direkt an Remove-Appxpackage weiterleiten:

Get-AppxPackage | Remove-Appxpackage

Das ist aber nicht empfehlenswert, da Microsoft einige Werkzeuge inzwischen nur noch als Apps ausliefert, wie etwas den Taschenrechner. Entfernen Sie alle Apps, ist auch der Taschenrechner weg. Solange Sie den MIcrosoft Store noch verwenden können, ist das im Übrigen kein Beinbruch, denn der Taschenrechner kann direkt aus dem Store wieder nachinstalliert werden. Besser ist es, Sie exportieren sich eine Liste aller Apps, die Sie entfernen wollen, und benutzen die Liste dann als Input.

Zum Erstellen verwenden Sie am Besten das Cmdlet Out-Gridview mit dem Parameter -Passthru. Out-Gridview kann die Ausgabe eines Cmdlets in einem Fenster darstellen, und mit Passthru bekommen Sie ein Auswahlfenster, in dem Sie einzelne Objekte markieren und weiterleiten können:

Get-AppxPackage | Out-GridView -PassThru | Export-Clixml -Path c:\temp\AppsToRemove.xml

Sie können die Datei dann mit Import-CliXml wieder einlesen und an Remove-AppxPackage weiterleiten:

Import-Clixml -Path C:\temp\AppsToRemove.xml | Remove-AppxPackage

Allerdings werden Sie eventuell ziemlich schnell bemerken, dass Sie die Apps nicht vom Computer entfernt haben, sondern nur aus dem Profil des Benutzers. Alle Windows-Apps sind nämlich provisionierte Pakete, die auf dem System hinterlegt sind und beim ersten Anmelden automatisch installiert werden. Sobald sich ein neuer Benutzer an dem System anmeldet, dass Sie mit Remove-AppxPackage bearbeitet haben, bekommt er alle Apps wieder installiert.

Um die Apps komplett loszuwerden, müssen Sie Get-AppxProvisionedPackage bzw. Remove-AppxProvisionedPackage verwenden. Diese beiden Cmdlets gehören aber zu den DISM-Tools und sind zur Bearbeitung von Windows Images (WIM-Files) gedacht. Sie haben daher zwei Parametersätze (Parameter, die nicht gemeinsam verwendet werden können):

• Get-AppxPackage -Online
• Get-AppxPackage -Path <Path zum gemounteten Wim-Image>

Get-AppxPackage kann Wim-Files, also Windows-Installationsdateien, offline bearbeiten. Sie können also Apps schon vor der Installation aus einem Image entfernen. Dafür müssen Sie ein Wim-Image mit Mount-WindowsImage zuerst in einem Ordner bereitstellen. Dann können Sie die Apps entfernen und die Änderungen anschließend speichern. Das Wim-File finden Sie z.B. auf allen Windows 10 Installations-CDs im Pfad <CD-Laufwerk:>\sources\install.wim. Kopieren Sie die Datei zuerst auf die Festplatte, da Sie auf die CD nicht zurückschreiben können. Dann lassen Sie sich den Inhalt der Datei ausgeben, da in einem Wim-File mehrere Installationspakte stecken können und suchen Sie sich den Index des Image, das Sie bearbeiten wollen. Den Index benötigen Sie zum mounten des Images.

mkdir C:\WimMount
Get-WindowsImage -ImagePath C:\temp\install.wim
Mount-WindowsImage -path C:\WimMount -ImagePath C:\temp\install.wim -Index 3
Get-AppxProvisionedPackage -path c:\WimMount | out-gridview -PassThru |
   Export-Clixml c:\temp\ProvisionedApps.xml
Import-Clixml -Path C:\temp\ProvisionedApps.xml | Remove-AppxProvisionedPackage -Path c:\WimMount
Dismount-WindowsImage -Save

Wenn Sie AppxPakte aus dem laufenden Windows entfernen wollen, nutzen Sie den Parameter -online anstatt -Path. Sie müssen dann keinen Pfad mehr angeben, sondern die Appx-Cmdlets benutzen automatisch den aktuellen Windows-Pfad. Achten Sie aber darauf, dass Sie auch beim Remove-AppxPackage den Parameter -Online mit angeben müssen.

Get-AppxProvisionedPackage -Online | Out-GridView -PassThru | Export-CliXml -Path c:\temp\ProvisionedApps.xml
Import-CliXml -Path C:\temp\ProvisionedApps.xml | Remove-AppxProvisionedPackage -online

Wenn es nur um ein System geht, kann man die provisionierten Apps auch in einem Rutsch entfernen, ohne sie erst in eine Datei zu schreiben:

Get-AppxProvisionedPackage -Online | Out-GridView -PassThru | Remove-AppxProvisionedPackage -online

Achten Sie aber wieder darauf, das bereits installierte Apps durch entfernen der provisionierten Apps nicht mit entfernt werden. Sie löschen nur die Installationsquellen!

Wenn ein Domänen-Computer gestartet wird, sucht er im Netzwerk zuerst nach einem Domänen-Controller, indem der den DNS-Server nach den LDAP-Service-Records seiner Domäne fragt. Anschließend versucht er, mit dem Domänencontroller einen Secure Channel, also eine verschlüsselte, sichere Datenverbindung aufzubauen. Dies geschieht über einen RPC Netlogon. RPC ist ein Challenge-Response-Protokoll, bei dem der Client und der Server sich gegenseitig einen zufälligen 64 Bit-Zufallswert, den Client- bzw. Server Challenge, zuschicken, aus denen mit Hilfe des Computerkennworts (wegen gegenseitige Authentifizierung sowohl auf dem Client als auch auf dem Server) ein Session-Key berechnet wird. Das funktioniert, weil sowohl der Client als auch der Domänencontroller über das Computerkennwort des Clients verfügen. Wenn der Domänencontroller und der Client nicht das gleiche Kennwort gespeichert haben, schlägt die Erstellung des Secure Channels allerdings fehl und dem Client wird die Verbindung zum Domänencontroller verweigert. Stattdessen wird eine Fehlermeldung angezeigt, die vermutlich jeder Administrator schon einmal gesehen hat: „The trust relationship between this workstation and the primary domain failed” bzw. "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden".

Wie und wo wird das Computerkennwort verwaltet

Der Client generiert beim Aufnehmen in die Domäne ein komplexes Kennwort, dass er ab Windows 2000 alle 30 Tage automatisch ändert. Da Computerkonten sind von den Kennwortrichtlinien der Domäne ausgenommen sind, können Sie auch nicht gesperrt werden, wenn sie länger offline sind.
Die Kennwortänderung führt der Client zuerst zuerst lokal aus. Danach ändert er sein Kennwort im AD. Schlägt die Aktualisierung im AD fehl, setzt er wieder das alte Kennwort. Das aktuelle Kennwort und sein Vorgänger werden im geschützten Kennwortschlüssel HKLM\SECURITY\Policy\Secrets\$machine.ACC gespeichert. Im AD sind die Kennwörter in den Attributen unicodepwd und lmpwdHistory abgelegt.
Ob und wie oft der Client sein Kennwort ändert, kann in der Systemregistrierung unter HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters konfiguriert werden. Für die Konfiguration sind drei Schlüssel verantwortlich:

MaximumPasswordAge: Der Eintrag MaximumPasswordAge legt fest, nach welchem Zeitraum der Netlogon-Dienst versucht, das Kennwort zu ändern. Der Standardwert ist 30 (Tage).

ScavengeInterval: Das Scavengeinterval legt fest, wie häufig der Computer prüfen soll, ob das maximale Kennwortalter erreicht ist. Der Standardwert beträgt 900 (Sekunden), also 15 Minuten. Der Eintrag ist nicht in der Registry hinterlegt, kann hier aber geändert werden. Der Typ des Eintrags ist REG_DWORD.

DisablePasswordChange: Sie können die Kennwortänderung des Computers mit diesem Schlüssel auch komplett deaktivieren, indem Sie den Wert auf 1 setzen.

Die aktuelle Konfiguration können Sie mit Regedit oder Powershell abfragen:

Get-Item "HKLM:\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters"

Alternativ kann das maximale Alter und die Änderungsdeaktivierung auch über Gruppenrichtlinien gesetzt werden. Sie finden die Einstellungen unter Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitsoptionen. Die Richtlinien heißen:

Domänenmitglied: Maximalalter von Computerkennwörtern
Domänenmitglied: Änderungen von Computerkennwörtern deaktivieren

Wenn der Secure Channel nicht erzeugt werden kann

Es gibt verschiedene Gründe, warum ein Kennwort nicht mehr stimmt oder der Secure Channel nicht erzeugt werden kann. Hier sind einige:

• Der Computer ist eine VM und wurde aus einem alten Snapshot wiederhergestellt.
• Wenn der Computer nach dem Erstellen des Snapshots sein Kennwort geändert hat, haben der Computer und die Domäne unterschiedliche Computerkennwörter hinterlegt.
• Das Computerkonto wurde im AD manuell zurückgesetzt (Kontextmenü des Computers -> Reset)
• Wenn das Computerkonto zurückgesetzt wird, wird ein neues Kennwort vergeben. Die Kennwörter des Computers und der Domäne stimmen nicht mehr überein
• Die Uhrzeit des Clients und des Domänencontrollers differiere zu stark
• Für die Erstellung des Secure-Channels wird auch die Uhrzeit als Timestamp verwendet. Differieren die Zeiten zu stark, schlägt die Authentifizierung fehl
• Doppelte Computernamen
• Wenn zwei Computer den gleichen Namen verwenden, wird das Kennwort des Computerkontos beim joinen der zweiten Maschine neu gesetzt und die erste verliert die Verbindung zur Domäne.
• Doppelte SIDs
• Wenn ein Computer nach dem Domain-Join geklont wird, ohne das Image vorher per sysprep zurückzusetzen, verwenden beide Maschinen die gleiche SID und das gleiche Computerkonto (und auch den gleichen Namen). Wenn einer der beiden Maschinen das Kennwort ändert, kann die andere Maschine keinen Secure Channel mehr erstellen.
• Wenn ein Computer über 60 Tage lang keine Verbindung zum DC herstellen konnte
• Wenn ein Computer läuft, aber keine Verbindung zur Domäne herstellen kann, versucht er nach dem Standardintervall von 30 Tagen sein Kennwort zu ändern. Nach weiteren 30 Tagen ändert er sein Kennwort ein zweites mal. Das Kennwort, das er als Historie speichert, wird durch das Kennwort überschrieben, dass beim ersten Wechsel nach 30 Tagen vergeben wurde. Damit ist dem Client das Domänenkennwort nicht mehr bekannt. Wichtig, dieses Verhalten tritt nicht auf, wenn der Client die ganze Zeit ausgeschaltet war – beim Einschalten verbindet er sich mit seinem Kennwort, ändert es in der Domäne und alles ist gut.

Zurücksetzen des Computerkennworts

Zum Zurücksetzen stehen Ihnen mehrere Optionen offen.

Computer aus der Domäne entfernen und wieder hinzufügen: Der vielleicht einfachste Weg - entfernen Sie den Computer aus der Domäne (auf dem Computer, nicht im AD!) und fügen Sie ihn wieder hinzu. Das Computerkonto wird neu verbunden, es bleiben also alle Berechtigungen erhalten.

Powershell: Powershell stellt Ihnen sogar zwei Cmdlets zur Verfügung, um das Computerkennwort zurückzusetzen. Hierfür muss der Computer nicht aus der Domäne entfernt werden! Verbinden Sie sich hierfür per RDP mit dem Client und verwenden Sie ein lokales Administratorkonto für die Anmeldung. Anschließend können Sie das Kennwort mit Reset-ComputerMachinePassword oder Test-Computersecurechannel zurücksetzen.

Reset-ComputerMachinePassword -Credential "Ihr Administrator-Konto"

oder alternativ

Test-ComputerSecureChannel -Repair -Credential "Ihr Adminsitrator-Konto"

Wenn Sie sich per Powershell-Remoting verbunden haben, müssen Sie die Anmeldeinformationen per Powershell erstellen, statt sie abzufragen.

$SecPwd = ConvertTo-SecureString -String "Password" -AsPlainText -Force
$cred = New-Object PsCredential("admin",$SecPwd)
Reset-ComputerMachinePassword -Credential $cred

Kommandozeile: Sie können auch den Kommandozeilenbefehl netdom.exe verwenden:

netdom resetpwd /server:DC_NAME /userd:USERNAME / password:PASSWORD

Weiterführende Links

MSDN: Secure Channel Establishment and Maintenance Methods

Netlogon Remote Protocol Dokumentation, pdf

Wikipedia: Challenge–response authentication

Wikipedia: Challenge–response authentication

Ask the Directory Services Team: Machine Account Password Process

Machine Account (AD Computer Object) Password Updates