Horizon View with Unidesk Network Flows and Operations

One of my customers recently asked me a question about his VDI environment.  I had given him a copy of my View 5 network flows diagram, but he was curious about what those flows actually do during day to day operations.  This struck me as a pretty important question, as the diagram is useful by itself when planning a new deployment, but when troubleshooting a problem it doesn't really help you to know where to look.  So, I typed up some explanations of what the system is doing on the back end during some common front end operations.  Since that's useful info, I figured that I should probably post it here in case it can help anyone else.

External User Connections


  1. The External View Client initiates the TCP 443 connection to the Security Server.  This connection is used until the user selects the desktop to which they want to connect
    1. After the user initiates the TCP 443 connection, the Security Server connects to the Connection Server
    2. The Connection Server authenticates the user to the Domain Controllers
    3. The Connection Server determines which desktops the user is entitled to and passes that information back to the Security Server
    4. The Security Server presents the list of desktops to the user
  2. After the user connects to a desktop, the Security Server establishes the TCP 4172 connection to the VDI Desktop and then the UDP 4172 connection.  The TCP 32111 connection is used when USB redirection is enabled and the TCP 9427 connection is used for Multimedia Redirection.

Internal User Connections


  1. The Internal View Client initiates the TCP 443 connection to the Connection Server.  This connection is used until the user selects the desktop to which they want to connect
    1. After the user initiates the TCP 443 connection, the Connection Server authenticates the user to the Domain Controllers
    2. The Connection Server determines which desktops the user is entitled to and passes that information back to the View Client
  2. After the use selects a desktop, the View Client establishes the TCP 4172 connection to the VDI Desktop and then the UDP 4172 connection.  The TCP 32111 connection is used when USB redirection is enabled and the TCP 9427 connection is used for Multimedia Redirection.

Desktop Creation/Maintenance


  1. The VDI Administrator establishes the TCP 443 connection to the Unidesk Manager where commands are received.
  2. The Unidesk Manager communicates with the CachePoint Servers on TCP 61616 to relay appropriate commands (information about what Layers they need and what desktops they run, etc.)
  3. The Unidesk Manager and/or CachePoint Servers communicate with the vCenter Server on TCP 443 to issue appropriate commands (vmdk file copy operations, VM power operations, changes to VMX configuration files, etc.)
  4. The vCenter Server uses its various connections to the SQL Server and the ESXi Servers to fulfill those commands.
  5. The Unidesk Manager communicates with the View Connection server on TCP 390 to perform any View related operations (adding desktops to Pools, querying the list of desktop pools, setting maintenance mode on desktops, etc.)
  6. The VDI Desktop communicates to the CachePoint Servers and the Unidesk Manager on TCP 61616 to relay information about the desktop’s current state (if it is available after a maintenance operation, who is logged into it currently, etc.).

Comments

Post a Comment

Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,

Popular posts from this blog

Clone a Standard vSwitch from one ESXi Host to Another

One of my customers is standardizing the configurations on their HP C7000 enclosures (they've been set up at various sites by various administrators with varying involvement from the architecture team).  As such, we need to stand up some temporary resources so that we can take down the main enclosure for reconfiguration.  That's fine, we can easily ship a smaller enclosure to each site for temporary compute resources.  Some of the sites are using Standard vSwitches, so we need to be able to quickly copy the networking configuration over from their existing blades to these new, slightly different blades.  As I see it, we had 2 good options: 1) Capture a Host Profile with the desired vSwitch configuration.  Delete every other component of the Host Profile so that only the networking section is applied; design the new ESXi hosts so that the vSwitches'll work with the old vmnic-to-vswitch configurations. 2) Write a script to clone the vSwitch from ones ESXi host to another.
Read more

PowerShell Sorting by Multiple Columns

PowerShell's Sort-Object cmdlet is super useful, especially when preparing output for human consumption.  A few people have found my blog while looking for more information about its use, specifically while looking for how to sort by multiple columns (well, properties, technically).  I've never done so (much less written about it), so I hope those folks found answers elsewhere.  But, it got me curious... and it turns out that it's really easy. The Technet article on Sort-Object has the answer directly spelled out: just use commas to create a list of properties to sort by (in order to precedence).  Let's look at some examples!  First, prepare a variable with some good sortable data: $myData = get-eventlog System -newest 25 And then we can get to sorting!  Say you want to sort primarily by EntryType (Warning, Information, Error) and then by Source.  Easy-peasy: $myData | sort EntryType,Source How about if you want it to be in descending order?  Yeah, there&
Read more

Deleting Orphaned (AKA Zombie) VMDK Files

A problem that most Virtualization Administrators need to deal with is Orphaned VMDK files (or Zombie VMDK files, as some people call them).  These are Virtual Machine hard drive files that are just hanging out, taking up storage, but are attached to no VMs.  How can this happen?  Well, the most common way is when an administrator needs to delete a VMDK but isn't quite ready to commit... so, after pressing "remove", they select "remove from virtual machine" rather than "remove and delete files".  The intent is always good: "I want to be able to restore this if it turns out to be necessary... so I'll just come back and delete it next week if nothing breaks!"  But, of course, next week something else happens and the file doesn't get deleted.  After a little while, it turns into "which files did I rename, again?" and nothing seems to happen. So, how do you deal with these orphaned files?  Well, a few years ago I found a scrip
Read more