Question:
How to configure K2 to use an SQL Database on a different physical server than the server used to run K2.

Answer:
Pre K2.net 2003 SP1 Version. The installation application on Pre SP1 versions of k2.net 2003 did NOT allow remote creation of the K2.net 2003 Transaction and Log Databases. To Install K2.net 2003 Pre SP1 in a distributed SQL environment follow the steps below:

1. Firstly run the K2.net 2003 Installation on the Server hosting the SQL Databases
2. Under the custom options of the installation deselect all the components expect for the K2.net 2003 Transaction and Log Database options.
3. Complete the installation.

Note: The installation will create the Transaction and Log database.

4. Run the K2.net 2003 Installation on the Server hosting the K2.net 2003 Server.
5. Under the custom options deselect the K2.net 2003 Transaction and Log Database options, and complete the installation.

Note: The installation will request Database configuration setting, complete the settings to point to the existing Databases create in step 1 to 3.

K2.net 2003 SP1. The installation application on K2.net 2003 SP1 allows you to create the K2.net 2003 Transaction and Log Databases on a remote Server. To Install K2.net 2003 SP1 in a distributed SQL environment follow the steps below:

1. Run the K2.net 2003 Installation on the Server hosting the K2.net 2003 Server.
2. Make sure that the K2.net 2003 Transaction and Log Database options are selected.
3. The installation will request the Database Server settings, complete the settings to point to the remote Server hosting SQL Server.
4. Complete the Installation.

See Also. Installation documentation included on the K2.net 2003 Installation disk.

Question:
K2.net 2003 Server does NOT contain any state information, is this correct?

Answer:
Yes this statement is correct; all process state is kept in the K2.net 2003 Transaction database to minimize the impact of a system failure. Furthermore this state makes use of the transactional ability of SQL Server, to ensure that no transactions are lost.

Question:
Recommendations for SQL configuration. We discussed both K2 servers connecting to one set of K2 databases. Do you recommend splitting the one set among the two active SQL servers or have them on one SQL server?

Answer:
The recommendation for SQL topology depends on the nature and structure of the solution. If the solution requires extensive reporting, or if there are numerous concurrent users utilizing the K2.net Workspace, it is suggested to separate the Log/Reporting environment (K2Log) from the Transactional environment (K2). Additionally, the amount of data being logged (and potentially reported on) will also impact the deployment decision.

Question:
Load balancing recommendations for the two K2 servers. We are looking at utilizing BIG IP and 3DNS from F5. Is there internal load balancing to your product? Do you recommend your internal load balancing over utilizing the F5 products?

Answer:
K2.net 2003 Server does not make use of internal load balancing but rather rely on external load balancing mechanisms. Extensive testing has been done on Microsoft Network Load Balancing (NLB) and is therefore recommended. We do not have extensive expertise with 3rd party load balancing applications, however believe these should work. It is recommended that proper testing is done before any implementation.

Question:
What is the local disk space requirement/recommendation on the K2 servers?

Answer:
A default K2.net Installation will require approximately 50Mb of hard drive space. This, however, only caters for the default (clean) transaction and log database, which will grow over time. The transaction database will grow as new process definitions are published (exported), however this only requires nominal storage. The transaction database will also grow depending on the number of running processes, however these processes are removed from the transaction database upon completion.

The log database will grow depending on the level of data being logged to the database, and the number of processes instances. The level of logging is based on the design of the actual process, the number of activities, data fields, XML fields, events as well as the number of workflow participants being used in the process will have a direct impact on the data growth in the log database.