Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

4070

November 19th, 2010 13:00

Does anyone have experience with vWorkspace and SCVMM integration for rapid provisioning?

Hello all,

My company is currently in the process of implenting a Quest vWorkspace VDI solution in combination with a Hyper-V R2 and SCVMM R2 virtualization platform which will host the VDI desktops. The Hyper-V R2 hosts are connected to two different Cluster Shared Volumes. Deploying VDI desktops using standard cloning works perfectly fine. Deploying VDI desktops using rapid provisioning however does result in the following error message: CVdiMachineScvmm::copyParentVHD: ERROR: Copy operation for "TVDI-W7-Kaal_disk_1-20101109190644.vhd" failed: ERROR: CHyperV::scvmmGetUncPathsForDriveBasedPath: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))::Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

Does this look familiar? The error message seems to be permissions related, however the Quest manuals do not specify any additional rights delegation that must be accomplished before rapid provisioning can be used. Any experiences (good or bad) in similar environments shared with us would be greatly appreciated.

In addition to this problem we encounter a second issue that might be related to the rapid provisioning problems. When we try to update the powerstate of different VDI desktops from within the connection broker console this operation fails with the following error message: VCHandlerBase::handleRequest: ERROR: CJvmErr: ERROR: CHyperV::updateVMs: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))::Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).

Other operations on the VDI desktops (like Shutdown O/S... and Power Off...) can be performed without any problems...

See the attached Word document for additional screendumps and logging.


Thanks in advance!


Tom

1 Attachment

101 Posts

November 19th, 2010 14:00

Tom,

What happens if you change "Log on As" for the Broker Helper to a domain account that will have permissions to the Cluster Shared Volumes?

Regards

Paul

6 Posts

November 22nd, 2010 08:00

Hi Paul,

Thanks for your response. Your suggestion to change the service account to a domain account did some real magic! Suddenly the update powerstate and rapid provisioning problems disappear! Rapid provisioning is still failing but that has nothing to do with the user rights and needs some additional investigation. I did change the service account to a domain administrator account. This is certainly not a best practice and cannot be implemented within the production environment so the question remains: which rights do we need to grant to the service account for the Broker Helper Service?


If I change the Broker Helper Service service account to a domain user account the service won't start. After granting local administrator rights on the SCVMM server to the service account I am able to start the service using the domain user service account. The update powerstate and rapid provisioning problems however return to the environment so it is clear that more user rights are needed for the Broker Helper Service service account. After adding the service account to the local administrator group on both Hyper-V R2 hosts the problems are solved again.

Would you say that granting the service account for the Broker Helper Service local administrator rights on both the SCVMM and Hyper-V R2 hosts is recommended by Quest? Or is it possible to do a more granular delegation of rights for the Broker Helper Service service account?

Once again thanks for helping us in the right direction!

Regards,


Tom

101 Posts

November 22nd, 2010 18:00

Hi Tom,

I am not sure why on the odd occasion the service requires it's credentials changed to a domain account.  Sorry I can't help any further but its not something I have personally got the bottom of.  Hopefully some other clever person can provide more info

Cheers

Paul

6 Posts

November 23rd, 2010 06:00

Hi Paul,

No problem, at least we have a running configuration now using a service account with administrative rights limited to the Hyper-V R2 hosts and the SCVMM server. All Quest vWorkspace functionality works perfectly fine now. Even the rapid provisioning feature is working (had to fix a problem with an old VHD). I marked this question as answered!

Thanks!


Tom

No Events found!

Top