KB4010672 Breaks all new networks about sdn HOT 10 CLOSED

@Bearcomtech I'm sorry you're experiencing this issue, and thanks for reaching out. I'll follow up with my team and we'll get back to you on this ASAP.

from sdn.

This issue is caused by VMM when this update installs a new certificate on the host without updating the network controller. The simple solution is to use VMM to "Repair" each host. That will cause VMM to import the correct certificate into the network controller. The VMM team is looking into addressing this to keep it from occurring with future updates.

from sdn.

@kallie-b Thank you for looking into this.

@grcusanz Could you elaborate a bit more? which certificate is the problem? In my tests i installed everything for the begining with all the latest patches which should make all involved systems to have all certificates from the begining. Except for my selfsigned certificate which is deplyoed during controller deplyment. I even in my first test removed the Switch from the host and reattached it without success.

from sdn.

Ping @grcusanz

from sdn.

We had similar issue, it turned out to be the scvmm certificate that was missing from trusted root on the Hyper-V hosts, it was just present in the personal store. Could be worth a look.

from sdn.

I am still confured. I got it working by installing hosts without updates and the rest of SDN components with fully updated vm's. I still get ALOT of errors when i run my debug but everything seems to work. however i would like to be able to patch my hyper-v hosts. Which is the scvmm certificate? which certificate is it that i need to verify. My selfsigned certificate is located on all hosts under hklm\root but you mention some other certificate that i cannot seem to understand which it is.

from sdn.

Hi, I meant the cert with friendly name "SCVMM_CERTIFICATE_KEY_CONTAINERhostname.domainname"
We have been troubleshooting this with Microsoft and at first that seemed to be the problem.
This however wasnt the issue.

The problem we had was caused by another certificate in "Trusted Root"(on all Hyper-V hosts), it was a cert that was "issued by" "Verisign Class 3 Public Primary Certification Authority" and "Issued to" "VeriSign Class 3 Public Primary Certification Authority - G5".
According to Microsoft this cert should not be in the "Trusted Root" since "Issued By" and "Issued To" is different.

This certificate was most likely automatically installed when we installed hardware agents, raid management or some other Fujitsu specific software. We don't at this point know for sure wich part installed this.

To solve this, rightclick the "bad" cert -> Properties and change "Certificate Purposes" to "Disable all" and after that restart the NC Host agent on the host.

This solved our issue, hopefully it will help someone else.
All credits to find the problem goes to Microsofts SDN/VMM team that helped us solve this.

from sdn.

Okay to close?

from sdn.

@Bearcomtech okay to close? Did this solve your issue?

from sdn.

Hi,
Well i have not solved the issue yet. But i suppose you can close the ticket. My problem does not seem to occur due to certificates.

from sdn.