Wyse Converter for PCs Installation Steps

The following steps outline the typical installation of Wyse Converter for PCs

  1. Download a copy of Wyse Converter for PCs here
  2. Ensure the PC you wish to convert meets the minimum requirements and pre-requisites noted here
  3. You will also want to get access to the Wyse Management Suite software to have a centralized way to configure and manage your converted PC’s. You can get access to Wyse Management Suite by going here. Alternatively, you can manually configure the device using local GUI during testing.
  4. Run ‘WyseConverterforPCs.exe’ on your Windows 7 or Windows 10 PC you wish to convert. Note: By default, you will get a 45 day trial license as part of the installation.
  5. Follow the steps below for a typical installation:
    1. After installation completes and PC reboots you will be brought to the following screen:


8. By default, Converter for PC will auto-logon as the locked down Standard User, ‘WyseUser’ as noted in step 4. In order to login as ‘WyseAdmin’ hold down ‘shift’ key and log off and you will be brought to Windows logon screen where you can select the user account you want to log in as.

  • default credentials
    • username: wyseadmin | password: DellCCCvdi
    • username: wyseuser | password: DellCCCvdi

9. At this point, you can begin your configuration of the Citrix client, VMware client, etc… using one of 2 methods:

10. You can access documentation Wyse Converter for PC documentation here and Wyse Management Suite documentation here.

Additional support resources as noted below:

Dell TechCenter Wyse Product Support Forums – these are a great resource for getting up and running with the solutions as well as tips and tricks for troubleshooting common issues. Once you join the Dell TechCenter community you will have a variety of resources to get started!

Dell Wyse Support Site – Wyse documentation, log support incident, etc…

Available categories with forum and topic lists:

  • Wyse general forum: for discussions that, for example, span multiple categories, involve end-to-end methods, heterogeneous environments, new use cases or topics not found under the support documentation or existing discussions.
  • Wyse thin clients: includes Cloud Connect, Linux, Windows Embedded Standard, ThinOS and zero clients for Citrix, MultiPoint Server and VMware.
  • Wyse software: includes Wyse Management Suite, Wyse Device Manager, Wyse WSM and Wyse Virtualization Software

@chris_messier ~~> Subscribe to blog to get latest updates <~~


Using HTTP for StoreFront Server

In some recent lab testing I setup Citrix StoreFront to use HTTP as I was running some quick tests and didn’t need HTTPS for my test.

Unfortunately, by default, the Citrix Receiver only allows you to connect via HTTPS. If you enter an HTTP URL, it won’t allow you to save it and instead, get the following error:

“The specified server address is not secure”


Once you click, “Add”, you will get the following:

“HTTP Store requires additional configuration before being added to the Citrix Receiver. Please contact your system administrator.”


The fix for this is to edit/add the following Registry keys on the client your using the Citrix Receiver to connect from:

  1. Set HKLM\Software\[Wow6432Node\]Citrix\Dazzle\AllowAddStore to A to allow users to add non-secure stores.
  2. (Optional) Set HKLM\Software\[Wow6432Node\]Citrix\Dazzle\AllowSavePwd to A to allow users to save their passwords for non-secure stores.
  3. To enable the addition of a store that is configured in StoreFront with a TransportType of HTTP, add to HKLM\Software\[Wow6432Node\]Citrix\AuthManager the value ConnectionSecurityMode (REG_SZ type) and set it to Any.
  4. Exit and restart Citrix Receiver.

Source: Configure and install Receiver for Windows using command-line parameters

You should now be able to use an HTTP URL in your Citrix Receiver to connect to StoreFront successfully!

Hope this helps someone else down the road!

@chris_messer ~~> Subscribe to blog to get latest updates <~~

Wyse Management Suite (WMS) DNS Discovery

Once you have Wyse Management Suite (WMS) installed the next step is to automatically have your devices ‘find’ and check-in into your WMS server. This is accomplished by setting up a few DNS records that include the key WMS server information. I’ve outlined the DNS records that need to be setup and steps to setup on Microsoft Server 2012.

  • Service Location (SRV) Record
    • _WMS_MGMT
    • _WMS_MQTT
  • Text (TXT) Record
    • _WMS_CAValidation

Steps to setup Service Location (SRV) Record on Microsoft Server 2012

  1. On your DNS server navigate to the domain you want, then right click on “_tcp”, and select “Other New Records”.

  2. To setup the 2 SRV records, select “Service Location (SRV) from the options.

  3. Setup your record for, “_WMS_MGMT”. This is the FQDN of your WMS server. Use the following options below:
    1. Domain: Your domain name
    2. Service: _WMS_MGMT
    3. Protocol: _tcp
    4. Priority: 0
    5. Weight: 100
    6. Port Number: 443
    7. Host offering this service: your_wms_server, i.e. wms1.dellse.local

  4. Setup your record for, “_WMS_MQTT”. This is a service port WMS uses. This is the FQDN of your WMS server. Use the following options below:
    1. Domain: Your domain name
    2. Service: _WMS_MQTT
    3. Protocol: _tcp
    4. Priority: 0
    5. Weight: 100
    6. Port Number: 1883
    7. Host offering this service: your_wms_server, i.e. wms1.dellse.local

  5. To setup the next 2 records, navigate to the domain you want, select that node, then right click and select “Other New Records”. *Note* do not select a sub node such as _tcp for these records.

  6. Select the “Text (TXT)” Record type:

  7. Setup your record for, “_WMS_GROUPTOKEN”. This is the specific Group Token/Profile that you setup and want to use. Use the following options below:
    1. Record Name: _WMS_GROUPTOKEN
    2. Fully qualified domain name (FQDN): _WMS_GROUPTOKEN.your_domain
    3. Text: defa-labdemo1
      1. This “Text:” field is the key that you want to use. You will get this from your WMS console where you setup your group profile under the key icon.

  8. Setup your record for, “_WMS_CAValidation”. If you are not using an SSL cert (default), then this value needs to be set to ‘False’. If you are using a cert, then this would be set to “True”. Use the following options below:
    1. Record Name: _WMS_CAValidation
    2. Fully qualified domain name (FQDN): _WMS_CAValidation.your_domain
    3. Text: False (or True, if using a cert)

9. Once you have these 4 options setup, you should see the following in DNS;

The following records should be listed under your_domain:

The other 2 records should be listed under, your_domain\_tcp

10. This completes the setup. Once your device boots up and does it’s DNS lookup it will populate the proper fields on the device, in this example, Wyse ThinOS:

Dell Wyse ThinOS – SCEP and NDES Certificate Configuration

In order to request certificates manually or automatically, for example for wireless access, you need to configure Dell Wyse ThinOS to request certificates. This process requires you have the Network Device Enrollment Service (NDES) role setup in your environment. This is what implements Simple Certificate Enrollment Protocol (SCEP), which is used to issue certificates.

The setup outlined here uses a Microsoft Windows Server 2012.

In addition to having an internal Certificate Authority setup in your Active Directory environment you will also need the Network Device Enrollment Service (NDES) role installed. This is role/service that implements the Simple Certificate Enrollment Protocol (SCEP) used to issue certificates.

If not already setup, you can setup your Certificate Authority following steps here.

If not already setup, you can install and configure the NDES server role here.

  • The Setup section here outlines exact steps to setup your NDES server to start handing out certificate.


How do you setup Dell Wyse ThinOS to request certificates from your Network Device Enrollment Service (NDES).


You will first need to setup your NDES environment by following steps in requirements section. Once setup your device will be able to request certificates manually or automatically.


We will first cover the manual process to have the device request a certificate from the NDES server.

On Dell Wyse ThinOS go to System Tools\Certificates and select “Request Certificate” and the following screen will appear.

Fill in the fields as shown below making note of the following;

  1. Request URL: This will be the URL of your NDES server. Note, do not include the prefix, http, otherwise, you will get an error: “failed getting port number.”
  2. CA Certificate Hash Type: if using MS CA/NDES server then this should remain MD5. Even though your server may issue SHA256 hashed certs, MD5 is what is used to issue the request but cert will be signed however you have them configured, i.e. SHA1, SHA256, etc..
  3. CA Certificate Hash Value: You will need to browse to the following location on your NDES server; http://hostname/certsrv/mscep/mscep.dll. You will then click link, http://hostname/certsrv/mscep_admin to get the Hash Value and Enrollment Password. * NOTE * Be sure to include spaces in the Hash Value name as it shows on the webpage example below.

  4.  Enrollment Password: This will be the password retrieved from above.

3. Once you click “Request Certificate” the client will communicate with the server and return the following:

Note: Be sure to check off “Install CA Certificate” so this is also installed otherwise, the certificate will be installed under ‘Unknown’ on client and not be chained correctly.

4. Click “Install Certificates” and both certificates will be installed on the client.

NOTE: You can also verify it has the correct Signature Algorithim, i.e. SHA1 or SHA256 or whatever your CA is set to.

SHA1 Cert:

SHA256 Cert:

NOTE 1: Even if Signature Algorithm is set to SHA256, the Thumbprint Algorithm will be set to SHA1. This is expected as noted here.

NOTE 2: It is helpful to know what Signature Algorithm your CA uses. You can confirm this from here;



Note: To upgrade your CA from using SHA1 to SHA256 you can follow steps here.

5. This completes process to manually request certificates. In order to Dell Wyse ThinOS request certificates automatically you will have to do this via an INI file or Wyse Management Suite. The values you will use to do this are outlined on the 8.4 INI guide and you can get documentation here.

NVIDIA Releases Updates to NVIDIA GRID GPU line!

Today, NVIDIA announced some updates to the  line of NVIDIA GRID GPU’s for VDI. I continue to see the use cases increase for GPU’s in VDI so great to see these new releases. The increase in user density is one of the key considerations customers always ask; how many users per server/GPU? Great to see the users density continue to increase!

Here are some details from todays launch webinar and my key takeaways;

  • renamed vWorkstation license version to Quadro Virtual Data Center Workstation Software (Quadro vDWS)
  • newer P40 & P6 GPU’s do NOT have 512MB profile (min is 1Gb)
  • a new license server will be released; 5.0
  • 50% more vGPU per physical GPU (improves density!)
  • updated/newer monitoring and insight integration into VMware vRealize Operations and 3rd party’s, i.e. Liquidware Labs, Lakeside, ControlUp, eGInnovations, etc..

Updated NVIDIA GRID line:

You can see press release here.

Dell Wyse ThinOS – “Invalid Digital Signature” Message

Issue: When attempting to downgrade ThinOS firmware from version 8.4.x to earlier versions, i.e. 8.3.x, 8.2.x, etc.. you may get the following message, “Invalid Digital Signature”.

Resolution: In order to rollback the version of firmware you need to add the following parameter to your wnos.ini configuration file or WMS/CCM configuration.


Note: This will need to be added on a line starting with, “autoload=x”

For example: autoload=1 VerifySignature=no

See v8.4 INI guide for further details here.

More details on VerifySignature= parameter from the 8.4 release notes:

“The option VerifySignature specifies to verify the signature or not when updating the firmware and/or packages. It is introduced in 8.4 and later to make sure the security and integrity of the firmware and packages. If set VerifySignature to no, it will not check the signature so that to downgrade the firmware and/or packages which did not support signature. The default is yes.”

@chris_messier ~~> Subscribe to blog to get latest updates <~~

Windows Embedded Security – Threat Defense | Dell Data Protection

When looking at Windows Embedded devices people often ask about options to further secure them. In many cases, the devices are only used to access virtual desktops and the thought is often, since it’s essentially a kiosk, i.e. not running email locally, browser, etc.., then I have a limited attack surface. Although the Windows foot print on the client is smaller than a full Windows build there is still value in looking to further secure the endpoint regardless how it is used.

One thing I always suggest to customers is to check directly with their existing A/V vendor for what they have for support on Windows Embedded as some have specific solutions for it and some do not.

Dell has recently integrated it’s Dell Data Protection products into the Dell virtual desktops portfolio, specifically 2 solutions;

The one I am highlighting here is Dell Data Protection | Threat Defense for Windows thin clients. You can see a great demo of the solution below. When looking at further securing your Windows embedded thin clients this solution may be worth a look.

Introduction to VMware NSX & VDI


In my quest to learn a bit more about VMware NSX for Horizon virtual desktops I came across a few great resources I wanted to share. If your not familiar with VMware NSX you can get a good overview of this network & security solution here: VMware NSX for VDI. In order to further secure virtual desktops, NSX allows you to create rules and policies that are VM & user centric to control various levels of access to the users VM.

A lot has been talked about whether VDI is inherently more secure than a physical PC environment and the opinions vary. A great post a few years ago was hotly debated on this topic on BrianMadden.com and is worth a read.


However you look at it, the industry is evolving to help further secure virtual desktop environment’s and VMware NSX is one solution to help in that area.

A great overview of the solution is below. Another deep dive that I thought was great can be found here.

Wyse ThinOS Fails to Auto Create Printer when using Citrix Universal Print Driver


Wyse ThinOS fails to auto-create local/USB printers using the Citrix Universal Print Driver when connecting to XenApp 7.8 on Windows Server 2008 or 2012 servers.

The issue occurs if the local Wyse ThinOS printer “identification” field is set to use the “PCL5” driver which ThinOS is set to use by default. On Windows Server 2008 R2 and 2012 servers running Citrix XenApp 7.8, and other versions, they do not have the specific PCL5 driver, “HP Color LaserJet 4500 PCL 5”, installed by default. This specific HP driver is the PCL5 driver that the Citrix Universal Print driver uses and is not installed by defaults so it needs to be manually installed.


The required Windows PCL5 driver that the Citrix UPD leverages, “HP Color LaserJet 4500 PCL 5”, needs to be manually installed on the Windows Server 2008 or 2012 servers. Citrix identifies this issue in the following CTX article:

CTX140208 – Non-Windows Clients may not Autocreate Printers on Windows Server 2012 using the Citrix UPD

“As non-windows clients do not support EMF or XPS drivers, they will attempt to use PS or PCL drivers. In Windows Server 2008 R2 or Windows Server 2012, PCL5c, PCL4, and PS drivers may not be installed by default. To install them, launch the Print Server Properties window and click Windows Driver Update.”

The default Citrix UPD drivers are the following and the PCL5c is the one generally missing:

PS driver HP Color LaserJet 2800 Series PS
PCL4 driver HP LaserJet Series II
PCL5c driver HP Color LaserJet 4500 PCL 5


By default, the server does not have the “HP Color LaserJet 4500 PCL 5” installed as shown under print server properties. As shown in the registry, the Citrix UPD uses this driver to map the PCL5c driver and since its missing, auto creation from ThinOS fails.

By default, Wyse ThinOS is set to use a PCL5 driver under “Printer Identification” field so when the printer is auto created it attempts to map to the PCL5 driver on the server which is missing so auto creation fails.

By default, the Citrix UPD is set to “Use universal printing only if requested driver is unavailable” and the UPD driver preference order is set to; EMF;XMS;PCL5c;PCL4;PS.

As noted above, “non-windows clients do not support EMF or XPS” so the first driver it attempts to use is PCL5c which is not installed by default so auto creation from Wyse ThinOS PCL5 fails. If Wyse ThinOS “Printer Identification” was set to use PCL4 or PS then auto creation would succeed as those 2 drivers are installed by default.

This issue and resolution is also documented in the following PDF Technote – Wyse ThinOS and Citrix UPD Fails to Autocreate Printers.

Citrix and Skype for Business on Wyse ThinOS

One of the great new features in the release of Skype for Business on Citrix XenDesktop is the ability to use a non-Windows, Wyse ThinOS, endpoint as the client device to support new Skype features. Previously, you were limited to using a Windows endpoint running a full Windows PC or Windows Embedded thin client.

More importantly, your able to leverage the power of the Citrix Real Time Media Engine (RTME) which is embedded in the Wyse ThinOS for audio/video offload. This allows the client to offload rendering from the server VM onto the client leveraging the client CPU/memory to process audio/video. This freeing of VM resources allow greater server/desktop density and better performance as local client resources are also being used.

The key benefit of leveraging the RTME support is you eliminate the traditional VDI hair-pinning of the unified communications audio/video traffic which would route all the audio/video traffic through the virtual machines as illustrated below.

This is very well illustrated in below video.

Site feedback? chris@vditoolbox.com | Twitter | LinkedIn