Mobile Application Development, Social Business Consulting, IBM Lotus Notes Consulting, IBM Lotus Domino Consulting, IBM Lotus Connections Consulting, IBM Sametime Consulting, XPages Development - Los Angeles, Orange County, Southern California and Beyond

The Trials and Tribulations of taking Quickbooks to the Cloud (Part I)


Recently our organization made a concerted effort to move all of our main server applications to the Cloud.  We wanted to significantly reduce the amount of time we spent internally managing and maintaining our servers so we could dedicate our time more to our core business.  One of the servers we moved to the Cloud was our #Quickbooks Accounting server.  Internally this was a virtual machine running Windows 2003 accessible via remote desktop client (RDP) from inside the firewall or from the outside via VPN. 
biz_woman_showing_cloud_10316757_m
We considered a couple of options before moving Quickbooks to the Cloud:

1. Have our Quickbooks hosted by a third party hosting company with automatic backups

2. Host Quickbooks ourselves using a Dedicated or Virtual Private Server from an Internet Hosting company

Hosting Option 1 was initially the more attractive choice since we could offload the whole process to a third party by simply uploading our Quickbooks data file and other important related files after an account was created for us.  Furthermore, Option 1 meant that we would not have to deal with backups since the hosting company automatically handled that for us on a daily basis.  Going with Hosting Option 2 meant that we would have to install Quickbooks ourselves, setup the various user accounts to access via RDP and create our own remote backup process.  From a monthly cost perspective Hosting Option 2 was a little less expensive since Quickbooks hosting companies usually charge a per user/per month charge whereas the VPS would be a fixed monthly cost for as many users as you could have supported by the Quickbooks application (in our case a total of 3).

Since our goal was to reduce our time managing servers and applications, we decided on Hosting Option 1 and signed up with a third party QB hosting company.  The sign up process was fairly painless.  We filled out a form, gave the company our QB licensing information, users’ names, and away we went.  By the following day we could upload our Quickbooks data and start accessing our accounting system.  To print we had to install a special universal print driver that worked with RDP, which was also fairly painless to setup. 

The first few days with the hosted QB solution, everything was going quite well until we were no longer able to access our Quickbooks, all of a sudden.  We contacted customer support and within a couple of hours we were back up and running.  This happened more than 3 times over a 3 week period.  At one point they moved our account to a different hosted server to solve our access problem.  In addition, accessing Quickbooks would slow down dramatically during the day as, we assumed, other users were accessing their hosted solutions at the same time.  After our final customer support request was solved, we could only start our Quickbooks session in Single-User Mode and then had to switch to Multi-User Mode manually after each logon.  It would never stay in Multi-User Mode after logging off of the application.  Although this was a minor inconvenience, it still meant having to contact the person currently logged in to ask him or her to switch to Multi-User Mode when other users wanted to access QB.

The customer support of the hosting company was very responsive and they would always end up solving our problems.  However, one of the reasons for moving to the Cloud was to not have to deal with these kinds of problems anymore.  We wanted access to our accounting system without hiccups if at all possible.  Although there is never a perfect solution, when we had QB hosted internally we had very few issues related to accessing our system, so it was frustrating to suddenly experience so many problems within the first 30 days.

Within a week or so of going with a third party hosting company and experiencing access problems, we started to be concerned with how reliable the backups were of our data.  Also, what would happen if the company suddenly went belly up and we could no longer get access to our Quickbooks?  Even worse, what if we could no longer get access to our data and months of accounting transactions were literally gone?  I’m sure, as we all ponder the advantages and disadvantages of having our data and applications in the Cloud, reliability of the Cloud providers will always be a major concern.  We are now putting our trust in a third party to serve up, backup and maintain something as important as our accounting system.

To help alleviate our concerns of no longer controlling our data, we looked into ways to regularly backup our QB data ourselves as a fail safe in case the unthinkable were to happen.  Here are the options we considered:

A. Manually run a backup of Quickbooks to our local drive from the Cloud when alerted to do so after so many times logging off of Quickbooks

B. Use the Intuit Data Protect (IDP) process to have our data automatically backed up directly to Intuit for a small monthly fee

C. Install a third party automatic backup solution 

D. Backup the data to a remote FTP server from the Hosted solution


Backup Option A was the simplest and cheapest of all.  There’s no cost to  having Quickbooks backup your data to a local drive from an RDP session.  After you use Quickbooks a few times, you can configure it to remind you to do a backup.  This was also our secondary backup scenario when we hosted the application internally.  Of course, when you backup from an internal server to a local drive on an internal PC, the backup is very quick.  However, from the remote hosting company to our local PC, the backup almost took 30 minutes to complete.   That meant that every time we wanted to backup QB after closing the application, we’d have to budget around 30 minutes to run the backup before we could disconnect from our session.  This made the backup too inconvenient where we’d probably never choose to run it defeating the whole purpose of the backup process in the first place.

So we turned to Backup Option B which appeared to be simpler than Option D and didn’t require us to install third party software as in Backup Option C.  We activated IDP for the 30 day trial with Intuit and setup the backup to run daily of our Quickbooks file.  It was great to know that the backup would run even the Quickbooks file was open at time.  In practice this turned out to be more complicated than anticipated.  Since our user accounts on the hosted solution were locked down so tight, it took a little legwork and intervention from customer support to get IDP activated and working in the first place.  When we finally had it working, within a couple of days, IDP could no longer contact the remote Intuit backup server.  We assumed that the hosting company blocked access to the Internet port required by IDP to run properly making it an unworkable solution for us. 

We also soon realized that both Backup Option A and B only backed up our QB data file.  No other files were being backed up.  That includes logo, attachment, and other important files that you may have added to Quickbooks for your invoices and other records.  This meant that a full restore, although still getting us our most important accounting data, we’d have to somehow replace all of the other files manually to get our setup to work the way it did before a restore was necessary.

Since Backup Option A and B were no longer viable, we tried Backup Option C.  However, this was an immediately found out to not be possible at all.  The Hosting company had blocked the installation of third party software including backup software solutions, so we had to cross Backup Option C off of the list.

We were left with Backup Option D.  We researched, developed and created an automated backup solution using a third party zip archiving utility, a Windows FTP utility and a Windows batch (.bat) file.  We were even able to automatically append the current date and time to the file name of each backup to perform a simple type of versioning.  Surprisingly the Hosting company did not block the installation of these third party utilities.  I can only assume this was because they were simple utilities.

With the automated backup finally working and after many problems accessing our third party hosted solution, we realized that maybe we should cut our losses and just go with Hosting Option 2: Host Quickbooks ourselves using a Dedicated or Virtual Private Server from an Internet Hosting company.  So we investigated various Internet Hosting company solutions and finally found one that met our budget and hosting criteria, installed Quickbooks, uploaded all of our data and setup our RDP accounts.  Within a few hours we were up and running.  We also installed the necessary software to get the backups working too. 

Our main accounting person was delighted.  The VPS was many times faster to use, printing was very simple with the built-in TS printer ports, and the one-click backup after closing QB, took less than a minute to backup the entire QB folder with an appended current date and time to the filename for versioning.

As you or your company move to the Cloud, I hope that this recounting of our Quickbooks hosting experience will help you in choosing the right path for your needs.  With so many SMBs still using Quickbooks to handle their day-to-day crucial accounting tasks, having a secure, reliable and recoverable Quickbooks environment is an essential part of Cloud Computing.  I’d also like to reiterate how important it is for your company to maintain control of its accounting data if the unthinkable happens.  #CloudComputing is the future, but there’s no reason why you have to give up full control of your applications and data.  At least in this case, you “can have your cake and eat it to”.

Lastly, I’d like to point out why using Backup Option D was also the best and most comprehensive backup to go with anyway.  Backup Options A and B, only backup the Quickbooks data file.  They don’t backup any other additional files or Quickbooks attachments that you may have outside of the QB data file.  If you restore only from the data file you will have your crucial accounting data, but nothing else.  Backing up the entire Quickbooks folder gives you true disaster recovery with a way to get right back to your accounting after a restore.  Everything is restored exactly as it was with the last backup.

A word of caution about signing up for the Intuit Data Protect 30 day trial.  Be aware that once you sign up you cannot cancel the trial online using your Intuit account.  You have to hunt down the right Customer Support number and then spend quite a bit of time with them to cancel your account over the phone.  We did all that before the trial was up and still got charged after the 30 day trial was over and after our account was canceled.  I had to contact them again to get the charges reversed on our credit card.  It was very time consuming indeed.  So I would highly recommend to think very carefully before signing up.  If they set up a way for you to cancel online, since you are able to sign up online, then it would probably make the whole IDP experience a lot easier to deal with.

Please note:  The full details of how we ultimately got the automated backup process to work will be detailed in a separate post coming soon.  For this posting, I wanted to focus on our challenges hosting #Quickbooks in the Cloud.  So watch out for that upcoming blog posting.

IBM Connections – Setting the Community File Library to a 5 Gb or Unlimited Quota

To increase an IBM Connections Community File Library max size to 5GB, perform the following steps in the wsadmin command prompt on your DM or AppSrv profiles:

//execute the filesAdmin script
execfile("filesAdmin.py")

// Get a list of libraries with detailed information
FilesLibraryService.browseCommunity("title", "true", 1, 20)
//Find your target library id
// Check if the library is indeed your target library. More info is displayed as well
FilesLibraryService.getById("f603f0a1-a463-46b7-b32b-1091cd4da1a0")
// Create a new policy
FilesPolicyService.add(title="5 GB Policy" maximumSize=5368709120)
// Get the Policy ID by performing the following command
FilesPolicyService.browse("title", "true", 1, 25)
// Apply policy to the target community using the format: ("Community ID","Policy ID")
FilesLibraryService.assignPolicy("f603f0a1-a463-46b7-b32b-1091cd4da1a0", "f3f7b5e8-1972-4f7a-b39f-ba83a2a3bf74")


To set an IBM Connections Community File Library to an unlimited quote by doing the following:

// Set unlimited for default community library size
FilesPolicyService.edit("00000000-0000-0000-0000-000000000001", "!Default for Community Files", 0)

// Set unlimited for personal library size
FilesPolicyService.edit("00000000-0000-0000-0000-000000000000", "!Default for Personal Files", 0)


There should be no need to restart Connections. Please check your libraries and you should see the max size increased to 5GB or unlimited.

IBM Sametime Chat Notification pauses Windows Media Player

While playing music in the Windows Media Player running on Windows 7 64-bit playback would suddenly pause whenever I got a chat notification from IBM Sametime. Each and every  time I had to push play to get the music going again.  Very annoying!

The problem turned out to be with a setting in Windows Control Panel that controls the behavior of the media player.  To fix the problem follow the steps below:

a) Click on Start
b) Click on Control Panel.
c) In control panel select the option” Hardware and Sound”

d) Now select the option “Sound”e) A new windows will appear, now click on the last tab “Communications”

f) Change the radio button to “Do Nothing”

This will most likely affect the playback behavior for other applications such as Skype so you may be better off just downloading and using a different media player altogether and keeping the default setting as is.

 

Pages