05-08-2013 01:42 PM
So we discovered the hard way, a couple of weeks ago, that you can't enable synchronisation if you have 25 concurrent users on your DB. (Well, maybe you could, but it'd require rewriting most of the triggers and stored procedures in your DB to take table locking into account. I learnt far more about the SQL internals of Act than I ever wanted to last week! On the upside, one little change to a config variable stored in the DB, and all those deadlocks when we have more than two people trying to login at a time have gone away! ).
Yesterday, somehow (I assume user error? But noone is owning up to purposefully opening the sychronisation control panel, and clicking Enable..), synchronisation became enabled on our main ACT Database again, and we had to pull the network cable on the server to be able to disable it (the background noise from 25 staff with Act.Outlook.Service running doing its heartbeat queries was too much load to be able to run the disable function!).
So now I'm wondering if there's a way to ensure that synchronisation can't be turned on for this particular database? Or if there's an SQL query I can shove into OpManager to alert us if it's been re-enabled? (Or a log file to watch?)
05-09-2013 12:11 AM
Not that I'm aware of.
Is this database to database sync or Sync with Outlook (Calendar/Contacts)?
If it's database to database (App/Network/Internet) then you could use the firewall to block traffic on port 65100 which is the default port Network Sync works on. Won't help if they change the default port tho.
If it's Sync with Outlook, I'd run a scheduled task to kill the process.
If it's Act.Outlook.Services.exe (required for attaching emails to Contact Histories) then do the same, use a scheduled task to kill the process.
It's a brute force approach, but occasionally it's the quicker path to resolution.
I'd recommend PsKill from Microsoft: http://technet.microsoft.com/en-au/sysinternals/bb896683
05-09-2013 02:36 AM
05-09-2013 04:46 PM
05-09-2013 04:57 PM