@Olga I am actually working on testing a change from net.tcp to https on my test server. I tried to just change the binding from UsernameWindowsChannel to HttpsBinaryUsernameChannel and that did not work, so I am going to make a new appserver.
@Olga I found a KB that recommended unjoining and rejoining the appserver from the domain and I did that tonight and the errors are quiet now. hopefully that will hold tomorrow.
@Mark_Wonsil I did make an https appserver and it also has not died on the test pc, but has only been there for a few hours.
Hoping for a better day tomorrow.
After unjoined and rejoined the app server to the domain last night and we did not go offline untill 1 PM, so better. Also the https appserver did not go offline
when the net.tcp appserver did at 1PM.
It looks like the Transport authentication failed messages are red herrings or garbage collection happening at 10 minutes.
I am going to install the https config for a few of the users and see if that will work long term. it is only a few, so I can go thru the extra steps of installing the cert on their pcs.
Just to close the loop on this. The https client does not have the disconnect issues that net.tcp does when going thru a vpn appliance and after adding an https appserver for clients and an second https appserver for tasks and printing this building is now stable.