02-04-2013 10:48 AM
I have a client, that I just upgraded from 2012 Premium to 2013 Premium, 18 users in the office and 6 users using Terminal Server. Since the upgrade, more and more users are getting the above error randomly through the day, from ACT! and from Outlook (probably because of the Address Book integration). Everyone opens ACT! in the morning and leaves it open all day, but many users experience the error up to 5x a day. Nobody gets the error when opening ACT! - just randomly throughout the day. ACT! & SQL are installed on one server, while just the ACT! client (no SQL) is installed and published on the Terminal Server. This is not the only account where I'm seeing this, but it's certainly the most severe occurance. As I always do, no SQL was installed on ACT! clients on the LAN in the office.
To me, this sounds like a network contention issue, or network dropouts, lost packets, something, perhaps DNS and name resolution issues through the day. Firewall? Not so likely.
Notice that everyone logs in, so don't ask me if SQL is running, or if the correct protocols are set or any of the myriad issues that one would examine if no one could open ACT!, ever.
This client was just acquired by a bigger fish who is, in turn, owned by an even bigger fish, both of whom use SFDC, and my client is resisting the migration, and an unstable installation won't help their/our cause.
02-04-2013 11:29 AM
Perhaps you could start with excluding the possibility of the SQL browser service failure to establish a connection through dynamic ports. You could specify a static port for the SQL instance. If for whatever reason, a connection is lost then SQL browser and dynamic allocation is one factor eliminated. (Effectively taking SQL DNS out of the equation).
BTW: Did the upgrade coincide with server OS upgrade, or substantial changes to the domain and hence Active Directory?
02-04-2013 12:15 PM