Category: VDI

Posted on

HP Thinpros and Windows 2008 R2 Remote Desktop Services (RDS)

I’ve been sitting on this blog for a while; so I thought it was about time I published it! Just recently we’ve been working with a client that was going through a desktop transformation process from Windows XP to HP thin client’s using a shared desktop on Windows 2008 R2 Remote Desktop Services (RDS). I’m not going to expand on why they chose Microsoft RDS over Citrix XenApp 6.x or why they chose Linux-based thin clients over Windows Embedded clients. Let’s just say that money did come into the equation.

What I’m going to cover in this post are the issues I’ve encountered whilst using the HP t5565 Linux-based thin clients with Microsoft’s RDS.

Remote Desktop Services Connection Broker

Lets start with the BIG one; they do not support the Remote Desktop Connection Broker (RDCB) or should I really say the open source rdesktop doesn’t! Now when I mean they it’s not supported, it can imply that it will work fine (but please don’t ask the vendor to help if any issues arise). In this case it simply doesn’t work. When the RDCB tries to either load balance or reconnect a disconnected session you will face a situation where you enter your login credentials then the session seems to just drop. If you are lucky your load balancer or round-robin DNS will direct you to the correct server, but this is just the laws of probability in action.

I should point out that this point will probably be an issue for any thin clients that are Linux-based and and utilising the rdesktop client. I have heard rumours that FreeRDP does work with the RDCB but I’ve not tried that myself so can’t confirm this; though this forum post does suggest it will work.

Bitmap Caching

Using “Bitmap Caching” in the rdesktop settings causes the screen to freeze randomly; so you have to way up the pros and cons of leaving it turned on. The benefits of enabling the bitmap cache is to minimise the amount of data transferred between the RDP client and server. However, this introduces the screen freezes. As a result, I went with disabling the bitmap caching to improve the user experience – the client had a well connected network so latency etc. was not an issue.

Other Issues

  1. Drawing shapes in Office 2003 will cause the screen to freeze and the system will become unresponsive – Resolved with this forum post.
  2. Using a second monitor to extend the primary display doesn’t work i.e. only show the taskbar on the primary display. What happens is screen spanning occurs therefore the taskbar is split across both monitors and the “Ctrl+Alt+Del” dialogue appears slap bang in the middle of where the monitors join – Resolved with this forum post (though I haven’t had time to test this myself).

I think the moral of this story is to try before you buy and then try some more! If you want to use the RDS Connection Broker then go for a Windows Embedded thin client, if indeed you want to use a thin client. Taking this approach may save you a lot of headaches going forward.

Nathan

Posted on

Disabling RES VDX

If you’re like me you spend a lot of time on customer sites and a vast amounts of time using the RDP client to connect to various client machines and servers. It may just be me, but I find the whole RES VDX popup notification when starting an RDP session rather distracting. It’s fine if the client has the VDX Engine installed in the hosted desktop, but more often than not they don’t. Worse still, when integrating RES Workspace Manager with VDX it becomes even more frustrating when connecting with Admin accounts as, typically, the RES Workspace Composer is disabled. This results in VDX connecting in “time trial” mode, bringing the local applications through into the remote session and then dropping them with a pop up notification. Grrrr!

It’s for this very reason that I set off looking for how to disable the integration and allow me to re-enable it if necessary for testing. I checked the available Administration Pack but it doesn’t allow us to suppress the notification so off I went to Google. It didn’t take too long to find out where the RDP and ICA add-in settings are stored in the registry. The ICA key is only created if the Online and the locations are different for RDP and ICA..

RDP
Key 32-bit/64-bit: HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns\RESVDX
Value: Name
Type: REG_SZ
Data 64-bit: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x64.dll
Data 32-bit: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x86.dll

ICA
Key 32-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\RESVDX
Key 64-bit: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\RESVDX
Value: DriverNameWin32
Type: REG_SZ
Data: VDXICAPlugin.dll

The simplest solution I’ve found is to rename the plugin DLL references in the registry so they’re not loaded. Renaming the individual registry keys doesn’t appear to work as the Add-In keys are still enumerated even though the key names have changed. I, for example, rename the above .dll filenames to .dl_ in the registry to disable the integration and set them back when needed. I have 2 .REG files; one to disable the integration and one to enable to make my life easier because I’m like that!

Posted on

Quest vWorkspace and RES VDX Integration

We’ve come across some issues with the integration of RES VDX and Quest’s vWorkspace on a couple of customer sites just recently. Some old timers might remember an issue that occured when using the then, RES Subscrber/Workspace Extender, with Provision Networks Virtual Access Suite (VAS). The issue fixed by Q201760 RES Subscriber and RES PowerFuse Workspace Extender do not work with Provision Networks VAS is the same issue experienced with vWorkspace.

Both the legacy VAS client and the newer vWorkspace client are virtually the same and the registry key is still called ‘HKLM\Software\Provision Networks\Terminal Server Client\’. However, to integrate the newer VDX components we need to reference the newer VDX DLL(s) rather than the Workspace Extender DLL.

To get the VDX integration to work with vWorkspace we need to create one of the following keys on the local machine. Note: these registry keys are HKEY_LOCAL_MACHINE.

For 32-bit clients:
KEY: HKLM\Software\Provision Networks\Terminal Services Client\Addins\RESVDX
VALUE: Name
TYPE: REG_SZ
DATA: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x86.dll

For 64-bit clients:
KEY: HKLM\Software\Wow6432Node\Provision Networks\Terminal Services Client\Addins\RESVDX
VALUE: Name
TYPE: REG_SZ
DATA: C:\Program Files\RES Software\VDX Plugin\VDXRDPPlugin_x86.dll

Simples once you know how! Iain

Posted on

Remote Assistance Troubleshooting

With any VDI technology that leverages Microsoft’s RDP (Quest’s vWorkspace and VMware’s View) deploying Microsoft’s Remote Assistance (RA) is a requirement for support as the typical remote console solutions do not work as originally intended. RES integrated the Remote Assistance technologies with the release of RES PowerFuse 2010 (Service Release 1?) and as a result we’re seeing more people attempting to integrate Remote Assistance with their VDI deployments. There are few things that can, and do go wrong.

RES Workspace Manager will configure the Remote Assistance registry settings on the local computer via the RES Workspace Manager agent without requiring Group Policy Objects or manual configuration of the registry. This includes ensuring that RA is enabled, the firewall ports are open and the RA Helper Active Directory accounts are populated with the specified groups. Once a Remote Assistance session is offered by the administrator via the RES Workspace Management console, this is handed off to the underlying infrastructure and RES Workspace Manager has nothing more to do with the remote session. If you’re having problems with Remote Assistance you might want to double check the following.

Local Helper Account

Ensure that the local HelpAssistant account is not disabled (on Windows XP). This account needs to be enabled on both the machine offering the Remote Assistance session and the target machine. If this is not enabled on the source computer, you may receive the “There is a problem with the invitation and it cannot be opened. To use Remote Assistance, the sender of this invitation will have to send you a new invitation.”

Remote Assistance HelpAssistant Error

Windows XP Help and Support Service

Double check that the “Help and Support” Service is enabled on Windows XP machines. There may be an old Group Policy Object somewhere that has disabled this and without this running, Remote Assistance is not going to be going anywhere! This service has been deprecated with Windows Vista and Windows 7.

DNS

The standard name resolution process is used to contact the destination computer when a Remote Assistance session is initialised. We have seen issues in VDI environments where the DNS records for desktops become stale. Here is a particular example:

  • VMware View is deployed with linked clone technology.
  • As VDI is booted it registers in DNS for the first time.
  • When the VM is recomposed it ends up with a new computer SID/MAC address but the same hostname.
  • The VDI attempts to update the DNS record but can’t because the SID associated with the DNS entry is incorrect.
  • If the RES PowerFuse console is located on a different subnet to the destination computer, Remote Assistance fails.

To ensure this isn’t a problem, make sure the computers are shutdown cleanly (and double-check their DNS entries are removed) before recomposing!

Virtual Engine Limited
450 Brook Drive, Green Park, Reading RG2 6UU