What Windows 10 version for my VDI desktop?

In a VDI project one of the questions in the design phase is always:  “What version I use for my Windows 10 VDI desktop?”. Before Windows 10, the Operating System release cycle was approximate 3 to 5 years. With Windows 10 a new release management concept is introduced called “Windows as a Service (WaaS)”. WaaS includes:

  • Feature updates: Twice a year new feature updates to Windows 10 will be released
  • Quality updates: Deliver both security and non-security fixes every month on patch Tuesday such as:
    • Security updates
    • Critical updates
    • Servicing stack updates
    • Driver Updates
  • Servicing channels: Allow organizations to choose when to deploy new features. The following channels are available:
    • Semi-Annual Channel (SAC):  This is also known as the Current Branch. Receive feature updates twice a year (Around March and September/October) with a 18/30 months support cycle. SAC releases numbers are for example: 1703, 1709, 1803 and 1809. (1809 stands for 18 = 2018, 09 = September).
    • Long Term Servicing Branch (LTSB) that is now called the Long Term Servicing Channel (LTSC). LTSC shares the same codebase as Windows 10 IoT and is only available when having a Windows 10 Enterprise license. The typical use cases are embedded systems such as manufacturing or medical equipment and KIOSK systems that don’t run Office and receive new feature updates every 2 to 3 years. LTSC comes with 10 years support cycle and looks like an Operating System release cycle before Windows 10 such as Windows 7 for example. The new announced LTSC version is called: Windows 10 2019 LTSC build 1809.
  • Deployment rings: are groups of devices used to initially pilot, and then to broadly deploy, each feature update in an organization

So we can choose between two servicing channels. Here is a quick comparison table between the two channels:

LTSB/LTSC Semi-Annual Channel (SAC)
Support 10 years 18/30 months (Windows 10 Support lifecycle, link.)
Latest new features or security enhancements No Yes
Support for new hardware (silicon) and Surface No Yes
Default browser(s) Internet Explorer 11 Internet Explorer 11, Microsoft Edge
Office LTSC only supports Office 2019.

On January 14, 2020 , Office 365 ProPlus will be no longer supported on LSTC or the older LTSB version (link)

Updates and Security updates Yes Yes
Office support Yes Yes
Universal Apps Support Yes Yes
Cortana support No Yes
Windows Store No Yes
Windows Ink and MS camera support No Yes
Includes non-business apps like Xbox, Minecraft, Candy crush No Yes
ConfigMgr Express Update No Yes

OneDrive files on demand that is introduced in release 1709 is not included in LTSB 1607.

No Yes

The advice from Microsoft is to use SAC channel over a LTSB/LTSC channel. Ask yourself the question: Why do I use a Windows OS? My personal answer on this question is: Because I need to run legacy Windows apps.  So a stable OS that requires less patching and overhead can be more relevant than having the latest features which involves more management, testing  and overhead. But more and more customers are migrating to Office 365.  Office 365 ProPlus delivers cloud-connected and always up-to-date versions of Office desktop apps. This requires Windows Update OS requirements for Office 365 ProPlus which means you’re stuck with the SAC channel.

For choosing between the Professional and the Enterprise edition there is a comparison table available link. Windows 10 Enterprise has for example more advanced security and management functions and support for LTSC.

When deciding what channel and Windows 10 version release to use, ask yourself the following questions:

  • Define the business scope, requirements, constrains, assumptions and risks.
  • What Windows 10 versions are supported by my VDI brokers and software such as Citrix XenDesktop, VMware Horizon, App Volumes and NVIDIA for example?
  • Are we going to use Office 365?
  • Do my applications support the channel and version? Ask the software vendors.
  • Define a update and patch management plan.
  • Perform a Proof of Concept (PoC).

I hope this blog post makes it easier to choose the right Windows 10 version for the VDI desktop.

vCenter Server Appliance (VCSA) Failed to send http data error

When trying to upgrade the vCenter Server Appliance (VCSA) to version 6.7 using the GUI wizard, I’ve got the following error:



Failed to send http data.

I checked the logs but didn’t find any clue. When installing the VCSA using the CLI I’ve got the same “Failed to send http data” error (link).  The FQDN of the ESXi host was revolvable by DNS and reverse lookup worked.  After changing the ESXi FQDN to the IP address of the ESXi  host, the deployment finished without errors. I changed the “ESXi host or vCenter Server name” in the wizard step 3 and 4 to fix the problem.

I couldn’t find  what causes the “Failed to send http data” error. I had this error during installs and upgrades in different environments. Hopefully someone can explain what happen or it is a bug that will be solved in future releases.

vCenter Server Appliance (vCSA) automated/unattended deployment

Installing the vCenter Server Aplliance (vCSA) automatically using an unattended scripted deployment can be done by command line (CLI) in combination with a JSON config file.  In this example an embedded vCenter Server Appliance with the Platform Service Controller (PSC) and vCenter Server role will be deployed.


  • This example is based on a Windows Operating System. Using a Linux or MAC OS is also possible but not highlighted in this blog.
  • Make sure the FQDN of the vCSA is resolvable by a DNS server and check if reverse lookup works.

Steps to perform:

  • Download the vCenter Server Appiance (VCSA) ISO (version 6.5 or 6.7)
  • Mount the ISO
  • The CLI installer for Windows requires a Microsoft Visual C++ Redistributable version 14.0. This requirement can be checked with the following command:
  • Navigate to the JSON templates. The vCSA ISO contains template JSON files that can be used for deploying the vCSA. The templates can be found on the ISO in the following map:

The types of templates are avalable:

           embedded_vCSA_on_*.json: Platform Services Controller (PSC) and vCSA
                                     together on one system
            PSC_on_*.json:           Only a PSC
            vCSA_on_*.json:          Only a vCSA
            *_on_ESXi.json:          Install onto the ESXi host specified in the JSON
            *_on_VC.json:            Install onto a host managed by the vCenter
                                     instance specified in the JSON file
  • Edit a template “embedded_vCSA_on_ESXi.json or use the example below with you’re favorite editor (I use Notepad ++) and save it to a writable location (in the CLI syntax you need to point to this modified JSON file). The template contains the minimal parameters needed to deploy the embedded vCSA. The vCSA will deployed as tiny (2 vCPU, 10 GB memory, 300 GB storage). An overview of all parameters that can be used are found here, link.

Example JSON file to deploy an embedded vCenter Server Appliance with the PSC and vCenter components:

    "__version": "2.13.0",
    "__comments": "Sample template to deploy a vCenter Server Appliance with an embedded Platform Services Controller on an ESXi host.",
    "new_vcsa": {
        "esxi": {
            "hostname": "",
            "username": "root",
            "password": "VMwaaare01!",
            "deployment_network": "vlan13-srv",
            "datastore": "SSD-M2-01"
        "appliance": {
            "__comments": [
                "You must provide the 'deployment_option' key with a value, which will affect the VCSA's configuration parameters, such as the VCSA's number of vCPUs, the memory size, the storage size, and the maximum numbers of ESXi hosts and VMs which can be managed. For a list of acceptable values, run the supported deployment sizes help, i.e. vcsa-deploy --supported-deployment-sizes"
            "thin_disk_mode": true,
            "deployment_option": "tiny",
            "name": "vcsa03.lab.local"
        "network": {
            "ip_family": "ipv4",
            "mode": "static",
            "ip": "",
            "dns_servers": [
            "prefix": "24",
            "gateway": "",
            "system_name": "vcsa03.lab.local"
        "os": {
            "password": "VMware01!",
            "ntp_servers": "pool.ntp.org",
            "ssh_enable": true
        "sso": {
            "password": "VMware01!",
            "domain_name": "vsphere.local"
    "ceip": {
        "description": {
            "__comments": [
                "++++VMware Customer Experience Improvement Program (CEIP)++++",
                "VMware's Customer Experience Improvement Program (CEIP) ",
                "provides VMware with information that enables VMware to ",
                "improve its products and services, to fix problems, ",
                "and to advise you on how best to deploy and use our ",
                "products. As part of CEIP, VMware collects technical ",
                "information about your organization's use of VMware ",
                "products and services on a regular basis in association ",
                "with your organization's VMware license key(s). This ",
                "information does not personally identify any individual. ",
                "Additional information regarding the data collected ",
                "through CEIP and the purposes for which it is used by ",
                "VMware is set forth in the Trust & Assurance Center at ",
                "http://www.vmware.com/trustvmware/ceip.html . If you ",
                "prefer not to participate in VMware's CEIP for this ",
                "product, you should disable CEIP by setting ",
                "'ceip_enabled': false. You may join or leave VMware's ",
                "CEIP for this product at any time. Please confirm your ",
                "acknowledgement by passing in the parameter ",
                "--acknowledge-ceip in the command line.",
        "settings": {
            "ceip_enabled": true

The first deployments failed when using the FQDN ESXi hostname in the JSON file, with the following error:

OVF Tool: Transfer Failed

OVF Tool: Error: Failed to send http data

Deployment failed. OVF Tool return error code: 1

I checked the logs but didn’t find any clue. The FQDN of the ESXi host was revolvable by DNS but after changing the ESXi FQDN to the IP address of the ESXi  host in the JSON file the deployment finished without errors.

  • Perform a template JSON verification without installing:
vcsa-deploy install --accept-eula --verify-template-only <JSON file path>
  • Perform the actually deployment
vcsa-deploy.exe install --accept-eula --acknowledge-ceip --terse --no-ssl-certificate-verification <JSON file path>

When the unattended deployment finished, an embedded vCenter Server Appliance with the Platform Service Controller (PSC) and vCenter Server role is ready to rumble.

I created a GitHub repository for the deployment and parameters, link.

VMware documentation about the CLI deployment can be found here, link.