none
Manage Server 2012 R2 Hyper-V from Win 10 LTSB 2016 client = "...could not access an expected WMI class..."

    Question

  • Trying to access Hyper-V running on Server 2012 R2 from Windows 10 LTSB 2016 and I only get an error:

    The Hyper-V Management Tools could not access an expected WMI class on computer....

    Same server accessed from Windows 8.1 H-V Management Tools is working fine.

    Anybody any idea?

    According to this it should be no issue

    Seb


    • Edited by scerazy Friday, September 16, 2016 8:13 AM
    Friday, September 16, 2016 8:11 AM

Answers

  • I talked to a WMI expert who was relayed all of the information above.  He certainly concluded that the fault lies with both Dell and HP for destructively blowing away this class, but couldn't come up with a less intrusive fix, and more or less recommended the hack that I did until the respective vendors fix their own products.

    He mentioned a few other ideas which didn't seem too plausible, and only sort-of half-explained them.  The part he was worried about with my fix is that it could easily miss stuff not related to Hyper-V, so it wouldn't ever be recommended on a KB article or "supported" by Microsoft in any way.

    Rather than upload the file, here's the instructions:

    • Load up WindowsVirtualization.V2.Mof in a text editor with can show line numbers on the side.
    • This file should have 4582 total lines, with line 4582 being empty.  File size should be 1466522 bytes. If both of these are not true, abort here.  Date will vary since it will be the time your image was created pre-sysprep.
    • Copy the following lines to a new text file: 5, 33-42, 49-223, 4544-4549
    • Save this file to msvm_interop.mof.  Place it where you want, it doesn't really matter.
    • run mofcomp msvm_interop.mof from an elevated Command Prompt in the directory you've placed it, or provide an absolute path. 
    • Marked as answer by scerazy Tuesday, February 07, 2017 8:39 AM
    Tuesday, January 31, 2017 7:58 PM
  • yeah that was an error on my part, WinDiff didn't highlight those line numbers properly.  It should be 4537-4541.  Here is the code snippet:

    class Msvm_ElementConformsToProfile : CIM_ElementConformsToProfile
    {
      [Override,MSFT_TargetNamespace("root\\interop")] Msvm_RegisteredProfile Ref ConformantStandard = $SVP;
      [Override] Msvm_ComputerSystem Ref ManagedElement;
    };

    Opening cases with Dell and HP are your best bet.  HP thinks they have a solution when someone here says they don't.

    • Marked as answer by scerazy Tuesday, February 07, 2017 8:37 AM
    Thursday, February 02, 2017 2:26 PM

All replies

  • Hi Seb,

    First follow the following blog to check WMI service:

    https://blogs.msdn.microsoft.com/clustering/2010/11/23/trouble-connecting-to-cluster-nodes-check-wmi/

    Besides, considering you are using Win 10, I suggest you post in Windows 10 forums for help:

    https://social.technet.microsoft.com/Forums/en-US/home?category=windows10itpro

    Best Regards,

    Leo


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, September 19, 2016 3:15 AM
    Moderator
  • There is NO issue with WMI of the cluster, as connectivity from ANY OTHER OS works perfectly fine.

    Why posting in W10 forum would be any better, if the issue does not concern OS, but Hyper-V Management Tools in particular?!

    Tuesday, September 20, 2016 10:22 AM
  • Hi Seb,

    >>Same server accessed from Windows 8.1 H-V Management Tools is working fine.

    >>as connectivity from ANY OTHER OS works perfectly fine.

    As you have mentioned, other OSes are connecting to the same server successfully.

    Best Regards,

    Leo


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Wednesday, September 21, 2016 1:18 AM
    Moderator
  • Thursday, September 22, 2016 3:56 PM
  • Hi Scerazy,

    I found a post of the similar error, and it seems it seems it's related to a HP update if you are using HP device.

    https://social.technet.microsoft.com/Forums/en-US/1cc9115d-5fce-4a64-a90f-d3fdc008b861/windows-10-build-10240-managing-hyperv-on-2012-r2-datacenter-cannot-connect?forum=winserverhyperv

    Besides, as far as I know, Win 10 LTSB may not have all the latest features, it is also a possible cause. If possible, test with a Win 10 of latest build.

    Best Regards,

    Leo


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Proposed as answer by Marti__G Sunday, August 20, 2017 4:11 PM
    Friday, September 23, 2016 5:51 AM
    Moderator
  • I do not use HP, as it is Hyper-V VM

    LTSB 2016 RS1 is the latest build, and a standard build I am using for all my client (including my admin) machines

    I get IDENTICAL error connecting from Server 2016 to Hyper-V on Server 2012 R2

    WindowsVirtualization.V2.mof does NOT exist in these builds!

    Seb


    • Edited by scerazy Monday, September 26, 2016 11:45 AM
    Monday, September 26, 2016 11:17 AM
  • Hi Seb,

    Have you tried the following command? This rebuilds the WMI components for virtualization.

    MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof

    If still the same, I suggest you open a case with Microsoft, more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this issue.
    Here is the link:
    https://support.microsoft.com/en-us/gp/support-options-for-business

    Best Regards,

    Leo


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, September 27, 2016 3:03 AM
    Moderator
  • I already stated:

    %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof

    does NOT exist in 2016 builds!

    Tuesday, September 27, 2016 7:46 AM
  • Hi Scerazy,

    I mean running the command on Server 2012 R2.

    The error is management tools could not access expected WMI class on Server, now you are stating components does not exist on Win 10.

    And I have mentioned, LTSB version is different from normal version, it will not be updated with new feature. That's why I suggest you test with a normal latest build.

    https://blogs.technet.microsoft.com/uktechnet/2015/07/13/windows-10-licensing-logic/

    Anyway, if your are believing the cause is the component not existing on Win 10, that is to say, the management tool on Win 10 is using a WMI class which doesn't exist on it. Well, it came to my original suggestion, posting in Win 10 forum.

    Best Regards,

    Leo


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, September 27, 2016 8:22 AM
    Moderator
  • What are you talking about?

    LTSB 2016 (NOT the original old 2015 version! you are probably thinking of)

    Why would I run anything on Server 2012 R2 which works perfectly fine & is accessible by ANY W7/8.x clients as well as other 2012 R2?

    Obviously it is something in W10 1607 version

    Also rebuilding the mof is causing other serious issues, so it should NOT be used in production, as per:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/1cc9115d-5fce-4a64-a90f-d3fdc008b861/windows-10-build-10240-managing-hyperv-on-2012-r2-datacenter-cannot-connect?forum=winserverhyperv#1cc9115d-5fce-4a64-a90f-d3fdc008b861


    • Edited by scerazy Tuesday, September 27, 2016 12:15 PM
    Tuesday, September 27, 2016 9:11 AM
  • Just bumping in here to let you know I have the exact same issue. Hyper-V Host is a Server 2012, connecting from any OS works fine but my Windows 10 Enterprise Anniversary Edition (1607) gives the exact same error message you ar getting.

    Tuesday, September 27, 2016 1:22 PM
  • For now I settled for:

    http://www.5nine.com/5nine-manager-for-hyper-v-free.aspx

    which works perfectly fine (obviously not a "solution, just software replacement - amazing that 3rd party makes something that works & MS can not connect from own software to own software!!!)

    Tuesday, September 27, 2016 1:31 PM
  • Hi Scerazy,

    Thanks for sharing the solution.

    I would post here if I got any updates on the issue.

    Best Regards,

    Leo


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, September 28, 2016 7:55 AM
    Moderator
  • I do not consider it a solution, it is 3rd party replacement, hardly solution to the existing problem/bug/whatever
    Wednesday, September 28, 2016 12:02 PM
  • Hi Scerazy,

    Server 2016 is launched, you could have a test with it:

    https://blogs.technet.microsoft.com/hybridcloud/2016/09/26/announcing-the-launch-of-windows-server-2016/

    If you have any issues when using it, you could try to post to the feedback site:

    https://windowsserver.uservoice.com/forums/295047-general-feedback

    Best Regards,

    Leo


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, September 30, 2016 2:16 AM
    Moderator
  • As ALREADY STATED, I had tested it with Server 2016 & get exactly the same issue!
    Friday, September 30, 2016 9:48 AM
  • Hi Scerazy,

    Are you testing with Technical Preview or Server 2016? Server 2016 was launched.

    There are posts of similar issue but with no solutions currently. I suggest you open a case with Microsoft, more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this issue.

    If it has been proved as a bug, the fee would be refunded.

    Here is the link:
    https://support.microsoft.com/en-us/gp/support-options-for-business  

    Best Regards,

    Leo


    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Monday, October 03, 2016 1:20 AM
    Moderator
  • Can't afford any fees for support, will wait for somebody else to do it
    Monday, October 03, 2016 12:49 PM
  • I get the same problem.

    Waiting for the fix from Microsoft.

    Tuesday, October 04, 2016 3:51 AM
  • The solution here works: https://social.technet.microsoft.com/Forums/en-US/1cc9115d-5fce-4a64-a90f-d3fdc008b861/windows-10-build-10240-managing-hyperv-on-2012-r2-datacenter-cannot-connect?forum=winserverhyperv

    run “MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof”

    Tuesday, October 04, 2016 8:27 AM
  • Why would you point back to same thread again? That is NOT a solution in any shape or form, just read my LAST post that that thread!
    Wednesday, October 05, 2016 10:10 AM
  • I'm getting the same problem. Works from Win 8.1 but not 10. Very frustrating.
    Monday, October 10, 2016 7:24 AM
  • We just configured two Windows 2012R2 hosts, on HP ProLiant hardware with clean installs of Hyper-V.  I could connect to one machine from the Hyper-V manager on our management workstation running the latest Windows 10 build. The second machine got the error noted above, even though they were identically configured. We were able to connect to both machines from each other's Hyper-V management consoles, incidentally.

    Running "MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof” did indeed fix it, right away.  For what that's worth.

    Friday, October 14, 2016 7:30 PM
  • @ Tavis F, did you read all side-effects that this will cause?

    As per post from Phil_Jehl here

    IT IS NOT A SOLUTION & DEFINITELY NOT FOR PRODUCTION!!!!

    "beware if you run  “MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof” it does fix the issue but  afterwards  you will have issues with System center virtual  machine manage running  jobs on that particular host. Some things worked but  most reconfigurations  via VMM would fail  or behave as completed but changes never made. All seemed to be working  until I tried to  apply a logical switch configuration to the host. I rolled back the host  back to the  its configuration prior to a running the mofcom command and all is back to normal. Since I have several test hosts  I was able to replicate the identical issue on another Hyper-v 2012R2 host (just to rule out it was not the particular host). Though I have VMM there are certain functionalities that it does not have that are available in the native Hyper-v manager."


    • Edited by scerazy Sunday, October 16, 2016 4:12 PM
    Sunday, October 16, 2016 4:11 PM
  • scerazy,

    Thanks for clarifying that. I, too, had read that this command fixed the problem but had undesirable side effects. So, tempting as it is, I haven't run it.
    I've got two identically built hosts with replication happily running between them but only one host exhibits this fault. It's incredibly frustrating, and no sign of a fix from Microsoft.

    Monday, October 17, 2016 9:57 AM
  • We are seeing the same issue here on Windows 10 1607. If I remember correctly it happened on Windows 10 1511 as well. We can use the Hyper-V Management Tools from Windows 7, 8.1 and 2012/2012 R2 with no problems, but anything with Windows 10 will not connect.

    Failover Cluster Manager has a similar issue. I can connect to a cluster without errors, but when trying to connect to a VM from the Failover Cluster Manager it fails with the same error message.

    Wednesday, October 19, 2016 11:42 PM
  • Anybody yet seen any acceptable solution to it?
    Monday, October 31, 2016 9:29 AM
  • Nope. Still tearing my hair out.
    Monday, October 31, 2016 9:48 AM
  • I get the same error when trying to connect to Server 2012 R2 Hyper-V hosts with Server 2016 Hyper-V Manager. It only seems to happen when connecting to HP servers.
    Monday, October 31, 2016 7:27 PM
  • To me it happens on DELL servers, so manufacturer is most likely coincidental

    I have NO agents of any kind installed on them

    • Edited by scerazy Tuesday, November 01, 2016 12:22 PM
    Monday, October 31, 2016 8:48 PM
  • I read somewhere about this only affecting HP servers (which is what I've got). Upon double-checking them, my ostensibly two identical servers turned out to be slightly different. The one that wasn't contactable by Hyper-V Manager had all the HP Management Agents installed, notable the HP WEBM Provider. I uninstalled it and started getting a slightly different error in Hyper-V Manager. I naively thought I was making progress, but no.

    I can only think that one of these agents messes up the native Windows WMI in some way. I may end up uninstalling all of them but as of now I'm still no further forward.


    • Edited by AndyChips Tuesday, November 01, 2016 10:04 AM
    Tuesday, November 01, 2016 10:04 AM
  • Still nothing from nobody?
    Monday, November 14, 2016 11:54 AM
  • Same here. Waiting for a solution from anyone, but most especially Microsoft. Very frustrating!

    Just as an FYI - this used to work just fine up until a few weeks ago. Obviously some automatic update from MS messed things up! No easy way to ascertain which one it was. Most annoying!

    • Edited by kwiggins Tuesday, November 15, 2016 1:08 AM
    Tuesday, November 15, 2016 1:02 AM
  • I ran into this issue as well. I have HP servers and I applied the latest 2016 SPP from HP. It updated the HP WBEM components and broke my Hyper-V MMC from my Windows 10 1607 client. I applied the suggested MOF file re-registration and that immediately fixed my Hyper-V management console from my PC, but broke VMM switches.

    The fix is to simply uninstall VMM agent from the Hyper-V host(s) (Programs and Features - Uninstall), refresh the Cluster in VMM (if applicable), then the Hosts itself in the VMM Console. If you look at the host properties in VMM you should then see a WinRM ERROR, now re-install VMM Agent from the original media/ISO. (Done locally on the Hyper-V server in question). Once re-installed go back to VMM and refresh the cluster (if applicable) and then the host, you should now have an "Attention", rather than an "ERROR", and will need to do a "Repair All" of the Hyper-V host to update the VMM agent software. Once software is updated, reboot the Hyper-V host. Repeat with each Hyper-V host that has the issue. If you install the agent software and still see any issues with Performance Counters in the host properties, you just need a Hyper-V hosts reboot and then another refresh of the host in VMM.

    This procedure has worked for me numerous times with not only HP software but other 3rd party software that messes with WMI. VMM is very sensitive to WMI changes.

    Also note that you may have some VMs that show up as unsupported cluster configuration once you're all done, just right click and refresh the VM in VMM, it should clear any false errors. It did for me.

    I also posted this in similar forum post...

    https://social.technet.microsoft.com/Forums/en-US/1cc9115d-5fce-4a64-a90f-d3fdc008b861/windows-10-build-10240-managing-hyperv-on-2012-r2-datacenter-cannot-connect?forum=winserverhyperv


    Sean

    Tuesday, November 15, 2016 1:16 AM
  • Thanks, Sean. Will try your fix tomorrow and report back the results.
    Tuesday, November 15, 2016 1:19 AM
  • Hi Sean,

    Thanks for your detailed response. Unfortunately, it did not work for me. However, the link to your posting in another forum did provide the solution that worked for me. Cannot guarantee it will work for everyone but for those who are interested here is what I did:

    Short answer – remove and re-add Hyper-V role.

    Detailed steps for my situation:

    I have 5 Hyper-V hosts all in the same cluster. I did this individually to each host one at a time. Sorry if you have a large number of hosts L

    1. 1. Move all guests off the host, even shut down ones.

    2. 2. Put host in maintenance mode.

    3. 3. Remove host from cluster, if it is in one.

    4. 4. Remove Hyper-V role from host. Don’t have to remove management tools.

    5. 5. Check config on management NIC and reconfigure if needed.

    6. 6. Reboot host. Have alternate means of console access if using remote desktop (i.e. iLO or DRAC) in case you lose settings on management NIC.

    7. 7. Reconfigure management NIC (if needed).

    8. 8. Re-add Hyper-V role. Set correct default paths to disks and vm files if needed.

    9. 9. Reboot host.

    1010. Re-create any virtual switches you had previously on the host. And set other host properties as appropriate.

    1111. Re-join host to cluster if host was previously clustered.

    1212. Exit maintenance mode if host shows as still in that mode.

    You should now be able to manage your host from Win10! J Until the next update breaks it again ;-)

    Ciao!

    • Proposed as answer by kwiggins Monday, January 02, 2017 3:43 PM
    Wednesday, November 16, 2016 10:45 PM
  • Not really a "solution" for PRODUCTION, is it?

    "...remove and re-add Hyper-V role..." = sledgehammer to a nut

    Thursday, November 17, 2016 6:53 AM
  • Maybe not really THE 'solution' but it was A solution that worked for me. Anyway better than getting more and more frustrated waiting around for MS to issue a patch or some other 'production ready' solution. And, oh , by the way, I did it while all my VMs were in production. That's the beauty of having an N + 1 Hyper-V hosting solution ;-) Good luck in your search for 'THE' solution. Please post back here if you find it. Cheerio!
    Thursday, November 17, 2016 7:11 AM
  • This my solution that does not involve uninstalling Hyper-V role nor removing the Server from the Cluster:

    https://technobabble.tech/hyper-v-expected-wmi-class

    • Proposed as answer by Someone24 Tuesday, December 20, 2016 11:19 AM
    Tuesday, December 20, 2016 11:07 AM
  • Hi Someone24,

    Your solution involves running the command: “MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof”

    As pointed out earlier in this thread, "IT IS NOT A SOLUTION & DEFINITELY NOT FOR PRODUCTION!!!!"

    Just want others reading this thread to be aware this command has caused problems for other users.

    My solution posted above, although, "= sledgehammer to a nut", as pointed out by scerazy, at least worked and did not create any other problems.

    Happy New Year!

    • Proposed as answer by kwiggins Monday, January 02, 2017 3:43 PM
    • Unproposed as answer by kwiggins Monday, January 02, 2017 3:43 PM
    Monday, January 02, 2017 3:38 PM
  • Hi Kwiggins,

    Whilst it does run “MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof” the issues others have had are to do with the fact VMM no longer works after it has been run due to dependencies with WMI.  Removing the VMM Agent and reinstalling after it has been run resolves these issues.

    Removing Hyper-V feature and re-adding it is doing much the same thing as running the above command.  Removing Hyper-V removes it from the WMI namespace and then reinstalls it which is exactly the same as running mofcomp.

    If you can document exactly what issues this approach causes I'll be happy to amend the published resolution.

    Wednesday, January 11, 2017 1:11 PM
  • Hi Someone24,

    Nice explanation. Thanks for the clarification. Now I like your solution as a better one than mine. I cannot document exact issues running mofcomp causes as I did not use the command. If any others can, please post. Otherwise +1 upvote from me and I propose we list yours as the solution of choice until MS can come up with a fix for this problem.

    Cheerio!

    Wednesday, January 11, 2017 4:35 PM
  • So, I've had a case open on this with 3rd Tier premier for a while and have finally figured out the exact cause of this on my own.

    I was aware of the WindowsVirtualization.V2.mof hack which breaks UEFI boot settings and wanted to figure out more.

    We have both Dell and HP Servers, and there are two specific components which cause this problem:

    • Dell OpenManage Inventory Agent (used for SCUP/SCCM integration for driver/firmware updates)
    • HPE Insight Management WBEM Providers (used primarily for monitoring and replacement of SNMP)

    These two tools add root\Dell and root\HPQ Namespaces as their primary function.  However, they also destructively modify root\Interop.  Event ID 5631 is logged right after the install:

    WMI interop namespace class "%1" has been overwritten. Some of the Interop scenarios might not work properly. Please issue following commands from elevated command prompt to restore the behavior."mofcomp %windir%\system32\wbem\interop.mof" and similarly mofcomp all the interop.mfl under %windir%\system32\wbem and its subdirectories.

    I wasn't sure what Interop had to do with Hyper-V, but I decided to enable WMI Tracing on the Hyper-V box to see what was going on when I tried to connect.  Under WMI-Activity, in the Tracing Log, I got Event ID 11 when I tried to connect and failed:

    CorrelationId = {B76DE300-7352-0008-ECE3-6DB75273D201}; GroupOperationId = 26653; OperationId = 27079; Operation = Start IWbemServices::ExecQuery - root\interop : references of {Msvm_RegisteredProfile.InstanceID="DMTF|System Virtualization|1.0.0"} where ResultClass = Msvm_ElementConformsToProfile Role = ConformantStandard; ClientMachine = HYPERVSERVER; User = DOMAIN\username; ClientProcessId = 536; NamespaceName = \\.\root\interop

    So, the Hyper-V console on Windows 10 is indeed looking for instances under Interop\Msvm_RegisteredProfile.  Using WMI Explorer, I compared a machine which worked with one that didn't.  Here's a screenshot of one that worked:

    WMI Explorer

    On a non-working System (such as my test system listed in the Event ID 11 above), Msvm_RegisteredProfile is either completely missing, or is empty - no instances are present.  There’s also Msvm_ReferencedProfile, which is in the same boat, but only on HP servers; however, I’m not sure how important that class is.   Both of these classes are in WindowsVirtualization.V2.mof.  So it appears Windows 10 needs these classes to be present, but Windows 8.1/2012R2 do not care.  Recompiling interop.mof/mfl did nothing, since these classes aren’t present in that MOF.

    As a hack, I basically cherry-picked the root\Interop sections from WindowsVirtualization.V2.mof and saved them as a new MOF and imported it.  It seems to work (I can now reconnect), and still allows the UEFI boot settings that recompiling the entire WindowsVirtualization.V2.mof would break.  I can't comment on SCVMM, as I didn't replicate that problem.

    I'm waiting back to hear from a WMI expert on whether or not this course of action would be worthwhile.  If so, I'll upload the small 192-line MOF file.  (For reference, WindowsVirtualization.V2.mof is 4581 lines).  If you are comfortable editing MOF files, feel free to try it yourself on a test machine.

    /gw

    Friday, January 20, 2017 9:05 PM
  • Excellent post, agressiv!

    Don't know if anyone else is still watching this thread as no one has posted, especially OP scerazy. However, I for one, am very interested to hear what else you can find out.

    Please do post back with any other info you find.

    Thanks!

    Wednesday, January 25, 2017 1:31 AM

  • As a hack, I basically cherry-picked the root\Interop sections from WindowsVirtualization.V2.mof and saved them as a new MOF and imported it.  It seems to work (I can now reconnect), and still allows the UEFI boot settings that recompiling the entire WindowsVirtualization.V2.mof would break.  I can't comment on SCVMM, as I didn't replicate that problem.

    I'm waiting back to hear from a WMI expert on whether or not this course of action would be worthwhile.  If so, I'll upload the small 192-line MOF file.  (For reference, WindowsVirtualization.V2.mof is 4581 lines).  If you are comfortable editing MOF files, feel free to try it yourself on a test machine.

    /gw

    Finally, someone who's made progress on this.  That huge old thread about recompiling the entire .mof just has dozens of people parroting the same "fix" that breaks UEFI.

    If you've gotten any further with this, I'd love to hear about it.  Looking at the entire WindowsVirtualization.V2.mof file, I'm not about to mess with it just yet.  I've looked at a few .mof files for Config Manager and made very specific tweaks, and that's the limit of my understanding of them.  I think I see the stuff you're talking about (everything from line 33 to line 224?) but reluctant to just pull the trigger on it, heh.

    Thanks!

    edit: some searching turned up HP doc ID c04896145 - looks like HP may have finally fixed their stuff, but not if you're doing an upgrade.  Explains why a system that was running HP WBEM 10.40 and been "fixed" (not really) by the heavy-handed mofcomp re-broke when I installed 10.60 a couple weeks back. 
    • Edited by Jay-bone Thursday, January 26, 2017 8:25 PM
    Thursday, January 26, 2017 7:52 PM
  • Hi Jay-bone,

    Thanks for the HP doc ID reference. That helps a great deal to clarify this whole situation.

    http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04896145&DocLang=en&docLocale=en_US&jumpid=reg_r11944_usen_c-001_title_r0001

    Bottom line - HP/Dell/any other manufacturers really need to coordinate with MS to fix this problem.

    It took a lot of digging by a lot of people to finally get some clarity on this problem. Even now the solution is not clear.

    HP's proposal to restore from backup SUCKS! That should never be a legitimate answer for a production server. Restore from backup is meant to be a last-ditch effort to avoid/recover from disaster. Let's hope MS is monitoring this thread and will come up with a more elegant solution. As it is right now, I will not do any updates to HP WBEM until I can be assured it will not break Hyper-V management and I don't have to do a 'fresh install' or 'restore the namespace after the upgrade.'

    Please post back if you come up with any more info.

    Friday, January 27, 2017 12:23 AM
  • in my testing that Advisory doesn't fix it anyway.  As soon as I apply the WBEM components, Hyper-V is hosed.  Even on a brand new server install.  I can't believe that people are not raising hell over this.

    For now, I guess I will not be installing that pkg.


    • Edited by dotps1 Tuesday, January 31, 2017 6:46 PM
    Monday, January 30, 2017 4:13 PM
  • D'oh!  Glad someone had a fresh server to test this on.  Thanks dotps1.

    agressiv, where did you go?

    This is gonna end up like https://xkcd.com/979/ isn't it?

    Tuesday, January 31, 2017 6:06 PM
  • I talked to a WMI expert who was relayed all of the information above.  He certainly concluded that the fault lies with both Dell and HP for destructively blowing away this class, but couldn't come up with a less intrusive fix, and more or less recommended the hack that I did until the respective vendors fix their own products.

    He mentioned a few other ideas which didn't seem too plausible, and only sort-of half-explained them.  The part he was worried about with my fix is that it could easily miss stuff not related to Hyper-V, so it wouldn't ever be recommended on a KB article or "supported" by Microsoft in any way.

    Rather than upload the file, here's the instructions:

    • Load up WindowsVirtualization.V2.Mof in a text editor with can show line numbers on the side.
    • This file should have 4582 total lines, with line 4582 being empty.  File size should be 1466522 bytes. If both of these are not true, abort here.  Date will vary since it will be the time your image was created pre-sysprep.
    • Copy the following lines to a new text file: 5, 33-42, 49-223, 4544-4549
    • Save this file to msvm_interop.mof.  Place it where you want, it doesn't really matter.
    • run mofcomp msvm_interop.mof from an elevated Command Prompt in the directory you've placed it, or provide an absolute path. 
    • Marked as answer by scerazy Tuesday, February 07, 2017 8:39 AM
    Tuesday, January 31, 2017 7:58 PM
  • @agressiv - thanks for the detailed update. Very helpful. Now - anyone have any ideas how to get HP, Dell, etc. to sit up and pay attention?
    • Marked as answer by scerazy Tuesday, February 07, 2017 8:38 AM
    • Unmarked as answer by scerazy Tuesday, February 07, 2017 8:39 AM
    Tuesday, January 31, 2017 11:36 PM
  • @agressiv - Thank you very much for your detailed information on this problem. We have HP servers and have confirmed in the root/interop namespace the exact issue and can see the Msvm_RegisteredProfile is missing on our problematic servers. 

    I am going to test by creating the file per your directions, however I am wondering about lines 4544-4549. Can you confirm that is the correct lines and explain what that section is for?

    Thanks!

    Thursday, February 02, 2017 12:41 AM
  • yeah that was an error on my part, WinDiff didn't highlight those line numbers properly.  It should be 4537-4541.  Here is the code snippet:

    class Msvm_ElementConformsToProfile : CIM_ElementConformsToProfile
    {
      [Override,MSFT_TargetNamespace("root\\interop")] Msvm_RegisteredProfile Ref ConformantStandard = $SVP;
      [Override] Msvm_ComputerSystem Ref ManagedElement;
    };

    Opening cases with Dell and HP are your best bet.  HP thinks they have a solution when someone here says they don't.

    • Marked as answer by scerazy Tuesday, February 07, 2017 8:37 AM
    Thursday, February 02, 2017 2:26 PM
  • Thanks for the update. I'm going to test it out.

    As for HP's solution. They fixed the problem in their WBEM providers so that when they are installed they don't delete root/interop. However, they do not add back in the missing information that their installation process removed in the first place. So the problem shouldn't happen moving forward, but it doesn't help any of us that already have the issue.

    Thursday, February 02, 2017 4:43 PM
  • Thanks for this, but as my \\.\root\interop

    is completely blank I get error during compile, as there is NO Msvm_RegisteredProfile

    C:\Windows\System32>mofcomp msvm_interop.mof
    Microsoft (R) MOF Compiler Version 6.3.9600.16384
    Copyright (c) Microsoft Corp. 1997-2006. All rights reserved.
    Parsing MOF file: msvm_interop.mof
    MOF file has been successfully parsed
    Storing data in the repository...
    An error occurred while creating object 1 defined on lines 4 - 6:
    0X80041002 Class, instance, or property 'CIM_RegisteredProfile' was not found.
    Compiler returned error 0x80041002
    Seb

    Monday, February 06, 2017 2:38 PM
  • Try running this first:

    mofcomp C:\Windows\System32\WBEM\interop.mof
    mofcomp C:\Windows\System32\WBEM\en-US\interop.mfl
    

    Replace en-US with your language code if it's something else.

    Monday, February 06, 2017 3:57 PM
  • Perfect! Works fine after that & connectivity is restored

    Well done agressiv !!!

    I just have no idea what would cause the issue in first place on my Dell R720 server, as I do NOT have any Dell specific agents installed at all.

    Seb


    • Edited by scerazy Tuesday, February 07, 2017 8:51 AM
    Tuesday, February 07, 2017 8:37 AM
  • Awesome.  Thanks, agressiv!
    Wednesday, February 08, 2017 3:14 PM
  • in my testing that Advisory doesn't fix it anyway.  As soon as I apply the WBEM components, Hyper-V is hosed.  Even on a brand new server install.  I can't believe that people are not raising hell over this.

    For now, I guess I will not be installing that pkg.


    I can't duplicate that, at least not with a new-ish package from HPE.

    Just got in a new ProLiant and did the following:

    1. Installed and patched up 2012 R2
    2. Added Hyper-V role
    3. Verified connectivity from Win10 and classes with WMIexplorer
    4. Installed all relevant HPE stuff from the October 2016 SPP
    5. Verified connectivity from Win10 and classes with WMIexplorer (went from 77 to 261, with the three msvm* classes still intact)
    6. Rebooted, in case it there were peding breaking changes
    7. Verified connectivity from Win10 and classes with WMIexplorer

    And so far, it's still working, without having to mofcomp all the msvm stuff, since it's all still intact, so far.

    Are you sure you were using a new version (10.60) of the HPE WBEM package?

    Wednesday, February 22, 2017 7:52 PM
  • Hi Agressiv,

    Great work - thank you. I'm just about to try your fix and I wanted to make sure I was copying the correct lines from the original MOF.

    5
    33-42
    49-223
    4537-4541
    4544-4549

    Are these correct?
    Thanks,
    Andy.

    Tuesday, February 28, 2017 12:05 PM
  • Andy -

    That is correct.  As always, test on something non-critical first if you are nervous about such changes.

    Wednesday, March 01, 2017 3:33 PM
  • <details about installing the HPE WMI-killing stuff on a new server deleted>

    And so far, it's still working, without having to mofcomp all the msvm stuff, since it's all still intact, so far.

    Are you sure you were using a new version (10.60) of the HPE WBEM package?

    Interestingly, all's still well, but only when connecting from a CBB 1607 box.  From CBB 1511... not so much.  On the 1511 box, it's not the same old error we've all seen that specifically calls out root\interop, though. It's a more generic one:

    • "Hyper-V encountered an error trying to access an object on computer 'ComputerNameHere' because the object was not found.  The object might have been deleted.  Verify that the Virtual Machine Management service on the computer is running."

    "An object"  Oh. Well, that really narrows it down. :P

    Getting out of my depth here, but looking with WMIexplorer, the msvm_ReferencedProfile and msvm_RegisteredProfile classes on a connectable server are populated with various instances.  On the one that 1511 won't connect to, those classes are empty.  Same 1511 workstation connects fine to a test box that was formerly broken and fixed with agressiv's process.  That one fixed with agressiv's process also has all of those missing instances.

    I didn't check the contents of the classes before installing the HPE stuff, nor whether a 1511 workstation could connect to that host with Hyper-V manager.  I just checked that the classes existed both before and after.  It may be that the HPE stuff did break them, just not as badly as it used to.  It may also be that upgrading the 1511 box to the new CBB version will fix the problem.  Unfortunately, I can't really test either scenario at the moment, since that server's been put into production and I don't have the time and resources (another workstation to use at the location while upgrade happens) to upgrade the 1511 workstation, or any other 1511 workstations to test with.

    Thursday, March 02, 2017 7:52 PM
  • To me it happens on DELL servers, so manufacturer is most likely coincidental

    I have NO agents of any kind installed on them

    Not even any kind of DELL agents, similar to HP SPP WBEM for example?
    Monday, October 30, 2017 9:12 PM
  • Hi Jay-bone,

    Thanks for the HP doc ID reference. That helps a great deal to clarify this whole situation.

    http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04896145&DocLang=en&docLocale=en_US&jumpid=reg_r11944_usen_c-001_title_r0001

    Bottom line - HP/Dell/any other manufacturers really need to coordinate with MS to fix this problem.

    It took a lot of digging by a lot of people to finally get some clarity on this problem. Even now the solution is not clear.

    HP's proposal to restore from backup SUCKS! That should never be a legitimate answer for a production server. Restore from backup is meant to be a last-ditch effort to avoid/recover from disaster. Let's hope MS is monitoring this thread and will come up with a more elegant solution. As it is right now, I will not do any updates to HP WBEM until I can be assured it will not break Hyper-V management and I don't have to do a 'fresh install' or 'restore the namespace after the upgrade.'

    Please post back if you come up with any more info.

    My problem is settled after I run "mofcomp %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof" on my 2012R2 host. That hpe link is really helped because I just updated my server WBEM.

    Thursday, January 18, 2018 3:43 AM