Citrix XenServer 7.6 – Adding to a Clustered Pool

Here are the steps for adding a new node to an existing clustered pool:

  1. Make sure all VMs on the existing clustered pool are in maintenance mode, as well as shut down.
  2. Disconnect the storage repository by right-clicking and selecting “Detach”. Be sure to check the “General” tab on the storage and that it shows the existing connections are broken.
  3. Disable clustering by right-clicking the cluster in XenServer, selecting Properties, and then uncheck “Clustering”
  4. Right-click the new node in XenCenter and select “Add to pool”
  5. Once added, make sure an IP is assigned to the cluster network interface, and attempt to ping another node in the network via the new node’s console in XenCenter.
  6. If the ping is successful, re-enable clustering.
  7. Reconnect the storage by right-clicking the storage repository and selecting “Repair”.

WMS Remote Shadow Error: SSL Handshake Fails

Remote Shadow is essential in my environment for assisting thin client users. However, I was surprised to get a consistent error when attempting to use that functionality via WMS. Every session attempt would fail after entering the VNC password with a “SSL_HANDSHAKE” error.

Solution: Use Firefox

For some reason, the UI of WMS is broken in other browsers (this was tested on both a Windows 10 and Server 2016 machine).

Wyse Management Suite for Windows 10 IoT thin client deployments

Documentation and support for Wyse Management Suite is sparse, so I wanted to include some basic details I learned from deploying to a small-to-medium business environment.

Image Policies and Groups

In Wyse Management Suite (WMS), Groups are used to separate different thin client devices to apply different sets of Policies. These Policies determine what image is to be applied to the device, as well as any specific configuration instructions (removing access to Control Panel, setting a wallpaper, etc.). I’ll use the terms “image” and “image policy” interchangeably through this write-up, as the image policy in WMS is just a configuration package for the thin client disk image. In my current environment, there are three different models of Wyse thin clients in production: 5020, 5060, and 5070.

In order to apply the correct image to each model, the Groups should only contain those of the same model. Here is an example of the Group structure in my environment (bold text indicating top-level groups, bullet points indicating sub-groups):

Production

  • 5020-Prod
  • 5060-Prod
  • 5070-Prod

Staging

  • 5020-Stage
  • 5060-Stage
  • 5070-Stage

Here’s an explanation as to why these specific sub-groups are necessary: WMS does not allow for a specific image policy to be chosen when attempting to image a single device. However, when choosing to apply an image across all devices in a group, WMS allows for a choice between image policies. In this environment’s repository, we have two images for each model: an image for the default standard image available from Dell Support, and a customized image created for the specific environment (pulled directly from a thin client).┬áThe custom image is necessary for production, as the standard Dell image includes a severely outdated version of Citrix Receiver, while the custom image was pulled with a current release version of Citrix Workspace (the successor to Receiver).

A problem I initially ran into was having two different image policies assigned to the same group, so when trying to image a thin client with our custom image, the default image would get flashed instead. I had no way to choose before starting the imaging job. Creating a sub-group specifically for the imaging process was the only way to choose the custom image.

Imaging a single device

  1. Make sure the device is in the correct group for the image you want to flash onto it.
  2. Go to Devices at the top
  3. Select the checkbox for the device and go to More Actions
  4. Select Upgrade ThinOS/WES Image

After a minute or so, a prompt will appear on the device and the imaging process will begin.

Modern Team Sites and Site Collection Administrators

This is a brief solution to an issue I encountered while working on implementing Microsoft Teams in an Office 365 environment. When a “Team” is created, an Office 365 group, a shared OneNote notebook, a shared mailbox, and Sharepoint Modern Team Site are automatically created as well. However, even when the Team is created by a Global Office 365 Administrator, that Administrator is not the Site Collection Administrator for the generated Team Site.

This is expected behavior from Sharepoint, as the Site Owner and Site Collection Administrator roles are meant to be separate (the Site Owner being a normal employee while the Site Collection Administrator typically being a member of the IT department). The way to resolve this is:

  1. Install the Sharepoint Online PowerShell module
  2. Open the Sharepoint Management Shell
  3. Connect to your O365 Tenant
  4. Run this command for each site collection:

Set-SPOSite -Identity contoso.onmicrosoft.com/sites/Test -Owner admin@contonso.onmicrosoft.com -NoWait

EDIT: I noticed that many of the Teams that I created as the Office 365 Global Administrator did not have this issue. I only encountered this sporadically.

Offline Files and DFS

A few months ago, my boss and I were stuck on a user’s issue: they continually reported drops of a network drive while on a VPN connection. The user would navigate the drive’s folder structure, going many subfolders deep, but would then get disconnected randomly: left only with their Offline Files cache of their Desktop and Documents. They would then have to uncheck the “Work Offline” button in File Explorer in order to get access to network files, and start the digging process over. Naturally, this was very frustrating for the user, so we began analyzing what factors could’ve been at play.

Many variables came to mind: the VPN settings themselves, the Offline Files cache, the WiFi chipset in the user’s laptop, their home WiFi connection, etc. We tested the VPN connection to the drive using different networks and hotspots, purchased a USB WiFi adapter and disabled the existing WiFi chipset, along with verifying the VPN configuration on the firewall, but the solution was actually related to the drive itself.

This network drive (we’ll call it the Z: Drive) was a DFS share used by the entire company, and this was the first issue we had heard regarding connectivity issues over the VPN. The Z: Drive was also responsible for storing users’ Desktop and Documents for folder redirection. After considering that the issue could be related to the DFS share, we set up a test where we had two SMB shares (one on a Server 2012 R2 machine and one on a Server 2016 machine, as Server 2016 was the host OS for the DFS target) mapped as network drives alongside the Z: Drive. We then connected to the VPN and waited for a drop to occur. The Z: Drive would drop and be inaccessible, but at the same time, the other two network drives could be accessed without issue.

Thus, the resolution: disabling slow-link mode via Group Policy. Slow-link is part of the Offline Files feature in Windows, where the client computer, based on bandwidth and/or latency values, transitions to using the Offline Files cache of network files rather than accessing them directly. This transition would disconnect users entirely from the folders in the Z: Drive they needed, as the Offline Files cache only contained their Desktop and Documents.

After this solution was implemented, we received no more complaints from the user, and in fact, other laptop users came out of the woodwork to state that they were having a much more stable experience with the Z: Drive. The lesson learned here was that we spent too much time focusing in on common problem elements (the VPN, the WiFi connection) instead of considering all the aspects of the problem.

TL;DR: The solution was to disable slow-link mode via Group Policy.
Our GPO was configured as such:

Computer Configuration -> Administrative Templates ->

Network -> Offline Files -> Configure slow-link mode = Disabled