­

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 😀

RDP, Windows 8 und VPN

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

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.

VMWare Workstation 9 und Windows 8 Hyper-V

Ich musste schmerzvoll feststellen dass Audials 10 auf einem Windows 8 Rechner mit aktiviertem Hyper-V das System unbootbar macht (bleibt ewig hängen) – andererseits ist die USB-Weiterleitung eines Windows Phone 8 in eine VMWare Workstation VM (für Windows Phone 8 SDK bzw. Visual Studio 2012 als Deploymentziel) um es höflich auszudrücken “holprig”.

Damit die Sache nicht zu einfach wird bringts auch nix eine Hyper-V VM mit Audials machen zu wollen – weil MS ja klugerweise das Audiomapping für Hyper-V erst gar nicht eingebaut hat, wozu auch – braucht doch eh keiner.

Also was tun wenn man für WP8 entwickeln (und damit den auf Hyper-V basierenden Emulator braucht) aber auch gleichzeitig auf der gleichen Hardware mit Audials 10 immer wieder mal was konvertieren will?

Der Versuch VMWare Workstation 9 auf einem Hyper-V Windows 8 Rechner zu installieren scheitert am Installer der da verweigert – und laufend Hyper-V über Add/Remove Windows Features aus- bzw. ein zu schalten ist vermutlich langfristig auch keine soooo gute Idee. Man kann scheinbar auch VMWare VMs betreiben wenn Hyper-V aktiv ist aber dann nur 32 Bit VMs und mit einem massiven Performanceproblem – ich hab das gar nicht probiert, einen Typ-2 Hypervisor auf einen Typ-1 Hypervisor zu setzen erschien mir etwas krank.

27 Google-Suchen weiter bin ich auf diesen Artikel gestoßen – der kopiert den Default Booteintrag vom Windows 8 und setzt bei der Kopie hypervisorlaunchtype auf off:

  • bcdedit /copy {default} /d "Windows 8 without Hyper-V"
  • bcdedit /set {guid die beim ersten Befehl rauskommt} hypervisorlaunchtype off
Wenn man nur alle (halb-)heiligen Zeiten die VM braucht eine gangbare Lösung.

Lync 2013 CU1 Update Warning

Ein weiteres “you can safely ignore this warning”: Wer bei der Installation vom Lync 2013 CU1 folgendes Warning bekommt

....
Dropping error message table.
Creating database objects.
Executing RtcAbTypes.sql...
Warning: Failed to execute batch --
-- Copyright (c) Microsoft Corporation. All rights reserved.
--
exec sp_addrole N'ServerRole'.
Executing RtcAbDb.sql...
Updating database roles.
Setting owner for database rtcab to sa.
.....

sollte sich nicht wirklich grämen, das kann man offensichtlich ignorieren, zur Sicherheit in DB RtcAb (Instanz RTC wenn mans lokal hat) in den Permissions schauen ob dort die Rolle “ServerRole” existiert und das Recht “View database state” hat dann ist alles gut.

Die anderen zwei Warnings die einem normalerweise entgegen geschleudert werden kann man auch ignorieren, die sind in Wahrheit nur Info:

Setting SQL Server Show Advanced Options to 1
Setting SQL Server Recover Interval to 5 mins.