Category Archives: Windows

Windows vCenter Server 6.7 Install Guide

VMware vCenter Server pools ESXi host resources to provide a rich feature set delivering high availability and fault tolerance to virtual machines. The vCenter Server is a centralised management application and can be deployed as a virtual appliance or Windows machine. It should be noted that vCenter 6.7 is the final release where Windows modules will be available, see here for more information. All future releases will only be available in VCSA form, if you have not already started planning migration to VCSA see vCenter Server Appliance 6.7 Install Guide and Migrating Windows vCenter Server to VCSA 6.7. This post gives a walk through on a clean installation of vCenter Server 6.7 on Windows Server 2016.

vCenter 6.7: Download | Release Notes | What’s New | VMware DocsvSphere Central

Software Considerations

  • The operating system should be 64 bit and Windows Server 2008 SP2 or above.
  • For environments with up to 20 hosts and 200 VMs the bundled internal PostgreSQL database can be used.
  • If an external database is used it should be Microsoft SQL Server 2008 R2 SP2 or above, or Oracle 11g or 12c. You can review a full list of compatible versions at the Database Interoperability Matrix.
  • The account used for external database authentication requires Oracle DBA role, or SQL sysadmin server role, or db_owner fixed database role. For a full list of explicit permissions review the Database Permission Requirements.
  • You must check compatibility of any third party products and plugins that might be used for backups, anti-virus, monitoring, etc. as these may need upgrading for vSphere 6.7 compatibility.
  • Any hosts you want to add to vCenter 6.7 should be running version 6.0 or above, 5.5 and earlier will not work and do not have a direct upgrade path to 6.7.
  • To check version compatibility with other VMware products see the Product Interoperability Matrix.
  • The points above are especially important since at the time of writing vSphere 6.7 is new enough that other VMware and third party products may not have released compatible versions. Verify before installing vSphere 6.7 and review the Release Notes and Important information before upgrading to vSphere 6.7 KB.

Architectural Considerations

  • As noted above the Windows modules will not be included for future versions, therefore the recommended installation method for vCenter 6.7 is the vCenter Server Appliance (VCSA).
  • When implementing a new vSphere 6.7 environment you should plan your topology in accordance with the VMware vCenter Server and Platform Services Controller Deployment Types.
  • A series of videos covering vCenter Server and Platform Services Architecture can be found here. If you require further assistance with vCenter planning see also the vSphere Topology and Upgrade Planning Tool here,
  • Most deployments will include the vCenter Server and PSC on one server, following the embedded deployment model, which I will use in this guide.
  • Greenfield deployments of vSphere 6.7 can take advantage of Embedded PSC with Enhanced Linked Mode, providing native vCenter Server HA support, and removal of SSO site boundaries.


Hardware Considerations

  • A Windows based vCenter Server can be installed on either a physical or virtual machine. Windows vCenter Server with embedded PSC requires the following hardware resources:
    • Tiny (up to 10 hosts, 100 VMs) – 2 CPUs, 10 GB RAM.
    • Small (up to 100 hosts, 1000 VMs) – 4 CPUs, 16 GB RAM.
    • Medium (up to 400 hosts, 4000 VMs) – 8 CPUs, 24 GB RAM.
    • Large (up to 1000 hosts, 10,000 VMs) – 16 CPUs, 32 GB RAM.
    • X-Large (up to 2000 hosts, 35,000 VMs) – 24 CPUs, 48 GB RAM – new to v6.5.
  • Where the PSC is deployed on a separate machine this requires 2 CPUs, 4 GB RAM.
  • Environments with ESXi host(s) with more than 512 LUNs and 2048 paths should be sized large or x-large.
  • The Windows vCenter Server requires the following free disk space for installation: (the first 2 may not necessarily be the system drive depending on installation location) Program Files 6 GB, Program Data 8 GB, System folder 3 GB. The PSC machine requires; Program Files 1 GB, Program Data 2 GB, System folder 1 GB.
  • There are a number of Intel and AMD CPUs no longer supported with vSphere 6.7, review the Release Notes for a full list of unsupported processors.

Other Considerations

  • It may be necessary to temporarily stop any third party software which could interfere with the installer, such as anti-virus scanner.
  • If the vCenter Server services are running as a user other than the Local System account then the user must be a member of the administrators group and have the following permissions; log on as a service, act as part of the operating system.
  • Verify that the local machine policy allows assigning Log on as a batch job rights to new local users.
  • All vSphere components should be configured to use the same NTP server.
  • FQDN resolution should be in place when deploying vCenter Server.
  • A list of Required Ports for vCenter Server and PSC can be found here.
  • The configuration maximums for vSphere 6.7 can be found here.
  • In vSphere 6.7 TLS 1.2 is enabled by default. TLS 1.0 and TLS 1.1 are disabled by default, review the Release Notes for more information.

Create Data Source

Before beginning if you intend to use vCenter Server with an external SQL database you must configure a 64-bit ODBC data source for external databases. You may also need to install the Microsoft ODBC Driver for SQL Server. ODBC Data Source Administrator can be accessed via Control Panel > Administrative Tools. Click System DNS, Add and input the details for the external database, test the data source before continuing. If you are using the internal Postgres database then the System DSN is added automatically during installation.



Download the VMware vCenter Server and Modules for Windows ISO from VMware downloads: v6.7.0.

Mount the ISO and right click autorun.exe, select Run as administrator. The VMware vCenter Installer will open. Ensure vCenter Server for Windows is selected and click Install.


The vCenter Server 6.7 Installer will open in a separate window, click Next.


Accept the end user license agreement and click Next.


In this guide we will be using an embedded deployment model. If you are using an external deployment model the PSC component must be installed first before the vCenter. Select the deployment type and click Next. If the Windows server does not have sufficient resources allocated the installer will error at this stage.


Enter the FQDN in the System Name field and click Next.


Create a new Single Sign-On domain, or join the vCenter to an existing SSO domain. If you are creating a new SSO domain either leaves as the default vsphere.local or create a new SSO domain name, (not the same as your Active Directory name). Configure a password for the SSO administrator account and a vCenter specific site name, click Next. Note: vCenter 6.7 is the last release where a SSO site name will need to be provided.


Select whether to run vCenter services as the local system account or enter details of a service account and click Next. Ensure the account running vCenter services has been granted permissions as per the other considerations section of this guide.


Select an embedded Postgre database or point the installer to the DSN for an external database, click Next.


Accept the default port configuration and click Next.


Select the directory to install vCenter services and click Next.


Tick or untick the VMware Customer Experience Improvement Program as appropriate and click Next.


Check the configuration on the review page and click Install to begin the installation process.


Once the installation has completed click Finish.



Connect to the vCenter post install using the IP or FQDN of the vCenter. Access vSphere by clicking either Launch vSphere Client (HTML5) or Launch vSphere Web Client (FLEX). As the web client will be depreciated in future versions, and the HTML5 client is now nearly at full feature parity, we will use the HTML5 vSphere client.


You must apply a new vCenter license key within 60 days. If you have purchased vCenter Server then log into your licensing portal here. If the license key does not appear then check with your VMware account manager. Log in to the vSphere Web Client using the SSO administrator login.  From the Menu drop-down click Administration,


Under Licensing select Licenses. First we need to add a new license key, click Add New Licenses. Enter the new license key for vCenter Server, click Next. If applicable assign a name to the licence, click Next. Click Finish to add the license key.


Switch to Assets, the vCenter Server is listed in evaluation mode. Highlight the vCenter and click Assign License. Select the license key and click Ok.


If you have an Active Directory domain then vCenter can use this as an identity source. First ensure the vCenter is joined to the domain; from the Menu drop-down click Administration. Under Single Sign On click Configuration. Select the Active Directory Domain tab and verify the vCenter is domain joined. Change to the Identity Sources tab and click Add Identity Source. Fill in the Active Directory details for your domain and click Ok.


You can now add permissions to vCenter objects such as datacenters, clusters, folders, individual virtual machines, etc. for Active Directory users and groups. To learn more about vSphere permissions click here.

To start adding ESXi hosts to vCenter click the Menu drop-down and select Hosts and Clusters. Right click the vCenter and select New Datacenter, give the datacenter a name and click Ok. Right click the datacenter and select Add Host. Follow the onscreen wizard to add a host. Creating clusters and configuring vCenter is beyond the scope of this post, for assistance follow the documentation links at the top of the page.


Setting Service Dependencies in Windows

It may be necessary to delay the loading of a specific service until another service has started and is available for use, such as in an application stack, or for troubleshooting purposes. This quick post will walk-through creating a dependency, or sequence of dependencies, for services on a Windows machine.

Many built in Windows components, and third party applications, include dependencies configured during installation, these are visible from the Services GUI. In order to add dependencies after installation we can use the Windows Service Control (SC) command or add the entries manually in the registry.


Command Line

Open an elevated command prompt, be aware that when we set dependencies any existing dependencies are overwritten. So first let’s list the current dependencies using sc qc, the example below will list the properties, including dependencies, of Service1.

sc qc "Service 1"

Use sc config to add a dependency. In the example below Service1 depends on Service2, this means that Service1 will not start until Service2 has successfully started.

sc config "Service 1" depend= "Service 2"

For multiple services use a forward slash.

sc config "Service 1" depend= "Service 2"/"Service 3"

To remove all dependencies use the following command.

sc config "Service 1" depend= /


Open regedit and locate the following key.


There will be a subkey listed for each installed service, click the subkey for the service you wish to configure.

Click Edit, and New Multi-String Value. Right click and Rename the value DependOnService. Right click and select Modify, enter the names of the services you want this service to depend on (one per line) and click Ok.


Windows 2016 Storage Spaces Direct

Storage Spaces Direct for Windows Server 2016 is a software defined storage solution providing pooled storage resources across industry standard servers with attached local drives. Storage Spaces Direct (S2D) is able to provide scalability, built-in fault tolerance, resource efficiency, high performance, simplified management, and cost savings.

Storage Spaces Direct is a feature included at no extra cost with Datacentre editions of Windows Server 2016. S2D can be deployed across Windows clusters comprising of between 2 and 16 physical servers, with over 400 drives, using the Software Storage Bus to establishe a software-defined storage fabric spanning the cluster. Existing clusters can be scaled out by simply adding more drives, or more servers to the cluster. Storage Spaces Direct will automatically detect additional resources and absorb these drives into the pool; redistributing existing volumes. Resiliency is provided across not only drives, components, and servers; but can also be configured for chasis, rack, and site fault tolerance by creating fault domains to which the data spread will comply. The video below provided by Microsoft goes into more detail about fault domains and how they provide resiliency.

Furthermore volumes can be configured to use mirror resiliency or parity resiliency to protect data. Using mirror resiliency provides resiliency to drive and server failures by storing a default of 3 copies across different drives in different servers. This is a simple deployment with minimal CPU overhead but a relatively inefficient use of storage. Alternatively we can use parity resiliency, where parity symbols are spread across a larger set of data symbols to provide both drive and server resiliency, but also a more efficient use of storage resources (requires 4 physical servers). You can learn more about both these methods at the Volume Resiliency blog by Microsoft.

The main use case for Storage Spaces Direct is a private cloud (either on or off-premises) using one of two deployment models. Hyper-Converged where compute and storage reside on the same servers, in this use case virtual machines would sit directly on top of the volumes provided by S2D. Using a Private Cloud Storage or Converged deployment method S2D is disaggregated from the hypervisor, providing a separate storage cluster for larger-scale deployments such as Iaas (Infrastructure as a Service). A SoFS (Scale-out File Server) is built on S2D to provide network-attached storage over SMB3 file shares.

Storage Spaces Direct is configured using a number of PowerShell cmdlets, and utilises Failover Clustering and Cluster Shared Volumes. For instructions on enabling and configuring S2D see Configuring Storage Spaces Direct – Step by Step, Robert Keith, Argon Systems. The requirements are as follows:

  • Windows Server 2016 Datacentre Edition.
  • Minimum of 2 servers, maximum of 16, with local-attached SATA, SAS, or NVMe drives.
  • Each server must have at least 2 solid-state drives plus at least 4 additional drives, the read/write cache uses the fastest media present by default.
  • The SATA and SAS devices should be behind a HBA and SAS expander.
  • Storage Spaces Direct uses SMB3, including SMB Direct and SMB Multichannel, over Ethernet to communicate between servers. 10 GbE or above is recommended for optimum performance.
  • All hardware must support SMB (Server Message Block) and RDMA (Remote Direct Memory Access).


Windows 2016 Containers

Containers are portable operating environments which typically utilise the same kernel whilst isolating applications. Software developers use containers to build, ship, and run applications. To the application the container gives the illusion of a totally isolated and independent operating system, in much the same way that a virtual machine doesn’t know it shares compute with other virtual machines; applications within containers are unaware they share a base operating system with other containers.

Using namespace isolation the host projects a virtualised namespace containing all the resources that an application can interact with, such as files, network ports, and running processes. Namespace isolation is extremely efficient since many of the underlying OS files, directories and running services are shared between containers. If and when an application makes changes to these resources then those changes are written to a distinct copy of that file or service using copy-on-write.

Containers house everything an application needs to run, and that gives it greater portability; allowing for exact copies between development and production environments. By using containers software developers and IT professionals can also benefit from improved efficiency in use of existing infrastructure, standardised environments, and simplified administration. This is evident from the Microsoft images below.

Deploying applications using traditional virtual machines:


Deploying applications using containers:


The user of containers isn’t new technology, it has been around for years in Linux before the toolset was properly utilised by Docker. Docker is a container technology which automates and simplifies the creation and deployment of containers to build, ship, and run distributed applications from any environment. Docker have partnered with Microsoft to develop a Docker engine for Windows 2016 and Windows 10, enabling users to take advantage of container functionality with Windows.

Windows containers run in two different formats; Windows Server containers which isolate applications using namespace isolation technology, and Hyper-V Containers which run containers inside optimised virtual machines.

Hyper-V containers have identical functionality to their Windows counterparts, the only difference is the isolation of the kernel. Whereas Windows containers share the same kernel with other containers and the host, Hyper-V containers provide kernel level isolation by provisioning individually optimised virtual machines for each container. A use case for such isolation could be a secure environment such as PCI compliance. Hyper-V containers need nested virtualisation to be enabled and this is currently only compatible with Intel processors.

Windows containers require installation of the Containers feature, and installation of the Docker engine. Once these two components are installed you can go ahead and begin building Windows server containers.


Microsoft Azure are offering a free trial with £125 credit, to deploy a Windows 2016 virtual machine and try containers out for yourself see Azure Virtual Machine Deployment.

See also VMware Container Projects.

Updating WSUS Group Policy

If you need to update group policy to change an update schedule or make other alterations you can do so, even after patches have been approved on the WSUS server.

Open Group Policy Management and browse to the relevant GPO you want to update, right click and Edit the GPO. If you’re using Advanced Group Policy Management you’ll need to check out the policy before editing. Expand Computer Configuration > Policies > Administrative Components > Windows Components > Windows Update.


Double click the setting you want to change and update as appropriate. For the purpose of this post I have updated the scheduled install day from ‘1 – Every Sunday’ to ‘4 – Every Wednesday’.


Click Ok to save the change. If you’re using Advanced Group Policy Management you’ll need to right click the GPO and check in, and then deploy the GPO.

Depending on your environment you may need to wait a short while for replication, you can force a group policy refresh on a server by running gpupdate /force from the command line. Furthermore if you are running Windows 2012 or 2012 R2 you can right clicking an OU in group policy management and select Group Policy Update.


We can test if the group policy has updated by opening the registry on one of the servers and browsing to: COMPUTER\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU. Cross check the settings in the registry with those you changed on the group policy.


You’ll notice straight away the data is a decimal or hexadecimal value, you may have noticed too that the options in the GPO editor had a corresponding number. In this case I changed the scheduled install day from ‘1 – Sunday’ to ‘4 – Wednesday’, the value of the registry option ScheduledInstallDay has changed from 1 to 4, so I know the change has taken effect.

Another important thing to note is the UseWUServer option, this must be set to 1 to use a WSUS server, or none of the other options apply. You can go up a level to ‘Windows Update’ to check the configured Windows Update server.

Finally, here is a really useful list of registry values for Automatic Updates: