CCH® ProSystem fx® Engagement Deployment Planning Guide

CCH

ProSystem

Engagement

Deployment Planning Guide

2022

reproduced or transmitted, in any form or by any means, without prior written permission. Requests for that permission

should be directed to:

CCH Incorporated

20101 Hamilton Ave., Suite 200

Torrance, CA 90502

The contents of this publication are believed to be accurate. However, responsibility cannot be assumed for the

information contained herein, and the consequences resulting from the use thereof. Material in this publication is subject

to change without notice.

This User Manual and the computer software it describes are designed to provide accurate and authoritative information

in regard to the subject matter covered. They are distributed with the understanding that the publisher is not engaged in

rendering accounting, legal, or other professional service. If legal advice or other expert assistance is required, the

services of a competent professional should besought.

“CCH ProSystem

” is a registered trademark of CCH Incorporated.

“Windows” is a registered trademark of Microsoft Corporation.

All other brand, product, or company names are trademarks or registered trademarks of their respective owners.

Contents • i

Chapter 1: Deployment Planning – Configuration 1

Introduction 1

Scenario 1: Multi-Site Firm, WM Workstations, Distributed Office Servers 3

Scenario 2: Multi-Site Firm, WM Workstations, Centralized Office Servers 4

Scenario 3: Multi-Site Firm, WM via Terminal Services, Centralized Office

Servers

Scenario 4: Multi-Site Firm, Terminal Services, and Local PCs 6

Scenario 5: Single-Site Firm, WM Workstations 7

Scenario 6: Single-Site Firm, WM via Terminal Services 8

Scenario 7: Single-Site Firm, Terminal Services, and Local PCs 9

Other Scenarios 9

Summary of Deployment Scenario Recommendations 10

Chapter 2: Deployment Planning – Servers 11

Overview 11

Database Server Overview 11

High Availability and SQL Clustering 11

Microsoft® SQL Express® vs. Microsoft® SQL Server® Standard or

Enterprise

Microsoft® SQL Server® (x86) with Address Windowing Extensions (AWE)

vs. Microsoft® SQL Server®(x64)

File Servers Overview 12

Using a SAN 12

SQL 12

Physical Files 13

Microsoft® Windows Server® 13

Hardware Considerations 13

Firm IT Staff Roles and Responsibilities 13

Virtualization 14

Upgrading CCH ProSystem fx Engagement 14

CCH ProSystem fx Engagement OfficeServer Recommendations 15

Terminal Servers 16

CCH ProSystem fx Engagement Terminal Services Client Overview 16

Terminal Services Client Recommendations 16

Terminal Services Database Overview 17

Terminal Services Database Recommendations 18

Contents

Contents • ii

Summary 19

Chapter 3: Deployment Planning – Workstations 20

Microsoft® Windows® 20

Microsoft® Office 20

Microsoft® SQL Server® 21

Hardware Considerations 21

Installation 21

Active Directory® Push 22

Security 22

Use of File Server – Network Template Storage 22

CCH ProSystem fx Engagement Workpaper Management

Recommendations

Chapter 4: Deployment Planning - SQL Server Agent 24

Overview 24

Start Up Account 24

Pre-Installation Steps 24

Post-Installation Steps 25

Chapter 5: Ongoing Monitoring andUpgrade Considerations 26

Monitoring the Servers 26

Database Backup and Health Check 26

Bin Maintenance 27

Disk Space Usage 27

Disk Fragmentation 27

Chapter 6: Working with CCH ProSystem fx Engagement in the Field 28

Overview 28

Connection Types 29

Name Resolution 29

Engagement Services and Ports 32

Firewalls 33

CCH ProSystem fx Engagement Configuration Utility 35

Appendix A: Database Administration 37

Database Backup and Health Check 37

Contents

Contents • iii

Database Maintenance Plan 38

Overview 38

Agent XPs 38

Database Maintenance Plan 38

CCH ProSystem fx Engagement Administrator Migration 40

Migrating the Office Server 40

SQL Server® Jobs 42

Database Statistics 42

Index Fragmentation 42

Transaction Log File Growth 43

Hardware Performance 43

Hardware Performance Indicators 43

CPU 43

Memory 44

Disk I/O 45

Tools Available for HardwarePerformance Monitoring 45

Performance Monitor 45

Performance Dashboard Reports for SQL Server® 45

Troubleshooting Performance Issues 46

SQL Server® (x64) vs. SQL Server® (x86) withAWE Enabled 46

SQL Server® Editions 46

SQL Server® Express Edition 47

SQL Server® Standard Edition vs. Enterprise Edition 47

Appendix B: Upgrading CCH ProSystem fx Engagement 48

Before the Installation 48

Upgrading the Office Servers 48

Upgrading Workstations Using Active Directory® 49

Manually Installing the Workstations 49

Appendix C: Installing CCH ProSystem fx Engagement on a SQL Cluster 50

Before Beginning the Installation 50

Installing the Administrator Module 50

Installing the Terminal Services Database Module 51

Contents

Contents • iv

Installing the Administrator and Terminal Services Database Module

Together

Performing a Repair of CCH ProSystem fx Engagement on a SQL Cluster 54

Performing a Modify of CCH ProSystem fx Engagement on a SQL Cluster 54

Uninstalling CCH ProSystem fx Engagement on a SQL Cluster 54

Appendix D: Additional Resources 55

Contents

Chapter 1: Deployment Planning – Configuration • 1

DEPLOYMENT PLANNING – CONFIGURATION

Introduction

The purpose of this document is to identify the key factors that influence the performance, reliability,

and functionality of the CCH ProSystem

Engagement application. These deployment guidelines

can help ensure the highest possible level of reliability, sustainability, performance, predictability, and

end-user usability.

The target audiences for Engagement deployment are the firm administrators and managers who

make business decisions and evaluate technology and network infrastructure.

Firms that are new to Engagement, as well as firms which are upgrading an existing installation, must

plan their deployment strategy well in advance of installation day.

Key decisions during planning may require answers to some of the following questions:

What is the hardware capacity that is needed to support the anticipated peak usage? Is there a

need for additional hardware?

Does your firm prefer data in a central location or data distributed across multiple offices?

Is there already an infrastructure established between multiple offices, such as a WAN

connection? Is there a need for such an infrastructure?

Does your firm prefer that users access Engagement through a Terminal Services Application

Server? If so, is there already an Application Server in place?

Does your firm prefer to use Citrix

with Terminal Services?

How centralized would your firm prefer to manage workstation software installation and

administration?

Is SQL Server

Express adequate? If not, does your firm already have SQL Server

Standard or

Enterprise licenses? If so, does your firm require additional licenses?

Should your firm set up a Virtual Private Network?

What roles and skill sets are necessary to deploy, support, and maintain Engagement?

This planning guide provides general guidance to new and existing customers in answering these

questions and manymore.

Chapter 1

Chapter 1: Deployment Planning – Configuration • 2

Chapter 1 describes seven common deployment scenarios for CCH ProSystem

Engagement

Workpaper Management (WM) and the associated Office Servers:

Scenario 1. Multi-Site Firm, WM Workstations, Distributed Office Servers

Scenario 2. Multi-Site Firm, WM Workstations, Centralized Office Servers

Scenario 3. Multi-Site Firm, WM via Terminal Services, Centralized Office Servers

Scenario 4. Multi-Site Firm, Terminal Services, and Local PCs

Scenario 5. Single-Site Firm, WM Workstations

Scenario 6. Single-Site Firm, WM via Terminal Services

Scenario 7. Single-Site Firm, Terminal Services, and Local PCs

Subsequent chapters address the details of Server, Network, and Workstations deployment

applicable to the scenarios above.

CCH ProSystem

Engagement Office Servers host three basic categories of data:

Admin data. Firm information, staff properties and staff rights, licensing information, and client

information

Central File Room data. Binders, workpaper properties, workpaper files, and notes

Central File Room workpaper files

CCH ProSystem

Engagement WM Workstations and WM Terminal Servers also host three basic

categories of data:

Admin data. Firm information, staff properties and staff rights, licensing information, and client

information

Local File Room data. Binders, workpaper properties, workpaper files, and notes

Local File Room workpaper files

The data and files are synchronized between Office Servers and the WM Workstations or WM

Terminal Servers.

Chapter 1: Deployment Planning – Configuration • 3

Scenario 1: Multi-Site Firm, WM Workstations, Distributed Office

Servers

The first scenario is a multi-site firm that has deployed a “Main” Office Server at the firm’s main site

and a “Secondary” Office Server at the other sites. The Central File Rooms are thus “distributed”

across the firm. At each site, users run Workpaper Management on their WM workstations and

synchronize binders between Local File Rooms (on workstations) and Central File Rooms (on servers)

via a high-speed Local Area Network (LAN).

While this configuration maximizes the speed at which binders are synchronized, synchronization

between offices is slower in the absence of a Wide Area Network (WAN). However, WAN

synchronizations are still significantly slower than LAN synchronizations.

Figure 1 – Multi-Site Firm, WM Workstations, Distributed Office Servers

Chapter 1: Deployment Planning – Configuration • 4

Optionally, Office Server performance is optimized by storing SQL database files and workpaper files

on a SAN device connected to the server with a fiber optic cable.

If an optional Virtual Private Network (VPN) is configured at a site, remote users may connect to

synchronize.

Scenario 2: Multi-Site Firm, WM Workstations, Centralized Office

Servers

In the second scenario, there are also multiple sites, but only one site has an Office Server that is

shared by all users at all sites.

This scenario minimizes server costs by eliminating the need for servers at all sites, except the main

site. Because Workpaper Management is running on workstations, the server is stressed only by

synchronization. Because binder synchronization typically occurs between sites, this configuration is

most suitable when those sites are connected through a WAN.

Figure 2 – Multi-Site Firm, WM Workstations, Centralized Office Servers

Chapter 1: Deployment Planning – Configuration • 5

Scenario 3: Multi-Site Firm, WM via Terminal Services, Centralized

Office Servers

This configuration uses Terminal Services to provide Workpaper Management functionality to users.

This requires an adequate investment in server hardware and software; however, the bandwidth

requirement between offices is less significant than with Scenario 2. Usually the Terminal Services

Database Module is installed on the same machine as the Administrator Module. In some cases, to

boost performance it is necessary to split the installation of the Administrator module and the

Terminal Services Database module.

Figure 3 - Multi-Site Firm, WM via Terminal Services, Centralized Office Servers

Chapter 1: Deployment Planning – Configuration • 6

Scenario 4: Multi-Site Firm, Terminal Services, and Local PCs

This final configuration of the multi-site firm uses Terminal Services just like Scenario 3, but also has

some installations on workstations.

Figure 4 - Multi-Site Firm, WM via Terminal Services, WM on Local Workstations, and Centralized Office Servers

Chapter 1: Deployment Planning – Configuration • 7

Scenario 5: Single-Site Firm, WM Workstations

The single-site scenario for WM Workstations is identical to Scenario 1, but simpler due to the

absence of secondary sites.

Figure 5 - Single-Site Firm, WM Workstations

Chapter 1: Deployment Planning – Configuration • 8

Scenario 6: Single-Site Firm, WM via Terminal Services

The single-site scenario for Terminal Services is identical to Scenario 3, but simpler due to the

absence of secondary sites.

Figure 6 - Single-Site Firm, WM via Terminal Services

Chapter 1: Deployment Planning – Configuration • 9

Scenario 7: Single-Site Firm, Terminal Services, and Local PCs

The single-site scenario for Terminal Services is identical to Scenario 4, but simpler due to the

absence of secondary sites.

Figure 7 - Single-Site Firm, WM via Terminal Services

Other Scenarios

If none of the listed scenarios is adequate, then all parties involved need to work together to develop a

sustainable, predictable, and reliable solution.

Chapter 1: Deployment Planning – Configuration • 10

Summary of Deployment Scenario Recommendations

Chapter 2: Deployment Planning – Servers • 11

DEPLOYMENT PLANNING – SERVERS

Overview

The main types of servers that are implemented with CCH ProSystem

Engagement are a

Database Server, a File Server, and an optional Terminal Server. Key factors in deployment of these

servers include the Microsoft

Windows

version, available RAM, number of CPUs, Microsoft

SQL

Server

edition, high availability, and the roles and responsibilities of the IT staff supporting these

servers. A final consideration is whether to have a File Server or a SAN device.

Some of these considerations vary considerably based on the firm size and the number of users. See

the chart in

CCH ProSystem fx Engagement Office Server Recommendations

on page 15

for

recommendations.

Database Server Overview

Microsoft

SQL Server

is the database engine used by Engagement. In this section, we describe

some of the factors in deciding how to deploy SQL Server

with Engagement.

High Availability and SQL Clustering

Microsoft

SQL Clustering can be used to reduce single points of failure as part of a high availability

solution. The CCH ProSystem

Engagement Administrator and Terminal Services Database

Modules can both be deployed in a cluster environment when a SQL Server

2014, SQL Server

2016, or SQL Server 2017

instance has been configured for failover.

See

SQL Server

2017, SQL Server

2016, and SQL Server

2014 for more information on failover

instances. Installation of this environment may require the assistance of the firm's system engineer,

network engineer, storage management engineer, and database administrator.

To migrate from a non-clustered environment to a clustered environment, the CCH ProSystem

Engagement Backup and Restore Utility should be used. See

CCH ProSystem fx Engagement

Administrator Migration

on page 40

for the firm DBA on this topic. For instructions on deploying

Engagement to a SQL Cluster, see

Appendix C: Installing CCH ProSystem fx Engagement on a

SQL Cluster

on page 50.

Chapter 2

Chapter 2: Deployment Planning – Servers • 12

Microsoft

SQL Express

vs. Microsoft

SQL Server

Standard or Enterprise

Microsoft

SQL Express

is installed and set up with little effort by the firm, but it has limited

resources and is not recommended for use with more robust environments. For recommendations on

specific environments, please see the chart in

CCH ProSystem fx Engagement Office Server

Recommendations

on page 15.

Microsoft

SQL Server

Standard or Enterprise editions are recommended as the best choice for

deploying SQL Server

. See

SQL Server® Express Edition

on page 47

in Appendix A for more

information on this topic.

Microsoft

SQL Server

(x86) with Address Windowing Extensions (AWE) vs.

Microsoft

SQL Server

(x64)

Microsoft

SQL Server

(x86) only supports 2 GB of RAM by default. This is due to the 4 GB of virtual

address space limitation of SQL Server

32-bit. The x64 version of Microsoft

SQL Server

does not

have this limitation. If for any reason there is a constraint that prevents installing Microsoft

SQL

Server

(x64), it is still possible for Microsoft

SQL Server

(x86) to utilize more than 2 GB of RAM by

enabling the AWE option. However, the maximum RAM SQL utilizes with AWE enabled depends on

how much memory is supported by the corresponding operating system that is running SQL Server

Due to the limitations and complexity of implementing AWE, it is recommended that Microsoft

SQL

Server

(x64) be installed for Enterprise solutions. See

SQL Server® (x64) vs. SQL Server® (x86)

with AWE Enabled

on page 46

in Appendix A for additional information for the firm DBA on this topic.

File Servers Overview

Implementing a File Server may assist with space usage, redundancy, and in some cases

performance. CCH ProSystem

Engagement allows the physical files for a Central File Room on a

network location. A common device used for this implementation is a SAN device. Both of these

hardware choices are optional but have many advantages if implemented.

Using a SAN

Both the SAN device and the File Server provide redundancy and help with disk space usage. SAN

devices typically provide better performance than the File Server when connected via a fiber channel.

For this reason, a SAN device with fiber channel is recommended for Enterprise solutions.

SQL

The SAN device is used to store the SQL Databases and physical files for the Central File Room

(CFR), and also the Local File Room (LFR) for a Terminal Services Database, to minimize the latency

created from disk I/O with these files. The SAN device is a requirement for setup of a clustered

environment.

In addition, the SAN device must be configured and recognized as a local drive for Microsoft

SQL

Server

to function correctly.

Chapter 2: Deployment Planning – Servers • 13

Physical Files

For physical file storage of the CFR workpapers, if the drive is configured as a local drive, similar to

the configuration for using the SAN device as previously mentioned, a UNC path is not necessary.

Physical files that are located on a File Server network require a UNC path.

Microsoft

Windows Server

We recommend Microsoft

Windows Server

2016 (x64), or Microsoft Server® 2019 as the base

operating system for all servers. The following link has more information from Microsoft

on RAM

Limitations. Microsoft

Small Business Server

(this includes Server 2011 Essentials and Server

2012 Essentials), Windows Server

Essentials, Microsoft

Windows Server

2012 R2 (x64) and

Windows Server

Foundation are not supported.

Hardware Considerations

RAM, CPUs (or cores on the CPUs), and file storage have the biggest impact on performance. For the

database server, the highest performance is achieved when RAM is equal to the size of all the

databases simultaneously loaded into memory to avoid swapping from the hard disk. The exact

minimum amount of RAM varies depending on firm usage. The recommendations in this guide are for

optimal performance.

The base recommendation for the larger more robust servers is to have anywhere from 32 GB of RAM

to 64 GB of RAM. For application servers, CCH ProSystem

Engagement, Microsoft

SQL Server

and Microsoft

Office are used. The recommended amount of RAM for application servers is 32 GB

of RAM and a maximum of 20 users per server.

Indications of a bottleneck of CPU utilization are when CPU utilization is constantly over 80% and

servers with high usage are operating with less than 24 cores. In addition, x64 processors are required

to install the x64 versions Windows Server

2016, and Windows Server

2019 as previously

recommended.

Too much disk I/O is expensive, so preventing or minimizing the impact of when heavy disk I/O

actually does happen is important. SAN devices are a good solution for this aspect and are

recommended for systems with over 250 connected users.

More details on monitoring the hardware and performance considerations are in

Chapter 5: Ongoing

Monitoring and Upgrade Considerations

on page 26

and

Hardware Performance

on page 43

Appendix A.

Firm IT Staff Roles and Responsibilities

Certain roles and skill sets within the firm are necessary for Engagement to perform optimally:

System Engineer for Windows Servers

. Assists in the design, testing, and implementation

stages of Windows

Projects. This role should have working knowledge of Microsoft

Chapter 2: Deployment Planning – Servers • 14

Windows

operating systems, Active Directory

, DNS, Terminal Services and Group Policy.

Network Engineer. Installs, configures, and maintains network services and devices.

SQL DBA or Database Administrator. Installs, configures, and maintains the machines with

Microsoft

SQL Server

. This includes monitoring the performance, making any tuning

adjustments, and performing backup processes.

Chapter 5: Ongoing Monitoring and Upgrade

Considerations

on page 26

and

Appendix A: Database Administration

on page 37

includes

specific details on this role.

Storage Management Engineer. Plans, sets up, and administers file servers and SAN

devices.

Security Analyst. Implements and maintains the firm’s security policies, which include

Engagement, the services, SQL, firewalls, and ports.

Deskside Technician. Installs Engagement on laptops and workstations, diagnoses end user

issues, and establishes network connectivity.

Desktop Engineer. Shares some of the same responsibilities as the Deskside Technician,

except this role is responsible for physically setting up the system. The Desktop Engineer may

also test hardware and software to see if it fits the firm’s needs. This role is also responsible for

performing an Active Directory

Push of the installation.

These roles help design the initial setup and provide ongoing maintenance of the environment. Staff

with these skills can perform troubleshooting or performance tuning. The configuration and

complexity of your firm’s network and database structures will determine the types of roles and skill

levels required. A single IT staff can perform one or more of the roles depending on their skill set.

Virtualization

The virtual machine must meet the same system requirements for Engagement as a physical

machine. Please consult with your virtualization vendor for specific recommendations.

Upgrading CCH ProSystem

Engagement

You can take several steps to make the upgrade from a prior version go smoothly. The first step is

reviewing all documentation, including the Release Notes, the knowledge base article

Installation

Guidance for CCH® ProSystem fx® Engagement, and this Deployment Planning Guide.

You can also do the following to help ensure data integrity:

Synchronize binders to the Central File Room

Perform a backup both before and after the upgrade using the CCH ProSystem

Engagement

Backup and Restore Utility

Check for compressed databases

For detailed instructions on upgrading, see

Appendix B: Upgrading CCH ProSystem fx Engagement

on page 48.

Chapter 2: Deployment Planning – Servers • 15

CCH ProSystem

Engagement Office Server Recommendations

The following chart contains recommendations for deploying Engagement Office Servers, also known

as the Administrator module. Office Servers are both Database Servers and File Servers. This chart

shows the different considerations, including SQL Server

, File Storage, and architecture.

The recommendations for installing Engagement Office Servers, including some of the optional

components from the previous chart, can be found on the Customer Support Web site under the

CCH ProSystem

Engagement System Requirementstab.

Chapter 2: Deployment Planning – Servers • 16

Terminal Servers

Terminal Servers, although optional, allow for the use of the application server/database server

topology. A few typical scenarios are generally chosen for this section.

Refer to

Chapter 1: Deployment Planning – Configuration

on page 1

for more details on Terminal

Services, more specifically

Scenario 3: Multi-Site Firm, WM via Terminal Services, Centralized

Office Servers

on page 5

and

Scenario 5: Single-Site Firm, WM Workstations

on page 7

CCH ProSystem

Engagement Terminal Services Client

Overview

Application servers, dedicated for application files and no user data, are sometimes part of a farm.

Engagement will install on any machine with the Terminal Services Role installed. These machines

link to the database server with CCH ProSystem

Engagement Terminal Services Database. The

Terminal Services Client Module requires that Microsoft

Office already be installed on the terminal

server or Citrix

box.

Terminal Services Client Recommendations

The following chart contains recommendations in regards to deploying Engagement on Terminal

Services. We start with the recommendation of 20 users per Terminal Server, and then show

recommendations for operating systems, Microsoft

Office, and hardware. See

Microsoft® Office

page 20

for more details on the recommendations for Microsoft

Office.

Chapter 2: Deployment Planning – Servers • 17

The recommendations for the installation of CCH ProSystem

Engagement Terminal Services

Client, including some of the optional components from the chart, can be found on the Customer

Support Web site under the CCH ProSystem

Engagement System Requirements tab.

Terminal Services Database Overview

Microsoft

SQL Server

and the prerequisites for SQL are installed first on these servers. This type of

server is considered both a database server and a File Server as it contains both the physical files,

such as Microsoft

Excel

and Microsoft

Word, and the CCH ProSystem

Engagement database

files.

Chapter 2: Deployment Planning – Servers • 18

Terminal Services Database Recommendations

The following chart contains recommendations regarding deployment of the CCH ProSystem

Engagement Terminal Services Database. This module is used in conjunction with one or many

CCH ProSystem

Engagement Terminal Services Client installations. The recommendations are for

Microsoft

Windows

, Microsoft

SQL Server

, file storage, and hardware.

The recommendations for the installation of the CCH ProSystem

Engagement Terminal Services

Database, including some of the optional components from the chart, can be found on the Customer

Support Web site under the CCH ProSystem

EngagementSystem Requirements tab.

Chapter 2: Deployment Planning – Servers • 19

Summary

Various hardware and software choices are made prior to deploying Engagement. The server choices

include operating system, amount of RAM, number of processors, and infrastructure. The choices are

based on the role of the server as well as the usage. Several recommendations exist as a starting

point, such as 64-bit operating systems, the use of Microsoft

Standard or Enterprise Edition of SQL

Server

, and SAN devices for larger firms. As stated in

Chapter 1: Deployment Planning –

Configuration

on page 1

, a few scenarios are generally chosen based on the firm’s needs.

Chapter 3: Deployment Planning – Workstations • 20

DEPLOYMENT PLANNING - WORKSTATIONS

In an Enterprise environment, deploying Engagement means deploying the application to possibly

hundreds of workstations. This factor alone warrants planning the deployment of these workstations.

This chapter covers:

Microsoft

Windows

Microsoft

Office

Microsoft

SQL Server

Installation

Security

Use of a File Server

Hardware considerations

Roles of the IT staff

Microsoft

Windows

8.1 or Windows

10 is recommended for the operating system choice on workstations.

See the

Microsoft

Windows

Web site for more information.

Microsoft

Office

Engagement supports the features and benefits of:

Microsoft

Office 2013

Microsoft

Office 2016

Microsoft

Office 2019

Microsoft

Office 365™ - Desktop version

These features include the Office task-oriented ribbon interface, greater document capacity, and new

customization features.

Note: The Microsoft

Office 365™ Online version isnot supported.

Chapter 3

Chapter 3: Deployment Planning – Workstations • 21

Microsoft

SQL Server

For workstations, Microsoft

SQL Express

is recommended. Microsoft

Standard or Enterprise

edition are only necessary for servers. The recommended versions are:

Microsoft

SQL Server

2017

Microsoft

SQL Server

2016

Microsoft

SQL Server

2014

Starting with Microsoft

SQL Server

2016, you can only install a 64-bit version of the software. If you

already have a 32-bit version of a SQL instance installed, there is not a traditional upgrade path to a

64-bit platform. To move to a 64-bit platform of SQL Server

, you will need to uninstall the 32-bit SQL

instance and then re-install the instance using the 64-bit version.

For more information, please refer to this

Microsoft article.

Note: Prior to performing any installation processes with your SQL instance, be sure to use the

proper SQL backup procedures for the installed instance to prevent data loss. Once the

installation procedure is completed, you can restore your 32-bit backup to the 64-bit version of the

instance without issue.

Hardware Considerations

RAM, CPUs (or cores on the CPUs), and the hard disk have the biggest impact on performance. As

stated in the Office Server section of Chapter 2, Engagement uses Microsoft

Office and Microsoft

SQL Server

, so the system needs enough memory to run all of these applications along with other

applications used by your firm. The recommendation for a workstation is 4 GB of RAM.

An indication of a possible hardware bottleneck is when CPU utilization is constantly over 80%. A

dual- or quad-core processor is recommended. More details on monitoring the hardware and

performance considerations are in

Chapter 5: Ongoing Monitoring and Upgrade Considerations

page 26

and

Hardware Performance

on page 43

in Appendix A.

Installation

Engagement has several prerequisites before installation. The most important of these is a

Microsoft

SQL Server

. For workstations, Microsoft

SQL Express

is easily installed from the

Engagement Install Media and is already configured through the installer. Microsoft

SQL Express

is not the only requirement, however. The knowledge base article Installation Guidance for CCH®

ProSystem fx® Engagement provides links and information to help you identify other components

that are required prior toinstalling Engagement.

Chapter 3: Deployment Planning – Workstations • 22

Active Directory

Push

Once all of the prerequisites are installed on the workstations, Active Directory

can be used to push

out the Engagement MSI installer. By using this method, possibly several hundred machines can be

updated at the same time. Refer to the knowledge base article

How do I push an installation through

Active Directory® when installing CCH® ProSystem fx® Engagement or Workpaper Manager? for

more detailed instructions.

Security

Encryption, user rights, firewalls, virus scanning, script blocking, and Windows

service packs are

common forms of protection against security breaches. Microsoft

Office also has its own set of

security restrictions. If the restrictions on this software are not managed correctly, some functionality

inside Engagement is blocked. Refer to the knowledge base article

How do I push an installation

through Active Directory® when installing CCH® ProSystem fx® Engagement or Workpaper

Manager? for more information.

Use of File Server – Network Template Storage

As previously stated in Chapter 2, a File Server is beneficial to your firm. Engagement utilizes several

different types of templates. These templates are used for the creation of new binders, workpapers,

account groupings, and trial balances. These templates are created and stored locally by default but

are sometimes placed on a network location, if desired. If these templates are moved to the network,

they are only accessible when the workstations have access to that location. If the workstations leave

the office, they will need the templates locally.

CCH ProSystem

Engagement Workpaper Management

Recommendations

The following chart contains recommendations in regards to deploying the CCH ProSystem

Engagement Workpaper Management, including recommendation on hardware, Microsoft

Office,

Microsoft

Windows

, and Microsoft

SQL Server

Chapter 3: Deployment Planning – Workstations • 23

The recommendations for the installation of CCH ProSystem

Engagement Terminal Services

Client, including some of the optional components from the chart above can be found on the

Customer Support website under the CCH ProSystem

Engagement System Requirements tab.

Chapter 4: Deployment Planning - SQL Server Agent • 24

DEPLOYMENT PLANNING -

SQL SERVER AGENT

Overview

SQL Server Agent is typically enabled to run in the Engagement database operations for two

purposes:

To support the database maintenanceplan.

To support SQL Server clustering.

Start Up Account

The startup account can be configured in

Services

to indicate on whose behalf the SQL Agent service

will be running, and it will be used inside the SQL Agent to make database connections to the

corresponding SQL instance. All Windows

Accounts (except for the [BUILTIN\Administrators]

accounts) are to be revoked from the SQL instance during the Engagement installation process. If the

SQL Agent is running on your system with a startup account other than the BUILTIN\Administrators

accounts, then the installer will fail to delete that account, hence, it will fail to complete. It is

necessary to follow the

Pre-Installation

and

Post-Installation Steps

below in order to prevent the

Engagement installation from failing.

Note: The “Local System Account” or “LocalSystem” Account, also known as “NT

AUTHORITY\SYSTEM” Account is a member of the BUILTIN\Administrators group.

Pre-Installation Steps

From Windows

, open and view the

LocalServices

Right-click on the SQL Server Agent(PROFXENGAGEMENT).

Select Properties.

Right-click on the Log On tab and note the startup account name currently used. If the start up

account is a “Local System Account,” you may skip the rest of the steps; otherwise, continue.

Click on the General tab.

Chapter 4

Chapter 4: Deployment Planning - SQL Server Agent • 25

Click the Stop button to stop the service. This will allow the referenced account to be removed

from the SQL Server catalog during the installation process.

Click OK to close the window.

Post-Installation Steps

If you stopped the SQL Agent during the

Pre-Installation Steps

, you must add the startup account

back to the SQL instance and start the SQL Agent manually:

as “sa” or with Windows

Authentication.

From the

View

menu, select Object Explorer\Expand Security.

Right-click on the Logins and select New Login.

Search and locate the Windows

Account noted in the

Pre-Installation Steps

Click the Server Roles tab and check sysadmin.

Note: Add a new account with the [sysadmin] role at your own risk.

Click OK.

From Windows

, open and view the

LocalServices

Right-click on the SQL Server Agent(PROFXENGAGEMENT).

Select Properties.

10.

Click on the Log On tab and verify that the startup account name you previously noted when

stopping the service is still shown. If not, enter or select that

account name

11.

Click on the General tab.

12.

Click the Start button to start the service. This will allow the account to be added back to the

SQL Server catalog.

13.

Click OK to close the window.

Chapter 5: Ongoing Monitoring and Upgrade Considerations • 26

ONGOING MONITORING AND

UPGRADE CONSIDERATIONS

Monitoring the Servers

Monitoring the health of the machines using CCH ProSystem

Engagement is essential to ensure

the best performance is achieved and to determine when an upgrade is necessary. There are three

basic areas to monitor, RAM usage, CPU usage, and disk I/O. Disk I/O is one of the slowest functions

on a system and heavy disk I/O will affect performance. Several counters are setup to monitor the disk

I/O. A SAN device with fiber channels is also used to help performance with heavy disk I/O.

RAM will contribute to disk I/O if there is memory pressure; monitoring the memory usage is

recommended. Consider that Microsoft

SQL Server

is a memory intensive application and by

default will use as much memory as the operating system will allow. The final consideration for

hardware is the processor. If the usage is constantly over 80%, an upgrade might be necessary.

Monitoring the process at the same time as the RAM is ideal.

Consider all of the topics in this Chapter to create a clear picture of future hardware and software

requirements. The counters help determine if more RAM is needed, more processing power is

needed, or if the disk is too slow.

Appendix A: Database Administration

on page 37

has some

detailed information on exactly what to monitor and when to upgrade.

Database Backup and Health Check

Data integrity to the firm is important and the CCH ProSystem

Engagement Database Backup and

Restore Utility assists the firm in this manner. The utility has a built-in health check for each of the

SQL databases and will mark both the log file and the backup file with "Failed –" appended to the

name in the case of an unsuccessful backup. The firm must create a Microsoft

Windows

scheduled

task for this utility to perform these backups on a nightly basis. The utility will not back up the physical

workpaper files. This is done by a separate task or 3rd party software. It is possible to use other

backup techniques but CCH ProSystem

Engagement Database Backup and Restore allows for

single-binder restoration.

Database Backup and Health Check

on page 37

in Appendix A has more

details on this topic.

Chapter 5

Chapter 5: Ongoing Monitoring and Upgrade Considerations • 27

Bin Maintenance

By default, bin maintenance tasks are scheduled to run on a nightly basis. It is important to monitor

the result of each run on a daily basis to make sure all steps are executed successfully. This will help

to ensure sufficient database space is used in each bin and the database statistics are up-to-date. Pay

special attention to the bin diagnostics report, which displays the first time an administrator logs in to

the Office Server after each nightly task is run. You can also view this report by selecting

Tools > Bin

Diagnostic Report in the Administrator module. It is recommended to avoid overlap among different

CCH ProSystem

Engagement nightly tasks, and between a CCH ProSystem

Engagement

nightly task and other nightly tasks, such as Windows® updates.

Disk Space Usage

Make sure the disk drives hosting the database files have sufficient disk space for the database files

to grow. Checking the location of the physical files is also recommended. At minimum, both tasks

should be performed on a weekly basis.

Disk Fragmentation

Since disk fragmentation may have significant impact on performance, it is recommended to monitor

the disk fragmentation on the hard drives hosting the CCH ProSystem

Engagement SQL .mdf and

.ldf files on a weekly basis, and if significant numbers of fragments are detected, defragmentation of

the hard drive level should be performed.

Chapter 6: Working with CCH ProSystem fx Engagement in the Field • 28

WORKING WITH CCH PROSYSTEM FX

ENGAGEMENT IN THE FIELD

Overview

This document, along with the Engagement Help files and installation articles in the knowledge base,

can help you understand and resolve common issues. The instructions here are for use by

Engagement users working together with their network administrators and IT professionals.

For a basic usage background, we strongly encourage you to read the help topic

Synchronizing with a

Local File Room

. This topic gives a step-by-step overview

the

Field

Synchronization

process,

which you should understand to effectively create and use a field environment. To locate this topic

from in Engagement, select

Help > Help Topics, and then open the topic Sharing and Distributing

Binders > Peer-to-Peer Network Environment > Field Synchronization/Synchronizing with a

Local File Room.

Synchronizing data is an essential function. For synchronization to work properly, it is critical that the

operating system can resolve the names of the other machines involved in this process. This can be a

challenge in the field for two primary reasons:

The machines are no longer using the servers in the office, including the DNS server.

Four ports are required for synchronization. These must be open and not blocked by a firewall.

It is important to create and test a simulated field environment while you are in the office. This can be

done on a conference room table, using the actual laptops, networking cords, and other networking

equipment that is used in the field. Every office is different; it is important to establish a set of steps

that works for your equipment before you go to the field. If there are difficulties, it is much easier for

you to work with Engagement support representatives to find and implement a solution before the

team is on an actual job in the field where time is critical, and users may be far from the office.

Any type of network connection can work with Engagement, as long as it provides network

connectivity between the machines that will be used for field synchronization. Generally, the

difficulties are not due to the specific type or brand of hardware being used, but are related to the

myriad network configuration settings that must be considered for every unique environment. The

remainder of this document focuses almost exclusively on these configuration settings rather than the

underlying hardware.

Chapter 6

Chapter 6: Working with CCH ProSystem fx Engagement in the Field • 29

Connection Types

Engagement can work with many types of network connections. As long as a connection meets all of

the requirements, then the type of connection is not important. The connection type can affect factors

such as speed and reliability, but do not determine whether Engagement will work. Engagement will

use any connection type that meets its requirements.

Some possible connection types that can be used for field synchronization with Engagement include:

Hub/Router

Wireless Access Point

Ad Hoc Wireless

Client Network

While each of these connection types can work with Engagement, each has different characteristics

and can require different setup steps. It is the responsibility of your IT staff to assist with the setup

and configuration of the network connection type, based on the available equipment and capabilities.

Name Resolution

The first and most important challenge in any field synchronization is to confirm that proper name

resolution exists between the machines that will be connecting together. The basic concept of name

resolution is quite simple. However, the process is complicated by many factors, including:

IP address changes

Server not available

Client network setup

Hub/router setup

Microsoft

Windows

version

Firewall settings.

When the machines cannot resolve each other’s names, you can use the Networking tab of the

CCH ProSystem

Engagement Configuration Utility to assist with name resolution. See the section

on the next page that describes the usage of this utility.

Chapter 6: Working with CCH ProSystem fx Engagement in the Field • 30

Machine Location IP address source

Name Resolution Illustration

The following explores some of the issues around name resolution, and provides tips for

troubleshooting and resolving these issues.

Finding the IP Address and Machine Name

When a computer is booted, it is assigned an IP address, a unique set of four or six numbers that

identifies the machine on the network. It is the basis for all network communications. When the

machine is booted, it looks for a network connection and requests to be assigned an IP address from

that network connection source.

In a normal office network, this address is provided by a Windows

DNS server. However, if the

machine is being booted from a remote location outside the office, the machine can get its IP address

from a number of different places. This wide variety of connection types can cause a machine’s IP

address to change often. That is why it can be very difficult to connect machines with each other when

taken out of the standard office environment.

Connected to office network DNS server in office

Connected to client’s network DNS server on client’s network

Connected to hub/router Hub/router

Coffee shop or airport Wireless router in coffee shop or airport

Cell phone or air card Cell phone network provider

Company VPN Windows® DNS server in office

Not connected to any network Machine uses a self-generated IP address

Chapter 6: Working with CCH ProSystem fx Engagement in the Field • 31

When connecting machines in the field, it is very important to know the name of each machine, as

well as where each machine is getting its IP address from at any given moment. Engagement relies

on a working network connection to connect successfully for field synchronization.

To find the machine name and IP address, do the following:

Select Start > All Programs > Accessories> Command Prompt.

Enter

hostname

at the command line and press

Enter

. Your machine name displays below the

command prompt.

Enter

ipconfig

at the command line and press

Enter

. Your IP address displays below the

command prompt.

Once you know the IP address and name for each machine, you can test if a connection exists

between the machines and if there is the proper name resolution for the machines.

Testing IP Address Connections

To test for a connection, run a “ping” command for the machines in your group.

On your computer, select Start > All Programs > Accessories > Command Prompt.

Enter

ping <IP address>

at the command line and press

Enter

. Replace

with

the IP address of another computer in the group. If the connection was:

Successful, you see the message

Packets: Sent = #, Received = #, Lost = 0 (0% loss)

Unsuccessful, you see the message

Packets: Sent = 0, Received = 0, Lost = # (100%

loss)

Testing Name Resolution

Testing name resolution uses the machine name instead of the IP address.

On your computer, select Start > All Programs > Accessories > Command Prompt.

Enter

ping <machine name>

at the command line and press

Enter

. Replace

with the machine name of another computer in the group. If the connection was:

Successful, you see the message

Packets: Sent = #, Received = #, Lost = 0 (0% loss)

Unsuccessful, you see the message

Packets: Sent = 0, Received = 0, Lost = # (100%

loss)

Chapter 6: Working with CCH ProSystem fx Engagement in the Field • 32

If the tests above are successful, then you have confirmed that there is basic network connectivity

(based on IP address) and there is machine name resolution (based on machine name). Both of these

are required to continue and for the Engagement synchronization to function successfully.

Engagement Services and Ports

Engagement uses a number of services and ports on the machines that will be connected to each

other. The following illustration shows these services and technical details for each one.

Chapter 6: Working with CCH ProSystem fx Engagement in the Field • 33

Depending on which functions are being used in Engagement, these services and ports are used at

various times. For the primary function of synchronization, Engagement uses SQL Server

and the

Synch Service. For these functions to work correctly, the machine must have basic connectivity as well

as name resolution. Also, the machine must be able to communicate freely on the ports noted on the

previous page. A port can be compared to a television channel. Even though the television may be

connected to the antenna or cable, it must be tuned to receive the designated channel.

Firewalls

A firewall is used to block or allow communication on specific ports of the machine. Using the

television channel analogy above, this is the equivalent of having certain channels blocked that might

be considered harmful or undesirable. A firewall performs exactly the same function, keeping out

certain types of network communications, while allowing other types.

If the ports needed for synchronization are blocked, this can affect how the Engagement

synchronization process works. This can be caused by a firewall, an antivirus program, a client’s

network, or almost any other connection type that restricts the type of network traffic that can pass

through. The following illustrates a network connection that will not work correctly because of a

firewall block.

Testing the ports to be used by Engagement can be done with the free Port Query tool from

Microsoft

. You enter the ports to be tested manually, or receive a special configuration file from

Engagement support that has the proper ports already entered.

Download the Port Query tool from the following link:

http://www.microsoft.com/download/en/details.aspx?id=24009

To test the Engagement ports using the PortQryUI tool, do the following:

Open portqueryui.exe.

Enter the name of the machine to be tested.

Do one of the following:

Chapter 6: Working with CCH ProSystem fx Engagement in the Field • 34

Use the Engagement query predefined service. Select the Query predefined service

option, and then select Engagement from the list (the config.xml will need to be edited

to add Engagement and its ports as a predefined service). Each of the primary ports

used with Engagement is tested, and a separate section in the results will be listed for

each port.

Manually input query ports. Select the Manually input query ports option, and then

enter the port number and/or port ranges separated by commas.

Click Query.

For each port number, a result of LISTENING or NOT LISTENING will be reported, as shown in the

following illustration. If a port is noted as NOT LISTENING, this means either the associated service

is not running, or the port that it is using is blocked by a firewall of some kind.

Chapter 6: Working with CCH ProSystem fx Engagement in the Field • 35

Based on the results of the PortQryUi tool, you can continue troubleshooting to determine what is

causing the ports to be blocked.

If ports are blocked, do the following:

Disable the Windows® Firewall on all machines.

Retry the Port Query test, and see if the result shows LISTENING. If so, you can successfully

use Engagement only if the firewall is turned off, or if specific exceptions for those ports are

added to the Windows® Firewall or other port monitoring software.

CCH ProSystem

Engagement Configuration Utility

Once a network connection has been established between the machines, every user working in

Engagement should run the CCH ProSystem

Engagement Configuration Utility.

Select Start > All Programs > CCH ProSystem

Engagement > Utilities, right-click on the

CCH ProSystem

Engagement Configuration Utility, and then select to Run as

Administrator.

Note: It may be necessary to alter the short cut for the Configuration Utility. If it fails to

launch, right-click on the Configuration Utility icon and select

Properties. The target will

point to the PfxConfigUtil.exe, and there will be a /m client switch at the end. In some cases

this switch has prevented the utility from launching. Remove the /m client from the end of

the Target path.

Select the Networking tab of the Configuration Utility.

Select all check boxes in the

Delete Settings

section and click

Delete

. This removes any

previous entries made by this utility that may no longer be relevant.

Click

Detect

in the

Auto Detect

section. It is important that every user do this step at the same

time. The Detect feature broadcasts each user’s machine name and IP address.

Once all the users machines can be seen in the Auto Detect window, click Save.

Note: Pressing Save creates an SQL alias in the registry and creates entries for the

workstations in the hostsfile.

Close the Auto Detect window and close the CCH ProSystem

Engagement Configuration

Utility.

Open Engagement and select

Field

from the

Select location

list.

Test the ability to connect to other users. This step is not required for field synchronization.

Click the Staff tab, right-click a user to connect to, and select Properties. The

Staff

Location Properties

window displays.

Click the Existing location drop-down to verify the correct machine name for the user

you are connecting to.

Click OK. The contents of the other users' Local File Room should display. This indicates

Chapter 6: Working with CCH ProSystem fx Engagement in the Field • 36

a successful connection between the two users and that field synchronizations is

possible.

Perform a synchronization.

Select a binder.

Right click and select Synchronize binder. The Synchronize Binder Wizard guides you

through the synchronization process.

On the

Select a Synchronization Target

page, select a user to sync with and verify that

the Existing Locations list displays the correct machine name.

Click Next to assign workpapers or click Finish to complete the synchronization process.

Appendix A: Database Administration • 37

DATABASE ADMINISTRATION

As an important role for the CCH ProSystem

Engagement software operation, the SQL DBA will be

responsible for performing a list of tasks, either on a period-by-period basis or based on

requests/needs. There are two types of SQL deployment that need to be closely monitored, the Office

Server and the Citrix

/Terminal Services SQL Server

both of which are SQL Servers

Database Backup and Health Check

One of the most important tasks for a DBA is to perform successful database backups on a regular

basis.

At the very minimum, a full backup and health check should be performed on every Office Server on a

daily basis. The CCH ProSystem

Engagement Backup and Restore Utility helps to make this easier

and includes a built-in health check feature. The SQL DBA should create a nightly task to run the

CCH ProSystem

Engagement Backup and Restore Utility, ideally allocating a dedicated window on

the server for this task to run. The SQL DBA should be monitoring the status of this task, reviewing the

log of the utility on a daily basis to make sure a successful backup was performed, and ensuring all

databases remain in optimal health. For large firms, as the number of bin databases grows larger, it

may take a longer time to perform full backup on a nightly basis. Therefore, you may need to monitor

this closely to find out if the current window allocated for backup is sufficient for the task to run. If not,

either reschedule the task for a different time when a longer window is available, or implement the

differential backup option in the utility.

Important:

Make sure to save the backup files into a different drive other than the one hosting the database

.mdf and .ldf files. If the files are on the same drive, a single point of disk failure could result in

the loss of both the production drive and the backups.

Periodically check the recovery operations to validate the contents of the backup and ensure the

entire environment can be restored.

Note: The Database Backup and Restore Utility does not back up any of the Terminal Services

Databases.

Appendix A

Appendix A: Database Administration • 38

Database Maintenance Plan

Overview

Setting up a database maintenance plan helps the SQL Server

to operate efficiently and also helps

to ensure data integrity. We recommend setting up this plan to check database integrity, shrink

databases, rebuild indexes, update statistics, and cleanup. For a more detailed overview of database

maintenance plans, refer to the following document:

http://msdn.microsoft.com/en-us/library/ms191002.aspx#Restrictions

Agent XPs

Before creating the plan, the SQL Server

option for Agent XPs must be turned on. To turn on the

SQL Server

option for Agent XPs, refer to the following document:

http://msdn.microsoft.com/en-us/library/ms178127.aspx

Database Maintenance Plan

We recommend you set up the database maintenance plan by doing the following:

Open SQL Server

Management Studio.

Expand the Management folder.

Right-click Maintenance Plans.

Select Maintenance Plan Wizard.

Enter Pfx Engagement for the plan name.

Leave Single schedule for the entire plan or no schedule selected.

Click

Change

to change the schedule of the task. The

Job Schedule Properties

dialog

displays.

In the

Frequency

section, select

Monthly

from the

Occurs

drop-downmenu.

10.

Select The first Sunday of every 1 month(s).

11.

Leave

Occurs once at: 12:00:00 AM

selected in the

Daily frequency

section.

12.

Click OK.

13.

Click

Next.

The

Select Maintenance Tasks

dialog displays.

14.

Select the following maintenance tasks:

Check Database Integrity

Shrink Database

Rebuild Index

Update Statistics

Maintenance Cleanup Task

15.

Click Next.The tasks should be performed in the order listed in step 14.

Appendix A: Database Administration • 39

16.

Click Next.

17.

Complete the following for the tasks selected:

Database Check Integrity

Select

All databases

Pfx Engagement databases

from the

Databases

drop-down menu.

ii.

Click Next.

Shrink Database

Select

All databases

from the

Databases

drop-down menu.

ii.

Enter

100

MB in the

Shrink databases when itgrows beyond

box.

iii.

Leave 10% in the

Amount of free space to remain after shrink

box.

iv.

Select Return freed space to operating system.

Click Next.

Rebuild Index

Select

All databases

Pfx Engagement databases

from the

Databases

drop-down menu.

ii.

Select Reorganize pages with the default amount of free space in the

Free

space options

section.

iii.

Click Next.

Update Statistics

Select

All databases

Pfx Engagement databases

from the

Databases

drop-down menu.

ii.

Select

All existing statistics

from the

Update

options available.

iii.

Select

Full scan

as the

Scantype

iv.

Click Next.

Maintenance Cleanup

Select

Maintenance Plan text reports

from the

Delete files of the following

type

options.

ii.

Select Search folder and delete files based on an extension.

iii.

Select Browse and browse to the The ProfxEngagement SQL Server Log file

path.

Example: C:\Program Files\Microsoft SQLServer\MSSQL10_

50.PROFXENGAGEMENT\MSSQL\Log

iv.

Enter

txt

in the

File extension

box.

In the

File age

section, check

Delete files based on the age of the file as

task run time.

vi.

Enter

and select

Months

from the drop-down menu in the

Delete files older

than the following

section.

vii.

Click

Next.

The

Select Report Options

dialog displays.

Appendix A: Database Administration • 40

18.

Make your preferred report optionsselections.

19.

Click Next.

20.

Click Finish to complete thewizard.

Note: Maintenance Plansare not available in SQL Express.

CCH ProSystem

Engagement Administrator Migration

Server migrations are sometimes necessary due to various reasons. The simplest approach to

migration utilizes the CCH ProSystem

Engagement Backup and Restore Utility. Prior to performing

the migration, it is essential to take into consideration the factors mentioned here to help make the

process go smoothly. Many of the recommendations mentioned take place prior to preparing for the

migration and before the actual migration takes place. Missing any of these steps could result in data

loss or an unsuccessful migration.

Prior to beginning the migration, it is recommended that all workpapers be checked in. It is also

recommended that the installation path be the same on both the old server and the new server. For

instance, if the CCH ProSystem

Engagement Administrator module is installed to C:\Pfx

Engagement\ on the existing server, it should be installed to C:\Pfx Engagement\ on the new server.

In addition, the same version of CCH ProSystem

Engagement Administrator should be installed on

both servers.

The version of SQL Server

can be greater than or the same version on the target, or new server, but

it cannot be less than the original server. For example, if the original server was using Microsoft

SQL

Server

2014, the new machine can use Microsoft

SQL Server

2016, or Microsoft

SQL Server

2017. If the old server was using SQL Server

2016, then the new server cannot use SQL Server

2014. In addition, you cannot upgrade from different editions. For example, you cannot upgrade

from Microsoft

SQL Server

2014 Standard to Microsoft

SQL Server

2016 Express.

Note: You also cannot upgrade from a 32-bit instance or SQL Server to a 64-bit instance..

Migrating the OfficeServer

Important Notes:

These steps only involve the migration of Administration Module. If you have other modules on

your server, such as the Terminal Services Database, all binders from CCH ProSystem

Engagement Terminal Services Client sessions must be checked into the Central File Room

prior to migration.

The Terminal Services Database is not included in the backup of CFR SQL databases.

The Terminal Services Database cannot be migrated.

The office server migration must be performed at a time when the CCH ProSystem

Engagement application is not in use.

It is required to use a full backup during a planned migration.

Appendix A: Database Administration • 41

To migrate the office server, do the following:

On the new server

, install the same version of CCH ProSystem

Engagement Administrator

to the same physical installation as on the old server.

Important: Do not launch the application on the new server once installation has

completed.

On the old server

, open

CCH ProSystem

Engagement Administrator

Locate the

Central File Room(s)

in the lower left-hand corner.

Right-click the Central File Room and select Properties.

Locate the Workpaper path and document for future reference.

Repeat steps 3-5 for each Central File Room.

Still working with the old server, run CCH ProSystem

Engagement Database Backup and

Restore Utility and perform a backup of the CCH ProSystem

Engagement application. See

How do I manually run the CCH ProSystem fx Engagement Database Backup & Restore

Utility? for instructions on how to back up your database.

Note

: If you are on CCH ProSystem

Engagement 6.5, make sure you have downloaded

and used the updated CCH ProSystem

Engagement Backup and Restore Utility from

http://support.cch.com/updates/Engagement/.

Disable CCH ProSystem

Engagement SQL Service (SQL Server

[PROFXENGAGEMENT]) on the old server.

Right-click My Computer and select Manage.

Select Services and Applications from the navigation tree.

Select

Services

in the

Services and Applications

tree.

Locate the

SQL Server (PROFXENGAGEMENT)

service.

Right-click the service and select Stop.

Right-click the service again andselect Properties.

Change the startup type to Disabled and select Apply.

Close the

Computer Management

dialog.

Copy the .bak file created with the CCH ProSystem

Engagement Database Backup and

Restore Utility to the new server.

10.

On the new server

, run the

CCH ProSystem fx Engagement Database Backup and Restore

Utility

. Restore the .bak file you copied from the oldserver.

11.

Copy the

Central File Room Workpaper

folder(s) from the old server to the exact same physical

location on the newserver.

Appendix A: Database Administration • 42

Note: If the path is different on the new server, and you are on 6.x, you can use the CFR

Workpaper Path Change executable that can be obtained from CCH ProSystem

Engagement Support, or from the CCH ProSystem

Engagement Install Media

Image/utilities folder (available only on CCH ProSystem

Engagement v6.8 and newer).

See How do I use the CFR workpaper path change utility? for instructions.

12.

On the new server

, open the

CCH ProSystem

Engagement

Administrator

module for

the first time. If the server name has been changed, you are prompted to update to the new

computer name.

13.

Select

Yes

to accept the name change.

14.

Log into each workstation that has CCH ProSystem

Engagement installed.

Select OK on the message that displays indicating the program could not find the old

server.

Select Browse and browse to the new office server, or type in the name of the new

office server.

SQL Server

Jobs

By default, the SQL Agent for CCH ProSystem

Engagement SQL instance is disabled. If for any

reason this needs to be turned on and some SQL tasks need to be added, it is important to make sure

these SQL tasks do not have significant impact either on the run time process during the day or any

nightly tasks set to run for the CCH ProSystem

Engagement databases.

Database Statistics

Statistics update is essential to the performance of SQL Server

. The update of statistics is part of

the bin maintenance nightly tasks. It is recommended to monitor and make sure the update step is

executed successfully on a daily basis to ensure the statistics are always up-to-date.

Index Fragmentation

Index fragmentation is monitored by running the “Index Physical Statistics” report from Microsoft

SQL Management

studio. If it is determined some indexes are highly fragmented, it is

recommended to perform an index rebuild or defragmentation based on the type of fragmentation

during the weekend. Microsoft

explains fragmentation here.

Appendix A: Database Administration • 43

Transaction Log File Growth

The transaction log files, also known as .ldf files, are the files that track transactions during the data

modification operations. As CCH ProSystem

Engagement databases are created on the SQL

instances, the corresponding .ldf files are set to not grow. It is recommended to keep monitoring

these files on a weekly basis to make sure they do not grow to a significantly larger size or span over

the hard drives. Typically, if the size of an .ldf file is larger than 1 GB, it is an indication the truncation

process is not running properly. It is recommended to manually truncate the log and shrink the log file.

Hardware Performance

It is important to know how the hardware is currently performing for CCH ProSystem

Engagement

operations. Since there are so many factors affecting the hardware performance, it is good practice to

monitor performance of the main resources to determine if there is any bottleneck on the current

hardware. Monitoring the following three areas is ideal:

CPU

Memory

Disk I/O

In some cases, it is necessary to monitor network utilization and performance.

It is recommended to monitor the hardware performance on a monthly basis. It is also a best practice

to monitor performance for a period of time, for instance, from morning to evening, or during peak

hours of the day. The following sections include details on what to measure and the tools that are

available.

Hardware Performance Indicators

CPU

Two indicators help to determine whether there is any CPU pressure:

% CPU time. If CPU usage is frequently above 80%, it is an indication of CPU pressure. This is

an indication that a hardware upgrade of the CPU may increase performance. To monitor this,

set up a trace in Performance Monitor to capture the value in the

Processor:% Processor

Time counter by sampling the data every 10 seconds for peak hours or for the entire day.

Appendix A: Database Administration • 44

Number of Tasks waiting to run. This number indicates how many runnable tasks are waiting

for the CPU. A frequent observation of a non-zero value of this number or a high value is an

indication of a CPU bottleneck. To obtain the value, reference the result under the “runnable_

tasks_count“ column from the following query:

select

scheduler_id,

current_tasks_count,

runnable_tasks_count

from

sys.dm_os_schedulers

where

scheduler_id < 255

To monitor this, you may write a script to run this query repeatedly every 10 seconds in Microsoft

SQL Management Studio

and save the results in a table.

This value is also available under the column “SOS_SCHEDULER_YIELD” in the Performance

Dashboard report – Wait category.

Memory

The following three indicators help to determine whether there is memory pressure:

Buffer Cache Hit Ratio. This value indicates when SQL needs to visit a particular page of data

and determine how often it finds the data in the cache. If this value is frequently below 99%, this

is an indication that a hardware upgrade of the memory may increase performance. This value

is obtained from Performance monitor > SQL Server:

Buffer Manager object > Buffer Cache

Hit Ratio counter. It is also available in Performance Dashboard.

Page Life Expectancy. This value indicates how long a page stays in memory, if it often below

300, then it indicates more memory could help to improve the performance. This value is

available in Performance monitor > SQL Server:

Buffer Manager object > Page Life

Expectancy counter.

Page reads/Sec. This number indicates the frequency for which the SQL Server needs to go to

disk to visit a desired page data. If this value goes above 80, it is an indication of memory

pressure. This number is obtained from Performance monitor > SQL Server:

Buffer Manager

object > Page reads/Sec counter.

To monitor the memory pressure, simply add the above counters to the same task as stated above

with the CPU Counters.

Appendix A: Database Administration • 45

Disk I/O

The following three indicators help to determine the health of disk I/O:

Ave Disk Sec/Read. This value indicates how long it takes to fulfill one read request by the

hard drive. The ideal value is 0.005 second. A value under 0.010 second is also acceptable.

However, if it is frequent to see more than 0.010 second in this counter, it is an indication the

hard drive throughput is not sufficient. This value is available in

Performance

Monitor > PhysicalDisk Object > Ave Disk Sec/Read counter. The overall statistics values

are also available in Performance Dashboard.

Ave Disk Sec/Write. This value indicates how long it takes to fulfill one write request by the

hard drive. The ideal value is 0.005 second. A value under 0.010 second is also acceptable.

However, if it is frequent to see more than 0.010 second in this counter, it is an indication the

hard drive throughput is not sufficient. This value is available in

Performance Monitor >

PhysicalDisk Object > Ave Disk Sec/Write counter. The overall statistics values are also

available in Performance Dashboard.

Ave Disk Queue Length. This value indicates how many tasks are waiting for the hard drive to

perform a disk I/O. A frequent observation of values higher than 1 is an indication of I/O

pressure. This value is available as a counter in

Performance Monitor > PhysicalDisk Object

> Avg. Disk Queue Length. The overall statistics values are also available in Performance

Dashboard.

To monitor the disk I/O, simply add the above counters to the same task as stated above with the

CPU Counters.

Tools Available for Hardware Performance Monitoring

Performance Monitor

This tool is ideal for contiguous monitoring of resources for a period of time, for instance, during peak

hours or for an entire day of operations. Since scheduled tasks are used to collect data on an interval

basis, the performance monitor helps to provide the SQL DBA a good indication of how the hardware

resources are utilized. All the desired indicators are available as counters under different categories.

Performance Dashboard Reports for SQL Server

This tool provides a quick overview on performance-related facts for the current moment. It requires

no set up and is easy to use. It is useful to help diagnose a known performance issue on the SQL

server

and help to analyze the hardware performance bottleneck for a given moment. It will also

provide data to help analyze software bottlenecks, such as blocking.

Appendix A: Database Administration • 46

Troubleshooting Performance Issues

To diagnose a known performance issue, do the following:

Try to reproduce the issue. If the issue is reproduced, as the process is run on the user’s

machine, launch the performance Dashboard report from SQL management studio.

Detect if there is any CPUbottleneck.

Detect if there is any memory pressure present.

Detect if there is any disk I/O bottleneck.

Detect if there is any blocking present – either software or hardware.

Document any findings. If it is determined there are hardware-related issues, upgrade the

corresponding resource, if possible; otherwise, contact CCH ProSystem

Engagement support

for more help.

SQL Server

(x64) vs. SQL Server

(x86) with AWEEnabled

A 64-bit server operating system is recommended for use in conjunction with the 64-bit editions of

either Microsoft

SQL Server

Standard Edition or Enterprise Edition. This combination can fully

utilize available RAM on the server, and in the event that more RAM is added, 64-bit editions of

Microsoft

SQL Server

, Windows Server

2016, and Windows Server

2019 operating systems

will take full advantage of the additional resources. Microsoft

SQL Server (x86) only supports 2 GB

of RAM by default. This is due to a limit of 4 GB of virtual address space of SQL Server

(x86).

If for any reason, there is a constraint preventing the use of Microsoft

SQL Server

(x64), it is still

possible for Microsoft

SQL Server

(x86) to utilize more than 2 GB of RAM by enabling the AWE

option. However, the maximum RAM SQL utilizes with AWE enabled depends on how much memory

is supported by the corresponding operating system that is running SQL Server

SQL Server

Editions

Consider the following factors when choosing a SQL Server

edition:

SQL instance on Office Server vs. SQL Instance Citrix

Server

Number of concurrent users

Overall data volume on the SQL server

Number of processors to support

Other factors to consider:

Capability of online re-indexing

Performance with parallel processing features

Appendix A: Database Administration • 47

SQL Server

Express Edition

Due to the limit on RAM (1 GB) and CPU (1 Processor), this edition is not appropriate for a Terminal

Services environment.

SQL Server

Standard Edition vs. Enterprise Edition

Microsoft

SQL Server

Standard Edition and Enterprise Edition can take full advantage of the RAM

available to the corresponding operating system. However, Standard Edition only supports up to 4

processors. The necessity of the Enterprise Edition of Microsoft

SQL Server

is determined by the

number of processors installed in the SQL Server

. If it is determined more than 4 processors are

necessary for a particular environment, Enterprise Edition is the only option for the server.

Determining whether additional processors are necessary is accomplished by monitoring resource

usage on the current hardware configuration and then deciding whether additional processors would

improve the performance of the server. For more details on this topic, see

Hardware Performance

Indicators

on page 43 in this appendix.

CCH ProSystem

Engagement databases do not fully leverage the capabilities of the Enterprise

Edition of Microsoft

SQL Server

, but additional features in this edition such as online re-indexing

and parallel processing capability will improve performance over a sustained period of time. Please

consider these factors when choosing between SQL editions.

For a detailed comparison between the available editions of Microsoft

SQL Server

, please refer to

the following document link:

http://www.microsoft.com/sqlserver/en/us/editions.aspx

Appendix B: Upgrading CCH ProSystem fx Engagement • 48

UPGRADING

CCH PROSYSTEM FX ENGAGEMENT

The purpose of this section is to provide an overview of the steps necessary to ensure an upgrade to

the latest version of Engagement completes successfully.

Before the Installation

Review the contents of this guide for the most recent version of Engagement. Each version of

the program has very specific requirements which should be followed to ensure optimal

performance.

Review the Release Notes and the knowledge base article Installation Guidance for CCH®

ProSystem fx® Engagement for important information regarding the latest version of

Engagement. This information includes the latest supported service packs and software.

Synchronize all Binders to the Central File Room. You are not required to check workpapers in

for an upgrade. However, synchronizing all binders provides a backup and fallback plan for each

machine in case an upgrade fails for some reason.

Manually perform a backup of all Office Servers using the CCH ProSystem

Engagement

Backup and Restore Utility.

Back up all template types (binder, trial balance grouping, and workpaper) on each Office

Server.

Note: Backing up template types is especially important if the templates are stored on a

network location accessible by all users in the firm.

Ensure all prerequisites required by the CCH ProSystem

Engagement Installer are installed.

Refer to the knowledge base article

Installation Guidance for CCH® ProSystem fx®

Engagement for more details.

Upgrading the Office Servers

Microsoft

SQL Server

requires that all folders containing SQL databases not be compressed.

Before performing the upgrade on each Office Server, it is recommended to check for

compressed folders and decompress them if found. The Compressed Database Utility, located

on the CCH ProSystem

Engagement Install Media, can be used to check for compressed

databases.

Appendix B

Appendix B: Upgrading CCH ProSystem fx Engagement • 49

Disable virus scanning software on each Office Server.

Begin the upgrade process on the Main Office Server.

If the logon credentials were previously changed for PFXSYNPFTService to allow for a CFR

location on the network, these logon credentials will need to be reset.

Verify all scheduled tasks, including the backup and restore, still function correctly.

Verify the permissions on the Admin Share folder are set to allow administrative users full

control.

Repeat these steps until all Office Servers are upgraded.

Note: After upgrading versions of Engagement, it may be necessary to install the latest Tax

Grouping Update Wizard.

Upgrading Workstations Using Active Directory

Note: If the firm is not using the Active Directory

method of pushing the update to all machines,

see the next section,

Manually Installing the Workstations

Microsoft

SQL Server

requires that all folders containing SQL databases not be compressed.

It is recommended to check for compressed folders and decompress them if found.

Upgrade Engagement by publishing the update. Refer to the knowledge base article Installation

Guidance for CCH® ProSystem fx® Engagement for more details.

Note: After upgrading versions of Engagement, it may be necessary to install the latest Tax

Grouping Update Wizard.

Manually Installing the Workstations

Microsoft

SQL Server

requires that all folders containing SQL databases not be compressed.

It is recommended to check for compressed folders and decompress them if found.

If the user is in the field and a synch was not performed with the Office Server, binder packages

should be taken of all binders.

Close Microsoft

Word, Excel

, and Outlook

Close any additional programs.

Disable virus scanning software.

Upgrade Engagement.

Note: After upgrading versions of Engagement, it may be necessary to install the latest Tax

Grouping Update Wizard.

Appendix C: Installing CCH ProSystem fx Engagement on a SQL Cluster • 50

INSTALLING CCH PROSYSTEM FX

ENGAGEMENT ON A SQL CLUSTER

This section is a reference to the steps necessary to install Engagement on a SQL Cluster. Two

modules are supported on the SQL Cluster, the CCH ProSystem

Engagement Administrator and

Terminal Services modules. Both modules can be installed on the same cluster or they can be

installed individually.

Before Beginning the Installation

Review the contents of this guide for optimal configuration.

Review the Release Notes and the knowledge base article Installation Guidance for CCH®

ProSystem fx® Engagement for important information regarding the latest version of

Engagement. This information includes the latest supported service packs and software.

Synchronize all binders to the CFR and check in workpapers during this process.

Manually perform backups of all office servers. This includes the SQL Databases and the

workpapers.

Installing the Administrator Module

The Microsoft

Windows Server

Cluster should be installed and configured.

Microsoft

SQL Server

2017, SQL Server

2016, orSQL Server

2014 should be installed as

a failover instance tothe cluster.

Set the preferred owner of the SQL Instance to the node currently logged into for installation.

Set the Failover property of the SQL server

to "Allow failback immediately."

Create the Task Scheduler resource as a generic service.

Ensure the SQL Agent cluster resource is offline.

Note: If the SQL Agent is not offline, you may receive error messages and may not be able

to complete the install. Refer to

Chapter 4: Deployment Planning - SQL Server Agent

page 24 for more information.

Open an Elevated Command Prompt.

Appendix C

Appendix C: Installing CCH ProSystem fx Engagement on a SQL Cluster • 51

Run the msiexec with command line with parameters for

ADMIN_CLUSTER="1"

CLUSTERDIR="DRIVE FOR SQL"

Example: msiexec /i "C:\CCH ProSystem fx Engagement.MSI" ADMIN_CLUSTER="1"

CLUSTERDIR="G:\PFXEngagementData\" ENGSQLCLUSTER=ENGAGEMENTSQL

If this is an upgrade, add parameter

CLUSTERUPGRADE = “1”

Example: msiexec /i "C:\CCH ProSystem fx Engagement.MSI" ADMIN_CLUSTER="1"

CLUSTERDIR="G:\PFXEngagementData\" ENGSQLCLUSTER=ENGAGEMENTSQL

CLUSTERUPGRADE = “1”

Select the Admin Feature.

10.

Complete the Installation.

11.

Set share permissions in a way that administrative users using the CCH ProSystem

Engagement Administrator have write access to the x:\PfxEngagementData\Admin Share.

Note: Failure to perform these steps can result in impaired functionality in the

Administrator.

12.

Fail-over to the next node.

Repeat Steps 1 – 10.

13.

Open Server Manager.

14.

Go into the Failover Cluster Manager.

15.

Create the following resources as generic services:

PfxEngDesktopService

PfxSynPftService

16.

Copy the backup files of the office servers you created to the cluster. Refer to Step 4 in

Before

Beginning the Installation

on theprevious page

17.

Launch the CCH ProSystem

Engagement Backup and Restore Utility.

18.

Perform a Full Restore using the backup files copied in Step 16.

Installing the Terminal Services Database Module

The Microsoft

Windows Server

Cluster should be installed and configured.

Microsoft

SQL Server

2017, SQL Server

2016, orSQL Server

2014 should be installed as

a failover instance tothe cluster.

Set the preferred owner of the SQL Instance to the node currently logged into for installation.

Set the Failover property of the SQL server

to "Allow failback immediately."

Create the Task Scheduler resource as a generic service.

Ensure the SQL Agent cluster resource is offline.

Appendix C: Installing CCH ProSystem fx Engagement on a SQL Cluster • 52

Note: If the SQL Agent is not offline, you may receive error messages and may not be able

to complete the install. Refer to

Chapter 4: Deployment Planning - SQL Server Agent

page 24 for more information.

Open an Elevated Command Prompt.

Run the msiexec with command line with parameters for

TSDB_CLUSTER ="1"

CLUSTERDIR="DRIVE FOR SQL"

Example: msiexec /i "C:\CCH ProSystem fx Engagement.MSI" TSDB_CLUSTER="1"

CLUSTERDIR="G:\PFXEngagementData\" ENGSQLCLUSTER=ENGAGEMENTSQL

Select the Terminal Services Database Module.

10.

Complete the Installation.

11.

Set share permissions in a way that users using the CCH ProSystem

Engagement Terminal

Services Client have write access to the x:\PfxEngagementData\WM\Workpapers share on the

cluster.

Note: Failure to perform these steps can result in impaired functionality in the Terminal

Services Client.

12.

Fail-over to the next node.

Repeat Steps 1 – 10.

13.

Open Server Manager.

14.

Got into the Failover Cluster Manager.

15.

Create the following resources as generic services.

PfxEngDesktopService

PfxSynPftService

Installing the Administrator and Terminal Services Database

Module Together

The Microsoft

Windows Server

Cluster should be installed and configured.

Microsoft

SQL Server

2017, SQL Server

2016, orSQL Server

2014 should be installed as

a failover instance tothe cluster.

Set the preferred owner of the SQL Instance to the node currently logged into for installation.

Set the Failover property of the SQL server

to Allow failback immediately.

Create the Task Scheduler resource as a generic service.

Ensure the SQL Agent cluster resource is offline.

Appendix C: Installing CCH ProSystem fx Engagement on a SQL Cluster • 53

Note: If the SQL Agent is not offline, you may receive error messages and may not be able

to complete the install. Refer to

Chapter 4: Deployment Planning - SQL Server Agent

page 24 for more information.

Open an Elevated Command Prompt.

Run the msiexec with command line with parameters for:

ADMIN_CLUSTER=”1”

TSDB_CLUSTER="1"

CLUSTERDIR=”DRIVE FOR SQL”

Example: msiexec /i "C:\CCH ProSystem fx Engagement.MSI" ADMIN_CLUSTER="1"

TSDB_CLUSTER="1" CLUSTERDIR="G:\PFXEngagementData\"

ENGSQLCLUSTER=ENGAGEMENTSQL

Select the Admin and Terminal Services DatabaseModules

10.

Complete the Installation.

11.

Fail-over to thenext node.

Repeat Steps 1 – 10.

12.

Open Server Manager.

13.

Go into the Failover Cluster Manager.

14.

Create the following resources as generic services.

PfxEngDesktopService

PfxSynPftService

15.

Copy the backup files of the office servers you created to the cluster. Refer to Step 4 in

Before

Beginning the Installation

on page 50.

16.

Set share permissions in a way that users using the CCH ProSystem

Engagement

Administrator have write accessto:

Administrative users. "x:\PfxEngagementData\Admin" share on the cluster.

All users. "x:\PfxEngagementData\WM\Workpapers" on the cluster.

Note: Failure to perform these steps can result in impaired functionality in the

Administrator and in the ability for users to login from Terminal Services Client.

17.

Launch the CCH ProSystem

Engagement Backup and Restore Utility

18.

Perform a Full Restore using the backup files copied in Step 15.

Appendix C: Installing CCH ProSystem fx Engagement on a SQL Cluster • 54

Performing a Repair of CCH ProSystem

Engagement on a SQL

Cluster

Performing a repair of CCH ProSystem

Engagement on the SQL Cluster is not supported. You

must uninstall and reinstall CCH ProSystem

Engagement on the cluster following the installation

instructions in this appendix.

Performing a Modify of CCH ProSystem

Engagement on a SQL

Cluster

To perform a modify installation on the cluster, run a command via the command line with

MsiExec.exe. Performing a modify installation from the Windows® UI will not be allowed. The

following command should be used:

MSIEXEC /i <path to msi> ADDLOCAL=CLUSTER_ADMIN,CLUSTER_TSDB,ADMIN,TSDATABASE

ADMIN_CLUSTER="1" TSDB_CLUSTER="1" CLUSTERDIR=<Directory on the cluster to install>

ENGSQLCLUSTER=<name of the sql cluster> /PASSIVE

Example: MSIEXEC /i "C:\CCH ProSystem fx Engagement.MSI" ADDLOCAL=CLUSTER_

ADMIN,CLUSTER_TSDB,ADMIN,TSDATABASE,CDIMAGE ADMIN_CLUSTER="1" TSDB_

CLUSTER="1" CLUSTERDIR="G:\PFX ENGAGEMENT DATA"

ENGSQLCLUSTER=SQL2012ENG /PASSIVE

Uninstalling CCH ProSystem

Engagement on a SQL Cluster

To uninstall CCH ProSystem

Engagement on a SQL Cluster, do the following:

Close all programs on your computer.

Select Programs and Features from your computer's Control Panel.

Select CCH ProSystem

Engagement from the list and click Remove to display the

Welcome

dialog.

Click Yes on the confirmation dialog.

Appendix D: Additional Resources • 55

ADDITIONAL RESOURCES

Additional resources that will help with the evaluation and deployment of CCH ProSystem

Engagement:

CCH ProSystem

Engagement Documentation

Installation Guidance for CCH® ProSystem fx® Engagement

CCH ProSystem

Engagement Customer Support

Training

Training and Consulting

Microsoft

Terminal Services Deployment Guide

Product Life Cycle

Infrastructure Planning and Design – SQL Server

Infrastructure Planning and Design – Terminal Services

Microsoft

SQL Server

Edition Comparison

SQL Clustering with 2014

SQL Clustering with 2016

SQL Clustering with 2017

Appendix D