VDI Matters! (things that deal with VDI)

Hey folks, it’s been a little while since I’ve posted and time for some fresh content here.  This comes from a recent customer I worked with that had a very strange performance problem with a system they recently purchased.  The customer had ordered a couple of  Dell Precision T5820 systems with an nVidia GTX1080 and Tera2240 card and they were using some older Wyse P25 endpoints for remote workstation access (a pretty nice setup for doing remote graphics).

The initial problem called in on was that one of the systems would lose its CMOS Time when the system was started up remotely from the P25.  Specifically, when the customer would turn on the workstation from the front power button of the Tower – everything was fine, but when the “power on” was sent remotely from the P25, the system would power on and stop pre-POST with the message “CMOS Time not set, Press F1/F2 to continue” – which everyone knows means the CMOS either got reset or lost it’s time configuration… but in this use case, why??

What is a Teradici Card?

A Teradici Host Access card is a pretty impressive widget for doing HD graphics (CAD, design, modeling) from a remote location.  The HAC can accept input HD Video from an onboard video card, scrape 6 different functions off the motherboard via the PCI bus (keyboard, mouse, audio and several USB device channels), then compress and packetize all of those to send across your network to a hardware or software client with almost lossless video.  This provides the end user access to a high quality user experience while the system stays secure at the office or in a datacenter (meaning: the data stays secured).

One additional cool feature of the Teradici Host Access Card (HAC, from here forward) is that you can remotely power up/down a system that has a Tera card installed.  This is accomplished on the HAC through a 2-wire, power management cable that connects a jumper on the HAC to the Remote Power jumpers on the motherboard of the system where the HAC is installed (picture below).

Installation:

The picture above is a Tera2220 with Power Managment Cable attached to the card (white socket/circle).  It’s a standard PCIe device and just plugs into a PCI slot in your system.  If you have a dual socket system and only have one socket populated, check your motherboard documentation on which PCI slots are driven by the installed processor.  If you happen to be in that scenario and plug it into a PCI slot that belongs to the empty 2nd socket, the HAC will power up (it pulls power through the PCI slot) and you will be able to access the WebInterface for the device (AWI), but it won’t be able to interact with the system (mouse/keyboard) because there’s no processor handling the I/O from that PCI slot.  This scenario isn’t an uncommon problem and we’ve diagnosed it quite a few times.

Once installed in the PCI slot, there is also the Power Management Cable (PMC) to deal with.  One end of the PMC should already be attached to the HAC.  At the other end is what equates to a “splitter”.  The power management cable can be used on systems with a Remote Power jumper on the motherboard, or on systems that only have a single  power control jumper for the bezel mounted Power Switch.  The port circled in red above is the connector that will be plugged into the Remote Power socket on the motherboard.  The connector I’m holding (blue circle) is only used if you do not have the 2nd Remote Power jumper on your motherboard.  In that instance, you will unplug the the bezel power cable plugged into the motherboard jumpers and plug the bezel power cable into the socket I’m holding, then plug the red circled connector into the power jumpers on the motherboard.

After that, use the supplied DisplayPort to miniDP cables to jumper the video out from your HD Graphics card into the Teradici HAC.

That’s it for installation.  As long as you know where the Remote Power socket _is_ on the motherboard…

The Fail part…

After a lot of remote troubleshooting of the System, checking BIOS, sending a CMOS battery, Tera HAC configuration and other checks which I won’t bore you with, we got down to asking the customer for a picture of the area around the PCIe slots where the HAC was plugged in to see how “what is plugged in to where”.

Once we got the picture of the motherboard, the picture became much clearer (all pun intended).  Unfortunately, the only obvious jumpers exposed anywhere near the PCIe slots on the T5820 were:  BIOS Password Reset & CMOS reset.  The BIOS Password Reset jumpers are covered/jumpered by default on Dell systems and the CMOS jumpers were the only uncovered jumpers available (in the Red Circle below).

Somehow, some way, the Tera card’s Power Mgmt Cable had been plugged into the CMOS reset jumpers.  So when they executed a remote power command from the P25, the Tera card was closing (read as:  jumpering) the CMOS Reset and wiping the configuration.  This explains how the front Bezel power-on didn’t exhibit the issue when used, but would wipe the config when doing power control from the Wyse P25.

Fortunately, the correct jumper socket for Remote Power was found next to all the Bezel control jumpers at the opposite edge of the motherboard from the PCI slots (noted by blue arrow, below), hidden under all the cables for the Bezel controls (and the socket wasn’t labeled either – that detail was pushed back to Engineering).

Once the Power Mgmt Cable was tapped into the Remote Power control socket, the system started working as expected.

Have y’all seen any odd outcomes from what would seem like a routine card installation??  Let me know in the comments…

Extra Resources:
Teradici Installation Instructions

Finding/Setting IP address on Teradici

** Update 10/4/2018 –  I just tested out RDS installation on Server 2019 in workgroup mode and the same configuration issues will be experienced and the process below will get you through it.  -Scott **

Ok, so if you are here – you already know this is not a recommended configuration for Remote Desktop Services, but you want to do it anyway.  With my experience in Technical Support with a now very large computer company, your odds of succeeding in this endeavor if things go wrong are about 50/50, but let’s get you some info to assist and get you the best odds of winning.

Remote Desktop Services (RDS) is designed to be in a Microsoft Active Directory integrated environment, meaning there is a writable DNS server in the environment and an AD User/Service database to pull environment information from.  Along with the needed AD pieces, there is also the issue of the RD Connection Broker service won’t install, due to the lack of permissions – which means you do not have an RD Management interface with which you can configure your RD environment.  So given these fail points, without taking other steps you will wind up with an RD environment that cannot be accessed due to RD Licensing configuration failure (yeah, you do need RD licenses, too).

Here’s what you will see in EventViewer:System logs:

And when you go to RD Licensing Diagnoser, you’ll see this:

And looking in RD Overview in Server Manager, you get:

Since you don’t have the GUI to work with to configure RD Licensing with, we’re going to have to go about this differently.

** Also, if you installed RDS on a system with Active Directory installed, you may, or may not, get the Overview GUI installed on your server (error pic above).  Even if you do have the GUI installed in this scenario – it’s almost a 100% chance that the Licensing Configuration through the GUI will not work.  The tweeks below work to fix RD Licensing for both Workgroup and AD scenarios.

Open up Regedit and navigate to: HKLM\Software\Policies\Microsoft\WindowsNT\TerminalServices

You’ll need to add two keys:

• LicenseServers  (string value), with a value of your FQDN of the License Server instance.  One option instead of using a FQDN is just use “localhost” or “127.0.0.1” to point the RDS instance to look on the workgroup server for the RD Licensing Instance (as long as RD Licensing is on the same workgroup system).
  • **edited/added the loopback IP address here 2/6/19**
• LicensingMode  (32-bit DWord), with one of 2 values:  2 – for Per Device mode  or 4 – for Per User mode

Once you have those set, restart the RD Licensing Service and RD Session Host Service and then re-run the RD License Diagnoser – it should run clean now.

** Other important note here…  An RD Licensing instance can handle Per User and Per Device licenses and hand them out with no problem to multiple RD Session Hosts, but a single RD Session Host can only ask for 1 type of RD License – either Per User or Per Device.  This is a common issue where Per User licenses are purchased and installed, but the Default licensing mode configuration for RDSH is “Per Device”.  So, RD will hit your RD license host and ask for a Per Device licenses, which it doesn’t have.  Changing the licensing mode to “Per User” fixes the issue.

Good lucks out there!  Comments??

Hey folks, it’s been a little while since I’ve shared something.  But this afternoon I found something worthy.

A customer has some Wyse 3040’s (ThinOS) already deployed, connecting to Horizon View 7.3 on the back end, and now they want to test performance with the Blast protocol instead of PCoIP.  The customer is using Wyse Management Suite to configure their endpoints and is using only 1 endpoint to test with.

How to do this???

The customer is using ThinOS 8.5_012 on their endpoints, but the process is pretty much the same for most WMS/ThinOS clients that support Horizon View.

First, the endpoint needs an additional package deployed to support Blast Protocol.  In ThinOS, the Horizon View Client only supports RDP & PCoIP protocols and manual configuration will only display those protocols in the drop down menu.

If you are using On Premise WMS (locally hosted):

1. Navigate to where you unpacked your downloaded ThinOS package.
2. Drill into the PKG folder and locate:  horizon.i386.pkg
3. Copy that file to your repository on the server that is hosting WMS (..\WMS\LocalRepo\repository\thinClientApps)
4. Wait a few minutes for WMS to update it’s inventory.
5. Go to App & Data on the top toolbar & on the Lefthand side:  App Policies – Thin Client.
6. Create a policy to deliver the new package to the endpoint & confirm the installation by checking SystemTools:Packages and verify that Horizon.i386.pkg is installed.

If you are using Cloud Based WMS, the packages for your ThinOS should already be listed and available.

Once that is done, then just deploy your configuration policy to the endpoint device groups and test.

Hope this helps.

Any good VDI Techie knows that College computer labs and VDI were made for each other.  Before XenDesktop & Horizon View took over the leading roles in “We Do VDI Better” in the last three years, there were plenty of computer labs using Remote Desktop services and VDI-in-a-Box.  And before that, Active Directory attached PC’s with some well documented re-imaging process for those times when “somebody did something and now it doesn’t work”.  As times have changed and needs for protecting data have increased, offering accessible computing resources to College students (BYOD or not) have also increased, and a robust solution computing solution for campus environments has always been just out of reach.  Until recently….

The University of Arkansas was recently awarded this year’s Tech Target’s Access Innovation Award for their implementation of a campus-wide accessible VDI based end-user computing project.  The University of Arkansas partnered with DellEMC and leveraged their VDI Complete Solution – a package of VMware vSAN HCI solution, VMWare Horizon View, nVidia GPUs, DellWyse Thin clients & Industry proven PowerEdge R730 servers.  DellEMC was able to provide a sturdy, high performance solution (in computing and graphics processing) to cover 27,000 students on the Fayetteville, AR campus through Lab accessed resources and “roaming” access through campus WiFi and off-campus access.

—————————————————————————————————————————–

Hi folks,

I recently worked a case with a customer who was setting up a dedicated remote graphics workstation leveraging a Teradici Host Access card for remote access.  The problem they were experiencing was the DellWyse 7030 was connecting to the Teradici card, but they were getting a message “No Signal”.

Here’s the hardware setup:

• Dell Precision R7910 Workstation
• Windows 10
• nVidia Quadro K6000 video card
• Teradici Tera2240 Host Access Card (4 miniDisplayPort)
• DellWyse 7030 Zero Client

I had never seen a Quadro K6000 yet, so just to figure out the “lay of the land” the customer sent us a picture of the back of the server – with the Tera card and Video card and current cabling.  The K6000 is kinda unique, aside from having over 2000 cuda cores for graphics processing and using a single-PCIe and two slots wide.  That’s all pretty cool, but the uniqueness is that it has 4 video out ports on the back and it’s made for single user/client video.

However, there’s a problem with the configuration of the 4 ports that can cause some issues when trying to leverage a Tera2240 card.  The K6000 has 2x DisplayPort outputs and 2x DVI outputs, and that’s a problem when trying to light up 4x miniDisplayPort connections to feed 4 monitors on the 7030 endpoint.

The Tera2240 is designed to work with DisplayPort connections only, so it’s packaged with 4x DisplayPort to miniDisplayPort cables to do the Interconnection between the video source (DisplayPort) to the Tera card (miniDisplayPort).

Initially, the customer had configured the solution as in the picture below.  The DisplayPorts on the K6000 are shaded in the picture, but I highlighted them with the Blue circle (there’s a better pic further down), but note that they are unused.

From the image above, the customer had purchased two consumer grade miniDisplayPort (mDP) to DVI adapters to make the connection between the DVI output on the K6000 and the mDP input on the Tera2240.  It seems like it should work because there’s a DVI port on one side and mDP on the other side, right??

Not understanding the solution, they wired it up as above and didn’t understand why it didn’t work and they were getting a “No Signal” message after connecting to the Tera card from the DellWyse 7030.

Let’s break down the parts in the solution real quick, which will help us understand how to put it together and be able to get proper video to the endpoint:

Quadro K6000:  The Quadro K6000 does have 4 video out ports – 2x DP & 2x DVI.  However, there is “precedence” in the default video ports as seen in the host operating system, as to which port has Monitor1, Monitor2,…, Monitor4 video out.  This can be changed inside the OS, but the default is best described by a picture.  Ports indicated as 1 & 2 are your DisplayPort outputs, 3 & 4 are your DVI outputs.

Tera2240:  As shown below, the Tera2240 card has 4 mDP inputs and are labeled in order.  So, this is just as simple as matching up Video Out ports (from K6000 above) to the Tera2240 mDP inputs in the image below, right??

Well… no.  There’s still a problem – with the converters.

Converters:  After doing some research on video signaling and conversion from DP->DVI and DVI->DP, these are two very different processes.  DisplayPort is a much newer and robust digital video & data transfer interface (go to market ~2008) and is backwards compatible with VGA, DVI and HDMI displays formats.  This is accomplished with a simple passive (read as:  non-powered) adapter that takes the DP signal stream input and strips out everything but the needed signal (based on the adapter output type) and putting it out on the other side of the adapter.  Unfortunately, up-converting from VGA/DVI/HDMI to DP takes a bit more work from a processing side and requires a power input to assist with the computational processing.

So it is important to know what your video source is and what your output is supposed to be and that you get the right adapter for it.

So, putting all of these pieces together, here is what the configuration should look like to provide a Quad Monitor experience leveraging the K6000, Tera2240 & have the video come out properly on the Dell Wyse 7030 Endpoint.

• K6000 ports 1 & 2 will use the provided DisplayPort to mDisplayPort cables (noted in blue) to connect into ports 1 & 2 on the Tera card.
• Ports 3 & 4 will use a short DVI cable out (noted in red), which will need to plug into an Active/powered DVI –> mDP up-converter (noted in tan) to translate the DVI signal into a DP capable signal, plugging into ports 3 & 4 on the Tera card, with likely an assist from USB power off the back of the server to power the Active up-converter.

Here’s a look at some examples of Active Up-converters to go from DVI–>mDP :
Here…   and…   Here…   off of Amazon.com  (Disclaimer:  I’m not necessarily recommending either of these, they are just examples.  Verify with the vendor that it will work or they have an equitable return policy)

There’s a lot of good info on the DisplayPort spec: here.

Hope this helps.  Hit me with questions.