1. Once you deployed a new vcenter pointed to primary one in linked mode .. have you joined the new VC to AD?
2. Have you added the permissions at vcenter level or global permissions?
only after VC is joined to AD, the global permissions inherit to the second VC.. If the permissions are at vcenter level, they will not be inherited by second vcenter. You need to manually assign the permissions
thanks,
MS
Hey Guys,
I recently upgrade my environment from 6.7 u1b to 6.7 u3f.
The first thing I noticed after the upgrade was the version numbers were different in the appliance management console and the vsphere web client.
The appliance management stated version 6.7.0.43000 build 15976714
The vSphere web client stated version 6.7.0.42000 build 15976728
According to https://www.virten.net/vmware/vcenter-release-and-build-number-history/
Would this be of any concern?
Also we have an Horizon View connection server, when trying to connect using the alias via the Horizon Client it is considerably slower than normal. Would this have anything to do with the upgrade?
Appreciate any help
Hi Stefan,
Thanks for your question. I have reached out to our security folks and they have confirmed that the "ACL MODE: Legacy" text will still appear after the upgrade. The KB article has been updated to make that clear.
Thanks,
--
Darius
This build 15976714 is a VAMI release and build 15976728 is client/MOB
Thx, but the issue it seems more complex. Too much time to debuging out. Instead i migrated the distributed switch, disconnect the host from the old system, reconnect to the new, and migrate the network only. Its works nicely. The only issue is i lost the VM folder structure, but thats OK, i can recreate. I think this is far more better than migrate from the old system. It seems many other things messed up so i give up that. I can migrate everything with this method without any downtime. Its only ~150 VM, and 4 hosts. No big deal. Its a little handwork for sure.
On the other hand GSS not an option this time. Because the coronavirus i cant even reach anybody on the support.... I have to do everything by myself.
Really looking for some help .... as a newbie, I'm trying to setup a lap to learn, so anything appreciated. Any of the setting in this red box, CAN NOT SET them, maybe I can via esxcli? OR set the GUI right?
Hoping for some guidance / help. Right now have used the command line to setup a second TCP/IP stack, hoping to have a second mgmt connection. I have successfully:
1. created the TCP/IP stack
2. created vmk nic
3. made the associations in web ui,
4. able to view the above vmk, TCP/IP stack.
i. NONE of the static setting in custom stack are editable, from what I have been able to learn, is I need to 'enable' or setup vmkernel port? (HOW, I don't know.)
I can 'edit' the stack in the gui. I have successfully set the management setting for the vmk nic, but the last thing ... that I think I need to do is set up the custom TCP/IP stack, but I can't. I'd be ok with doing it vi esxcli command but I can't find anything on how. HELP if you can pls
Cheers!!
However I tested it again to be ensure in my lab... For ESXi version 6.0 and 6.7 (that I deployed them before) when you connect directly to the ESXi host with the vsphere web client, regardless of Default TCP/IP stack you cannot modify none of the TCP/IP stacks. Then I back to the vCenter server and change the provisioning stack's IPv4 gateway, and come again to the ESXi. While that field is shown editable, but I couldn't change the parameter here. (prompt failed to update ...)
Update repo URL is pointing to https://vapp-updates.vmware.com/vai-catalog/valm/vmw/8d167796-34d5-4899-be0a-6daade4005a3/7.0.0.10100.latest/ as this is the latest version, and as new updates are not available yet, we are seeing this error. I feel this error would be gone once a new update is released.
Are we affected by Vcenter vulnerability? Need confirmation for the below link..? we are running VCenter 6.5 standard.
https://securityaffairs.co/wordpress/101805/security/vmware-vcenter-server-issue-details.html
Thank you.. for the reply. So if I understand you tested it, and was not able to modify any of the settings? So I'm guessing that the custom TCP/IP stack is not an option I can use. I thought I was close with the esxcli options, but I can't seem to find the command / method of how to configure the stack from the command line. Do you have any suggestions I might be able to try
That vulnerability only affects vCenter 6.7 after it's been upgraded from 6.0 or 6.5. If you are running 6.5 currently you are not affected - https://kb.vmware.com/s/article/78543 for more info
I can confirm that the "ACL MODE: Legacy" still gets thrown after upgrading to vCenter 6.7 U3f.... They should've changed that TBH.
One thing I found that my vCenter is quite different from normal is the data center authority of the Administrator account:
Normal vCenter.Data center permissions for the Administrator account：
Abnormal vCenter.Data center permissions for the Administrator account:
Do you know how to restore the original authority of Administrator?
One thing I found that my vCenter is quite different from normal is the data center authority of the Administrator account:
Normal vCenter.Data center permissions for the Administrator account：
Abnormal vCenter.Data center permissions for the Administrator account:
Do you know how to restore the original authority of Administrator?
I think if you have many configuration and modification on the vsphere infrastructure, like creating vsphere distributed switches, host profiles, content library and so on, I think it's better to choose upgrade instead of new installation to avoid risks of any downtime, orphaning objects or lose of vCenter related components. Especially VMware put an option of migration from windows-based vCenter server to the appliance-mode in the VCSA installation console.
Until you can upgrade the vCenter in any form of deployment (even with the external PSC), it's better to choose it and avoid clean setup
Always you have a little more changing and customization operations in the CLI/Shell environment (especially via the using the esxcfg / esxcli) in front of vsphere client/ web client, but after all you should know exactly each one of TCP/IP stacks are used for which operation:
Ok! Thanks, that explains
:-)