…even though some of the improvements in the Remote Desktop technology are excellent.
I’ve been running hundreds of thin client Windows desktops from Citrix for well over ten years, starting with Metaframe 1.8 on Windows NT4 Terminal Server Edition right through to XenApp 6.x on Windows Server 2008 R2. I’ve been using cheap low power Windows CE based thin clients, originally Wyse 3200LE and later HP 5000 series.
Server 2008 R2 gave a pretty good Windows 7 style desktop experience but the multimedia support was rubbish. HDX Mediastream for Flash was too cumbersome and had too many issues, it didn’t work with CE clients anyway. I wanted to roll out Lync but it wasn’t supported.
Then Server 2012 came along (shortly followed by 2012 R2) and with it all the new enhancements in Remote Desktop Session Host and RemoteFX. So I started to evaluate it as a replacement. The RemoteFX adaptive encoding works really well; areas of the screen are identified and encoded in different ways depending on the type of content they’re deemed to hold. USB devices (can be made to) work just like they do on a PC.
Video is all transcoded on the fly into H.264 which means that the client only needs to support H.264. This gets around the problem of needing something like Citrix to have “special” support for each codec – they only ever really did Windows Media properly, Flash was too much of a bolt on, and forget things like Quicktime and RealMedia. The problem with the RDP approach is that doing on-the-fly video transcoding requires a LOT of CPU power. I had originally read that this could be offloaded to a graphics card, which made sense, and I even did some tests. But the results and information from Microsoft were not promising. I was going to need a whole load of high-end blade servers to provide all that CPU (I’m talking dual socket E5-2690v2 CPUs).
Reason number 1: Local desktops are cheaper
Plus you need to have a client device that has enough grunt to decode the H.264 video stream. I didn’t really want to go down the Windows Embedded route as the management overhead with the Windows CE clients was so low, so turned to the Wyse ThinOS range. I was told that Lync support was coming, and things were looking good. Until we tried to make them work properly, via the connection broker. Several months later we had that sorted. Video performance was ok but we had some audio lag issues, most noticeable when people were speaking in shot – the audio wasn’t synced to their lip movements. Not great for employee training videos. There’s no way to limit the amount of CPU that’s used for the video transcoding either, so if you have ten users on a server and nine of them decide to watch some YouTube at lunchtime, user number ten who is trying to do some work suddenly has no CPU capacity free to run their LOB apps, yet if nobody is running any video you have CPUs sat at about 1% when people are just running Office apps. Then I found out that Lync support had been dropped. Then I discovered the Intel NUC. The unit with the Core i3-4010U processor is more than powerful enough to do H.264 video, even full screen to a 24″ monitor, and with a 64GB mSATA SSD and 4GB RAM makes an excellent fast booting client. Plus I get the Windows 8.1 client licence for no extra charge due to my licencing agreement. It works out cheaper than a ThinOS client too, yet has far more CPU grunt, better connectivity and much more flexibility. So then I started wondering if I needed to have all that high-end Remote Desktop Services server hardware as well… why not just run the desktop locally on the client…
Reason Number 2: RemoteApp works on local desktops
I also use my Citrix XenApp farm to publish corporate applications to desktops. These run seamlessly such that they look like they’re running on the end user’s desktop. This works pretty well, and is pretty much the only way I could support some of the more “unique” apps. I deliver them to the client PCs via the PN Agent/Online Plugin/Citrix Receiver (take your pick of the names) so the application availability is handled by making users members of Active Directory security groups and the PNAgent puts shortcuts onto the Start Menu, passthrough authentication means the apps “just start” when people click the shortcut. Microsoft introduced a feature called RemoteApp which does a similar thing, and Windows 7 and higher, plus Server 2012 and higher have a RemoteApp connection manager built in which performs a similar function to PNAgent. On Windows 8/server 2012 you can even configure it via Group Policy. Oh, unless your desktop is itself being delivered from a Remote Desktop Session Collection. Where they deliberately broke it. You can add in the URL manually, but that’s not great if you have a mix of Remote Desktop and Local Desktop clients – I want consistency. Oh, and if you’re using User Profile Disks, another great feature of Server 2012, that workaround fails. Yes you can use the RemoteApp web site to access your apps, but you can’t make it automatically accept your user credentials from the desktop session, and you don’t get any filetype associations.
Reason Number 3: No Lync support
I’d found out that Wyse had dropped Lync support from their ThinOS range, which was a shame, but was still considering building my own “thin client” running a very locked down Windows 8 that effectively launched a full screen Remote Desktop as soon as anyone logged on. I’d done this before with Windows NT 4 and it worked pretty well. Then I found out that Microsoft had decided not to support Lync at all in Session Host desktops – the only “remote desktop” support for Lync is via a hypervisor-based VDI solution, which provides far lower user densities than a Session Host (and thus higher costs). Lync is what we’re moving to for all our telephony, so Lync support for all desktops is mandatory.
Reason Number 4: Poor management and helpdesk support
My helpdesk staff can currently see a list of user sessions (be they logged on or disconnected) via the Citrix <insert current product name here> management console. This allows me to assign permissions to the helpdesk staff such that they can perform certain operations and not others, the most useful of which is shadowing (i.e. viewing a users’s desktop to ease troubleshooting and/or provide better application assistance). It also enables them to see which XenApp server the user is logged into, which helps the end users if a server develops a software fault – several users running from the same server calling with problems enables them to disable logons to that server and escalate to second level support. Remote Desktop Services doesn’t have this. Microsoft dropped the old tsadmin.exe utility, and replaced it with the so-called Remote Desktop Management Server. This is a total farce, is it’s just a “feature” of the Server 2012 Server Management GUI. You have to add ALL the Remote Desktop Services servers to the managed server pool, and if the back end teams add any extra RDSH servers (or remove any) the console breaks and must be configured by hand via the clunky GUI by every member of your helpdesk staff. It is utter rubbish. I wrote my own basic shadowing console using PowerShell, but now won’t need it – if you have a local desktop you just need the computername and you can shadow via Remote Assistance.
I am not going to be running full desktops via Remote Desktop Session Host. There are too many weirdly broken and oddly unsupported bits of critical functionality, plus the server hardware requirements are just too high and too uncontrollable.
RemoteFX is brilliant tech, User Profile Disks are a good innovation, I am so disappointed with the lack of a coherent desktop strategy from Microsoft. But ultimately their part-broken tech has saved me a load of money. I’ll still deliver applications from Server 2012 R2 via RemoteApp, but as there’ll be no video requirement I can carry on using the same X5560-based servers that I’ve had for the past five years or so – these have plenty of power for the application load. I might even ditch some of them as with no desktops at all I can run fewer RDSH servers – my application-only servers have far lower resource requirements than ones funning full desktops.