I had been waiting for a while to get my hands on the final version of the MS RDP 6 client to use in our VDI deployment. When it was finally released, I realized that it wasn't all that I was hoping for. My biggest gripe - it only allows monitor "spanning." For those that haven't tried it, what this means is that your 2 monitors will behave as one big desktop. Essentially the RDP client has no way of knowing where one monitor ends and one begins, which is bad for things like maximizing windows (windows will always maximize across both monitors, and not just one), dialog boxes that pop up in the middle of the screen, etc. I haven't found any way to get around this using MS RDP 6.
I am wondering what other people do to get around these issues? I doubt we are the only people out there trying to do multiple monitors in a VDI scenario. I'm trying to purchase a few of the Matrox Epica cards to see how they work. But does anyone know of any other solution that allows configurable multi-monitor setups that can be used with VDI or over an RDP connection?
Thanks
Bobby
As of yet no. I was planning to do some testing with RDP 6 though, so I do appreciate the information. The only thing that I have seen in my research thus far is the Matrox Epica cards as well. I'll be curious to know if you have any better luck with them.
Multiple monitors is somewhat of a make or break in some of our implementations around here, so when looking to VDI we have to keep that in our sights. If I run into anything else new though, I'll try to make a point of updating in this thread.
Again, thanks for the info on RDP6
Steve
Good question.
I have been involved in a potential VDI project a while back for the traders of a bank. The reason for which we have been looking at VDI was DR made simple.
Unfortunately one of the requirements of the traders was to have multi-monitor so we had to give up.
If anyone has a good suggestion for this question ....... well you know where to post now.
Massimo.
Our design had dual monitor support as a pre-requisite. We have been able to address this through both the existing Windows clients and with the Thine Terminals.
The ability to span RDP across multiple displays is a limitation of the client and not of the remote guest. This then presents two options to support the duial screen spanning, either the RDP 6.0 client for Windows or rDesktop for the Linux world. Intially we were able to get it working by extracting the RDP client components out of a beta of Vista which thankfully was then packaged and released as an independant package for either Windows XP or 2003 in the last couple of months. To take it one step further it now has been released for public as of last week.
So with the RDP 6.0 client we could get our Windows clients to work through a broker (Leostream) by provind the argument 'span monitors:i:1' as part of the RDP settings. We then extended this to the thin client by installing the RDP client on XPe device (Neoware e140). We also tested with the Matrox Epica cards on other devices but due to cost we dropped this as an option. So we now had at least met part of our design goal. Next issue was that we did not want to implement XPe and preffered either a Linux or thinner OS option.
Through working with Neoware and Wyse we now have dual screen solutions in Linux from both Manufacturers through a VDI broker client. We are still working closely with both Manufacturers as there is still a problem withthe experience which both are addressing and we are testing with our user base.
RDP presents a spanned workspace to a remote client. It may be able to span mulitple monitors but it has no awareness of the seperate monitors. This requires a bit of smarts either at the guest end. Although not 100% there yet we do have solutions from both Wyse and Neoware that are able to be used and accepted by the business.
So in short the options to support dual monitors in a VDI environment are available and development is very active to provide the complete end to end experience. Keep eyes peeled and general release of solutions should surface in the next month or so not to mention other solutions for VDI limitations.
Now if someone could just resolve the multimedia lag issue your users could all switch!
Dave,
interesting input. I was sure when we gave up that things were going to be solved over time and it looks we are getting closer and closer.
I am worried about the fact that the end-user experience is currently not similar to what u get on a standard PC so "my traders" might not be able to digest it (spoiled people ......;-) ).
Massimo.
however if they are traders, thay have money to burn, they would go with the Matrox Epica cards if they were proven to be useful
The problem with traders is not just the video but also the nature of the applications they use. Typically Reuters and Bloomberg have high levels of constant screen refresh which in turn can place large loads on an RDP based solution.
Better suited to Traders (who typically have 4-6 screens - Epica can go up to 4 btw) is something like bladestations. This gives the required performance in all areas while maintaining a data centre based location.
Although VDI is very good and the benefits are large in both cost and management, it does not neccessarily fit every requirement and video intensive solutions is one negative.
Tom,
agreed. they have enough money to have an SE per each desktop they have. As a matter of fact this group was looking into VDI just for DR reasons.
Dave made good points in his latest append as well.
Massimo.
I've done a couple of posts tonight on the solution I've been testing (Provision networks) - it doesn't seem that many of you are familiar with it becasue i don't see posts about it.
From my testing so far and talking to them, they have extended the RDP protocol quite a bit. One of the features is true multi-monitor support.
check out the bottom of this link under USER EXPERIENCE:
http://www.provisionnetworks.com/solutions/vas/vas_features.aspx?CID=
Muti monitor support is a constraint at the client side and not at the Host. As such Provision overcame this by writting there own client. In saying that though rDesktop also supports muli monitor and so does the Microsoft RDP 6.0 client. What that means that any Windows (XP, XPe, 2003, Vista) and Linux client can support multi monitors.
What you need to be wary of though is RDP presents multi monitors as a single work space. The implication of this is that when you maximise a screen it will span all monitors. This can be addressed by utilising the Matrox Epica range but with a significent cost hike on your thin client. We have been working with two thin client manufacturers on this exact issue and both are close to announcing solutions.
So in summary what I am trying to say is that do not let the multi monitor support be a feature winner for a broker as they all can support it.
SplitView - http://www.splitview.com - is a software utility that automatically 'splits' the big desktop seen by RDP/Citrix back into two desktops, one for each display.
It automatically repositions dialog boxes and windows so they do not appear in the middle of the two monitors. Also, it has the capability to prevent windows from Maximizing across both monitors. It is highly customizable and works well with Citrix and Remote Desktop in span mode.
We looked at Splitview but due to certain technical and cost factors it was eliminated as an option. Best to let your vendors supply a solution as we have so that it is then incorporated into the product solution.
Give a call to neoware, they have a setup with dual head video on a thin terminal and a software setup that accomplishes this. I don't know what the price range is on it right now...but I was hoping to test it with a radiology app this year possibly.
The NeoWare is an e140 with a dual head Matrox Epica card in the additional slot. We received one as a part of our trial/demo group of thin clients from different vendors. Although the Matrox Epica card is nice, I don't believe it works with RDP (yet anyway).
Also in order to get the desktop to split as expected, additional software is required on your Citrix server. Granted all of this information is from a short conversation I had a few days ago with a Neoware sales rep. and one of their engineers. I haven't had a chance yet to test any of this out, but I'm hoping to have some time to do that soon.
We were looking at RDP 6, the thin setup from neoware. As far as I recall from the conversation, it didn't require anything further. And it was not just spanning monitors, they were separate. You might check with them now...they've got some interesting new things going on. I'm tensely waiting for the new manager also...I don't care for the old one.
We are running the e140 (linux) in dual mode with a supporting piece of client side software which works a treat. We also have a solution from another manufacturer which will be announced shortly which is also very promising.
We tested the Epica (both TC2 and TC4) and quickly discarded it as high cost for minimal return in relation to our solution. With thin client and VDI you are still (currently) bound by RDP so having a card able to play those games, or do that detailed video editing may not be a good fit. Same goes for supporting four displays with the TC4, if that many displays is requried (as with traders etc), then maybe the Blade based stations is a better path. This way you still get the data center based management but with the additional graphical and horsepower advantages over Virtual devices.
Got to love the period between Xmas and NY, great time to waffle on!
I am having some similar thoughts. We have a requirement for openGl 3d support for trading apps and we want to ideally run them on vmware hosted desktops. Not too keen on the concept of using blade pc's because we reckon we can get greater throughput on hosted vm desktops.
Worth also remembering that RDP 6.0 supports 3D graphics when it is a vista to vista session, hence the glass support from a Vista client. It can not be to far down the track for rDesktop to jump onto this and provide the functionality to the client. Assuming this would require that the video card installed on the client could also support 3D graphics could be another thing to consider.
Let me offer you the low-cost software remedy for most RDP multi-monitor issues - Actual Window Manager[/i] (http://www.actualtools.com/windowmanager/).
Though it doesn't provide an ability to get the "true multi-monitor environment" it has many window management features (like automatic window sizing/placement, placement restrictions, automatic repositioning of dialogs spanning monitors, and others) which can be used to organize a strictly ordered desktop with well-behaving windows. The only possible obstacle - it must be installed and run on the server machine so the server machine must run Windows[/i].
Also you may try Actual Window Guard[/i] (http://www.actualtools.com/windowguard/) which is "lesser brother" of Window Manager[/i] but has most of required desktop organzation features.
This can be a pain, particularly in developer and trader desktops where they are use to the behavior of true dual monitor controlled by the graphics card and the added features they offer some times. But, not all deployments are a fit for VDI or thin clients.
We covered this with a developer deployment where 20% of the desktops were dual monitors. They opted not to use a third party tool.
Actual Tools and Split Screen are both good choices. In the end most people have been ok with adjusting to the behavior. Windows will remember window placement and size across reboots and RDP disconnects. It requires manually sizing your windows and placing them where you want at first, but then its not to bad.
If your users are static in nature, once they get going they rarely need to redo anything. If they are mobile and you have different screen / resolution configs it gets nasty as your windows will all reset based on the lower resolution. When you move back to a higher resolution they will be the same size just in different places.
