Koozali.org: home of the SME Server
Legacy Forums => General Discussion (Legacy) => Topic started by: Jeff Fentum on April 11, 2003, 07:47:03 PM
-
I am currently using a box running v5.6u (server only mode-behind the firewall!) at my company to centralize all of the Quickbook Pro files. The 'local' network users have had no problems accessing and using these files, but when we started connecting a user at a remote office via a secure IPSEC VPN-freeswan connection (via 2 separate boxes running v5.6u in server/gateway mode--1 at each location, of course), that's when the problems started.
First of all, when the remote office user ends his session in Quickbooks Pro (the latest version), the .qbw file becomes inaccessible to all of the local users. So far, the only quick solution that has worked to un-lock the files is to reboot the server hosting the files. Not the best option. Is the drive mapped at the remote location? Yes. Is the user logging in to the session as "multi-user"? Yes. What gives!?
Also, the connection at the remote office is extremely sloooow. I've tried to explain to management that this is because an internet vpn connection is not going to have near the throughput of data that a 10/100 connection will. I've demonstrated this with ping stats, 84ms from the remote connection, .06ms from the local. How can I improve this without getting a hyper-expensive connection setup? The local office has a static 768k T1 and the remote location has an ASDSL connection w/static IP(512k-I think).
In any case, I've been handed the thankless job of "fixing" these problems. Any help/guidance/clues?
-
I think I discovered the answers/explanations to these problems.
There's no quick fix for the slowness of the VPN connection with the remote office, aside from shelling out a bunch of cash for souped-up connections. It's really a matter of over extending the capabilities of the program that's being used, Quickbooks Pro, in this case. The remote office user does not exactly need to have up-to-the-minute information, just daily updates, so I think I'll set up an automated rsync operation to duplicate the data to the remote office.
Now for the problem with the file being locked. When a Quickbooks user is running a session, the program creates a file with a ".qbi" extension on it. Remote users accessing the database will have a file of their session created, which is SUPPOSED to be deleted when the remote user closes their session. Due to a glitch in the program itself, this file is not being deleted, and will prevent other users from accessing the db. The fix is to delete telltale ".qbi" file after the remote user closes their session.
Please note: I have not tried this tip myself--yet. I'm simply regurgitating what the Intuit tech support person advised.
-
We have an e-smith client running QB in both local & remote multi-user mode as you describe.
Performance was poor, but it wasnt due to e-smith and its VPN connection but for the fact that QB insists on opening the db file and sending a significant chunk of the accounts down the pipe to the user PC at application startup. On a 110MB QB file it is bad enough (5-10 sec delay) on an 100MB LAN, over a DSL connection it is unreal. I've seen the same thing with another client running a couple giant Maximizer databases over a DSL speed connection - ugly at the start.
Anyway, to help improve the VPN performance we did thin out the QB data with a purge of the data and creating an archive version for other users interested in old data. But it is still a bit of a dog at startup loading the customer & vendor lists alone.
I also was concerned of dropped connections (on the brainless user's part) comprimising the QB db so our solution was to still connect over VPN but in remote control mode (rather than remote access) to a pcAnywhere PC running QB. Performance is much much faster and more consistant with only the screen images being sent back & forth. For the pcAnywhere host we picked up an elcheapo used box and stuck it headless in the closet - viola.
To provision the main accounting user with fast, unlimited access from home office, we have done similar to what you describe, created an overnight QB copy in a seperate area for her to download to her home laptop. She underatands this is purely for inquiry/reporting and is stale as of the previous day.
Yes, I have removed that QBI file at times and have seen no negative effects, but I may have just been lucky!
-
Interesting,
What you folks are describing is exactly a situation I am just working through.
The vendor of the software does believe in and use and support Linux as well, so that was a plus.
His description/solution to the problem was this:
All you want to do is transfer the "Keystrokes" not the data. In order to do that , his recommendation was/is PC Anywhere, or MS Terminal Server.
In our case we put in a Win2K Server behind the Mitel W/ Terminal Server on it.
We have not hooked up the remote location yet, but this vendor assures me that in the 19 years they have been in business, connecting two or more locations as desctribed to do Client Server, is best with Terminal Server, next is PC Anywhere.
Dan
-
I have used terminal server quite a lot via vpns (sme -pptp generally) and its rock solid stable and almost as quick as "being there" plus you can't corrupt your data files when the link goes down. As an alternative - if there is a spare machine sitting idle at the head office - xp pro remote desktop works great as does net meeting remote desktop - all are light years ahead of poor old vnc.
in my limited experience I would have thought opening a database file directly over a remote link was asking for corruption.
cheers
Mark
-
Thin Soft (www.thinsoftinc.com) makes an addon to XP that allows up to 21 terminal server connection. You can put a XP behind e-smith and portforward the TS port (3389) to the IP of the XP station and run QB from anywhere. The price of thin soft is $295 for 3 connections.
We have this setup in our office with Citrix but it is more expensive