QuickPrep breaking 'Remote Desktop Users' group definitions

[Bucketenator]

All,

Have a customer who wants me to roll out View desktops with a go-live of next week (no pressure!). I've installed VV successfully, and have created linked-clone desktop pools (both persistent & non-persistent). I have an XP SP3 parent VM as the master, and within I have added the AD group 'RBMA\VDI Remote Desktop Users' to the local 'Remote Desktop Users' group. With this config in place, I'm able to RDP in and login as a domain user (one that's in the 'VDI Remote Desktop Users' AD group). I shutdown the parent VM, take a snapshot, and then recompose the desktops that are linked to the parent. A replica is created and then the linked clone desktops are created & quickprep'd. The AD computer account appears in the specified OU and is enabled - it appears to be joined to the domain just fine.

Then I try to login to one of the desktops using the View client (yes, I've entitled the pool to the users) and then proceed to login. I then get an error stating that 'you do not have access to logon to this session'. Having tried many things (review GPO settings, review parent VM settings etc) I then decided to clone the XP parent VM to a template and create a more traditional pool based on sysprep / customisations to deploy VMs from this new template .... desktops are created, and the AD computer accounts are created (although never in the OU I want ... why can't we specify the OU somehow?). I move the computer accounts into the VDI OU (so GPO is applied) and then try to login using the same user account as before ... SUCCESS!

Comparing the two desktops (linked-clone v traditional cloned desktop), I notice that the linked-clone desktop has a mangled entry for the 'RBMA\VDI Remote Desktop Users' in the local 'Remote Desktop Users' group ... see attached screenshots.

Conclusion: Quickprep is breaking my local 'Remote Desktop Users' group entry in the desktop, hence the domain user cannot login via RDP. The question is why?

Background:

- ESX 350U3 (build 123630).

- VC 2.5U3.

- VV build 127642 + composer 126338

All thoughts / help greatly appreciated!

Cheers,

JD

[admin]

Hi there,

is the linked clones desktop really in the right OU? Is the GPO definately applied? Could you login to one of the desktops via VI console... do an gpupdate /force, and check if the group is in again?

Where did you set that the group is in the Remote Desktop Users grou? In the template/master image or via GPO? You should set it in the GPO/domain policy. You can confiigure Restricted Groups there. Also check that it is allowed to connect through terminal services.

The reviewers guide of VDI will give you the infomration needed for Restricted Groups etc...

Thanks,

Christoph

[Bucketenator]

Christoph,

Thank you! You've given me the hint I needed .... Restricted Groups ... something I'd never heard of (still a student of AD & GPOs) but now I see it's part of the default domain GPO policy, and was mapped to a non-existent security group. Once I fixed that (assigned the real VDI Remote Desktop Users group) all was good.

Thanks once again...

JD

[DwayneL]

Hi

I am also deploying VDI desktops to replace every computer in a remote health region next week. We couldn't afford the extra $100 per license so have to use non-persitent desktops to save on storage. A lot of our users are not on at the same time. We are using folder redirection and roaming profiles to save space. Once you're up and running for two weeks do you mind posting how much your size has changed for your linked clones before refreshing. Maybe you're spouse to refresh the pools sooner then that, i am not sure but i would be curious to hear your findings.

[Bucketenator]

I've configured serveral pools, persistent, non-persistent (both linked clones) as well as traditional persistent clones - so it's a mixed bag. Have a use population of 100 concurrent users, XP SP3 8GB base disk on a 1TB datastore (was planning on using VDM but linked clones was too good to pass up). The non-persistent will obviously refresh after logoff, but the persistent desktop disks will obviously grow over time. I'll post some analysis in a couple of weeks...

JD