Tag Archives: windows

Using HP StoreOnce as target for Windows Server Backup (WSB)

This posting is ~4 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Some days ago, I blogged about the new HP StoreOnce software release 3.13.0. This release included several fixes. One fix wasn’t mentioned by me, although it’s interesting.

  • Fixed issue where Windows 2012 R2 built-in native backup was not supported with 3.12.x software (BZ 61232)

Windows Server Backup (WSB) is part of Windows Server since Windows Server 2008. WSB can create bare metal backups and recover those backups. The same applies to system state backups, file level backups, Hyper-V VMs, Exchange etc. Very handy for small environmens. Backup can be stored on disk or on a file share. With Server 2012, the file share must be SMB3 capable. So if it’s not a Windows file server, the NAS that offers the file share has to be SMB3 capable. This doesn’t apply to Windows Server 2008 (R2).

With StoreOnce 3.13.0, HP has fixed this. Starting with 3.13.0, you can use a CIFS share on a StoreOnce appliance as a target for Windows Server Backup. This allows you to take advantage of the benefits of StoreOnce, like industry-leading deduplication and replication technology.

I was able to test this new feature with StoreOnce VSA appliances in my lab, as well as with a customers StoreOnce 4700 appliance.

Download you free copy of the HP StoreOnce Free 1 TB VSA today and give it a try!

Logon problems after demoting a branch office Domain Controller

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

A customer of mine is currently refreshing his branch office server infrastructure. A part of this project is to demote the Active Directory Domain Controllers, that are currently running in each branch office. The customer has multiple branch offices and each branch office has an Active Directory Domain Controller which is acting as file-/ print- and DHCP server. Each branch office has its own Active Directory site. The Domain Controller and the used IP subnets are assigned to the corresponding AD site. Due to this configuration the clients at the branch office choose the site-local Domain Controller as logon server. This works totally flawless since a couple of years. Over the year bandwidth of site connection has increased and even small branch offices have a redundant MPLS connection to the HQ. And no one likes single domain AD forests with 20 or more Domain Controllers…


After demoting the Domain Controller in the first branch office I visited, my colleague and I discovered an interesting behaviour: The removal of the Domain Controller was flawless. Everything went fine. But when we tried to logon at a client, we got no GPOs and no network drives mapped. The name resolution was fine, so this was not our problem. I checked the content of the % LOGONSERVER% variable and discovered that it contained the name of the (now) demoted Domain Controller. After another logout and login, everything was fine. The client had chosen a new domain controller, now from the HQ AD site. This was correct and an expected behaviour. The branch office IP subnets were changed at the same time and the new IP subnets were assigned to the HQ AD site days before we demoted the DC.

Assumption: The client (Windows 7 Enterprise) used cached credentials to logon. These credentials included the old Domain Controller. During the second logon, a new Domain Controller is discovered based in the AD site.

To the lab!

Because I had to do the same in other branch offices, I searched for a solution. I used a couple of VMs to create a similar situation.

  • 2 sites
  • Each site has its own port group
  • 1 IP subnet per site
  • Router VM routes traffic between IP subnets
  • Subnets were assigned to AD sites
  • 1 DC per AD site
  • Client gets IP address from a DHCP in the site
  • Client is moved from one site to another site by switching port group
  • Client uses “last” logonserver (from the old site)
  • After the second logon, the site-local DC is chosen
  • nltest shows the correct DC for the site
  • If usage of cached credentials is disabled, client uses the site-local DC at every logon

I took some screenshots to clarify this. Logon as [email protected] on client2 in site 2.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

I powered off the VM, switched the port group and powered on the VM. I logged on as [email protected] on client2 in site 1. You can see, that the client still uses DC2 as logon server. The client got an IP from site 1.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Logout and logon as [email protected] on client2 in site 1. Now the client uses DC als logon server.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

I tried this several times. The behaviour was always the same. Then I disabled cached credentials using a GPO (“Interactive logon: Number of previous logons to cache” set to 0). Now the client always chose the site-local DC on the first attempt.


I don’t know if this is willed behavior. It’s reproducible and I don’t think that this is the result of a misconfiguration or a bug. If you demote a Domain Controller in a branch office, and it’s the only Domain Controller, the clients will try to reach it on the next logon. If the Domain Controller is still available, maybe because you moved it to another site, everything’s fine. But if it’s gone, you will get in trouble due to cached credentials.

In my case, the customer and I decided to assign all used IP subnets from the branch offices to the HQ AD site. Even if the branch offices still have a Domain Controller, the clients now chose the Domain Controller from the HQ. The Domain Controller in the branch offices now acts as only as DHCP and DNS until they are demoted.

Update OS or reinstall DataCore SANsymphony-V Storage Server

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Sometimes you have to update the OS of your DataCore Storage Server, or the server is crashed and you have to reinstall it. In both cases, a configuration backup is the starting point. The procedure remains the same, regardless if it’s an update or a reinstall after a server crash:

  • Install Windows Server OS
  • Copy configuration backup file to C:\Program Files\DataCore\SANsymphony\Recovery
  • Install DataCore SANsymphony-V

Take a backup

You can take the configuration backup on different ways:

  • Using the DataCore SANsymphony-V Management Console
  • Using the SANsymphony-V Cmdlets for Windows PowerShell

Regardless of how you take the backup, be sure that you have a valid backup! I recommend to take backups in a regular and automated fashion, e.g. with a PowerShell script. I have written such a script in the past: Backup DataCore SANsymphony-V config using PowerShell

You can take the backup with the DataCore SANsymphony-V Management Console by right clicking the server group and then select “Backup Configuration” from the context menu.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

When you use the PowerShell, you have to execute three different Cmdlets:

  • Connect-DcsServer to make a connection to the server group
  • Set-DcsBackupFolder to set the location of the backup folder
  • Backup-DcsConfiguration to backup the configuration and store it in the backup folder

The Cmdlets take the configuration backup for all servers in the server group! Make sure that you copy the configuration backups to a safe location. Make sure that you copy a valid backup of each server in the server group. On thing is important: If you take the backups online (DataCore Storage Server is running!), then you will see full recoveries in case of a restore. If you plan to reinstall a DataCore Storage Server, stop the DataCore Storage Server and then take the configuration backup. In case of a clean shutdown, only log recoveries will be necessary.

Restore the backup

Disconnect backend and mirror ports before you reinstall the OS! Install the Windows OS according to the DataCore guidelines (meet the prerequisites, read the know errors with 3rd party components PDF, check name resolution etc.). Make sure that you install the same build of DataCore SANsymphony-V that was used prior the reinstallation. Don’t install newer or older builds! Install exactly the build that was used when taken the configuration backup. Create the folder structure “C:\Program Files\DataCore\SANsymphony\Recovery” and copy the ZIP file into it. Start the DataCore SANsymphony-V installation. You will be prompted during the installation, that a saved configuration was found.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

If not, log a call at DataCore or follow the instructions in the DataCore online help. You also need the DcsAdmin password during the installation! I hope you have written it down somewhere. ;) After finishing the installation, shutdown the server and reconnect backend and mirror ports. Power-on the server and open the SANsymphony-V Management Console. If everything’s fine, start the DataCore Storage Server and watch the mirror recoveries. Take a configuration backup and support bundles. Proceed with the next servers in the server group.

Final words

The process is quite simple. If you’re unsure about the correct steps, log a call at the DataCore support or take a look into the DataCore online help. Don’t try in-place upgrades to update the OS. I also don’t recommend to take images of running storage servers. Just reinstall the OS and use configuration backups to restore the configuration.

Publishing Outlook Web Access with Microsoft Web Application Proxy (WAP)

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Microsoft has introduced the Web Application Proxy (WAP) with Windows Server 2012 R2 and has it positioned as a replacement for Microsoft User Access Gateway (UAG), Thread Management Gateway (TMG) and IIS Application Request Routung (ARR). WAP ist tightly bound to the Active Directory Federation Services (AD FS) role. WAP can be used

  • pre-authenticate access to published web applications, and
  • it can function as an AD FS proxy

The AD FS proxy role was removed in Windows Server 2012 R2 and it’s replaced by the WAP role. Because WAP stores its configuration in the AD FS, you must deploy AD FS in your organization. The server, that hosts the WAP, has no local configuration. This allows you to deploy additional WAP servers to create a cluster deployment. The additional servers get their configuration from the AD FS.

The deployment of WAP can be split into two parts:

  • deployment of the AD FS role
  • deployment of the WAP role

The AD FS deployment

You can deploy the AD FS role on a domain controller or on a separate server. AD FS  acts as an identity provider. This means, that it authenticates users and provides security tokens to applications, that trust the AD FS instance. On the other hand it can act as a federation provider. This means, that it can use tokens from other identity providers and can provide security tokens to applications that trust AD FS. The AD FS role can be deployed onto a domain controller or a AD member server.

The first step is to install the AD FS role onto a AD member server or domain controller. I used the DC in my lab. Depending on your needs, this can be different. I used the PowerShell to install the AD FS role.

A reboot is not necessary. The next step is to configure the AD FS role. This process is supported by configuration wizard. Before you can start, it’s necessary to deploy the group Managed Service Account (GMSA). Open a PowerShell console and execute the following commands:

Then you can start the configuration wizard. If this is the first first AD FS server, select the first option “Create the first federation server in a federation server farm”.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

To perform the configuration, you need an account with domain administrator permissions. In my case, I simply used the Administrator account.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

You need to enroll an SSL certificate that is used for AD FS. This SSL certificate must include the DNS name for the AD FS server and also the Subject Alternative Names enterpriseregistration and enterpriseregistration.yourdomainname.tld. This screenshot includes the values that I used in my lab deployment. I entered this values into the “Attributes” box:


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Create the certificate and export it with the private key as pfx file. You must import the certificate into the “Personal” store of the local computer, that acts as AD FS server. You also need two DNS entries for the names, that are included in the certificate.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

If the certificate import was successful, you can select the certificate in the wizard. Add the Federation Service Name and the Display Name.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

The Service Account can be a existing domain user account or a Managed Service Account. I used my Administrator account for simplicity.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

If you deploy a single server, you can use the Windows Internal Database. If you plan to depliy multiple AD FS servers, you have ot use a SQL server database.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Review the options and continue with the pre-requisite checks. If everything went well, you can proceed with the installation. Finish the setup and close the wizard.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Open a browser and enter the AD FS URL into the address bar. In my case this URL looks like this:



Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

If you get a screen like this, everything’s fine and AD FS works as expected. Check the Windows Server 2012 R2 AD FS Deployment Guide for more information. Now it’s time to deploy the Web Application Proxy.

The WAP deployment

To install the WAP role, simply open a PowerShell and run the Install-WindowsFeature cmdlet.

Then you can run the WAP configuration wizard. This wizard guides you through the configuration of the WAP role.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

First you have to connect to the AD FS server. Enter the Federation service name you used to deploy the AD FS instance, and provide the necessary user credentials.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

At this point you have to select the certificate, that is used by the AD FS proxy. You can use the same certificate you used for the AD FS server. But you can also create a new certificate. The certificate must be imported into the “Personal” store of the WAP server.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Confirm the settings and click “Configure”. At this point, the wizard executes the shown PowerShell command.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Close the wizard and open the management console of the Web Application Proxy to check the operational status. At this point, the WAP only acts as a AD FS proxy.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

To test the functionality, I decided to publish Outlook Web Access (OWA). Use the “Publish New Application Wizard” to publish a new application.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

To publish OWA, select “Pass-through” as pre-authentication method.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Now it’s getting interesting. When you enter the external URL, the backend server URL is automatically filled. External and Backend URL have to be the same URL. Because of this, you need split DNS (see “Configure the Web Application Proxy Infrastructure” and “AD FS Requirements” at the Microsoft TechNet Library). You also need a valid external certificate, that matches the FQDN used in the external URL.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Check the settings and click “Publish”. The wizard executes the shown PowerShell command.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Close the wizard and check the functionality of the published application. This screenshot shows the access to OWA from one of my management VMs (MGMTWKS1):


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

This drawing shows my lab setup. I’ve used two subnets ( and to simulate internal and external access, as well as split DNS.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

The host dc.vcloudlab.local ( has the AD FS role installed and resolves cas.terlisten-consulting.de to (HAProxy). MGMTWKS1 resolves the same FQDN to (WAP1 – my WAP server).

Final words

This is only a very, very basic setup and I deployed it in my lab. The installation was not very difficult and I was quickly able to set up a working environment. Before you start to deploy AD FS/ WAP, I recommend to take a look into the TechNet Library:

STOP c00002e2 after changing SCSI Controller to PVSCSI

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Today I changed the SCSI controller type for my Windows VMs in my lab from LSI SAS to PVSCSI. Because the VMs were installed with LSI SAS, I used the procedure described in VMware KB1010398 (Configuring disks to use VMware Paravirtual SCSI (PVSCSI) adapters) to change the SCSI controller type. The main problem is, that Windows doesn’t have a driver for the PVSCSI installed. You can force the installation of the driver using this procedure (taken from KB1010398):

  1. Power off the virtual machine.
  2. Create a new temporary 1GB disk(SCSI 1:0) and assign a new SCSI controller (default is LSI LOGIC SAS).
  3. Change the new SCSI controller to PVSCSI for the new SCSI controller.
  4. Click Change Type.
  5. Click VMware Paravirtual and click OK.
  6. Click OK to exit the Virtual Machine Properties dialog.
  7. Power on the virtual machine.
  8. Verify the new disk was found and is visible in Disk Management. This confirms the PVSCSI driver is now installed.
  9. Power off the virtual machine.
  10. Delete the temporary 1GB vmdk disk and associated controller (SCSI 1:0).
  11. Change the original SCSI controller(SCSI 0:X) to PVSCSI as detailed in Steps 3 to 5.
  12. Power on the virtual machine.

Please note, that this change is not a supported method to change the controller type. Usually you should install a server with disks already attached to a PVSCSI controller.

The problem

I changed the controller type for a couple of VMs using the above described method. This worked really fine until I changed the controller type of my Domain Controller. The DC failed to boot with the new controller. I changed the controller type back to LSI SAS and the VM started without problems. A change in the type of controller led to another BSoD (Blue Screen of Death). But it was not the usual STOP 0x0000007B.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

STOP: c00002e2 Directory Services could not start because of the following error:

A device attached to the system is not functioning.

Error Status: 0xc000000f.
Please shutdown this system and reboot into Directory Services Restore Mode, check the event log for more detailed information.

Something new… I booted into Directory Services Restore Mode (DSRM) and logged in with my directory services restore mode password (I hope you remember your password…).


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

I checked the disks and found my SYSVOL volume offline.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

I usually let DCPROMO install the NTDS and SYSVOL onto a separate drive instead using the system volume. In my case this drive was offline! This causes that Windows failed to start.

The solution

The solution was simple: Bring the volume online and reboot the VM.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Windows started without problems and the AD was also okay.

Final words

I think it’s clear, that you can’t replace the controller type without additional steps. And it should also be clear, that changing the controller type isn’t a good idea until you’re really know what you’re doing. I also think that it’s unsupported to change the controller type (but I haven’t found a statement if it’s supported or not). I did this a couple of times and I never had problem with the above described procedure. In this case, the problem is related to the controller type change. The cause for the BSoD was the offline NTDS/ SYSVOL volume. Bringing the volume online in DSRM solved the problem.

VMware vCenter: Host state “not responding” flapping

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

While I was onsite at a customer to decommission an old storage system, one of my very first tasks was to unmount and detach some old datastores. No big deal, until I saw that one after one ESXi hosts went to “not responding”. Time for a heart attack but hey: Why should a host ran into a PDL/ APD, while I was dismounting datastores on the vSphere layer? The LUNs were still there and accessible. The hosts came back quickly and from that point, I watched the hosts flapping between “connected” and “not responding”. Time for an investigation. My first thought was that it must have something to do with the network. But the network was okay, no problems with interfaces, (M/R)STP or similar. Then I checked the logs and found this

and this

in the sms.log on the vCenter server.  This messages was logged multiple times per second in the Windows Server eventlog:

A short search in the Microsoft Knowledgebase pointed me to KB2577795.  Checking the number of current connections showed, that the server opens hundreds and thousands of connections to itself. Unfortunately, the installation of KB2577795 did not solved the problem. My second attempted was to rise the number of MaxUserPort which is used to limit the number of dynamic ports available to applications. Open the registry editor and locate the key:

Create a new DWORD wamed MaxUserPort and add the value 65534 to it.

After a reboot of the vCenter server, the host state flapping has stopped and and did not recur. This is NOT the solution, it’s only a dirty workaround. The customer and I decided to reinstall the virtual vCenter Server and update it to vCenter 5.5 U2. The reinstallation wasn’t a big deal due to an external database and a backup of the SSL certificates.

As I already mentioned: I don’t have a clue what happened to the vCenter server. I was able to create a workaround but I wasn’t able to solve to root cause. But the customer used this situation to make a clear cut and to start with a new vCenter server.

Automating updates during MDT 2013 Lite-Touch deployments

This posting is ~5 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

I use Microsofts Deployment Toolkit (MDT) in my lab to deploy Windows VMs with Windows Server 2008 and Windows Server 2012. I described the installation and configuration of MDT in a small blog post series. Take a look into the intro post, if you’re a new to MDT. But the OS installation isn’t the time consuming part of a deployment: It’s the installation of patches. Because of this, I decided to automate the patch installation and make it part of the OS installation.

The requirements

To automate the installation of patches, we need

To save resources, I’ve installed WSUS on the server I also use for MDT. In Windows Server 2008 R2 and Server 2012 (R2) WSUS is a installable role. Because I use a Windows 2008 R2 host for MDT, I could simply add the role to the server. I will not describe the installation of the WSUS role, because this is really easy.

Configuration of MDT 2013

In principle, there are two changes:

  • Enableing Windows update in the task sequence
  • Adding WSUS server to the CustomSettings.ini file

First of all you need to enable the Windows update part in the task sequence. Start the Deployment Workbench and navigate to the task sequences. Go into the properties, switch to the “Task Sequence” tab and enable the “Windows Update (Post-Application Installation)” task by unchecking the “Disable this step” box on the “Options” tab.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

Click “OK” and switch to the deployment share. Go into the “Control” directory and open the CustomSettings.ini. Add this line to the end of the [Default] section:

Make sure that you change the FQDN to your WSUS host and save the file.

If everything went fine, you should see this during the deployment process:


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

The host, that is currently deployed, should also appear in the WSUS console.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

How it works

During the deployment process the script ZTIWindowsUpdate.wsf is called. This script connects to the WSUS server and installs all appropriate updates, servicepacks etc. This includes the latest version of the Windows Update API and the Microsoft Update binaries. Because the script install ALL appropriate updates, service packs etc., there is no way to exclude updates from being installed. Really no way? However, there is a way. You can use the WUMU_ExcludeKB switch in the CustomSettings.ini to exclude updates. Simply add one line for each KB that you want to suppress.

Event ID 4625 – Failure Reason: Domain sid inconsistent

This posting is ~6 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

The last two days I had a lot of trouble with Microsoft Remote Desktop Services (RDP), or to use the older wording, terminal services. To be honest: Terminal servers are not really my specialty, and actually I was at the customer to help him with some vSphere related changes. But because I was there, I was asked to throw a closer look at some problems with their Microsoft W2K8R2 based terminal server farm. Some problems with removable media (USB sticks etc.) and audio on IGEL thin clients were hard to troubleshoot, but we were able to fix them. The biggest problem was none at first glance. The customer described, that remote users couldn’t login into a terminal server over VPN. But the login was successful, if the local administrator account of the terminal server was used. Some short tests confirmed the described behaviour. I checked the event logs and there it was: Event 4625.

I checked the SID of the terminal servers with PsGetSid and they all had the same SID. I asked the customer how he had deployed the terminal servers and he explained, that he had deployed the first server from a VMware template with a customization specification. The following terminal server were cloned with VMware, but the customization specification wasn’t applied. Furthermore, sysprep wasn’t run. I can’t explain why this error was only logged when a user tried to connect over VPN, but it was reproducible.

The Solution

It was clear that we had to change the SID. Unfortunately is NewSID not supported with Windows Server 2008 R2. So this wasn’t an option. The best way is to re-run sysprep. The customer and I developed an action plan to resolve the issue.

  1. Remove the server from the domain and add it into a workgroup
  2. Run Sysprep from C:\Windows\System32\Sysprep. Select “System Out-of-Box Experience (OOBE)”, “Generalize” and “Reboot”.
  3. After the reboot, rename the server with the old name. Activate Windows and do some tests.

This steps worked for us and resolved the issue. You need to test this in your environment before you apply the changes.

Change network adapter type with PowerCLI

This posting is ~6 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

Today I found this neat PowerCLI One-liner in my Twitter timeline:

A nice side effect of this one-liner is, that the mac-address doesn’t change, as you can see in the screenshots.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

If you have ever changed the adapter type of a vNIC you will know, that this leads to a changed mac-address and a new adapter in the OS. Windows will show a “Local Area Connection 2”, Linux will show a eth1 instead of eth0. So you need to lend a hand. If you use Linux and you’ve changed the adapter type using this one-liner, everythings fine. eth0 will stay eth0, but the kernel loads another driver. No need to modify or delete the 70-persistent-net.rule file under /etc/udev/rules.d. But how does Windows handle it? Unfortunately Windows doesn’t handle it. Windows detects a new device, because the hardware ID changed.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

The only way to fix this, is to delete the old, non-present adapter. In order to do that, open a CMD and enter the following command:

Then open the Device Manager, choose “View” and click “Show hidden devices”. Then delete all non-present network adapters and the newly detected VMXNET3 adapter.


Patrick Terlisten/ www.vcloudnine.de/ Creative Commons CC0

After that, right click the computer icon (in my case LABLAB-V4143BPG) and select “Scan for hardware changes”. Windows will detect a new VMXNET3 adapter, which you can finally configure with the hopefully documented IP settings.

Windows Server 2012 Cluster with VMware vSphere 5.1/ 5.5

This posting is ~6 years years old. You should keep this in mind. IT is a short living business. This information might be outdated.

While I was poking around in my Twitter timeline, a tweet from Victor van den Berg (VCDX #121) got my attention.

My first though “What a step backwards!”. I have installed a bunch of Microsoft clusters in Virtual Infrastructure and vSphere enviroments and most times it was PITA. Especially with Raw Device Mappings (RDM) and bus sharing, which prevents vMotion a VM to another host (regardless of this: it’s not supported!). It’s ironic to invest a significant amount of money into a technology, which  increases availability and manageability, and another technology lowers availability due additional maintenance windows for cluster failovers. But that’s exactly what you get, when you use MSCS with SCSI bus sharing (RDM or VMFS). A way to address this issue is to use in-guest iSCSI. This means that you access the shared disks directly from the VM due a iSCSI initiator running in the VM. To do so, you have to present the disks for the cluster to the VMs, not to the ESXi hosts. To be honest: In-guest increases complexity. Especially then, when the customer doesn’t have a iSCSI infrastructure. A second method is in-guest SMB, which is currently only supported with Windows Server 2012. Just to clear up the matter with in-guest iSCSI and W2K12(R2):

Mostafa Khalil /VCDX #002) provided the crucial information:

In-guest iSCSI is supported with W2K12 on vSphere 5.5, which also supportes W2K12 R2 failover clustering. But there’s another interesting fact, that was new to me: Windows Server 2012 failover clustering isn’t supported with ESXi provided shared disks! I found a hint in VMware KB1037959.

Windows Server 2012 failover clustering is not supported with ESXi-provided shared storage (such as RDMs or virtual disks) in vSphere 5.1 and earlier. For more information, see the Miscellaneous Issues section of the vSphere 5.1 Release Notes. VMware vSphere 5.5 provides complete support for 2012 failover clustering.

This means, that you can run Windows Server 2012 failover cluster on vSphere 5.1, but only with in-guest iSCSI or in-guest SMB.

What’s new in vSphere 5.5?

Windows 2012 R2 failover clustering is now supported. But much more significant are changes regarding the storage protocols. With vSphere 5.5 RDMs (shared disks for quorum or data) can be on iSCSI and Fibre Channel over Ethernet (FCoE). Until vSphere 5.5 only Fibre-Channel (FC) was supported. iSCSI and FCoE are supported for cluster-in-a-box (CIB) and cluster across boxes (CAB). Just to make it clear: NFS isn’t supported. Neither for RDM nor for VMFS! Furthermore software and hardware initiator, and mixed setups are supported for iSCSI and FCoE. With vSphere 5.5 the VMW_PSP_RR can be used for the RDMs. There’s no need to change the PSP for the RDMs. VMware KB2052238 summarizes the changes in vSphere 5.5 together.

Final words

Clusters are never an easy thing. The complex support matrix does not make it easier. If you’re using Microsoft clusters, be sure to check the above mentioned knowledge base articles before you make a update of your vSphere enviroment or of your Microsoft cluster.