Wednesday, January 20, 2010

Implementing Intuit Statement Writer on a Secure Network

The Intuit Statement Writer is a custom reporting and financial statement tool for use with QuickBooks Premier Accountant and Microsoft Excel. The solution has a few peculiarities that must be addressed in order to make it function properly (or at all!) in a networked or hosted environment.

The issues center primarily around the fact that the application was designed for use on a standalone PC, and doesn’t take into consideration the potential for redirected or restricted data folders. Further, the method of integration with Microsoft Excel requires specific support from the Excel application, so care must be taken in selecting the version of Excel (or Microsoft Office) to be used.

In computing environments where the QuickBooks and Office applications are installed directly on each PC, and where data is stored locally on the PC, most of these issues become irrelevant. When the applications are utilized within a strictly controlled domain, however, a variety of issues may arise. If the applications are to be utilized in a terminal server environment, then many issues will certainly come into play.

The Intuit Statement Writer solution requires QuickBooks Premier Accountant v2010, and Microsoft Office 2003 or greater. The version of Office or Excel used must be at least version 2003, and it must be either the full standalone version of Excel, or Excel as part of MS Office Standard, Professional, or Enterprise. Excel as part of MS Office Small Business, Basic, or Student/Teacher editions is not compatible. All editions of Excel 2007 are compatible.

By default, the Intuit Statement Writer (ISW) stores its files on the local PC where the application is installed. The application utilizes the local “My Documents” folder as the location for ISW files. In an environment where the My Documents folder is redirected to a network folder or share, the program fails to install or run properly. The specific error messages encountered may vary, but are essentially indicating the same issue: you are attempting to use an unsupported file folder location.

Intuit Statement Writer (ISW) requires full trusts and permissions to the My Documents folder, which is automatically granted when the folder is local to the PC. When My Documents folder is pointed to a shared network drive, the trusts and permissions are no longer granted and the error message will appear. According to Intuit, “Intuit Statement Writer files and appearance files (.gsm and .gss) can be stored on a server or network drive, but it is not possible to open and work with the files while they are located on the server without modifying security policies on the machine. Because we don't recommend this, the files must be local when working with them." It is necessary to copy the ISW file you wish to work with to your local drive, and, when finished working with the file, copy it back to the server.

In addition to having difficulties using server or network drives, ISW also will not function as a multi-user application, due to the architecture and reliance upon the MyDocuments folder. While ISW may be used without issue while QuickBooks is in multi-user mode, only one user at any time is able to work with the Intuit Statement Writer files.

Relating to the policy and permissions issue, there is a Microsoft Support article which describes a potential resolution ( How to: Grant Permissions to Documents and Workbooks in Shared Locations (2003 System)) This article addresses this issue and provides information on modifying security policies around the Office Document Membership Condition on the computer(s) where ISW will run.

Two methods are provided: using Visual Studio command line tools, or using the Microsoft .NET Framework configuration tool.

In an effort to simplify making these changes on your systems, Intuit has provided a batch file which can be run on the system where ISW is installed, and where the My Documents folder is redirected for the user.

Obtain the batch file here:

This batch file (actually 2 batch files) grant full trust to the ISW dll files, checks to see if and where the My Documents folder is redirected, and attempts to grant full trust to the specific network location of the My Documents folder through the Microsoft .NET Framework 2.0 assemblies. Care must be taken any time .NET security policies or configurations are adjusted, especially when working within a secure domain. The .NET Framework Configuration tool (Mscorcfg.msc) enables users and administrators to modify security policies for the machine policy level, the user policy level, and the enterprise policy level.

From Microsoft: "Prior to the .NET Framework, most Windows applications had free access to all of the local computer resources, including the registry, file system, event logs, environment variables or available printers. Due to the limitations of role-based security, administrators were conditioned to accept that nothing was off limits to a running application as long as the user (or the user context under which the application is running) was authorized to use the resource.With the proliferation of distributed component-centric systems, it's not uncommon for applications to download and execute components from Internet/intranet sites or network shares. The possible negative consequences of such applications are obvious. Malicious code, whether by design or not, could be loaded from an external entity and wreak havoc on a local computer or the network on which it resides. There is also the threat of security breaches that could jeopardize the privacy of sensitive data."

Because the Intuit Statement Writer utilizes features of Microsoft Excel, it relies heavily on the behavior of the Office applications and document permissions on the computer and network. These permissions are often controlled by establishing security profiles or policies via the .NET framework. If the location of a Microsoft Office 2003 document is not secure (for example, a SharePoint site or file share that users—possibly including malicious users—can write to), or if you are not sure who has permission to upload content, you can grant permissions only to documents and workbooks in the location, rather than to all content. You do this by using the Office Document Membership Condition, and modifying the security policy to check for this condition on the computers on which your solution will run.

When you use the Office Document Membership Condition, only Office documents are trusted; assemblies and executables are not granted permissions to be run from the share.This permission or trust is often assigned to a “code group”. Code groups can provide information on how the system determines the allowed permissions. The allowed permission set for the policy level is the permission set associated with the code group that has this attribute.

When all policy levels are considered, the runtime never grants the code more permissions than those associated with the Exclusive code group. Within a given policy level, code can be a member of no more than one code group that has the Exclusive attribute. This may be problematic for some administrators who wish to implement the Intuit “fix”, which creates a policy group and then establishes that group with the Exclusive attribute. Network administrators with pre-existing security policies may well find that the Intuit fix will not work as delivered, due to the fact that Exclusive policy groups may already exist to govern the permissions of Office or other documents.

Intuit KB Article:

1. After the zip file is downloaded, you will need to extract it to the desktop...

2. After the file as been unzipped, open up the ISWFix1 folder and double-click on the ISWFix1.bat file.

3. These steps will need to be performed for each computer or user account that needs access to ISW.

4. Terminal Services/Citrix: Ensure the ISWprefs.ini file is set to not delete itself when the user logs out.

Microsoft .NET Framework configuration tool