Forum Discussion
MCC Phantom Install
Hi All,
This was rather complex, so I'll leave my full resolution to this and some other things I ran into. I believe most of the problem centered around us using a VLAN ID on the NIC in the OS.
I did manage to get it at least mostly working (though not confirmed by our workstation team yet) by going through a convoluted route of creating an additional Hyper-V virtual switch set to bridge the network connection and specify the VLAN ID. This isn't possible using the default v-switch because the installer makes it fresh each time, so there's no way you can set a vlan ID on it until after, by which time it has already failed. In addition to this I disabled IPv6 on it (which Microsoft generally doesn't recommend). This was our test environment. Network and Workstation team have been having some trouble getting things configured and working for their part, so it may still be related to this janky configuration. Once I got it mostly working here, I came at the problem from another angle when it came to configuring our production server, which we skipped to due to a tight deadline for this project.
The fix for our production server was to have the network team adjust the vlan settings so that we didn't have to specify it in the OS. Then instead of disabling IPv6, we just lowered the metric manually so that it would prefer IPv4 beyond the ethereal Microsoft statement that it is already preferred.
We still await testing, but I think the latter is going to work.
It's also worth noting, in case you weren't yet aware, importing a certificate when you're using a gMSA for a runtime account doesn't work. MS has acknowledged this, but to my knowledge they have not stated when or if they will fix this. They will also be requiring HTTPS for MCC sometime in the future, so just keep that in mind.