Sun VDI 3.1-EA: "Microsoft Remote Desktop" Provider -- Bug?

Question

It seems there is a bug in VDI 3.1:
After having added a VirtualBox desktop provider I also wanted to add a Windows 2003 terminal server as desktop provider, so I go ...
- https://localhost:1801
- Desktop Providers
- Windows Remote Desktop
- New ...
- Step 1 ... Next
- Specify New Host
... And now it asks me for this information:
Host:
SSL Port: 443
User Name:
Password:
SSL Port? For a Windows 2003 server?
I am confused ... So I want to check the "Help" tab. The "Help" tab links to this URL:
https://localhost:1801/vda/faces/jsp/providers/tswizard/NewTSProviderWizard.jsp#
So guessing from that URL ( ... "NewTSProviderWizard" ...) I'd expect to find information regarding Windows TS servers?
But the help text reads ".... Enter the hostname or IP address, and administrator credentials for the *+VirtualBox+* host server ... "
VirtualBox? I wanted to get help with Windows 2003 TS.
So I'd assume that this is a bug?
- the "Add Microsoft Remote Desktop" wizard will get you the one for VirtualBox
- Help text is talking about VirtualBox too
I assume that this will be fixed before the final release?
Regards,
DJ.

Answer 1

What specifically does your customer object to ?The server being +"touched"+. That's already enough for them. I'm ashamed to admit this ... but I too was a Windows admin once. I was young, stupid and I needed the money. ;-)
So having been a Windows admin once myself ages ago in my dark past I can fully understand them. One stupid patch, one stupid incompatible product, one silly addon someone somewhere wrote ... and that server dies in a nice ugly "Bluescreen of Death". Or so they think. Because a typical Windows admin spends 90% of their daily job running from one dying Windows server to another dying Windows server the last thing they want is yet another server that is bound to die because one of us unworthy Penguin worshippers dared to install something on it ....
So NOT having to install anything on that server like with SSGD is perceived as being OK.
Having to install ANYTHING on that server for which the admin doesn't understand the reasons within 1 second simply is a NO GO for them.
+"Why doy ou want to install this BS? My RDP connections work tip top without that thing you want to install ... take your hands off my server ... "+
So ... How do I explain to a very very stressed and hyper-nervous Windows server administrator that I need to install some SSL stuff on his precious Windows 2003 or Windows 2008 installation when SSGD (also from Sun last time I checked ...) didn't need that? And none of his other RDP applications need that?
How do you explain something like that? YOU CAN'T. The discussion is over even before it can begin. And if their Windows administrators are screaming like mad and panicking that you are about to hose their precious Windows systems then soon enough even their managers (who up to that second were on your side) demand an explanation ... "Why does VDI require that when SSGD didn't require that??"
In the end it's easier for me to configure an Windows RDP application via SSGD and deliver it that way to the VDI sessions than argue with the customer and their nervous admins about why in the world I now have to touch their servers with this stuff ...
See what I mean? Yes, I know: I exagerated slightly. Just to give you a feeling of the troubles us people in the frontlines are facing.
SERIOUSLY:* The RDP-Provider in VDI 3.1 is in need of being re-evaluated and re-designed. Like it or not: But it simply is not going to fly the way it is now. Most Windows admins simply don't want any additional stuff installed on their servers. PERIOD. Because only the Gods know what other things such stuff will break one day ...
So the RDP provider in VDI 3.1 should look and feel and act exactly like the one in SSGD. If you want to offer RDP-over-SSL: fine, offer it as an option for the lucky few who don't have to argue with their customer about that.
RIght now it's easier for me to create a Linux VM that auto-boots into a pre-configured "rdesktop" session and then deliver that as a login option to users than to argue with the Windows admins why their precious servers need to be touched ... So yes, I'd say this part of the Sun VDI 3.1 product is in need of a re-design.