– Jan's Cloud – online Gedankenstütze ;)

26. November 2018

Windows Zertifikatsspeicher unter Firefox nutzen Part II

Filed under: Gruppenrichtlinien,Sonstiges — Schlagwörter: , , , , , — Jan Mischo @ 17:54

Hier ein kleines Update zum Beitrag wie der Windows Zertifikatsspeicher im Firefox Browser genutzt werden kann.

Um es ganz kurz zu halten: Mozilla hat dem Firefox ab der Version 60 beigebracht mit Gruppenrichtlinien umzugehen. Yay! 🙂 Dazu einfach die ADMX Templates von github (https://github.com/mozilla/policy-templates/releases) laden und in den zentralen Richtlinienspeicher (PolicyDefinitions Ordner (\\<Domain DNS Name\SYSVOL\<Domain DNS Name>\Policies\PolicyDefinitions)) kopieren. Im Anschluss die Gruppenrichtlinienverwaltung (gpmc.msc) starten, in der Computer- und / oder Benutzerkonfiguration in die administrativen Vorlagen wechseln und Mozilla -> Firefox -> Zertifikate -> Windows Zertifikatsspeicher benutzern -> Aktivieren.

Wie man sehen kann lässt sich die Einstellung „security.enterprise_roots.enabled“ im about:config-Tab nicht mehr ändern und diese erhält durch die Richtlinie den Status „gesperrt“.

Neben der Aktivierung des Windows Zertifikatsspeichers im Firefox können die Richtlinien noch ein wenig mehr wie zum Beispiel die Ausführung von Flash nur auf bestimmten Seiten zulassen oder den Zugriff auf Kamera, Mikrofon und Standort steuern. Eine vollständige Liste gibt es ebenfalls auf github bzw. im ZIP File mit den GPO Templates: https://github.com/mozilla/policy-templates/blob/master/README.md

8. November 2018

Koexistenz Probleme mit Exchange 2010 und 2013 bis 2016

Verschiedene Konstellationen die zu Problemen beim Clientzugriff während der Koexistenz von Exchange 2010 und 2013 bis 2016 führen können

Da ein Großteil unserer (Neu) Kunden jetzt so langsam anfängt Ihre Exchange Server 2010 in den wohlverdienten Ruhestand zu schicken stolpern diese, oder auch ich, immer mal wieder über entsprechende Konfigurationsfehler. Hier mal ein Überblick, was wie zu Problemen führt und wie diese beseitigt werden:

Client Access Array zeigt auf OWA, ECP, EWS URLs und / oder Outlook Anywhere Host (https://blogs.technet.microsoft.com/exchange/2013/05/23/ambiguous-urls-and-their-effect-on-exchange-2010-to-exchange-2013-migrations/):

  1. Den Link bitte aufmerksam lesen! Wer möchte darf auch noch das und das lesen. 🙂
  2. Die Lösung umsetzen und intern sowie extern per Outlook Anywhere mit dem Exchange verbinden
    Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect
    Set-OutlookProvider EXCH -OutlookProviderFlags:ServerExclusiveConnect
    

Sollte das nicht möglich sein, wäre ein anderer Schritt eine weitere Datenbank anzulegen und dort den RpcClientAccessServer auf den Exchange selber zeigen zu lassen sowie im Anschluss die Postfächer in die neue Datenbank zu verschieben. Sobald die User sich mit Outlook in der neuen DB verbunden haben, können diese weiter auf den neuen Exchange Server verschoben werden.

New-MailboxDatabase "Name_der_Datenbank"
Set-MailboxDatabase "Name_der_Datenbank" -RpcClientAccessServer Name_des_Exchange_2010
Get-Mailbox -Server Exchange_2010 | New-MoveRequest -TargetDatabase "Name_der_Datenbank"

Achtung: Speicherplatz beachten! Bzw. vorher gründlich planen. 😉

Die nächste Alternative wäre das ClientAccessArray aus den bestehenden Datenbanken zu entfernen und zu löschen. Sollte Autodiscover nicht funktionieren, müssen alle Outlook Profile von Hand neu eingerichtet werden. Aber Achtung: Auch wenn Autodiscover funktioniert, ist die Chance sehr hoch, dass viele Outlook Profile von Hand neu konfiguriert werden müssen!

 

Outlook Web App (OWA) Proxy von Exchange Server 2016 / 2013 zu Exchange 2010 ohne Funktion (:-( Da hat etwas nicht geklappt.):

Outlook Web App Koexistenz 2010 2016 Da hat etwas nicht geklappt.

Outlook Web App Koexistenz 2010 2016 Da hat etwas nicht geklappt.

 

 

 

 

 

Hier ist mir eben grade noch eine HTTP -> HTTPS Weiterleitung bzw. eine Umleitung auf /owa auf die Füße gefallen. Entsprechende Umleitungen können an diversen Stellen konfiguriert sein:

  1. In C:\inetpub\wwwroot\ die „iisstart.htm“ macht ein <META> Redirect.
    Lösung: Am besten die Standard iisstart.htm wieder bereitstellen oder eine leere.
  2. Eine „web.config“ mit entsprechende Umleitung / entsprechenden Umleitungen in C:\inetpub\wwwroot
    Lösung: web.config aus dem Verzeichnis verschieben. Bzw. Backup erstellen und löschen.
  3. HTTP-Umleitung im Internetinformationsdienste (IIS)-Manager (inetmgr)
    Lösung: HTTP-Umleitung im „inetmgr“ deaktivieren

Neben dem Umleitungs-Problem kann es ebenfalls noch ein Berechtigugnsproblem auf dem virtullen Verzeichnis für ECP und / oder OWA sein:

  1. Internetinformationsdienste (IIS)-Manager (inetmgr) starten und unter der „Default Web Site“ im „ecp“ und „owa“ Verzeichnis prüfen, ob die Windows-Authentifizierung aktiviert ist. Falls nicht, diese aktivieren und im rechten Teil in den „Aktionen“ unter „Anbieter…“ sicherstellen, dass „NTLM“ und „Negotiate“ ausgewählt sind. Siehe Bilder:

Kein Zugriff auf Verschobene Mailboxen (Der Informationsspeicher steht zurzeit nicht zur Verfügung) :

Die beschriebenen OWA (Outlook Web App) Probleme können ebenfalls die Ursache dafür sein, dass ein Zugriff mit Outlook auf ein bereits verschobenes Postfach per MAPI over HTTP bzw. Outlook Anywhere nicht möglich ist. Sollte es hier zu einem „komischen“ und „unerklärlichem“ Verhalten kommen, ggfs. die o.g. Schritte prüfen und durchführen. 🙂

Eine Weitere potenzielle Fehlerquelle könnten komplett vergessene öffentliche Ordner (Public Folders) oder eine nicht erstellte PFProxyMailbox sein (Siehe dazu: https://jans.cloud/2018/07/migration-von-exchange-2010-zu-2016/).

Bei weiteren Problemen / Fehler, die mir über den Weg laufen, werde ich den Beitrag updaten. Generell kann es natürlich nie schaden -> RTFM 😀

7. November 2018

Offloading der Netzwerkkarte mit PowerShell aktivieren

Filed under: PowerShell,VMware,Windows Server — Schlagwörter: , , , , , — Jan Mischo @ 10:27

Ein kleines HowTo um Receive Side Scaling (RSS) sowie sämtliches Offloading der NIC(s) an einem Windows Server zu aktivieren (oder deaktivieren)

Ein Kunde hatte eine leicht vernachlässigte VMware vSphere Umgebung mit dem Stand der ESXi Hosts von 6.0 Update 1. Aufgrund der damals™ auftretenden Netzwerkprobleme, hatte der Kunde sich dazu entschlossen sämtliches Offloading sowie Receive Side Scaling auf den Netzwerkkarten zu deaktivieren. Siehe dazu den VMware KB Artikel 2129176. Nachdem die Umgebung auf einen aktuellen 6.5 Build aktualisiert wurde gab es erneut extreme Netzwerkprobleme. Siehe erneut den VMware KB Artikel 2129176. 😉

Kurzum musste auf diversen Windows Servern die erweiterte Netzwerkkartenkonfiguration angepasst werden. Vorher:

Jetzt folgte ein wenig PowerShell Magic:

# Zum Deaktivieren des Offloading sowie RSS alle Werte (-Value) auf "0" setzen
$RegRoot = "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}"
$RegItems = Get-ChildItem -Path Registry::$RegRoot -Name

foreach ($RegItem in $RegItems) {
    if ($RegItem -ne "Properties" -and $RegItem -ne "Configuration") {
        $RegPath = $RegRoot + "\" + $RegItem
        if ($(Get-ItemProperty -Path Registry::$RegPath | Select-Object -ExpandProperty "ProviderName") -eq "VMware, Inc." -and $(Get-ItemProperty -Path Registry::$RegPath | Select-Object -ExpandProperty "DriverDesc") -eq "vmxnet3 Ethernet Adapter"){
            Set-ItemProperty -Path Registry::$RegPath -Name "*IPChecksumOffloadIPv4" -Value "3" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*LsoV1IPv4" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*LsoV2IPv4" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*LsoV2IPv6" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*RSS" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*TCPChecksumOffloadIPv4" -Value "3" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*TCPChecksumOffloadIPv6" -Value "3" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*UDPChecksumOffloadIPv4" -Value "3" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "*UDPChecksumOffloadIPv6" -Value "3" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "OffloadIpOptions" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "OffloadTcpOptions" -Value "1" -Force
            Set-ItemProperty -Path Registry::$RegPath -Name "OffloadVlanEncap" -Value "1" -Force
        }
    }
}

Die evtl. große Frage: Was macht das Script? Generell recht simepl:

  1. Der Netzwerk-Adapter Zweig der Registry wird festgelet (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}). Siehe dazu die Microsoft Docs: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/system-defined-device-setup-classes-available-to-vendors
  2. Es werden alle Unterschlüssel des Registryzweiges ausgelesen und nacheinander in einer foreach-Schleife durchlaufen.
  3. Im Zweig gibt es neben den interessanten Schlüsseln „0000“ bis „00xy“ noch die uninteressanten Schlüssel „Propertiers“ sowie „Configuration“. Diese werden „aussortiert“.
  4. Der aktuelle Registry-Pfad wird gebaut und auf das Vorhandensein des Keys „ProviderName“ mit dem Wert „VMware, Inc.“ und „DriverDesc“ mit dem Wert „vmxnet3 Ethernet Adapter“ geprüft. (Wir befinden uns ja bei VMware, daher VMXnet3 und VMware Inc.)
  5. Zum Schluss werden die entsprechenden für das Offloading verantwortlichen Reg-Keys mit den passenden Werten geschrieben.

Und voilà:

Da wir uns hier ja im VMware Bereich befinden und es glücklicherweise die PowerCLI von VMware gibt, machen wir uns diese zu Nutze, um das Script auf allen Windows Systemen auszurollen:

$vCenterServer = "Name des VCenter Servers / der VCenter Appliance"
$Cred = Get-Credential

Get-Module -ListAvailable VMWare* | Import-Module

Connect-VIServer -Server $vCenterServer

foreach($VM in Get-VM | Where { $_.Guest -Like "*:Microsoft Windows Server*" }) {
    Write-Host $VM.Name
    Copy-VMGuestFile -VM $VM -Source C:\Install\Scripts\Offloading.ps1 -Destination C:\install\Scripts\Offloading.ps1 -LocalToGuest -GuestCredential $Cred -Force
    Invoke-VMScript -VM $VM -ScriptText C:\Install\Scripts\Offloading.ps1 -ScriptType Powershell -GuestCredential $Cred
}

Erneut, die Frage: Was ist passiert?

  1. Der FQDN des VCenters wird eingelesen, danach wird das Kennwort für einen entsprechenden Windows Benutzer in den VMs abgefragt und schließlich die verfügbaren VMware PowerShell Module der PowerCLI werden aufgelistet und geladen. Die PowerCLI gibt es übrigens >hier<.
  2. Es wird sich mit dem VCenter verbunden.
  3. Erneut geht es in eine foreach-Schleife in der alle Virtuellen Maschinen gesucht werden, die als Gast ein Windows Server OS ausführen.
  4. Völlig unspektakulär wird der VMName ausgegeben.
  5. Vom lokalen Client, auf dem die PowerShell ausgeführt wird, wird das Script C:\Install\Scripts\Offloading.ps1 (siehe oben) in die Gast VM an selbige Stelle kopiert. Dabei werden die anfangs eingegeben Credentials genutzt. „-Force“ wird benutzt, falls das Script schon dort liegen sollte.
  6. Zum Schluss wird das soeben kopierte Script in der virtuellen Maschine ausgeführt.

That’s it. 🙂

25. Oktober 2018

Remotedesktop Blackscreens mit Server 2016

Verschiedene Situationen die mit Terminalservern / VDAs unter Windows Server 2016 zu Blackscreens führen können

In unterschiedlichen Kundenumgebungen mit und ohne Citrix gab es in den letzten Monaten immer wieder Blackscreens bei der Anmeldung von Usern. Bei fast jedem Blackscreen half es nur den entsprechenden Session-Host bzw. die VDA durchzubooten. Hier einmal eine kleine Auflistung, welche Fehler in welchen Konstellationen aufgetreten sind und wie sie sich ggfs. beheben lassen:

  1. Citrix Virtual Apps and Desktops (XenApp / XenDesktop) verursacht in den Versionen 7.15 LTSR bis 7.17 bei Einsatz des User Profile Managers einen schwarzen Bildschirm
  2. Die Abmeldung eines Users mit durchgereichter Smart Card verursacht für sämtliche Neuanmeldungen am betroffenen Host Blackscreens
  3. Mozilla Firefox bringt den Audio-Dienst und AudioDG.exe zum Absturz und Neuanmeldungen landen für längere Zeit (ca. 10 – 20 Minuten) im Blackscreen

zu 1) Hier hilft, im 7.15 LTSR Fall, das Update auf 7.15 LTSR CU2 sowie anschließend die Installation des Hotfixes für den UPM: https://support.citrix.com/article/CTX235399. Sollte man im Blackscreen „gefangen“ sein, dann hilft CTX235100. Für den Fall, dass das Current Release (CR) eingesetzt wird, würde ich auf 7.18 bzw. 7 1808 updaten. So eben (29.10.2018) hat Citrix das CU3 für den Long Term Servie Release 7.15 veröffentlicht und den „Black Screen“ als Fixed Issue angegeben (https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/whats-new/cumulative-update-3/fixed-issues.html):

  • 7.15 LTSR CU2 sessions might launch as a black screen. The issue occurs with sessions running on XenApp and XenDesktop 7.15 LTSR CU2 and 7.17 VDAs when Profile Management is enabled. For more information and a workaround, see Knowledge Center article CTX235100. [LC9648]

zu 2) Dieser Bug wurde mit dem Kummulativen Update KB4103720 und folgenden behoben. In mehreren Fällen musste neben dem Update die Registry noch angepasst werden. Dazu unter

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Cryptography\Calais
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais

jeweils den 32-Bit DWORD „ForceWinStationUnregisterCall“ mit dem Wert 1 anlegen sowie die Sessions-Hosts durchbooten.

zu 3) Nach einem kurzen Case bei Microsoft hat sich ergeben, dass hier eine Deinstallation von Firefox auf den RDSHs / VDAs oder ein Deaktivieren des Audio-Dienstes hilft. Im Technet gibt es dazu einen etwas längeren Thread, mit einem kleinen Script, welches bei einem Kunden stündlich läuft und so „Abhilfe“ schafft. Zusätzlich empfiehlt es sich, die Windows Sounds zu deaktivieren. Dadurch kommt es nicht zum zehn- bis zwanzigminütigem Blackscreen-Loop. Deaktivieren lassen sich die Sounds z.B. per Gruppenrichtlinien-Einstellung Registry:

HKCU\AppEvents\Schemes (Default) REG_SZ .None

Quelle für den Registry Key: https://social.technet.microsoft.com/Forums/en-US/4e3ff4ea-ad23-4dda-b1e9-022f8d76c8e6/remote-desktop-rds-2016-gives-back-screen-on-logon-and-prevents-progression-to-desktop-audiodgexe?forum=winserverTS

REM Terminal Server instability seems to be caused by AudioDG.exe hanging and the Windows Audio
REM  service. Restarting these seems to bring it back up. So hopefully, pre-emptively restarting
REM  them at intervals will prevent it.

net stop Audiosrv
taskkill /F /IM AudioDG.exe
net start Audiosrv

Sollten mir noch weitere Blackscreens unter Terminalserver / Remotedesktopserver / XenApp & XenDesktop bzw. virtual Apps and Desktops auf die Füße fallen, so würde ich hier einfach ergänzen. 🙂

Zuletzt bearbeitet am:
  • 29.10.2018: 7.15 LTSR CU3 Informationen ergänzt.
Older Posts »

Powered by WordPress