TSADMIN das zittern und zuckeln austreiben

TSADMIN.MSC (genial als Remotedesktopdienste-Manager eingedeutscht) hat ein Problem – es ist nicht für Farmen mit zig Servern und tausenden Sessions gemacht. Spätestens bei 600-800 Sessions und einer entsprechenden Logon/Logoffrate ist das Ding unbenutzbar weil die Sessions über WTSWaitSystemEvent live in die Liste eingearbeitet werden – und das kann nicht abgestellt werden (konfigurierbar ist nur Prozessupdatefrequenz).

Glücklicherweise ist das MMC SnapIn in .NET implementiert und nicht obfuscated, d.h. man kann das Ding (%windir%\System32\tsadmin.dll) ganz gut mit z.B. ILSpy disassemblieren und als Visual Studio Projekt speichern.

ILSpy macht im Projekt dann pro Namespace einen Folder, in Microsoft.TerminalServices.Monitor.SnapIn gibt’s eine Klasse TerminalServer.cs – dort finden sich die Methoden die für die Updaterei zuständig sind: StartSessionMonitoring und EndSessionMonitoring. Ich habe einfach als erste Zeile ein return; eingefügt und schon ist Schluß mit zittern und zuckeln.

Um das ganze kompilieren zu können muss man bei ein paar Events noch die add und remove Methoden auskommentieren, weiß nicht warum das Fehler wirft – hat aber auskommentiert bisher keine erkennbaren Folgen. Ein paar Namespaces werden noch nicht von ILSpy eingefügt bzw. sind mehrdeutig (System.Threading.Monitor vor allem) – aber das ist eh täglich Brot für einen .NET Entwickler 🙂

Die DLL die da rauskommt legt man dann auf einem beliebigen Client (ab XP vermutlich, Windows 7 sicher) in ein beliebiges Verzeichnis – zusammen mit WTS.DLL, CERTPICK.DLL und TSADMIN.MSC (von einem RDS-Host oder wenn am Client RSAT installiert ist aus %windir%System32). Damit das SnapIn im neuen Verzeichnis gesucht wird muss man noch unter HKLM\SOFTWARE\Microsoft\MMC\SnapIns in den Keys FX:{3FCE72B6-A31B-43ac-ADDA-120E1E56EB0F} und FX:{321f5192-3295-46ba-9bf1-7a18d8c31322} die Werte ApplicationBase auf das Verzeichnis in dem das neue tsadmin.dll liegt und den Wert Type so ändern dass  PublicKeyToken nicht mehr enthalten ist (hinter Culture=neutral einfach abschneiden) ändern.

TSADMIN.MSC sollte so beim nächsten Start die neue DLL laden und die Sessions nicht mehr laufend aktualisieren. Ich hab für mich dann noch folgende Dinge eingefügt aber das würde hier zu weit gehen:

  • Spalten werden nach Ermittlung der Daten automatisch auf eine passende Breite gebracht damit alles sichtbar ist
  • Filter auf Benutzer, Clients, Server und Prozessnamen
  • Anzeige Anzahl der Listenitems in der Beschreibungsleiste
  • verhindern dass beim Start alle Sessions aller konfigurierten Gruppen ausgelesen werden (sondern erst bei Klick auf eine Gruppe)

Die notwendigen Änderungen dazu spielen sich alle in den Klassen GroupNode, ServerNode und TSManagerForm ab wenn jemand Lust verspürt – und ja, natürlich ist das gänzlich unsupported und böse 😮

2008R2 Bug des Monats

Noch früh im Monat aber was Besseres kommt nicht mehr: Wieder mal ein Grund ein oder zwei Jahre zu warten bevor man eine Windows-Version produktiv einsetzt: Audio capture redirection feature does not work after a second remote desktop connection is created in Windows Server 2008 R2. Rätselhaft wie sowas durch alle Alpha-, Beta-, TAP- und Sonstwas-Programme schlüpfen konnte 😐

Und ja, mit Citrix wär das auch passiert: Bi-Directional Audio Recordings Stop Working when Another Session is Opened or Closed

RemoteApps ohne RDPINIT.EXE am Client

…..funktioneren nicht 😀   Windows 7 Embedded Standard startet RDPINIT.EXE defaultmäßig nicht (warum weiß wohl nur Microsoft) – und damit zeigen RemoteApps ein “interessantes” Verhalten: Starten, anmelden und dann passiert exakt gar nix (für 2-3 Minuten), anschließend schreibt der Terminalserver einen DWM-Event (Fehler 0x40010004, irgendwas mit Desktop composition) und meldet die Session ab. Startet man RDPINIT.EXE vor der RemoteApp läuft alles rund – offensichtlich kommunizieren der RDPINIT-Prozess in der Session mit dem auf dem Client. Startet man dann lokal auch noch RDPCLIP.EXE funktioniert auch das Clipboard Mapping 😮

 

Barcode Scanner, Windows Embedded 7 und die Großbuchstaben

Ausgangslage:

  • HP t510 Thin Client mit Windows Embedded Standard 7 SP1
  • Barcode Scanner Symbol LS2208 USB
  • Terminalserververbindung mit RDP auf Windows Server 2008 R2 SP1

 

Problem:

  • Barcode Scans sollen auf Großbuchstaben konvertiert werden, tun sie aber nicht immer
    (einzelne Zeichen sind klein bzw. fehlt bei Sonderzeichen das Shift)

 

vermutliche Ursache:

  • scheinbar ein Timingproblem, sieht so aus als ob die verschiedenen (simulierten) Tastendrücke für SHIFT und den Buchstaben nicht am Terminalserver ankommen (zumindestens nicht zusammen) – auf einem “normalen” Windows 7 SP1 Rechner (mit entsprechend Dampf auf der CPU) passierts nämlich nicht

 

Workaround:

  • im RDP Client die Kombotasten von “nur wenn in Vollbildschirmmodus” (oder so ähnlich) auf “am Client” umstellen
  • damit geht’s zwar Barcode scannen einwandfrei dafür wird z.B. Strg+Alt+Entf oder Alt-Tab nicht in der Session sondern lokal angewendet was keinen wirklich Sinn macht – braucht man diese oder ähnliche Tastenkombinationen nicht ist das Problem damit gelöst

 

Lösung:

  • RDP8 für Windows 7 installieren
  • zuerst KB2574819 (DTLS, Voraussetzung für den RDP8 Client, Reboot muss nicht ausgeführt werden)
  • dann KB2592687
  • Rebooten, gut ists, Barcodes sind so wie sie sein sollen

 

 

RemoteAssistance nachträglich auf Windows Embedded Standard 7 installieren

Wer kennt das nicht, hunderte Geräte mit einem Image ohne ein bestimmtes Feature deployed (oder so gekauft wenn man das Image nicht selbst erzeugt hat) – manche Features lassen sich nicht wirklich vernünftig nachinstallieren (Bluetooth und 802.1x sind zwei für die ich es persönlich lernen musste :-D) aber RemoteAssistance pfeift einwandfrei; zwar ignoriert das Teil anschließend zwar scheinbar entsprechende Policies die von der Domäne kommen aber in der Not nimmt man alles…

Den grundlegenden Hinweise habe ich von aus dem HP-Forum aber das ist dort ein wenig chaotisch und unnötig offen beschrieben.

Notwendige Schritte:

  1. [optional] lokale Gruppe “Remoteunterstützungsanbieter” anlagen und z.B. Domänengruppe die RA anbieten können soll hinzufügen
  2. WinEmb-RemoteAssistance.cab vom WES7 Distribution Share auf den Client kopieren
  3. DISM /online /add-package /packagepath:<pfad wo das cab liegt>
  4. Reboot (wichtig sonst werden die folgenden Schritte beim nächsten Reboot überschrieben!)
  5. msra.exe.mui von einem deutschen Windows 7 Client aus System32 (wenn 32 Bit) bzw. SYSWOW64 (wenn 64 Bit) auf den Client auf C:WINDOWSSystem32de-DE kopieren (für andere Sprachen halt entsprechend anpassen, englisch wäre en-US)
  6. DCOMPERM.EXE besorgen.
  7. dcomperm.exe -aa {F8FD03A6-DDD9-4C1B-84EE-58159476A0D7} set %COMPUTERNAME%Remoteunterstützungsanbieter permit level:r,l
  8. dcomperm.exe -al {F8FD03A6-DDD9-4C1B-84EE-58159476A0D7} set %COMPUTERNAME%Remoteunterstützungsanbieter permit level:rl,ra

Temporäre Dateien heißen mit Absicht so

Es gibt da eine wunderbare Funktion im .NET Framework welche einem Pfad und Name einer temporären Datei liefert: Path.GetTempFileName() – man sollte den Namen aber auch Ernst nehmen und die temporären Dateien nach Benutzung wieder löschen. Nicht nur weil sonst möglicherweise irgendwann die Platte vollläuft, sondern weil die Funktion nur einen 16 Bit Zähler hat und damit nicht mehr als 65535 Dateinamen ausspuckt (ab dann nur mehr IOExceptions :-D)…..steht übrigens in der Doku, aber wer liest die schon 😎

WindowsPhone Background Agent Test Start

Wenn man am Windows Phone einen Background Agent für Hintergrundupdates hat will man den auch testen (und nicht ca. 30 min warten bis das OS den Agent anwirft) – das ist gut dokumentiert und funktioniert mit

ScheduledActionService.LaunchForTest("MeineApp", TimeSpan.FromSeconds(30))

In der Doku steht allerdings NICHT dass dieser Aufruf wenn das XAP aus dem Store kommt (und damit vermutlich nicht mit einem Developerzert signiert ist) die App unwiederbringlich in den Abgrund zieht – auf der Seite steht lediglich sowas in der Art von “im Produktionscode nicht empfohlen” 😮

WMI-Spaß mit Linq

Wenn man in .NET eine WMI Query erzeugt
ManagementObjectSearcher oWMISearcher = new ManagementObjectSearcher(@"\meinserverrootcimv2", "select * from win32_process");
Dann bekommt mein eine ManagementObjectCollection zurück. Das Blöde: Die ist von Haus aus nicht “Linq-fähig” (warum habe ich verdrängt).

Eine Statement wie folgendes (um die Top 10 Speicherfresser zu ermitteln)

List<ManagementObject> oWMIObjects = (from ManagementObject oMO in oWMISearcher.Get() orderby UInt64.Parse(oMO.Properties["WorkingSetSize"].Value.ToString()) descending select oMO).Take(10).ToList();

geht einfach nicht. Wenn man allerdings Linq sagt was es zu erwarten hat in dem man statt from oMO einfach from ManagementObject oMO nimmt pfeift das Statement einwandfrei 🙂

Source des Wissens, kommt nicht  von mir 😉

Lync 2013 zum pushen bringen

Wer Lync 2013 im Einsatz hat will vermutlich auch auf den mobilen Plattformen dazu (Android, iOS, Windows Phone) immer am letzten Stand (=immer online) bleiben. Android und iOS ab Version 6 braucht dazu coolerweise keinerlei Infrastruktur mehr (abseits eines normalen Access Edge Servers) – das eigene Produkt Windows Phone hingegen schon. Im TechNet gibts dazu einen guten Artikel der folgende Befehle abdeckt:

  • new-cshostingprovider -Identity "LyncOnline" -enabled $true -proxyfqdn "sipfed.online.lync.com" -VerificationLevel UseSourceVerification
  • New-CsAllowedDomain -Identity "push.lync.com"
  • Set-CsPushNotificationConfiguration -EnableMicrosoftPushNotificationService $true
  • Set-CsAccessEdgeConfiguration -AllowFederatedUsers $true

Was sie einem dort nicht sagen ist zwar logisch aber wenn mans nicht jeden Tag macht leicht zu übersehen:

  • Im Topology Builder bei den Properties des Edge Servers “Enable federation for this Edge pool (port 5061)” enablen
  • Der Edge Server muss mit seinem Access Edge NIC auf 132.245.193.21 (sipfed.online.lync.com) Port 5061 freigeschaltet warden (sofern nicht alles offen ist)

Was sicher irgendwo im TechNet steht ich aber durch mühsame Suche wo anders finden musste (und nicht unbedingt logisch ist):

  • am externen DNS muss es einen SRV Record _sipfederationtls._tcp.meinesipdomain für Port 5061 geben der auf den Access Edge service FQDN zeigt
  • das Zertifikat dass auf dem Edge Service verwendet wird muss von einer public CA kommen – und zwar nicht von irgendeiner sondern von einer aus diesem KB-Artikel.

Wenn das alles gegeben ist kann man mit

  • Test-CsFederatedPartner -TargetFqdn meininternername.vom.edge.server -Domain push.lync.com -ProxyFqdn sipfed.online.lync.com
  • Test-CsMcxPushNotification -AccessEdgeFqdn meininternername.vom.edge.server

testen ob das Konstrukt funktioniert – und zwar unbedingt vom Lync Front End Server aus – sonst kommen sehr kreative Fehler 😀

Custom shortcut icons am Netz und Windows 8

In Windows 8 wurde ein neues Sicherheitsfeature eingeführt: Shortcuts die ein custom icon haben welches irgendwo am Netz liegt (UNC oder mapped drive) warden nur mehr als weißes Kasterl angezeigt – kein Icon. Die Lösung: Computer Settings/Administrative Templates/Windows Components/File Explorer/Allow the use of remote paths in file shortcut icons – es wird zwar vor etwaigen Sicherheitsimplikationen gewarnt aber ein bisserl Nervenkitzel muss doch sein 😀