VMDK to VHDX conversion causes errors described in KB 2470478

Question

Hi all,
this is the situation:
We are converting multiple VMs (Windows 2008 - not R2) from ESXi 5.1 to Hyper-V 2012 R2.
The conversation itself is always successful but when we check the event log in the migrated servers we see errors like:
ESENT ... could not read header... c:\windows\softwaredistribution\datastore\logs\edb.log ... wuaueng.dll
--> Windows Update is not working anymore.
This seems to be caused by the problem described in KB http://support.microsoft.com/kb/2470478:
Applications that are built on ESENT and that run on a Windows Vista-based or Windows Server 2008-based computer may not work correctly after the reported physical sector size of the storage device changes.
I think the sector size changes during conversion to VHDX.
The KB says also that this affects many applications that are built on ESENT like AD, CA, ...
Questions:
Should the mentioned fix be already included in any updates?
Shall we install the hotfix prior to conversion?
What is the risk for AD when we migrate our DCs to Hyper-V?
Hope you can help to find out the risk we have regarding this bug. :-)
Thanks!!!

Answer 1

Hello Paul,
the problem that occures is related to am memory leak when the used matlab dll is loaded and released.
If DIAdem saves a matlab file this dll is loaded and unloaded which leads to the behavior you have seen.
There is a workaround if we keep the plugin being attached.
Option Explicit 'Forces the explicit declaration of all the variables in a script.
' Insert at the start of your script
dim validWritablePathToDummyMatFile : validWritablePathToDummyMatFile = "C:\temp\dummyFileToHoldDll.mat"
dim holdDllStore : set holdDllStore = navigator.ConnectDataStoreByParameter("MatLab", "<filename>" & validWritablePathToDummyMatFile & "</filename><model>http://www.ni.com/DataModels/USI/TDM/1_0</model>")
dim i : for i = 1 to 1000
datafileSave "C:\temp\out.mat", "MatLab"
Next
 This code will open holddllStore at the start of the script and will keep this store open till the script finishes.
This means that the memory leak only occures once for every script run. This should work out for your use case.
Greatings
Andreas