Tag Archives: Windows Server 2012

vCAC: Error requesting machine. (Exception from HRESULT: 0x8004D025)

While setting up vCAC 6.0 in my home lab, I encountered the following error when trying to deploy a machine from a blueprint.

Error requesting machine. Inner Exception: Exception has been thrown by the target of an invocation. Base Exception: The partner transaction manager has disabled its support for remote/network transactions. (Exception from HRESULT: 0x8004D025)

vCACSQLDTC00

I found a VMware KB article for an earlier version along similar lines which requires configuring some MSDTC settings on the SQL server holding the vCAC database. (It appears that this is a reasonably common issue for SQL based applications)

The recommendation from the VMware KB article is to configure MSDTC with the following:

Go to Start > Administrative Tools.
Open Component Services.
Expand Component Service > Computers > My Computer > Distributed Transaction Coordinator.
Right-click Local DTC and click Properties.
Click the Security tab.
Select the Network DTC Access option.
Select Allow Remote Client and Allow Remote Administration options.
Select the Allow Inbound and Allow Outbound options
Specify NetworkService for DTC Logon Account.
Click OK.

vCACSQLDTC01

Following those changes the MSDTC service needs to be restarted.

vCACSQLDTC02

My SQL server is 2012 running on Windows Server 2012 and is easy to change because it was for a homelab. Depending on the environment you might be deploying into, some consideration will need to be taken in advance into whether the above can be changed (if necessary) on a Production SQL server or whether a dedicated SQL server might be required.

Update: 19/05/2014

Following the comment from Charles Bryant below, here are the steps you need to automate this config.

You can get current DTC settings with:


Get-ItemProperty -Path HKLM:\Software\Microsoft\MSDTC\Security

DTC

We need to change 6 of these settings to a value of 1, then restart the service (Make sure your PowerShell session is set to run as administrator):


"NetworkDtcAccess","NetworkDtcAccessAdmin","NetworkDtcAccessClients","NetworkDtcAccessTransactions","NetworkDtcAccessInbound","NetworkDtcAccessOutbound" | ForEach-Object {Set-ItemProperty -Path HKLM:\Software\Microsoft\MSDTC\Security -Name $_ -Value 1}

Restart-Service msdtc

DTC02

Windows Management Framework (PowerShell) 4.0 is now available – ensure you already have .NET 4.5

Update 30/10/2013: There’s an updated post on the PowerShell Team Blog which now describes this situation with .NET 4.5 as a pre-requisite in more detail.

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

PowerShell 4.0 which shipped as part of Windows Server 2012 R2 and Windows 8.1 is now available for down-level Windows versions via the downloadable Windows Management Framework 4.0.

WMF 4.0 contains updated versions of the following features:

Windows PowerShell
Windows PowerShell Integrated Scripting Environment (ISE)
Windows PowerShell Web Services (Management OData IIS Extension)
Windows Remote Management (WinRM)
Windows Management Infrastructure (WMI)

Additionally, we have added a new and exciting Windows PowerShell feature which is available in WMF 4.0: Windows PowerShell Desired State Configuration (DSC)

To use this updated management infrastructure to manage Windows 7 SP1, Windows Embedded 7, Windows Server 2008 R2 SP1, and Windows Server 2012, WMF 4.0 must be installed on computers that are running the previously-released operating systems.

For this Release, WMF 4.0 installs only on the following operating systems:

Operating System Service Pack Level Editions
Windows 7 Service Pack 1 All
Windows Server 2008 R2 Service Pack 1 All except IA64
Windows Server 2012   All except IA64
Windows Embedded 7   All

Note that Windows 8 is not listed and you are required to take the free upgrade to Windows 8.1 to get PowerShell 4.0.

One important requirement that is worth taking particular notice of is that .NET Framework 4.5 is a pre-requisite. While you may have installed this on your Windows 7 machine, it maybe not that likely that you have installed it on your server installations.

While this information is in the release notes, there is nothing in the installation that warns you of this requirement and an installation attempt without it results in (IMHO) a slightly  bizarre outcome.

In this example I installed WMF 4.0 on a Windows Server 2008 R2 system with the WMF 2.0 / PowerShell 2.0 combination that ships as part of the OS.

The OS currently contains .NET Framework 3.5.

WMF4_01

Tip: You can quickly find your latest .NET version with the following one-liner

<br /><br />&amp;nbsp;<br /><br />Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse | Get-ItemProperty -name Version -EA 0 | Where-Object { $_.PSChildName -match '^(?!S)\p{L}'} | Sort-Object version -Descending | Select-Object -ExpandProperty Version -First 1<br /><br />

Having downloaded the correct WMF 4.0 version for Windows Server 2008 R2 I’ve started the installation:

WMF4_02

WMF4_03

WMF4_04

Once the installation is complete, I check the version of PowerShell and discover that it is still 2.0.

<br /><br />$psversiontable<br /><br />

WMF4_05

So nothing much seems to have changed! If you look carefully in the release notes though, installing without .NET Framework 4.5, results in two QFE hotfixes being installed.

Note: When you run the WMF 4.0 installation package, the following updates are installed first:

Examining these hotfixes we can see two hotfixes have been installed:

WMF4_06

(Confusingly, one of these KB2809215, is actually the KB2823180 mentioned in the release notes.)

If we attempt to install WMF 4.0 again we are told that it already has been installed:

WMF4_07

So, let’s see what happens if we install the .NET Framework 4.5 pre-requisite:

WMF4_08

WMF4_09

Test the install:

WMF4_10

Now try the install again

WMF4_11

WMF4_12

WMF4_13

After reboot, we can confirm we now have PowerShell 4.0.

WMF4_14

Got a headache yet? The crux of the story is make sure you have .NET Framework 4.5 before installing WMF 4.0 🙂

Windows Server 2012 on vSphere 5.0 – The Case of the Missing D:\ Drive

I sincerely hope this saves somebody else some time because I had a fair amount of head scratching with this today. Installed a Windows Server 2012 VM on vSphere 5.0 U2, pretty standard install with a C:\ drive for OS, Software etc and D:\ for data. This particular server needed to run SQL Server 2012, however the install kept repeatedly failing with the error “Could not find the Database Engine startup handle”. Initially I suspected that it might be a problem with a corrupt ISO as there are numerous postings around that and some, such as the below, suggesting that it could be an issue with mounting an ISO (I was pretty dubious about this though).

http://mbmccormick.com/2012/12/sql-server-2012-could-not-find-the-database-engine-startup-handle/

Having messed around with extracting the ISO, copying the files locally and other methods, eventually I tracked down in the SQL Server install log that it seemed to be having an issue reading and writing files to and from the D:\ drive during setup. During the SQL Server install wizard I’d specified that the path for databases, logs etc would be D:\. So I re-ran the installation and this time left the default of C:\ for everything and voilà, it worked!

No big deal I thought, I’ll simply change these locations post install. However, when I went to change the database server properties (or attempt to create a database) I was greeted with a dialogue box which only displayed the C:\ drive as accessible, no sign of D:\.

HotPlug4

Although clearly Windows was happy that a D:\ drive was present.

HotPlug2

This started ringing other bells because during the time I had been spending copying extracted ISO files around the $Admin share of D:\ had not been accessible (which I was going to look into later – should have done it then!)

Googling Researching this issue landed me at this forum post on SqlServerCentral.com – Sql Server 2012 can’t see 2nd drive. In there they link to this VMware KB article – Disabling the HotAdd/HotPlug capability in ESXi 5.x and ESXi/ESX 4.x virtual machines . Essentially what is happening is that Windows is marking the drive as Removable (i.e. like a USB drive) and consequently some operations that we would normally expect to be available are not. If you look in the taskbar the drives are potentially removable – although in practice if you try to they are not because they are in use.

HotPlug1

You can get round this either by applying the suggested workaround from VMware which is to add devices.hotplug = false into the .vmx file for the VM or in Windows  disable a security policy in gpedit.msc under Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies\Object Access .

I went for the former which you achieve by:

Connect to the ESXi/ESX host or vCenter Server using the vSphere Client.
Power off the virtual machine.
Right-click the virtual machine and click Edit Settings.
Click the Options tab.
Click General > Configuration Parameters > Add Row.
Insert a new row with the name devices.hotplug and a value of false.
Power on the virtual machine.

HotPlug3

Once powered on Removable Devices are no longer present:

HotPlug5

The D:\ drive is available over the network via the $Admin share and SQL is now able to see the D:\ drive:

HotPlug6

Incidentally, I blogged about this similar issue back in 2010 and at the time put the devices.hotplug setting into standard templates for Windows Servers; looks like I’ll need to do that for Windows Server 2012 too! Never seem to hear much about other people having issues with this problem though, would like to hear in the comments if it has caused you issues too…..