– derTest – online Gedankenstütze ;)

16. Oktober 2017

VMware Virtual Guest Tagging unter Hyper-V umsetzen

Wie kann Virtual Guest Tagging unter Hyper-V umgesetzt werden?

Häufig wird Virtual Guest Tagging für Firewalls / Router oder andere Netzwerk-Appliances (Load Balancer, Application Delivery Controller, …) benötigt. Da es unsererseits erste konkrete Pläne zum Ablösen der VMware Umgebung durch Hyper-V gibt, brauchen wir Virtual Guest Tagging unter Hyper-V für unsere gehosteten Netscaler Appliances.

In einer VMware Umgebung lässt sich relativ simpel Virtual Switch Tagging (VST), External Switch Tagging (EST) und Virtual Guest Tagging (VGT) umsetzen. In den meisten Fällen wird es unter VMware auf VST hinauslaufen. Unter Hyper-V wird das VLAN üblicherweise direkt an der virtuellen Netzwerkkarte der VM getagged. In der GUI gibt es leider keine Möglichkeit, Virtual Guest Tagging unter Hyper-V umzusetzen. Hyper-V bringt dafür aber ein entsprechenden PowerShell CMDlet mit: Set-VMNetworkAdapterVlan.

Set-VMNetworkAdapterVlan -VMName <Name der VM> -Trunk -AllowedVlanIdList "1200-1299" -NativeVlanId 1200
Set-VMNetworkAdapterVlan -VMName <Name der VM> -Trunk -AllowedVlanIdList "1200,1300,1400" -NativeVlanId 1200
Set-VMNetworkAdapterVlan -VMName <Name der VM> -Trunk -AllowedVlanIdList "1200-1210,1300,1400" -NativeVlanId 1200

Sofern der Netzwerker keine VLANs auf dem Uplink Trunk vergessen hat, kann auch schon das Tagging in der Gast-VM erfolgen.

Hyper-V in Guest tagging / virtual Guest tagging

Hyper-V in Guest tagging / virtual Guest tagging

13. Oktober 2017

derTest.org jetzt auch in HD – nein per SSL

Filed under: Sonstiges — Schlagwörter: , , , , , , , — testperson @ 12:04

… bzw. eher derTest.org jetzt auch in HD per SSL erreichbar – Juhu!

Da Host Europe scheinbar still und heimlich für die Produkte „WebPack“ den SSL Proxy rausgeschmissen hat und dafür die Möglichkeit bietet erschwingliche Zertifikate zu erwerben, habe ich diesen Umstand doch gleich genutzt und mir bzw. dem Blog derTest.org ein SSL Zertifikat für 30€ / Jahr gegönnt.

Daraufhin noch kurzerhand den HSTS Header (Strict Transport Security Header) in der „function.php“ des Themes hinzugefügt, die Basis URL des Blogs auf https://derTest.org geändert sowie in der .htaccess einen HTTP-Redirect (301, Moved Permanently) eingerichtet…

Functions.php (Relevanter Ausschnitt für HSTS):

...
add_action( 'send_headers', 'tgm_io_strict_transport_security' );
/**
 * Enables the HTTP Strict Transport Security (HSTS) header.
 *
 * @since 1.0.0
 */
function tgm_io_strict_transport_security() {
 
    header( 'Strict-Transport-Security: max-age=157680000' );
 
}
...

.htaccess (Ausschnitt der .htaccess):

...
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
...
</IfModule>

… und siehe da:

derTest.org Qualys SSL Labs A+

derTest.org Qualys SSL Labs A+

Scoring A+ at SSL Labs

Scoring A+ at SSL Labs

11. Oktober 2017

Terminalserver Zwischenablage per User

Filed under: Remotedesktopdienste,Windows Server — Schlagwörter: , , , , , , — testperson @ 08:27

Umleitung der Zwischenablage am Terminalserver pro Benutzer erlauben bzw. verbieten

Die Umleitung der Zwischenablage kann in den Eigenschaften der jeweiligen Sammlung nur für die gesamte Bereitstellung aktiviert oder deaktiviert werden. Möchte man allerdings verschiedenen Benutzern das Umleiten der Zwischenablage verbieten könnte man einfach zwei verschiedene RDS Farmen bereitstellen. Schaut man sich die Gruppenrichtlinien an, wird man vorerst auch nur unter der Computerkonfiguration -> Administrative Vorlagen -> Windows-Komponenten -> Remotedesktopdienste -> Remotedesktopsitzungs-Host -> Geräte- und Ressourcenumleitung fündig. Da wir uns hier allerdings wieder in der Computerkonfiguration befinden, greift diese Einstellung wieder für alle User die auf dem entsprechenden Host angemeldet sind.

Die Richtlinie „Zwischenablageumleitung nicht zulassen“ findet sich allerdings auch an entsprechender Stelle der Benutzerkonfiguration (Benutzerkonfiguration -> Administrative Vorlagen -> Windows-Komponenten -> Remotedesktopdienste -> Remotedesktopsitzungs-Host -> Geräte- und RessourcenumleitungAdministrative Vorlagen -> Windows-Komponenten -> Remotedesktopdienste -> Remotedesktopsitzungs-Host -> Geräte- und Ressourcenumleitung).

Jetzt muss nur noch ein GPO in der Gruppenrichtlinienverwaltung (gpmc.msc) erstellt und mit der entsprechenden Benutzer Organisationseinheit verknüpft werden. Ebenso muss die Sicherheitsfilterung angepasst werden, damit nur die gewünschten User diese Einstellung auf den gewünschten Terminalservern bekommen. Sollten die Terminalserver im Loopbackverarbeitungsmodus (Ersetzen) betrieben werden, bitte untenstehenden Hinweis beachten.

Zwischenablage per User

Zwischenablage per User

 

 

 

 

 

 

  1. GPO erstellen
  2. Registerkarte „Delegierung“ öffnen
  3. „Erweitert…“ klicken
  4. Die Gruppe „Authentifizierte Benutzer“ entfernen, da ansonsten jeder Benutzer an jedem Client diese Richtlinie übernimmt
    Gruppe hinzufügen (In meinem Fall „keine_Zwischenablage“), die die einzuschränkenden Benutzerobjekte enthält -> Lesen + Gruppenrichtlinie übernehmen: Zulassen
    Gruppe hinzufügen (In meinem Fall „RDS-Hosts“), die die Computerobjekte der Remotedesktopsession-Hosts enthält ->Lesen: Zulassen
Zwischenablage per User

Zwischenablage per User

 

 

 

 

 

Im nächsten Schritt sollte dann das GPO bearbeitet werden und die oben genannte Richtlinie in der Benutzerkonfiguration (http://gpsearch.azurewebsites.net/#10702) aktiviert werden.

Jetzt kann das Gruppenrichtlinien Objekt mit der entsprechende OU welche die Benutzerobjekte beinhaltet verknüpft werden.

Gegebenenfalls bietet es sich direkt an, ein weiteres GPO zu erstellen, in dem die Umleitung der Zwischenablage analog für die „restlichen“ Benutzer erlaubt wird.

Loopbackverarbeitungsmodus (Ersetzen):

In diesem Fall muss die Richtlinie natürlich mit der Organisationseinheit verknüpft werden, in der sich die RDS Hosts befinden. Des Weiteren sollte dann im Rahmen der Sicherheitsfilterung, sofern gewünscht, noch den Domänen-Admins sowie den Organisations-Admins die Berechtigung „Gruppenrichtlinie übernehmen“ verweigert werden.

17. August 2017

Get-ADPrincipalGroupMembership Fehler bei Gruppen mit Slash

Fehler beim Auslesen von Gruppenmitgliedschaften mit Get-ADPrincipalGroupMembership bei Gruppen mit „/“ (Slash) im Namen

Bei der Erstellung eines PowerShell Scriptes welches basierend auf Gruppenmitgliedschaften verschiedene Exchange-Eigentschaften der User setzen sollte ergab sich ein Problem mit dem CMDLet Get-ADPrincipalGroupMembership:

Get-ADPrincipalGroupMembership Fehler

Get-ADPrincipalGroupMembership Fehler

 

 

 

 

 

Get-ADPrincipalGroupMembership: Der Client konnte die Anforderung aufgrund ein es internen Fehler nicht verarbeiten. Wenn Sie weitere Informationen zum Fehler erhalten möchten, aktivieren Sie entweder IncludeExceptionDetailInFaults (entweder über das ServiceBehaviorAttribute oder das <serviceDebug>-Konfigurationsverhalten) für den Client, um die Ausnahmeinformationen zurück an den Server zu senden, oder aktivieren Sie die Ablaufverfolgung gemäß der Microsoft .NET Framework 3.0 SDK-Dokumentation, und prüfen Sie die Serverablaufverfolgungsprotokolle.
Bei xxxxx Zeichen:41
+ if ( (Get-ADPrincipalGroupMembership <<<< $User.DistinguishedName) xxxxx ) {
+ CategoryInfo: NotSpecified: (CN=xxxxx\,…xxxxx,DC=xxxxx :ADPrincipal) [Get-ADPrincipalGroupMembership], ADException
+ FullyQualifiedErrorId: Der Client konnte die Anforderung aufgrund eines internen Fehler nicht verarbeiten. Wenn Sie weitere Informationen zum Fehler erhalten möchten, aktivieren Sie entweder IncludeExceptionDetailInFaults (entweder über das ServiceBehaviorAttribute oder das <serviceDebug>-Konfigurationsverhalten) für den Client, um die Ausnahmeinformationen zurück an den Server zu senden, oder aktivieren Sie die Ablaufverfolgung gemäß der Microsoft .NET Framework 3.0 SDK-Dokumentation, und prüfen Sie die Serverablaufverfolgungsprotokolle.,Microsoft.ActiveDirectory.Management.Commands.GetADPrincipalGroupMembership

Dieser Fehler tritt scheinbar auf, sobald der User Mitglied einer Gruppe mit einem „/“ ist. In diesem Fall hieß die Gruppe „02 Lohn / FiBu“. Nach der Umbenennung der Gruppe in „02 Lohn FiBu“ ließ sich das PowerShell Script mit CMDLet Get-ADPrincipalGroupMembership problemlos ausführen.

 

5. Juli 2017

rpm.dll Fehler – Neue Anmeldungen am Terminalserver nicht möglich

Application Error mit Event-ID 1000 – Aufganbekategorie 100 – Fehlerhaftes Modul rpm.dll

Heute gab es zur Abwechslung einmal Probleme mit unserer eigenen XenApp Farm. Frei nach dem Motto „Die Schuster tragen die schlechtesten Schuhe“ 😉

Zur besten Knoppers-Zeit, gegen halb 10, konnten sich keine neuen User mehr an der Farm anmelden. Selbst eine Anmeldung in der Konsole war nicht mehr möglich. Nach einem Neustart der Server sowie einem Blick ins Ereignisprotokoll ergab sich ein Problem mit der svchost.exe_TermService. Beim vollständigen Lesen des Protokolls wurde das Modul rpm.dll aus „C:\Program Files (x86)\Citrix\System32“ bemängelt:

XenApp 7.x VDA rpm.dll Fehler

XenApp 7.x VDA rpm.dll Fehler

 

 

 

 

 

 

 

Wie dem Screenshot zu entnehmen ist, trat der Fehler schon etwas länger auf, wurde aber scheinbar nie bemerkt.. Der Schuster, die Schuhe, siehe oben.

Da unsere Farm so oder so vor dem Update auf die neuste Version 7.14 stand, wurde kurzerhand die neuste VDA (7.14.1) ausgerollt und der Fehler somit behoben. Sollte es zu Problemen mit dem Update der VDA kommen, hier klicken.

 

22. Juni 2017

Citrix Receiver Protokollfehler mit dem Authentifizierungsdienst

Ein Protokollfehler mit dem Authentifizierungsdienst bei der Citrix Receiver Einrichtung (Windows / iOS / Android)

Anfang des Jahres „wollte“ ein Kunde seine in die Jahre gekommene XenApp 6.5 Umgebung ablösen und auf modernere Betriebssysteme updaten. In diesem Zug musste natürlich auch die Citrix Umgebung aktualisiert werden. Das verlief auch alles sehr harmonisch und nach Schema-F ab bis es zur Einrichtung an einem iPad sowie einem externen Arbeitsplatz kam. Am Arbeitsplatz (nicht in der Domäne des Kunden) begrüßte mich nach Eingabe der Server Adresse und Benutzer / Passwort folgende Meldung:

Citrix Receiver Protokollfehler Authentifizierungsdienst

Citrix Receiver Protokollfehler Authentifizierungsdienst

 

 

 

 

 

Das Arbeiten im Receiver for Web und auch HTML5 Receiver war vollkommen problemlos möglich. Ebenfalls konnte im Receiver for Web der Citrix Receiver for Windows über die Schaltfläche „Aktivieren…“ in Betrieb genommen werden. Ebenso konnten am iPad / iPhone in einem Browser die Anwendungen gestartet werden.

Citrix Receiver Aktivieren

Citrix Receiver Aktivieren

 

 

 

 

Nach mehrtägiger / wöchiger / monatiger Fehlersuche (mit dem Citrix Support) konnte ich im Citrix Support Forum eine weitere Lösung neben der Citrix Lösung finden.

Die Citrix Lösung: Storefront deinstallieren und nicht von der ISO neu installieren, sondern das Storefront Setup seperat herunterladen und ausführen. Danach den automatisch generierten Store umbenennen oder benutzen. Wichtig: Den „Default Store“ nach der Installation nicht löschen und einen neuen anlegen! Genau dann bekommt man das oben genannte Problem…

Die Support Forum Lösung: In der web.config (im Ordner C:\inetpub\wwwroot\Citrix\Roaming) die Zeile mit „https://<FQDN>/Citrix/Authentication/auth/v1“ im Abschnitt „<tokenManager>“ suchen

Storefront Roaming web.config

Storefront Roaming web.config (vorher)

 

 

 

 

und die im Screenshot rot markierte Zeile löschen.

Storefront Roaming web.config

Storefront Roaming web.config (nachher)

 

 

 

 

Nach einem „iisreset“ am StoreFront Server ist die Einrichung des Citrix Receivers unter iOS (iPad / iPhone) oder auch im Citrix Receiver for Windows wieder möglich.

Hier noch der Link zur Diskussion im Citrix Support Forum: https://discussions.citrix.com/topic/376304-a-protocol-error-occured-while-communicating-with-the-authentication-service/ bzw. der entsprechende Post https://discussions.citrix.com/topic/376304-a-protocol-error-occured-while-communicating-with-the-authentication-service/page-2#entry1946776

 

21. Juni 2017

Citrix VDA Update 7.x Error

Filed under: Citrix,Windows Server,XenApp — Schlagwörter: , , , , , , , , — testperson @ 09:38

Berechtigungsfehler in der Registry beim VDA Update auf 7.14.1

So.. Nach langer Zeit der Pause bzw. des Arbeitens in mehreren Projekten und dem ein und anderen Urlaub gibt es hier endlich nochmal etwas Neues zu lesen! 🙂

Bei uns im Rechenzentrum stand das Update einer Menge XenApp Server VDAs von Version 7.x auf 7.14 an. Die Vorbereitungen und Tests dazu hielten mich in den letzten sonnigen und heißen Tagen am Arbeiten. Vereinzelt kamen dabei noch Windows Server 2008 R2 sowie überwiegend Windows Server 2012 R2 in den Genuss des Updates. Wie so häufig lief der erste Schwung der Updates vollkommen problemlos ab und es gab keinerlei Komplikationen.

Im zweiten Schwung gab es dann aber, wie sollte es auch anders sein, 3 rebellierende Server (2x Windows Server 2008 R2 / VDA 7.6.3 sowie 1x Windows Server 2012 R2 / VDA 7.11). Im XenDesktop Installer Log (%LocalAppData%\Temp\Citrix\XenDesktop Installer\XenDesktop Installation.log) gab es dann die ersten Hinweise (Zeilen mit $ERR$) auf die verursachende Komponente:

06:38:59.1015 $ERR$ : XenDesktopSetup:Failed to load cached objects System.InvalidOperationException: Die Auflistung wurde geändert. Der Enumerationsvorgang kann möglicherweise nicht ausgeführt werden.
bei System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
bei System.Collections.Generic.List`1.Enumerator.MoveNextRare()
bei Citrix.MetaInstaller.InstallationManager.CalculateComponentInstallOrder(IInstallableComponentGroup group, List`1& prereqs, List`1& downloads, List`1& components, Dictionary`2& hasBeenAdded, ICollection`1 groupsToInstall)
bei Citrix.MetaInstaller.InstallationManager.CalculateComponentInstallOrder(ICollection`1 groupsToInstall)

06:41:44.0170 $ERR$ : XenDesktopSetup:Installation von MSI-Datei ‚IcaTS_x64.msi‘ mit Fehlercode ‚InstallFailure‘ fehlgeschlagen (1603).
06:41:44.0180 $ERR$ : XenDesktopSetup:InstallComponent: Failed to install component ‚ICA für Remotedesktopdienste‘. Installation von MSI-Datei ‚IcaTS_x64.msi‘ mit Fehlercode ‚InstallFailure‘ fehlgeschlagen (1603).
06:41:44.0190 $ERR$ : XenDesktopSetup:Recording installation failure. Installation of the ICA für Remotedesktopdienste failed with error code 1603. Log Path: C:\Users\<der VDA installierende User>\AppData\Local\Temp\Citrix\XenDesktop Installer\MSI Log Files\IcaTS_x64516922318.txt

Das im Logfile aufgeführte Logfile IcaTS_x64 ist leider ziemlich unübersichtlich. Daher habe ich hier erst einmal aufgehört zu forschen und im EventLog mein Glück versucht. Dazu aber gleich mehr. Im oben genannten Log zur VDA Installation findet sich zum Zeitpunkt des Fehlers folgendes:

MSI (s) (B8:08) [06:41:22:197]: Product: Citrix HDX TS (retail) — Error 1402. Could not open key: HKEY_LOCAL_MACHINE32\SOFTWARE\Citrix\EUEM\LoggedEvents. System error 5. Verify that you have sufficient access to that key, or contact your support personnel.

Im Eventlog findet sich zeitgleich und zum Glück etwas übersichtlicher wie im MSI VDA Log:

VDA Installation Fehler Registry

VDA Installation Fehler Registry

 

 

 

 

 

 

Wem der Eventlog ebenfalls zu unübersichtlich ist, der darf auch gerne im Anwendungs-Log nach der Quelle „MsiInstaller“ und „Fehler“ filtern. Da sollte es nicht allzuviel zu finden geben.

Schnell in die Registry und dem <VDA installierenden User> Vollzugriff auf den ENUM Key sowie den LoggedEvents Key jeweils unter HKLM\SOFTWARE\Wow6432Node\Citrix\ erteilen. Als nächstes die Ica_TS_x64.msi von der Installations DVD aus <LW>:\x64\Virtual Desktop Components\TS installieren. Nach dem erforderlichen Reboot kann dann der Rest der Server VDA installiert werden.

1. Juli 2016

Alle Postfächer am Exchange Server nach Größe sortiert auflisten

Filed under: Exchange,PowerShell — Schlagwörter: , , , , — testperson @ 12:55

Exchange Server Postfächer nach Größe sortieren

Hier ein kleiner Code-Schnippsel zum Auflisten aller Mailboxen auf einem Exchange Server:


Get-MailboxStatistics -Server &lt;Exchange_Server&gt; | Sort-Object TotalItemSize -desc | ft TotalItemSize, DisplayName -AutoSize

Für eine schnelle Übersicht über die Maximal- / Minimal- / Durchschnittswerte sowie die Summe aller Postfächer auf dem Exchange Server:


Get-MailboxStatistics -Server &lt;Exchange_Server&gt; | %{$_.TotalItemSize.Value.ToMB()} | Measure-Object -sum -average -max -min

29. Januar 2016

Citrix Receiver und Outlook Anywhere vs. Telekom Navigationshilfe

DNS Probleme durch Telekom Navigationshilfe

An einem neuen Remote-Standort mit einem Telekom DSL Anschluss gab es das „Phänomen“, dass sich Outlook nicht mit dem Exchange Server und der Citrix Receiver sich nicht mit dem Netscaler verbinden lassen wollte. Kurz gesagt, das Problem liegt an der Telekom Navigationshilfe. Diese lässt sich nur im T-DSL Kundencenter deaktivieren:

Telekom Navigationshilfe

Telekom Navigationshilfe

 

 

 

 

 

Das Problem besteht im Fall des Citrix Receivers in der Beacon-Prüfung, ob er sich intern oder extern befindet und somit eine Verbindung über das Netscaler Gateway oder die Load Balancer VIP des Netscalers direkt auf den / die Storefront Server verbindet. Ein guter Beitrag zum Thema Beaconing: http://adamgamble.org/2013/12/09/citrix-storefront-beacons-explained/

Beim Exchange Server / Outlook Anywhere erfolgt die Prüfung intern oder extern durch einen Verbindungsversuch zum internen Exchange Server. Wird dieser nicht gefunden, nutzt Outlook den RPC Proxy. Da die Telekom Navigationshilfe jetzt den internen Host (falsch) auflösen kann, versucht Outlook erst gar nicht den RPC Proxy zu erreichen. Auch hier ein Link zum Thema Exchange und Outlook Anywhere: https://www.msxfaq.de/clients/oaclient.htm

 

 

19. Januar 2016

DotNet 3.5 Quelldateien werden nicht gefunden

Filed under: Windows Server — Schlagwörter: , , , , — testperson @ 16:15

Installation findet DotNet 3.5 Quelldateien nicht

Vor kurzem bin ich bei einem Kunden auf das Problem gestoßen, dass sich das DotNet 3.5 Framework auf einem Microsoft Windows Server 2012 R2 nicht installieren ließ. Nach kurzer Recherche fand sich im Netzwerk des Kunden ein Windows Small Business Server 2011 mit einem installiertem Windows Server Update Service in der Version 3.0 SP2. Hier scheiterte die Installation daran, dass der Server Manager keine Quelle mit den Installationsdateien für DotNet 3.5 finden konnte, obwohl diese explizit angegeben wurden.

DotNet 3.5 Quelle nicht gefunden

DotNet 3.5 Quelle nicht gefunden

 

 

 

 

 

 

 

 

Die Installation von DotNet 3.5 konnte dann durchgeführt werden, nachdem man entweder den Server 2012 R2 auf die öffentlichen Microsoft Update Server im Internet umkonfiguriert oder als deutlich bessere Alternative folgene Gruppenrichtlinie aktiviert:

Computerkonfiguration -> Administrative Vorlagen -> System -> „Einstellungen für die Installation optionaler Komponenten und die Reparatur von Komponenten angeben“

DotNet 3.5 Einstellungen für die Installation optionaler Komponenten

DotNet 3.5 Einstellungen für die Installation optionaler Komponenten

 

 

 

 

 

 

 

 

 

 

 

Older Posts »


Powered by WordPress