I started this thread (http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/8209ecda-a9ae-48db-b564-379d9ad47d02) a while
ago while I was in the planning/daydreaming stage of the project. Now that I have the foundation complete and have completed some initial scenario testing, I would like to share some information and hopefully get some feedback.
My #1 requirement is complete site independence. There were suggestions in the previous post that I connect both Conn Brokers to the same SQL Server so that I can make sure that each site has access to the same session info in the DB. That is not an option
as this does not fulfill the #1 requirement of site independence.
Here is my current setup:
I have 2 separate AD sites in the same domain connected by a 200mbps circuit. I am planning for not only local high availability, but also DR. Hurricane Sandy opened some eyes around here. Let's say there are 50 users in each location, and each site is going
to serve as the DR site for the other. My users do not roam from site to site. If they do, I do not have a problem with them running their VDI session over the WAN. The client I am planning to use is ThinKiosk. The UI allows me to present multiple RDWA portals
for the users. Since my users do not roam from site to site, they will be instructed which RDWA site to access. If they mistakenly go to the wrong RDWA site, they will not see any collections. However, after a DR event, the user will be instructed to access
the other RDWA site in order to get their desktop (See below on how I pre-created a unmanaged collection in the DR site to support this). The architecture will look like this:
Site A:
2 - RD Conn brokers in a HA setup backed by a SQL Cluster (VMs) / 2 license servers (VMs co-located with RDCB) / 2 RD Web access servers (load balanced via netscaler) (VMs co-located with RDCB) / 2 RDVH Servers (Hyper-V Cluster with CSV) (Physical) connected
to a 3PAR SAN
Site B:
2 - RD Conn brokers in a HA setup backed by a SQL Cluster (VMs) / 2 license servers (VMs co-located with RDCB) / 2 RD Web access servers (load balanced via netscaler) (VMs co-located with RDCB) / 2 RDVH Servers (Hyper-V Cluster with CSV) (Physical)
connected to a 3PAR SAN
I will be replicating the LUNs that the VMs are on using 3PAR Remote Copy. All the other components of the infrastructure (RDCB/RDLS/RDWA) do not need to be replicated for DR as the real horsepower required for my implementation is on the RDVH and these are
physical machines. I have also come to the realization that a "VDI deployment" in fact requires that all the roles participate with each other. For example, if the RDVH servers are down, the RDCB shows no collections even though they have been configured.
I initially created my collections as managed personal collections with manual user assignment. This seemed like the right way to go at the time when not taking DR into consideration because of the ease of setup (Deploy 50 machines from a gold image/assign
the users/done). Local site HA works flawlessly in both sites when taking this approach.
The next step involved DR testing and this is where it gets interesting. The following are the steps I took to bring up the VMs from Site A to Site B:
1. I shutdown all 4 machines in Site A to simulate a failure.
2. Broke the replication on the SAN.
3. Mounted the lun in Site B on the 2 RDVH servers.
4. Added the storage to the cluster and made it a CSV.
5. Changed the path of the mounted volume to what it was in Site A. In Site A, the CSV was mounted as C:\ClusterStorage\MAS-Volume1. When bringing it into the cluster in Site B, it was mounted as C:\ClusterStorage\Volume2. Using Windows Explorer,
I changed it to C:\ClusterStorage\MAS-Volume1
6. Imported the VMs from the CSV to one of the RDVH servers in Site B keeping the unique id the same as they were in Site A.
7. Added the VMs to the cluster using cluster manager.
8. At this point, it was time to add them to a collection. The only way to do this was to add them to an unmanaged personal collection which I pre-created in Site B for this purpose.
9. The users then logged into the RDWA portal in Site B and they were able to successfully login to their personal desktops.
The next step was to fail back the desktops from Site B to Site A which did not go as planned. I was expecting the VMs to be just as they were when I shutdown the environment but the desktops did not reappear in the original managed personal collection in Site
A. The following are the steps I took to return the VMs from Site B to Site A:
1. Removed the desktops from the collection
2. Removed the desktops from failover cluster manager
3. Shut them down from Hyper-V manager. Did not delete them from Hyper-V manager as this would delete the configuration files from the disk that I would be replicating back to Site A.
4. Removed the disk from CSV
5. Removed the disk from the available storage pool
6. Dismounted the lun from the 2 RDVH servers using the SAN interface
7. Reversed the replication so that the changes made to the desktops in Site B would be reflected in Site A.
8. Mounted the lun on the 2 RDVH servers in Site A.
9. Powered up the 4 servers in Site A. At this point, the VMs were powered up and available in both Hyper-V manager and failover cluster manager. I connected to the console to confirm.
10. Opened server manager on the RDCB in Site A and saw that the collection that the desktops were originally in, was empty. Since the collection is a managed personal collection, I cannot add the desktops back into the collection.
Now some questions?
1. Is there a way to add these orphaned desktops back to the collection using powershell or otherwise?
2. Would I have been better off creating a unmanaged personal collection in Site A in the first place so that I would have been able to re-add the desktops? Keep in mind that this increases the level of administration when creating the initial pool of desktops.
3.