Link to home
Start Free TrialLog in
Avatar of Paul Wagner
Paul WagnerFlag for United States of America

asked on

Best Practices For Provisioing Services VHD Storage?

We currently have this architecture:
- 2 PVS servers
- 1 File server
The PVS servers connect to the VHD images on a single mapped network drive on the file server.
User generated image

We have been experiencing network latency issues which I believe are due to the file server. I will have to shut down all of the VDAs in order to reboot the file server. This is a single point of failure for us. Bad News Bears...

This brings me to the question(s):
What is a best practice for ensuring fast and redundant VHD access for the PVS servers?

I have heard of placing a VHD on one PVS server and then replicating that to an identical folder on the other PVS servers. That way, there is less network activity. Is this something you guys do? What about replication file servers? Problems with either of those options?

I want to make sure my next architecture change is ready for 2017 and beyond (i.e.- new versions of XenDesktop and PVS)
Avatar of Cliff Galiher
Cliff Galiher
Flag of United States of America image

With SMB3, Microsoft supported clustering file servers as storage with separate computer nodes. In 2012, that means shared storage. With server 2016, with the right hardware and datacenter licenses, you can use storage spaces direct So shared storage isn't even a requirement.

Regardless though, multiple fine servers is not an inexpensive endeavor. Nor is using a fike server at all for multiple compute nodes. Fast disks, caches, no 2008/R2 can't skimp. Or performance will just suck, and it probably isn't just the network at fault.
Avatar of Carl Webster
Carl Webster
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Paul Wagner


@Cliff - At this time, we will continue to use Windows Server 2012 Datacenter for all server deployments. Are you saying that my best option is to deploy shared storage through file servers rather than put the VHD files on the PVS servers with replication?

@Carl - The robocopy script is manual, correct? I assume you prefer that to eliminate DFS-R as a possible point of failure...
So, how does that look once it is in place? You take one VHD, put it into maintenance mode, update the image, robocopy and then put into production on each PVS server?
Yes, robocopy script is manual.

Create a maintenance version, make changes, promote to test, test the changes, promote to production and run robocopy script. Script will only copy over the new or changed files which for versions, will be very small files. Exclude *.lok files and the WriteCache folder.
Sounds good. I searched your site for anything covering robocopy and didn't find it. Know of a good reference article for this?
Yes, your best option is shared storage. Replication itself introduces challenges in sync, proper lose balancing, and often increases administrative cost and other failure opportunities. I've ever seen a successful deployment survive real world ROI and DR analyses.
@Carl - I don't think that document is the right one. I didn't see anything about robocopy, PVS or Citrix.
I thought I had posted this link but it looks like it didn't make it from my phone.
That tool looks awesome, but if I'm reading the article right, it doesn't support intra-site replication.

I have a single farm, single site and two stores. From what I'm reading, the tool only works if I'm transferring to another site.
Using the tool, administrators can easily replicate a vDisk (or vDisks) from one PVS server to all other servers in the same site, and all PVS servers in another farm and site (including the export and import of vDisks and versions).
Well, that seems to be conflicting information. It doesn't support intra-site replication, but it replicates from one PVS server to all others in the same site...

I'll give it a try on a non-production vhd and see how it goes.
After making sure that I have mclipssnapin added to powershell, I still get "PCS Powershell Snap-In Not Found".

I am trying to run the GUI of the replication tool.
If you are running 64-bit PoSH, did you add both the 32-bit and 64-bit DLLs
Yes, 32 and 64 bit are registered and the transacted installs completed successfully.

User generated image
I can't run the GUI of the new tool powershell but the MCLI commands work so I'm pretty sure that the PVS snapin is working.
If I run the GUI command from the command prompt, I just get a notepad file that opens.
I had no problem after following the directions in the script's help text.

User generated image
Ya, I've tried it every which way and still get "PVS Powershell Snap-In Not Found". I'm going to get with Citrix Support and see if there's a problem with my PVS install... I'll get back to you.
Yes, your best option is shared storage
By shared storage, are you talking about a FC SAN kind of storage or using a file server that holds the vhd file(s) and is used by both PVS servers?

I got a reply from Samuel Breslow, the tool's maker, and he said that I need to be using PVS 7.7 or newer. I'll be upgrading PVS later this year. In the meantime, I'm exploring your recommendations for placing a copy of the vhd on each pvs server and then use robocopy.
You can install the 7.7 or later console on any prior 7.x PVS server to get the new PowerShell stuff.

Shared Storage can be CIFS/SMB, FC, iSCSI, NFS, NAS or similar storage tech that allows Windows to see a common storage are or drive.
Carl, this brings up a side question...
Should I just upgrade to a higher PVS version?
I was reading [url=""]this[/url] and Nick suggests going with 7.6 LTSR (although that was back in early '16), but what about all those cool features that came out later?!