VDI Support - How do you support your sessions?

[kbk00]

We are a large national company that is testing and piloting the intial rollout of VDI. Things have gone extremely well with the exception of a problem that popped up today. For our standard desktops, if a user needs assistance that requires helpdesk to see and manipulate the desktop, we use SMS Remote Control. This has worked great for us, from what I can tell. However, it looks like SMS Remote Control doesn't work 100% when servicing a TS session. The control is initiated but is basically read-only with no way to manipulate the desktop. So, a couple questions:

1. Has anyone seen this before and knows how to get past it?

2. How does your company work this issue out, if not for SMS?

Thanks in advance and any assistence with the SMS issue would be fantastic. I just haven't been able to find anything on the web about it.

Thanks!

Specifics:

VI3 (3.0.2U1)

No broker (today)

XP SP2 fully updated sessions

Wyse s10 thins

SMS 2003

[mreferre]

Ken,

one of my customers is using a similar setup and they prefer to use the S10 remote VNC capabilities. This allows them to even troubleshoot problems for low level issues (i.e. assisting users logging into the remote desktop through the broker interface etc etc) on top of, obviously, being able to get full control of the remote RDP session the user has opened.

They also use LANDesk Manager within the XP vm and they use it (similarly to you using SMS) when they deploy vm desktops on NON-S10 devices. As far as I know LanDesk is ok for this.

Sorry I don't have any inside for SMS.

Massimo.

[mreferre]

Alternatively ..... would the solution provided towards the end of this post work for your scenario?

http://communities.vmware.com/message/716406

Massimo.

[kbk00]

Good find on the post but this is just allowing shadowing without user intervention. This reg edit is something we have already in place. My issue is that the screen can't be manipulated. Only shadowed.

[Troy_Clavell]

This happens to us and unfortunaltly there is nothing that can be done excpet wait for the implementaton of SCCM, where this issue will be resolved.

You can always troubleshoot via the console. We have a few "power users" on the helpdesk that we allow access to the VM's console through Virtual Center and the web interface.

[mreferre]

ah ok ... correct.

How about the S10 native VNC service?

Massimo.

[kbk00]

Unfortunetely we don't have the infrastructure for the VNC capabilities due to several reasons. This is something we are working towards, though.

The end goal is to keep our support structure the same for both our hardware desktops and VDI sessions (SMS). The VNC solution is the backup plan that I'm hoping we don't have to move to.

Thanks for the ideas!

[kbk00]

Did you happen to have a link detailing the issue, by chance? I can't find anything on the web about this particular issue.

Thanks

[Troy_Clavell]

no, i haven't been able to find anything. I've only recently joined this comany and they uses SMS. It was through trial and error that we realized the problem. Thats one of the reasons we are trying to get SCCM deployed ASAP.

[chouse]

We use Novell zenworks for its remoting ability and that works fine.

But I do know that the windows request remote help thing works too and allows a helpdesk agent to connect to the session with the user's permission and view/interact with the VM even though both individuals are accessing the session over RDP.

On XP, you can initiate a help response without needing the initial request from the workstation. Just paste the following in to IE or your Run dialog box:

hcp://CN=Microsoft Corporation,L=Redmond,S=Washington,C=US/Remote Assistance/Escalation/Unsolicited/Unsolicitedrcui.htm

It prompts you for the IP/hostname of the VM and once entered, connects and prompts the user if they would like to accept assistance from you.

[dmshirkeyNMB]

Try Dameware NT utilities http://www.dameware.com/ . It will install a service on your guest machine. If you want to save resources just make sure that you set the startup type to manual. I do not think i have ever ran into a situation where i could not use it.

Life is like a toaster... you have to be pushed down before you pop up.

[hmartin]

We ran into the same limitation with SMS. We are considering using the VNC server built into the Wyse V10Ls, which is what we use as the client for most of our VDI VMs. How did you finally address this problem?

[markvr80]

We were already using the enterprise version of RealVNC for our desktops, and this works perfectly for the VDI VMs as well. To be clear, this is VNC installed on the VM, NOT the VNC to the Wyse box.

VNC to the wyse box is a bad idea IMHO (I disable it in wnos.ini) because you can only have shared password and I don't think it encrypts it on the LAN. The enterprise VNC on the XP VMs just uses an active directory security group so easy to add/remove sysadmins if they leave etc. Also VNC to the Wyse box needs you to know which box they are using, which in a hot desk environment is hard to find, whereas everyone always gets the same XP VM (persistant pools) with us.

This works really well and is exactly the same wether they are physical or VDI.

[buckethead]

In our environment we are using persistent pools and have virtualized all of the applications (except Office). Since doing that the need to get remote access has gone down, but we use WebEx for the situations that do arise. The user can either contact our Help Desk and launch and Remote WebEx session or the support person can fire up a WebEx meeting. Now if the user is with the browser this probably wont' work. In many cases we just have the user logout so that they get a new desktop and the issue is resolved.

Enterprise RealVNC is a good idea that I will explore as well. We looked at VNC on Wyse and the shared password scared me away as well.

[hmartin]

Thanks for the information. I'm hoping that PCoIP will allow us to go back to the SMS tools since we won't be using RDP anymore to connect to the VM.

[alelondon]

We have XP PRO SP3 desktop pools and enabled the built-in Remote Support via Active Directory GPO.

So when a user calls, engineers ask them to click on a shortcut which points to:

URL: hcp://CN=Microsoft%20Corporation,L=Redmond,S=Washington,C=US/Remote%20Assistance/Escalation/unsolicited/unsolicitedrcui.htm

Albeit a bit sluggish when dealing with remote sites (70ms latency), this works pretty well. It has chat, send and receive files, etc... AND is compliant with our security policy which states that the end user needs to allow the remote assistance.

[hmartin]

Thanks for the information. Can you tell me the GPO you had to enable? Did you have to do anything with the built-in HelpAssistant account? In our environment, it is currently disabled.

[alelondon]

we have created a group in AD for our "Helpers"

The GPO settings are as follows:

Administrative Templates > System/Remote Assistance

Offer Remote Assistance: Enabled

Permit remote control of this computer: Allow helpers

Helpers: DOMAIN\Myhelpers Group

Windows components / Terminal Services

Allow Users to connect remotely using TS: Enabled

Extra Registry Settings:

Software\policies\Microsoft\WindowsFirewall\DomainProfile\AuthorizedApplications\Enabled 1

Software\policies\Microsoft\WindowsFirewall\DomainProfile\AuthorizedApplications\List\%WINDIR%\PCHealth\HelpCtr\Binaries\Helpctr.exe::Enabled:Remote Assistance - Windows Messenger and Voice %WINDIR%\PCHealth\HelpCtr\Binaries\Helpctr.exe::Enabled:Remote Assistance - Windows Messenger and Voice

Software\policies\Microsoft\WindowsFirewall\DomainProfile\AuthorizedApplications\List\%WINDIR%\PCHealth\HelpCtr\Binaries\Helpsvc.exe::Enabled:Offer Remote Assistance %WINDIR%\PCHealth\HelpCtr\Binaries\Helpsvc.exe::Enabled:Offer Remote Assistance

Software\policies\Microsoft\WindowsFirewall\DomainProfile\AuthorizedApplications\List\%WINDIR%\SYSTEM32\Sessmgr.exe::Enabled:Offer Remote Assistance %WINDIR%\SYSTEM32\Sessmgr.exe::Enabled:Offer Remote Assistance

[hmartin]

Thanks. That got me one step closer. I set up the GPO and put a couple PCs in the test OU. Now, I'm able to successfully send the 'offer' from one View-based VM while connected via RDP and accept it on another View-based VM while connected via RDP. Also, the main Remote Assistance window successfully opens on both the sender and receiver. However, the session is immediately disconnected and presented with a dialog box that says "You have been disconnected from <userid's> computer. For more information, contact <userid>."

Attached are the events I found in the receiver's event logs.

Here is the text for each entry (bottom to top). Any suggestions are greatly appreciated.

A remote assistance ticket has been created with duration: 0.17hrs for user <domain>\<receiver>.

Session created in PENDING state: id=3, winStation=RDP-Tcp#9

Remote Assistance of <receiver>/<domain> started. (Note: Not sure why username is before the domain, but I assume that's normal.)

User <domain>\<receiver> has accepted a Offer Remote Assistance session from <ip_address> (visible IP address: <same_ip_address>).

Remote Assistance of <receiver>/<domain> ended.

A Offer Remote Assistance session for user <domain>\<receiver> from <ip_address> (visible IP address: <same_ip_address>) ended.

Session CANCEL: id=3, user (null)\(null), client=(null) (Note: Not sure why these show "null", but again I assume that's normal.)

[alelondon]

Very strange... Not much I can suggest myself but a bit of googling gave me this.

http://support.microsoft.com/kb/921982

Let us know how you get on