Brian, What could have possibly changed in the update process that would change a configuration for this to stop working. I was on 10.4 for LFDS and Server and Web Client, pretty much everything and the auto-login worked. As soon as I updated to LF 11 for LFDS, Server, and Web client, it broke. It works when I'm on the server itself, but not on my workstation. I even tried rolling back web client to 10.4 and I'm still getting the popup. All my machines are on the same domain. and I have read the white pages multiple times and followed them. My users can log in if they type in their user name and password and if they open another tab, it logs them in just fine. 

Even hitting the STS site causes the prompt to come up, And this was NOT a problem last week before my update. 

In this case we do not seem to have any Kerberos problems, the users can still login, but they are getting the IIS Windows Auth prompt instead of auto logging in even from their workstations which are on the same domain as the server.

That only leaves the browser trusted zone issue, however after upgrading to version 11, all workstations company wide are getting this prompt indicating the upgrade changed a setting on the server. Obviously it couldn't have changed a setting across all workstations at once.

I am thinking it is an IIS configuration somewhere.

Any chance the URLs got changed at some point during the upgrade? Before worrying about what might have changed server-side, validate that the exact hostname (or matching wildcard entry) for the LFDSSTS URL is in end user workstation's "Local intranet" zone with one of these two settings selected:

All IIS controls are:

1. If it throws a 401 Windows Authentication challenge
2. The providers (Negotiate/Kerberos/NTLM) supported for WinAuth and their priority
3. A few server-side WinAuth security settings like Kernel-mode Authentication

Whether or not the client auto-responds to the 401 auth challenge is up to the client's settings.

That said, sometimes what happens is that the clients attempt to automatically login, that fails, and the Win Auth prompt is immediately re-thrown. This can happen fast enough it makes it seem like the auto-login attempt isn't happening. Any chance you're running LFDS/LFDSSTS as AD service accounts instead of their default Network Service identity? Or changed the service/app pool identities in either direction during the upgrade? If you're using custom identities and tinker with the useAppPoolCredentials setting it's possible to screw things up:

No change to the URL. I have internal programs that use the URL to launch documents, and that is when everyone started noticing the issue. 

Local internet is configured by group policies, so those are set and have not changed. I checked with my network admin and he ensured that my LF servers are in the zones. 

Yes, I'm running an AD service account for almost everything in my environment. I have changed it between that and Network Service identity multiple times and nothing changes. 

In your screenshot of the IIS configuration Editor, are you saying that it should be False for useAppPoolCredentials? Mine is set to False. 

Something else I want to make sure is known is that on the server hosting LFDS and Web client, I get signed in automatically just fine.