Tuesday, March 17, 2009

QuickBooks Pro 2008 on Terminal Server 2008

Microsoft's Terminal Server 2008 (on Server 2008) has come a long way from its previous iteration (Server 2003). One of the many attractive features is application virtualization deployed through Terminal Services.

One group has about a half dozen remote and local users of Terminal Services who need to access QuickBooks. Now Intuit does offer their 'Enterprise' version of QB which is supported under Terminal Services but the catch is the cost (about triple of Pro for the same number of users) and the fact that it creates new data files that are not backwards compatible.

The QB installation goes fairly smoothly of putting QB Pro 2008 on the server but there are a couple of items that caused huge problems in reconciliation, printing to PDF, and e-mail reports; all of which make a call to the bundled Amyuni Document Converter that is built-in to the QB installation.

This client's environment is Server 2008 Enterprise 64 bit Terminal Server and there are several blogs and community posts about working with Vista 64 bit and having to change out the print driver to the new one, as well as deleting and re-installing the PDF Converter and often times Intuit's suggestion to fix many things is to uninstall and reinstall the program.

The best general solutions site that I found was at CCRSoftware. I followed the instructions to a tee but things hung up when trying to create a new printer port. What I found that worked was to login as the local admin on the terminal server (NOT as a domain admin, interestingly enough) and then I could create the port. Prior to that I wasn't able to create the port (invalid name was my error message from Windows).

After creating the port and installing the latest Amyuni driver (the link to download is also on the same document), the local administrator could generate PDFs. The catch was that the default Windows printer had to be one configured as a local printer in the Terminal Server. I then added the most popular local printers for the remote users, disabled the GPO and RDP client properties to set the local default printer to the TS default printer. This way the user can set one of the other printers as the default and it won't switch back.

I then logged into the TS as a normal user from AD, set the default printer to be one of the TS's local printers, and voila, I could reconcile, send reports in e-mail as PDFs, and save as PDFs!

Like I mentioned, nearly all of the information that I had found previously had to do with making it work on Vista 64 bit, of which Server 2008's core is based upon so I knew I was close but QB uses the PDF converter to perform many functions so for those to work correctly, it has to be dialed in just right.

No comments: