Administrators are able to logon to the RWW console without issue. However when a user account attempts to logon, they are able to enter their credentials, then it takes up to 15 minutes for the logon to successfully complete. The user is eventually able to logon, it just takes a long time to do so.
For additional information concerning RWW, please refer to the “Official SBS Blog” and query on Remote Web Workplace for additional information.
The problem was with the additional servers he had in his domain… what…. what would that have to do with anything? The Knowledge Worker Webpage (the page that is brought up once a User account is authenticated) give us the ability to enable or disable various links that are shown on the page through the registry.
I noticed that if I disabled the appTS registry key, then the user was able to logon almost immediately, but the option to connect to an Application Terminal Server link was not available. So do the users in this network need access to an Application Terminal Server? Absolutely….. just disabling the key was not an option on the network. So whats the hold up with the user logons only?
As we looked at the servers listed in the server list given under the RWW Administrator account, I noticed we had 24 servers showing. Twenty-four servers in an SBS environment…. thats a lot of servers! Come to find out the majority of them were no longer on the network. The servers had been created for various projects, but were never removed from the domain. I also discovered in DNS that we had a lot of boxes with the same IP…..interesting.
We removed the “dead” servers from the network and cleaned up DNS and rebooted the server. Tested the the connection with a user account and it immediately logged on.
In order for the Application Terminal Server link to work in RWW, the logon process attempts to contact each server in the domain in an attempt to verify if that server is an Application Terminal Server or not. In this case, since there were so many servers that were not available or had invalid IP’s, the process had to go through it’s timeout sequence before it could move on to the next server check. More “dead” servers and bad IP’s = more timeouts. More timeouts = longer logon times.
So why did the administrator account not experience this issue? Simple… it handles server resolution differently.
Thanks for reading,