TechAgility

I was helping build a Road Case for demos at MS 2008 Launches and other uses and while building a couple of VDI’s as well as BladePC’s for the Thin Client’s to connect to we found that roughly half of the devices were not responding at all to a simple RDP connection.

One point here is that although this was just a small Road Case for demo’s we had decided to try and emulate a proper enterprise environment as possible in that the systems had been setup as Multi-Homed with dual NIC’s so that there is a Private VLAN for Altiris imaging jobs as well as a Public VLAN for the connections and normal work, this enables BladePC’s, VDI’s and Thin Clients to be re-imaged without causing disruption to normal LAN activity.

So with that caveat in mind, what went wrong and how did we fix it?

Earlier we had discovered that RGS (HP’s Remote Graphics Software) was not connecting either and this was traced to the fact that ALL of the systems we had set up to run RGS had managed to bind to the wrong NIC.

Action: Disable NIC2, restart RGS Sender service - test, OK

Open Networks, click on Advanced, make sure the correct NIC is at the top of the order

re-enable NIC2, still test’s OK

reboot, tested again, still OK.

As a consequence we have checked back up with the Product Development Team and the feedback is that there is now an enhancement request in so that during installation of the Sender component it will check for NIC’s and with more than 2 it’ll ask you which NIC to bind to. There will also be a configuration to ensure the right NIC is bound.

So that was the RGS sorted, so what was happening to the RDP connections?

We could ping them, we could connect via Telnet on 3389, the Remote Connection box was checked, and the user was part of the Remote Desktop Users group…..  very strange.

Checked the Event Log and found some curious reference to TermDD and an error 50?

At one stage I thought it might be MS kb555382

But it finally transpired that it was this "The RDP Protocol Component "DATA ENCRYPTION" Detected an Error…" error message

Unbelievably the cause is: A potential race condition between the Icaapi.dll and Rdpwsx.dll dynamic-link libraries (DLLs) may cause the private certificate key on the Terminal Services server not to be synchronized.

It simply means the invalid certificate is deleted and it is recreated on the fly on the next reboot

Resolution:

To resolve this issue, follow these steps:

1. Locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TermService\Parameters
2. Under this registry subkey, delete the following values:
   Certificate
   X509 Certificate
   X509 Certificate ID
3. Quit Registry Editor, and then restart the server.  (Although this states Server - it can happen on XP SP2)

Interestingly enough there is also a mention of this very same KB article at VMware with reference to VMware Virtual Desktop Manager (VDM) 2.0 Release Notes

written by dcaddick

Well who would have thought it? is this Novell rising from the ashes? It will no doubt be an interesting year watching still further manoeuvrings in the Virtual space - although I wonder if the US does finally get in to a recession will this slow down the pace a bit?

Certainly VMware has a lot more competitors to contend with now than it did when the IPO was released last year and I see there share price is now back under USD$60 after the dizzy heights of $120 late last year….

Novell acquires PlateSpin

virtualization.info has just learned that PlateSpin, leader in the P2V migration market, has been acquired by Novell.

The canadian firm acquisition further boosts Novell visibility in the virtualization space.

Novell already has a major involvement in the market since the early days of Xen development in 2004, when the company was announcing the inclusion of the open source hypervisor in its SUSE Enterprise Linux.

After that first step another acceleration was provided by the interoperability agreement signed with Microsoft in 2006.

PlateSpin is a valuble acquisition target for Novell not just because of its flexible migration tool, PowerConvert, but also because of the other products in its offering: a capacity planning tool, PowerRecon, and most of all a new disaster recover solution called Forge.

These technologies will probably go integrated with the Novell management solution ZENworks, adjusted to handle virtual machines since end of 2006.

virtualization.info: Novell acquires PlateSpin

written by dcaddick