For reference we already had our linked vCenter talking to Active Directory over LDAPS. However, we are currently in the process of migrating all of our VMs over to new hardware. When we tried to move the main Active Directory server providing authentication to vCenter, lets just say it was not happy.
Upon trying to enter into the Identity Sources and update the server(s) manually on the Identity Source that was already being used we received the following message: “Check the network settings and make sure you have network access to the identity source”.
It was not found until after doing some Googling that you have to remove your current running Identity Source in order to make changes. In other words delete the current identity source and add a “new” one in order to make the changes you want to make.
This just seems bad.
However, after doing a lot of testing in our TEST environment I could not seem to run into any snags. If you login with email@example.com and delete and then immediately re-add the identity source back with the same domain name, alias, etc, there does not seem to be any issues. All of your permissions on objects defined with AD groups will remain.
I’m personally not a fan of in place Microsoft Server upgrades but I suppose they have their time and place.
Since many of our 2012R2 servers are from the 5.1 and 5.5 days of VMware many of them are still running Virtual Hardware v9. This hardware version needs to be upgraded to perform the OS upgrade.
I was able to successfully re-create the issue with an upgrade of a clean 2012R2 install on v9 hardware. After the first reboot you will get stuck at the black screen with blue window, with no circle running underneath. I let this run for two full days (48 hours) before cancelling it.
After cancelling it and resetting the VM, you will be given the following error message:
We couldn’t install Windows Server 2019
We’ve set your PC back to the way it was right before you started installing Windows Server 2019.
0xC1900101 – 0x20017
The installation failed in the SAFE_OS phase with an error during BOOT operation
VMware generally states that you shouldn’t upgrade the VM hardware version unless there is a need. In this case there is a need.
My recommendations would be to do the following:
Shut down the VM you want to perform an in place upgrade on
Take a snapshot with the VM off
Upgrade the Virtual Machine hardware version (We went to v15)
Power on the VM, mount the ISO, run the upgrade
This process seems to be working for us, and although this may be a no-brainer, I’m putting it out there for the search engines to index in case it does help someone.
There seems to be an issue within VMware Fusion with the network management, trying to share a WiFi connection. I’ve read on some forums that people have had luck with sharing the connection instead of bridging it. If I try to share the connection I lose internet on my Kali VM.
The only way I can keep a connection is to bridge the connection, which gives me an IP off my wireless and lets me browse the Internet but something is being done to the traffic when trying to update which causes some security issues.
My current work around was to plug in another USB WiFI adapter and pass it through to the VM and let the VM use it to connect to my wireless in order to get out.
This only appears to be an issue when installing or updating software and I’m not quite sure what the network stack is doing underneath. When I have more time I hope to dig into this further..
After rebooting our vCenter appliance we noticed an error on vCenter regarding “Certificate Status”
After going to the Administration snap-in and clicking on “Certificate Management” and logging in to verify certificates we saw nothing out of order. All the VMware provided certificates were fine. I decided to keep digging.
for i in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list); do echo STORE $i; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store $i --text | egrep "Alias|Not After"; done
This provided the output necessary to see all certificates on the vCenter appliance, including third-party certificates. We noticed that we still had a thirty party certificate listed in vCenter with an expiration date coming up even though we already replaced it.
We are following up with the third-party vendor to get to a resolution.