As per my previous blog on SMB1 AD authentication issue in 6.5u1 , VMware communicated that it will be fixed after the 6.7 U2 update but it looks like in the recent 6.5 U3 update it got fixed.In the release notes they mentioned some fix related to AD and we tested with few hosts and able to connect the AD now without issue.
PR 2268193: Managing the Active Directory lwsmd service from the Host Client or vSphere Web Client might fail
Managing the Active Directory lwsmd service from the Host Client or vSphere Web Client might fail with the following error: Failed – A general system error occurred: Command /etc/init.d/lwsmd timed out after 30 secs.
In our POC for our new application , noticed the significant differences on the performance on two different environment which is running on same hardware model.Even though the network layer is different from the environment A and B the issue is when the data is copied locally .
Later we noticed when we change the EVC Mode from Intel Nehalem Generation to Intel Ivy Bridge a good performance improvement.
From the VMwareblog , it is mentioned that ” For most enterprise applications you can see there is no, or an almost immeasurable, performance impact when using EVC. But, there are certain corner cases, like encryption, that are crippled when instructions sets like AES-NI set are not available (Example: Oracle Transparent Data Encryption, OpenSSL)” so our data in POC is also encrypted and to make sure we setup the test VM and configured the Apache for the speed test with SSL on port 1000.
The htdocs folder was in localdisk (tintri NFS datastore) and tested with localdisk (local SAS disk datastore)
As per the VMware Blog also they mentioned the test result and for encryption there is a huge different so when setting up the new cluster , we should understand the type of application and traffic type , based on that we have t select the cluster EVC mode.
Note : Anything above Nehalem Generation wont be supported by VMware 7.0 version for HP Gen8 old hardware models so pls check the VMware compatible guide and choose the EVC mode.
During the DR test we have noticed that few of the Redhat 5\6\7 VMs were failing with various errors like ( “A general system error occurred: vix error codes = (3016,0)”,”Error – Timed out waiting for VMware Tools after 900 seconds”) on IP customization part and we have tried few option but it looks like VMware tools 10.1.x is the cause for the login delay and VMware has recommended to upgrade the SRM to 8.1.1 version.
IP customization might be failing due to the login delays with 10.1.x and above tools which uses SAML token authentication on the OS whereas 10.0.9 and below uses VIX authentication using VM tools when they are running on OS.
With SRM 8.1.1 we have added a delay in the code so the timeout value for this specific task is increased which can allow the customization script to be completed at OS level:
On of our vCenter was having issue on connecting the AD users and when users trying to connect the VC , it will fail with the invalid credentials error.
I have already mentioned few blogs about AD authentication issue here and here .
Tried removing the AD and re-adding it from the PSC and also from the identify sources but it didn’t help to fix the issue so we started looking the logs and found the below error while trying to login using AD credentials.
In disjoint domain namespace the domain users might fail to authenticate after you update to vSphere 6.5 Update 1After you update a Platform Services Controller Appliance to vSphere 6.5 Update 1, in the disjoint domain namespace the users might fail to authenticate.1. Log in to the Platform Services Controller Appliance as root and activate the bash shell.
2. Leave the domain by running the /opt/likewise/bin/domainjoin-cli leave command.
3. Reboot the appliance.
4. Delete the computer account on the Active Directory.
5. Log in to the appliance again and enable the bash shell.
6. Join to the domain by running the following command /opt/likewise/bin/domainjoin-cli join domain-namedomain_admin_user
for example: /opt/likewise/bin/domainjoin-cli join vmware.com administrator
7. Reboot the appliance.
Refer :VMware vCenter Server 6.5 Update 1 Release Notes ( Please check in release notes under Server Configuration Issues section)
Yes, SMB2 is supported from 6.5u1 onward but the initial SMB packet negotiation
request always happen over SMB1 packet. If SMB2 is enabled on both AD and the
host, then the negotiation switches to SMB2 otherwise it negotiates through SMB
So if SMB1 is disabled on the domain controller then it would prevent the
initial packet negotiation, thus causing SMB packet drops and eventually domain
join failure with error ERROR_GEN_FAILURE.
From 6.7u2, we'll be supporting initial packet negotiation with SMB2 by default
instead of SMB1, thus disabling SMB1 completely.
We have also tried the option by selecting the preferred AD server option which is already enabled with SMB1 , still we were not able to join in domain and got the update from the VMware as below..
"preferred server" option does not specifically imply that the connection will go through the server specified, but it's just a reference in case it is under the servers reported.
It seems like our only option would be enable SMB1 on the AD servers,
So, basically we cant be able to join these hosts to AD domain unless SMBv1 is enabled. Otherwise, we need to Wait for 6.7 U2 release.