And if persist connection and/or connection of target to domain is not available or possible, why can't we find a permanent fix that will resolve this as was?
I find that every couple of days, without rebooting or changing anything else the NTLM hierarchy has changed once again and set yet again below the Negotiate bullet. à which means something is keeping (Actively) to change it from the TS or SMP.
When is this expected to be permanently resolved? Will Microsoft's Feb22 KB fix this? Is there a fixlet expected by Broadcom? What is the road map?
--------------------------------------------------------------------- A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
So now previously non connected Windows 2012 targets to any TS are OK?
Was the IIS procedure impactful on any other aspect? Is there any risk touching the NS IIS for this action?
Thank you Chris,
Yes, seeing all the commotion and the buzz around this KB in the past week.
Still hoping to hear about a permanent solution from MS / Broadcom that won't require a daily check to see if the NTLM configuration remains as was set.
Already viewed multiple other targets (same subnets, some network configuration) VM and Physical machines that yet again got disconnected from the TS. (yesterday I 1st only noticed VM's but later saw others as well).
Indeed when reverted the NTLM , all targets have successfully return online, but this is a weak workaround, since every restart of the SMP or TS, the NTLM settings are reset back to the original state (since the Jan22 Patches are implemented).
Is there any expected additional solution for this issue in Microsoft's Feb22 patches? Or Broadcom's fix let of some sort?
I know you are working on a chance of the entire SMP upgrade to 8.6 RU2 (+) to have the 3-part authenticate to get changed to 2-part, but that will require a full system (ITMS) upgrade, which if not necessary at this point, I wouldn't be so thread to perform just for the NTLM issue without knowing 100% resolves all targets.
The problem is the sporadic behavior of this issue, since I can pinpoint and find the root cause that some targets lose connectivity and others don't, if they are on the same network, same image, same OS, physical or VM, and yet , 1 act different than the other (if the NTLM isn't set as priority)