VMware Horizon Community
dphowes
Enthusiast
Enthusiast

Blocking passthrough of local drives to a VDM Virtual PC ?

Got VDM all setup and singing now, how would it be possible to block the passthrough of local drives from the client machine to the virtual desktop ?

There are a few possible avenues we are looking for VDM where we do not want users to be able to drop files from their local client machine to the virtual desktop at the other end.

Is this currently/going to be supported ?

Thankyou

Reply
0 Kudos
14 Replies
mattcoppinger
VMware Employee
VMware Employee

Hi,

VDM ships with two Active Directory Administrative Templates - vdm_client.adm and vdm_agent.adm.

vdm_client.adm will allow you to control the client RDP settings. For example, you can disable drive redirection. Simply add these ADM templates to your Group Policy (see the Microsoft article on this - ). Edit your group policy, go to User Configuration - Administrative Templates - VMware VDM Client Configuration - Redirect Drives and change the state to disabled.

For more information on this please refer to page 61 in the VDM administration guide.

Regards,

Matt

Reply
0 Kudos
dphowes
Enthusiast
Enthusiast

Thanks matt, think some RTFM on my part is required Smiley Wink

Will update on how I get on.

Reply
0 Kudos
lcounsel
Contributor
Contributor

You can also disable the use of all USB devices though the Configuration page of the VDM Administrator UI.

Reply
0 Kudos
shaneyoder
Hot Shot
Hot Shot

I understand the ADM for internal clients, but what if I have a user connect from their home pc to VDM? I don't want their drives connected to the VM at that point. I also don't want clipboard sharing. I can't use an ADM in that scenario and it leaves it wide open to security threats. How can I secure against that? The biggest benefit for VDI for us is to allow my workers to access their machines offsite. I read through the docs and can't figure out how to address this issue.

I would love VDM if it was more centrally controlled, I don't think these types of settings should have to be made on the client end.

Any input would be greatly appreciated. Thanks!

Reply
0 Kudos
shaneyoder
Hot Shot
Hot Shot

Sorry, my mistake. I never tried applying the GPOs to the host system. That works perfectly! Then it doesn't matter what client connects, the hosts GPO controls the settings for Term Services.

Reply
0 Kudos
markbenson
VMware Employee
VMware Employee

That's correct and a good way of setting this up. In terms of security, drive redirection should be controlled at the virtual desktop end. Only if the virtual desktop end allows this can the client end decide based on its settings.

I'm glad this is working the way you want it to, and thanks for posting back.

Mark.

Reply
0 Kudos
ullbergm
Enthusiast
Enthusiast

I'm a little confused, which system are you supposed to apply the policies to? It sounds like you can apply them on the virtual desktops but even if i load the ADM file on my target VM and configure several options they don't seem to apply.

I checked the registry and the settings are there:

http://HKEY_CURRENT_USER\Software\Policies\VMware, Inc.\VMware VDM\Client\RDP Settings
"DisableWallpaper"="true"
"RedirectDrives"="false"

I restarted the virtual machine and still nothing.

Thanks,

Magnus

Check out my orchestration blog here: http://ullberg.us/orchestrate/
Reply
0 Kudos
markbenson
VMware Employee
VMware Employee

Applying VDM Client settings on a virtual desktop will have no effect. VDM Client settings are for VDM Client only.

Reply
0 Kudos
ullbergm
Enthusiast
Enthusiast

Applying VDM Client settings on a virtual desktop will have no effect. VDM Client settings are for VDM Client only.

Ok, that makes sense. The post earlier in the threat at Feb 8, 2008 12:50 AM seemed to indicate (to me) that the GPO would work on the virtual desktop.

I just realized that i can probably use any of the microsoft terminal services polices on the virtual desktops just fine. The end goal here is to enforce policies when the users are connecting from machines that are not in my active directory.

Thanks,

Magnus

Check out my orchestration blog here: http://ullberg.us/orchestrate/
Reply
0 Kudos
markbenson
VMware Employee
VMware Employee

That's correct.

You can use GPOs on the virtual desktop to control Microsoft RDP (term svcs) settings. That's what the earlier post was referring to. I should have clarified that in my previous, (rather short Smiley Happy) post.

I'm glad this is clarified. Thanks for posting back.

Mark.

Reply
0 Kudos
ullbergm
Enthusiast
Enthusiast

Thanks for the quick replies tonight Smiley Happy

Check out my orchestration blog here: http://ullberg.us/orchestrate/
Reply
0 Kudos
kwilcox
Contributor
Contributor

Let me clear up some confusion here. The settings are VDM Client settings so the client template must be part of the GPO loaded by the workstaiton running the VDM client. This is pretty dumb IMHO since the client is very likely to be loaded on machines not within enterprise IT active directory jurisdiction. Offshoring/remote employee access are great examples of this. RDP GPOs need to be enforced by the vdm AGENT not the vdm CLIENT.

Hopefully this glaring oversight has been corrected in View 3 because its almost useless as it stands now for View's greatest promise: geographical independence/offshoring/work at home.

Reply
0 Kudos
mittim12
Immortal
Immortal

Why couldn't you apply the template to the agent PC and just use loopback processing mode to apply the user portion of the "block drives" to whatever use logs into the agent machine?

Reply
0 Kudos
kwilcox
Contributor
Contributor

Doesn't work. That was my original interpretation of this as well and I tried it. Nothing worked until I moved my vdm client equipped workstation into the OU under the GPO. The reason is that it's the VDM client that needs the GPO. In fact, loopback processing needs to be applied to the template in the OU that the computer running the vdm client is in if you want it to stick to a single machine. Without loopback processing, my user would have policy applied at any VDM equipped computer within the GPO's scope.

Reply
0 Kudos