RemoteApps ohne RDPINIT.EXE am Client

Posted on by roman

…..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

Posted on by roman

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

Posted on by roman

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

Posted on by roman

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

Posted on by roman

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

Posted on by roman

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

Posted on by roman

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

Posted on by roman

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 😀

RDP, Windows 8 und VPN

Posted on by roman

Angenommen wir haben zwei Windows 8 Rechner (oder 2012, es geht um RDP 8). Der Client ist via VPN in das Servernetzwerk verbunden. Der Client will ein RDP Verbindung zum Server (Win 8 oder 2012, egal) machen. Der Client verbindet sich zwar friert aber instant ein, kommt vielleicht kurzfristig wieder, reconnected irgendwann, vielleicht auch mehrfach, und irgendwann fliegt man raus.

Nach langem Suchen (und auch im Rahmen eine Supportcalls bei MS dazu) wurde vermutet dass es um die verwendete Verschlüsselungsmethode bei der VPN-Verbindung geht – AES (VPN) auf AES (RDP) erzeugt hier scheinbar bei manchen Leuten seltsame Effekt, eine Umstellung auf z.B. 3DES hilft hier scheinbar manchmal. Aber natürlich nicht bei mir – erst als ich diesen Blog gelesen habe ist mir eingefallen dass sich VPN wenn im TCP/UDP Mode ähnlich verhält (einfrierende, stockende Verbindung). Und in der Connectionbar oben ist beim Verbindungsqualitätssymbol die Info dass UDP aktiv ist angezeigt worden. Also kurzerhand HKLM/SOFTWARE/Microsoft/Terminal Server Client/DisableUDPTransport=1 (REG_DWORD) gesetzt und voila: Es pfeift und hört gar nicht mehr zu pfeifen auf 😀

RDSH Seltsamkeiten

Posted on by roman

Scheinbar beginnt ein RDSH (ab 2008) ab einer gewissen Last damit die Environmentvariable CLIENTNAME von Logonscripts aus nicht oder erst zu spät korrekt aufzulösen (obwohls schon längst in der Registry steht) – erst wenn man die asynchrone Ausführung der Logonscripts (Computer oder User Configuration / Adm. Templates / System / Scripts – Computer gewinnt wie üblich wenns auf beiden gesetzt ist) ausschaltet. Damit verliert man zwar je nach Loginscript einige Sekunden beim Logon aber dafür ist CLIENTNAME zuverlässig gesetzt. Von dem Problem sind übrigens auch via GPO gestartete Programme/Scripts – die sehen ebenfalls u.U. keine Environmentvariable CLIENTNAME…

Auch sehr seltsam: Programme die über User Configuration / Windows Settings / Scripts / Logon ausgeführt werden müssen a) sich selbst beenden (oder z.B. über ein CMD mit START losgelöst gestartet werden) sonst hängt das Logon ewig und zwei Tage (wenn die asynchrone Geschichte disabled ist) und b) werden die erzeugten Prozesse wieder gekillt (vermutlich von GPSCRIPT.EXE) – d.h. man kann dort also nicht die Nicht-Ausführung der diversen Run/Startup-Möglichkeiten die einer RemoteApp mangels Explorer verweigert werden nachbauen…hab daher einen Wrapper für RemoteApps geschrieben welchen man in die RemoteApp Config als zu startendes Programm einträgt und als Parameter das eigentliche Programm und dessen Parameter verwendet. Im .config File dazu kann man dann in PostStart_1 bis _9 hinterlegen welche Programme man nach dem Start den noch gerne hätte (value ist jeweils Programm|Argumente).

Als Draufgabe wartet RemoteAppStarter noch bis sich das gestartete (Haupt)program beendet und macht anschließend Logoff damit das leidige RemoteApp-Session-bleibt-trotz-geschlossenem-Programm-übrig Problem auch gleich gelöst ist.