Windows Server 2016 FTP Server unter IIS 10 funktioniert nicht
Unter Windows Server 2016 scheint es einen Bug in der Firewall bezüglich der ausgehenden FTP-Regel zu geben.
Symptom: Der Verbindungsversuch kommt beim IIS 10.0 an, dieser antwortet aber trotz sauberer Konfiguration nicht.
Umfeld: Firewall ist aktiviert und ausgehender Verkehr wird nicht geblockt. IIS 10.0 legt eine Firewall-Regel für ausgehenden FTP-Verkehr an und aktiviert diese.
Lösung: Deaktivieren Sie die ausgehende FTP-Regel (statt der gesamten Firewall) und schon klappt der Zugriff.
Word Press oder URL Rewrite auf Windows Server 2016 bzw. IIS 10 installieren
Grundsätzlich ist die Installation mit dem Webplattforminstaller eine einfache Angelegenheit. Leider ist die angebotene Software schlecht gepflegt.
Grund warum die Installation nicht klappt ist die Versionskontrolle in URL-Rewrite, die zwar sagt es muss IIS Version 7 oder höher installiert sein, aber mit einem Hexwert a (Version 10) kommt die Installationsroutine wohl nicht zurecht. Der Trick ist einfach:
Ändern Sie die Versionsnummer von IIS in der Registry von a auf 7 unter:
HKLM:\Software\Microsoft\InetStp\MajorVersion
Danach lässt sich URL-Rewrite problemlos installieren. Ebenso Wordpress, dass URL-Rewrtie benötigt wird dann bei der Installation nicht mehr meckern.
Zum Abschluß sollten Sie aber nicht vergessen, in der Registry unter besagtem Key wieder ein a einzutragen.
PowerShell 5 fehlende Help about Informationen
In PowerShell 5.0 gibt es einen Fehler in update-help. Die „about“-Files werden zwar heruntergeladen, haben jedoch den falschen Namen. Daher werden diese nicht angezeigt, wenn man help about eintippt. Die „about“-Files, haben nur die Dateinamenerweitung .txt müssten aber .help.txt haben.
Lösung:
Get-ChildItem C:\Windows\System32\WindowsPowerShell\v1.0\en-US\*.txt | ? {$_.name -notlike „*.help.txt“} | % {Rename-Item $_.name $_.name.insert($_.name.indexof(„.“),“.help“)}
bzw. für die Deutschen Help-Files:
Get-ChildItem C:\Windows\System32\WindowsPowerShell\v1.0\de-DE\*.txt | ? {$_.name -notlike „*.help.txt“} | % {Rename-Item $_.name $_.name.insert($_.name.indexof(„.“),“.help“)}
XML-Abfrage Ereignisanzeige
Die Filter für die Windows Ereignisanzeige (Eventlog) sind sehr mächtig geworden. Mit den standard Optionen in der grafischen Oberfläche kann man schon viel machen, aber leider nicht im Nachrichtentext filtern. Das geht auch mit XML Abfragen. Klicken Sie dazu zunächst einmal auf ein ähnliches Ereignis und klicken Sie dort die Detailansicht an. Dort wählen Sie XML View:
Dann erstellen Sie einen benutzerdefinierten Filter und wählen dort den Reiter XML. Setzen Sie das Häkchen bei Abfrage manuell bearbeiten. Wenn Sie bereits bei Filter Reiter Einstellungen gemacht haben, sind diese auch schon im XML hier vordefiniert. Haben Sie z.B. das Anwendungslog ausgewählt steht dort:
<QueryList>
<Query Id=“0″ Path=“Application“>
<Select Path=“Application“>*</Select>
</Query>
</QueryList>
Oben habe ich Sie den XML-View auswählen lassen. Warum? Dort sehen Sie, wie die jeweiligen Felder nach denen Sie suchen können benannt sind. Um nun also z.B. nach dem Benutzernamen zu suchen ergänzen Sie die XML Zeilen wie folgt:
<QueryList>
Id=“0″ Path=“Security“>
<Select Path=“Security“>*</Select>
*[EventData[Data[@Name=‘TargetUserName‚] and (Data=‘s‚)]]
</Select>
</Query>
</QueryList>
Selbstverständlich dürfen Sie das gerne weiter verkomplizieren:
*[EventData[Data[@Name=’SubjectUserName‘] and (Data=’abc‘ or Data=’123’)]]
Dies würde alle mit der Angabe abc oder 123 finden bei UserName finden.
Möchten Sie in mehreren Logs suchen:
<Select Path=“Security“>*[System[(EventID=’1234′)]]</Select>
<Select Path=“Application“>*[System[(EventID=’4321′)]]</Select>
Würde alle Ereignisse aus dem Eventlog Security mit der ID 1234 und alle Ereignisse aus dem Applicationlog mit der ID 4321 anzeigen.
Um die Filter in der PowerShell zu nutzen können Sie die XML-Abfrage genauso in einen String schreiben und mit Get-WinEvent abfragen:
$Query=@“
<QueryList>
Id=“0″ Path=“Security“>
<Select Path=“Security“>
*[EventData[Data[@Name=’TargetUserName‘] and (Data=’s‘)]]
</Select>
</Query>
</QueryList>
„@
$Evts=Get-WinEvent -log Security -FilterXPath $Query -maxevents 1000
In PowerShell Remote-Session auf UNC Netzwerkpfade zugreifen
Hat man Windows Remoting konfiguriert und Enter-PSSession als auch Invoke-Command klappen problemlos, fängt man an diese tollen Möglichkeiten rege zu nutzen. Ab und an will man dann aber vielleicht auch einmal aus so einer Remote-Session heraus auf einen Netzwerkpfad in Form von \\Servername\Freigabename zugreifen und man bekommt immer so nette Fehlermeldungen wie:
Get-ChildItem : Cannot find path ‚\\Servername\Freigabename‘ because it does not exist.
+ CategoryInfo : ObjectNotFound: (\\Servername\Freigabename:String) [Get-ChildItem], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
Doch der Server ist online und wenn Sie am entfernten Computer lokal angemeldet versuchen darauf zuzugreifen ist alles fein. Was läuft hier schief? Das ist wieder einmal so ein „Sicherheitsfeature“.
Der Quick and Dirty Way ist einfach mit:
net use n: \\Servername\Freigabename
eine Netzlaufwerksverbindung herzustellen (tolle Sicherheit). New-PSDrive und andere Experimente können Sie sich sparen…habe ich alles schon ausprobiert. N: können Sie dann ganz normal ansprechen. Nun der offizielle Weg:
Mittels Gruppenrichtlinien müssen Sie unter Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Remote Management (WINRM) bei den Unterpunkten WINRM Client als auch WINRM Service „Allow CredSSP authentication“ aktivieren. Des Weiteren müssen Sie unter Computer Configuration\Policies\Administrative Templates\System\Credentials Delegation die beiden Einträge Allow Delegating Fresh Credentials und noch einmal der Eintrag mit Allow Delegating Fresh Credentials with NTLM-only Server Authentication mit so einem Eintrag schmücken:
wsman/NameDesRechnersAufDenSieSichRemoteDraufSchaltenMöchten
Diese Policy muss an eine OU gehängt werden welche die Computer enthalten von denen aus Sie Enter-PSSession bzw. Invoke-Command ausführen möchten.
Haben Sie keine GPOs (z.B. weil kein AD) dann geht es auch in der PowerShell auf den einzelnen Systemen (aber nicht remote 😉 ) mit:
Enable-WSManCredSSP –Role Server
und
Enable-WSManCredSSP –Role Client -DelegateComputer NameDesServers
Um sich dann mit dem Server zu verbinden, müssen Sie die zusätzlichen Schalter -cred und -auth mit angeben. Zuvor sollten Sie sich allerdings die Anmeldeinformationen in einer Variablen hinterlegen, z.B. so:
$cred=get-credential
Dann können Sie Ihr eigentliches Enter-PSSession in dieser Form ausführen:
Enter-PSSession Remoteserver -cred $cred -auth credssp
Verrückte Welt! Ich nehme net use 😉
Fehler in der Beschreibung der PowerShell von get-help about_Advanced-Funktionen
In PowerShell kann man übergebene Parameter durch die PowerShell selbst überprüfen lassen. Das ist cool! Leider hat sich in der Beschreibung zur Überprüfung von Strings (Texten) ein Fehler in about_Advanced-Funktionen eingeschlichen. Im about File steht:
Param
(
[parameter(Mandatory=$true)]
[String[]]
[ValidateRange ("Sven", "Monica", "Christian")]
$UserName
)
$UserName
Richtig ist:
Param (
[parameter(Mandatory=$true)]
[String[]]
[ValidateSet("Sven", "Monica", "Christian")]
$UserName
)
$UserName
Achtung!!! Nicht nur das Wort Range ist durch Set auszutauschen, sondern nach dem Wort Set darf auch kein Leerzeichen zu der nachfolgenden ( stehen. Dann funktioniert es auch mit dem Aufruf. Speichern Sie den Textschnipsel z. B. direkt als test.ps1 ab. Wenn Sie dann das Skript mit Parameter starten, gibt’s bei der ersten Variante die gewünschte Fehlermeldung der Shell und in der zweiten ist der übergebene Parameter ja aufgelistet und er wird entsprechend ausgegeben.
.\test.ps1 blabla
.\test.ps1 Sven
Microsoft Outlook Configuration Analyzer Tool 2.11
Das Microsoft Outlook Configuration Analyzer Tool 2.1 führt eine Analyse Ihrer Outlook Profile durch und hilft bei Problemen.
WINSAT liefert „Mondwerte“
Wenn winsat zuverlässige Werte liefern würde, wäre es echt ein cooles Tool. Winsat ist ein Windows Bordmittel um auf der Kommandozeile Leistungsdaten von CPU, Festplatte und vielen anderen Dingen zu erfassen. Das habe ich doch gleich einmal an einem Einzelplatzsystem ausprobiert:
Hier fällt schon bei den ersten beiden Messungen auf, dass Winsat würfelt. Der erste Test war ein Lesezugriff der 17 Sekunden benötigt hat und dabei angeblich eine Transferrate von 128 MB/s (bitte vergeben Sie mir die Rundungsungenauigkeit 😉 ). Der zweite Test war ein Schreibtest mit derselben Datenmenge auf demselben Laufwerk. Der braucht wie erwartet länger, als der Lesetest nämlich 37 Sekunden, also 20 Sekunden mehr. Witzig daran ist, dass der Durchsatz dabei angeblich auf stolze 435 MB/s gestiegen ist. Eine Festplatte, die 4 x so schnell schreibt wie liest. Ich glaube ich sollte meinen PC patentieren lassen oder einem Museum übergeben. Das Beste daran ist, das er sogar auf 1464 MB/s hoch geht. Schade ist nur, dass die Werte wohl kaum der Realität entsprechen.
Probleme mit der Outlook-Konfiguration
Bei Problemen mit Outlook 2003, 2007 oder 2010 hilft ggf. OCAT 2.0 das Microsoft Outlook Configuration Analyzer Tool weiter.
Tastatur schreibt plötzlich Englisch
Wenn Sie aus heiterem Himmel Englische Tastatureinstellungen haben (z.B. z und y vertauscht), dann liegt das mit größter Wahrscheinlichkeit daran, dass Sie die Alt und die Großschreibtaste (Shift) gleichzeitig gedrückt haben. Machen Sie das einfach noch einmal und Ihre Tastatur schreibt wieder in Deutsch. Das ist allerdings nur unter Windows so.