Configuring L2TP VPN on Zyxel USG 60 for Chromebook / ChomeOS compatibility

For a couple of years I have had no problem connecting to my office VPN from my Chromebooks. Prior to departing for a long trip I decided to just double-check that all was well. Unfortunately, it wasn't. I could no longer connect to the VPN from either of my Chromebooks, even though I still connected successfully from Windows and from Android. I assumed that Google changed something, but as it turns out, it was probably a change that I made in the USG that caused the problem.

After months of frustration, I came upon an blog post that detailed the ipsec VPN configuration settings on a Fortigate router needed to work with the Chromebook's built-in VPN capability.

https://dbssolutions.freshdesk.com/support/solutions/articles/196790-how-to-configure-a-fortigate-ipsec-vpn-for-google?_utm_source=1-2-2

L2TP depends upon underlying ipsec protocols so I compared mine on the USG to those documented in the post above.

Looking at the IPSEC Phase 2 configuration, I saw that the policies did not match those I was using. Once I changed them to match those in the article, the Chromebook connected no problem. The results suggest that the Chromebook doesn't like SHA authentication. A while back I had changed a Zyxel default policy that specified MD5 authentication to SHA. Once I re-created a policy that uses MD5 authentication instead, the VPN link was established successfully and quickly. Here are my new working settings:

Cannot start Tigerpaw tsiTimers service after moving database to new server

We are using the Tigerpaw CRM software (v 12.1.08). After moving the Tigerpaw database to a new server, I was unable to restart the required tsiTimers service. Checking the Windows Event Logs, I found that the problem was that the service was immediately terminating because it detected evidence that a copy of the service was running on another computer:

Error starting service tsiTimers
Error in routine: StartService
This service is running on another machine

It turns out that unless the service is stopped and the database is shut down before migrating it to a different server, values referencing the name of the original server remain in the database, so when the new instance of the service starts it believes the old server is still running.

More specifically, the database contains a table named tblSysServiceStatus. In my case that table contained just two rows, both of which contained the old server name in the column "MachineName". The old server name was FUJIV1; the new server name is WHITE. A quick SQL statement put things to right:

UPDATE  tblSysServiceStatus
SET MachineName = 'WHITE'  WHERE  MachineName = 'FUJIV1';

Once I committed the above change, I was able to restart the tsiTimers service successfully.