< class="prominent-subhead ">

Best Practices for general K2.net implementations, re-installs, and integrated components

This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.

This document is intended to give a consolidated list of information contained in various K2.net resources: Online resources (Microsoft sites, K2.net KnowledgeBase, K2.net Forum, FAQs, and other technical discussion groups), trends and experience from K2.net support teams, and scenarios encountered in the field by K2.net training teams and consultants.

This article is intended to provide a list of information and resources. This includes online resources (Microsoft sites, K2.net Knowledgebase, K2.net Forum, FAQs, and other technical discussion groups), trends and experience from K2.net support teams and scenarios encountered in the field by K2.net training teams and consultants.

Topics covered in this article include the following
  • Network resources
  • Operating systems (Windows OS)
  • Systems interactions (e.g. SharePoint, BizTalk, SQL Reporting Services, Active Directory, legacy systems, et al)
  • Licensing considerations
  • Project deployment and planning
  • How the K2.net footprint integrates into the organizational infrastructure today and valuable considerations to in the near future
Intended Audience
This document is intended to equip both technical and non-technical staff with a list of considerations relevant to K2.net 2003 installations.
This article is by no means intended to be a detailed analysis of systems and platforms, nor a training guide or step-by-step instructions on implementing and supporting K2.net 2003 installations.
The article is an overview of topics to be considered when planning to integrate K2.net 2003 with an existing network.
Additional Information
This document may mention 3rd Party Applications and Products. Where relevant the K2.net 2003 Product Development, Quality Assurance and Support teams endeavor to thoroughly test and verify that 3rd Party applications and products may integrate without causing data loss or system issues. However, it is strongly advised that when installing another product to either work in conjunction with K2.net 2003 or one which may impact on the network environment either as a whole or on resources which K2.net 2003 depends it is strongly advised that you refer to the manufacturer's documentation for more thorough analysis and understanding of their products. There are no expressed or implied warranties and to install a third party product is entirely at the risk of the user.
K2.net Resources
Below is a listing of alternative documentation resources to review that may be helpful or provide details on specific functionality.

K2.net Portal

K2.net Product software, components, Service Packs, Help files, utilities.Available to K2.net customers and partners with active Maintenance Contracts.

K2.net Knowledgebase

K2.net Technical information, Training, and Step-by-Step instructions.Available to K2.net customers and partners with active Maintenance Contracts.

K2.net Forum

Online discussions and collaboration regarding K2.net and integrated applications and components.Available to the public (but most often K2.net customers and partners).

Microsoft MSDN Library

Microsoft resource library including discussions, white papers, and Microsoft product information.Anyone.


Excellent resource for researching common issues spanning applications, development platforms, and technologies.Anyone.

Project Management and Planning
K2.net 2003 is seldom deployed by the end user organization. In most cases, a K2.net 2003 Installation is implemented using an Integration Partner and or an IT Consultancy. A project coordinator would be appointed by the Implementation Partner to ensure that K2.net 2003 is implemented correctly.
Organizations all have their preferred methodologies of project management; a solid and well planned project is essential to avoid unnecessary delays and provide better long term stability. A well implemented K2.net 2003 Installation will enable the organization to successfully leverage their existing environment to improve their business efficiency and productivity.


Project Cost, Schedule, Performance (CSP)
Many deployments are delayed due to unanticipated approval processes and are complicated by the separation of duties across IT functions.
  • Specialization:  In large IT organizations, delays may occur due to specialization of skills within an organization - a single person or team is responsible for each of several technical areas ("Specialized").
  • Generalization: In smaller IT organizations, a single person or team may control multiple functions in the IT organization. This 'one stop shop' for handling technical support may result in faster response to IT requests. For K2.net, this represents a single person or team overseeing nearly all of the resources involved with K2.net (i.e. the Domain Administrator, SQL Server Administrator and K2.net Administrator).
Typically, the more people/teams involved, the slower the response/resolution. This also applies to conditions where K2.net Support teams are involved and need to engage with the systems administration teams. Examples of this may include where a single person/team becomes a bottleneck to getting necessary changes made.
Change Control
Many organizations have formal procedures for making changes to systems or Configuration Management systems. Making changes to systems is accomplished using an ECP (Engineering Change Proposal) process to firstly suggest the change and then secondly either one or more persons in authority need to validate the changes or sign them off. This is often a time consuming and lengthy process as each change is treated as a separate ECP process requiring individual sign off for each ECP.
Environments may include Development, Staging, and Production. If such control systems are in place, make sure the procedures are known, understood, and planned for in the project and deployment timelines.
It is critical for environments nearest to the Production system (i.e. QA or Staging) to mirror the Production (Live) environment as closely as possible. The more disparate the systems are, the more likely unexpected problems will be encountered when deploying the system to Production.
Naturally, the closer each system is to one another (Development/QA, QA/Production), etc, the lower the risk when deploying to the next subsequent system. Ideally, all stages should be the same in configuration. Since the cost can be prohibitive to replicate environments, other means can be used to develop environments which mirror the final production environment. Microsoft Virtual PC is an excellent means where multiple PCs can be run on a single hardware platform, provided the hardware platform has sufficient RAM to host multiple virtual hard drives.


Similarly, the more testing environments employed (Dev, QA, UAT, Production, etc.), the greater the opportunities for discovering conditions that may affect deployment timelines and eventual systems performance. Another advantage of using a virtual environment is that when a problem with an installation is discovered, the virtual hard drive can be discarded with no affect to the host system.
The following items should be considered prior to deploying K2.net 2003 on the Production network
  • Resources aligned for migrating, testing, and validation of results
  • Approvals secured
  • Support Teams notified and ready
  • Stakeholders notified
  • Systems prepared (hardware, software, login accounts, etc.)
  • Licensing conditions, limitations, settings, and differences between environments
  • Schedule conflicts identified and planned
  • Contingency plans defined
  • Systems Validation Tests defined
  • Documentation and deliverables for operational support of the system prepared
To ease migrating K2.net processes across environments (Development, Testing, QA and Production), the use of String Tables may reduce the time it takes to dynamically configure processes for each system.
If deploying into a Production environment, process instances and data from previous environment tests may not be desired to be retained. In such cases, a K2.net cleanup utility was developed that allows for the removal of process instances from K2.net systems. Refer to the K2.net Portal for more information.
Performance and Scaling Considerations
There are many factors which determine the performance of individual K2.net 2003 installations. Since each installation is unique, therefore capturing all and any factors impacting on the K2.net performance is very difficult.
Such factors may include (but are not limited to):
  • Single- or multiple server architecture
  • Network Architecture
  • K2.net process complexity
  • Destination User counts
  • Process longevity. The length of time a process is open
  • Amount and logic of custom code
  • Integration with other systems (SharePoint, InfoPath)
  • K2.net, IIS, database (etc.) server specifications and configurations
  • Network bandwidth and latency
  • Custom System Integration
  • Legacy System Integration
The K2.net 2003 QA and Support Teams endeavor to provide partners and clients with the necessary resources and information to assist them so far as is possible to optimize their installation. Refer to future K2.net Knowledgebase articles and K2.net Forum postings for planning/estimating resource requirements information.
Testing and Validation
Test/Validation plans are standard IT deployment project deliverables. Testing is critical to reduce the chance of unexpected behaviors during deployment. Test plans should be repeatable across all environments they are applied to.
Ensure the environment is designed and configured to handle the testing to be conducted (i.e. memory, disk space, and the number of licenses is adequate for testing scenarios).

Operational Support
One of the most often overlooked factors in deploying IT projects is the support and administration of the system after it is initially deployed (goes from a "Project" to "Operation").
Topics to consider include:
  • Who to contact and how, including submitting support requests
  • Hours of support and handling after hours requests and special requests
  • Escalation process
  • Systems outage schedules
  • Handling of enhancement requests
  • Maintenance of user accounts, environments, resources
K2.net should also be configured with or prepared with:
  • K2.net Service Manager's 'Error Profiles' to troubleshoot problems
  • Enable K2.net Server Trace Logs to capture K2.net events
K2.net Portal Accounts
Partners and Clients who may need to access K2.net resources on line or submit Support Requests can request login credentials for their own K2.net Portal Account. Those who currently have a K2.net Portal account in the organization may submit a request for a new Portal user account.
It is not advised that accounts be shared between users as this may cause delays in resolving important issues.


K2.net Licensing
K2.net licenses are machine-specific. A Machine/System Key is generated during the installation. The Machine/System Key is specific to the machine and is required for obtaining any/all K2.net License Keys.
If you require an immediate K2.net Server License, submit a request for a Trial License Key on line (which will also require the Machine/System Key for the request to be successful). The automated system will provide you with a Trial License key immediately, and a License key in line with your license purchased will then be issued shortly (please refer to your contract or support documentation with regards to specifics around the time lines involved in the issue or reissue of license keys) thereafter.
For development and testing systems, a K2.net Managed User Licensing model is common - however, depending on the number of users defined in the license, testing may be restricted due to not enough user licenses being available. Adjust the testing scenarios according to the licensing limits or request additional user licenses.
K2.net Installation Considerations
This section discusses information regarding new K2.net 2003 installations for any given organization. Upgrades are discussed in a separate section of this document.
Installation Process
It is highly recommended that all installation and configuration steps be documented as they are performed. One of the simplest ways to document this information is to capture screen shots of each step in the installation process.
It is highly recommended to install the most current version of K2.net 2003 when performing a new installation.
Always refer to the K2.net 2003 Installation documentation for software and hardware compatible a listing of Operating System (OS) and Service Packs, SQL Server, IIS, and other components (SharePoint, InfoPath, Visual Studio, etc.) and K2.net 2003 versions prior to beginning the installation.
Accounts and Permissions for System Resources
The following table describes some common user accounts, resources, and associated permissions required for K2.net to function properly.
Folder PermissionsC:\Windows\Microsoft.Net\Framework\v1.1.4322\Temporary ASP.Net
  • Authenticated Users
  • Authenticated Users
C:\Program Files\K2.net 2003\bin
  • Service account K2.net Server is running under
C:\Program Files\K2.net 2003\bin
  • Windows Integrated: Domain User Account
  • SQL Authentication: SQL User Account
K2.net Database: DBO rights
K2Log Database: DBO rights
K2.net Service
  • Domain User account, - or -
  • Local User account*
- Full control on K2.net Server
- Delegation rights
K2.net Workspace
  • SQL User Account, - or -
  • Domain User Account
See Folder permissions entries listed above
K2.net Workspace Web Service
  • SQL User Account, - or -
  • Domain User Account
See Folder permissions entries listed above
IIS K2Application Pool
  • Domain User Account, - or -
  • Local System Account
  • Network Service Account*
See Folder permissions entries listed above
* Not recommended. The account may lack the ability to reliably to delegate credentials across servers/systems.

K2.net Server
Refer to the K2.net Installation documents for software and hardware specifications.
K2.net Studio
This is not typically installed on the K2.net 2003 Server itself, but is installed on client machines for development and testing of K2.net 2003 Processes.

The "NET Framework 1.0 SDK" is required to be installed on the machine to use K2.net Studio. If web form development is to be done locally then IIS must be installed along with Visual Studio 2003. IIS is not enabled by default on Windows XP operating systems. Development against a remote IIS Server is possible. Refer to K2.net 2003 Studio software requirements for additional requirements.
K2.net Service Manager

Do not use individual user accounts to run services under. Ensure that any and all services have their own accounts.

Often, K2.net processes and/or services are installed using the developer's login account. However, once they leave the project their account is often disabled (i.e. if a contractor) or removed from the domain, causing systems and processes to fail.

Use an account that is well controlled and managed to avoid interruptions to services.

Transaction ("K2") and Log ("K2Log")
These can be installed from a remote server and can be clustered for increased performance. Retain the default database names unless there is a compelling reason to change the names.
K2.net Archive Components
This K2.net utility has been developed by K2.net technical teams to reduce the amount of data in the K2.net log database, improving performance and reducing database disk space consumption.
K2.net Exchange Components
MAPI components or Microsoft Office needs to be installed on the K2.net server. The K2.net Service account needs to be granted permissions (like a standard email user) on the Exchange server in order to access the required Exchange scheduling features.
K2.net Workspace
Although some customers prefer to write their own custom workspace, it is recommended to make sure the default K2.net Workspace is working prior to deploying custom workspaces. Having a functioning K2.net Workspace is valuable for troubleshooting K2.net Worklist issues and using the K2.net ViewFlow diagram in determining where problems reside.
When separate servers are used to host K2.net, IIS, SharePoint, etc., credentials may not be passed correctly between the systems, usually causing "NT AUTHORITY/ANONYMOUS LOGON" or "401 - Access Denied" messages to be displayed in the Workspace if not configured properly. Understand Kerberos - it is required when passing credentials across more than one server (when 2 or more 'hops' are involved).
See the KnowledgeBase article KB000123 - Basic Guide to enabling a K2.net 2003 Implementation to use Kerberos Authentication for more information.
The K2.net Workspace's "ViewFlow" diagram requires .Net Framework 1.1 to be installed on any client wishing to view the K2.net Process diagram. Also, test the K2.net 2003 Workspace from a local browser on the K2.net Server and from a remote client machine.
User Managers ("UMs")
K2.net 2003 offers support for Active Directory, but any LDAP-compliant user manager can be used.

A single User Manager is commonly used (AD being the default), however multiple UM's can be combined if necessary. Third-party vendors and K2.net Knowledgebase articles exist on how to implement multiple UM models for use with K2.net 2003.

Single Server vs. Multiple Servers
The most common problem encountered in configuring K2.net involves Windows Authentication requirement differences between running K2.net 2003, IIS, and SharePoint on a single or multiple servers. Single Server configurations can use NTLM since no credentials need to be passed from one server to another server. Multiple Server configurations most often require Kerberos authentication via the setting of SPNs (Service Principle Names).
  • If you are installing K2.net, IIS, and/or SharePoint on separate machines, be very familiar with Kerberos and how to set SPNs and delegation.
  • Neither K2.net 2003 nor Microsoft developed the Kerberos standard. Microsoft implemented the M.I.T. standard and K2.net depends on it for running on the Microsoft platform.
  • Many latent system security issues may be unearthed after installing K2.net. Such conditions probably existed prior to installing K2.net but weren't realized until the integration of the systems by K2.net.
It is imperative that the Installer is familiar with how each system interacts with adjacent systems, the send/receipt interfaces, and the format of the transmissions passed between them (i.e. XML, error handling involved, protocols, whether the contents are passed in clear text or encrypted, etc.).
K2.net Integration Considerations
This section describes general information regarding integration of various applications and utilities with K2.net 2003.
Windows Applications
When upgrading applications integrated with K2.net 2003, ensure to research both the K2.net 2003 and the new application's compatibility and support information.

Ensure to test the packages thoroughly prior to implementation into the production system.

Windows Security
Security is both a sensitive and an important issue. Kerberos was developed by MIT and Microsoft implemented it into their products owing to its effectiveness. Kerberos has become an industry standard and is well integrated into a number of product offerings. It is important therefore that Network administrators and Installers are familiar with the theory and practice of administering a network using Kerberos.
Active Directory
K2 .net 2003 relies heavily on AD for authentication and Task routing. Changes to AD accounts and groups could affect K2.net processes and therefore IT handling of AD Users and Groups should be understood when designing K2.net processes. Although K2.net is designed to handle dynamic changes to AD users and groups, Active Directory Administrators should be made aware of the subsequent impact to workflow processes when making unusual or significant changes to AD Users and Groups.
SQL UM can be used when users are not a member of the organization's domain (Active Directory can not be used to authenticate users that do not have accounts in the domain). The SQL UM account can then be handled in K2.net Process design logic.
SharePoint and Windows SharePoint Services (WSS)
When installing SPS and or WSS it is strongly recommended that K2.net 2003 Workspace not be installed on the same web site. There is no known compelling reason to do so that justifies the potential administrative problems it causes.

When running the K2.net SP2a installation for the K2.net SPSWebService, another K2.net component must be selected (e.g. K2.net Studio). (This will be resolved in the next release of K2.net.)

If you have applied the SPS SP2 patch you will need to run a hotfix provided by K2.net. The SPS SP2 patch changes the way SPS events are handled therefore causing K2.net process activities that worked prior to SPS SP2 to stop working.

Note: The Hotfix is not required for K2.net 2003 with SP3 onwards.
InfoPath's document format is XML and the XML is passed to K2.net 2003. Each Destination User for a K2.net task uses a separate copy of the original InfoPath document which requires careful analysis and understanding of the business processes and handling of the completed InfoPath forms.

Be cautious when InfoPath activities occur in parallel; due to the way InfoPath data is stored, there will be times when previous InfoPath data is overwritten by subsequent InfoPath submissions when two InfoPath activities are running in parallel. Make sure that the InfoPath document and the K2.net process remain synchronized.

If BizTalk is to be integrated with K2.net 2003, make sure the BizTalk installation is fully operational and fully functional prior to integrating it with K2.net.
IIS requires good planning and the person responsible for implementation must be familiar with system accounts, user accounts, web sites, application pools, permissions to folders and other environment resources. Involve the IIS administrator when planning the K2.net installation, configuration, and web application design.
Host Headers and Ports
The person responsible must be familiar with using host headers and ports and how to reference them properly when setting SPNs for Kerberos implementations.
The settings contained in the MetaBase.xml file must be accurate when implementing Kerberos.
See the KnowledgeBase article KB000123 - Basic Guide to enabling a K2.net 2003 Implementation to use Kerberos Authentication for more information.
Network Architectures
Network Infrastructure and Architecture will affect how K2.net, IIS, Active Directory, Visual Studio, Exchange, Office (including Outlook), SharePoint, CMS and BizTalk are installed and function. Proxy servers, multiple domain controllers, firewalls, and network policies may also affect how these applications or services function independent of each other and how they interact with each other.
Network Changes
To complicate troubleshooting, any of these factors may be altered or re-configured without warning or unusual conditions (i.e. increased network traffic) begin affecting the networking environment, causing once well-behaving systems to begin exhibiting inconsistent behavior. To reduce the impact of such conditions, it is recommended that these conditions be understood and it be known how they may affect K2.net and related systems.
DNS settings
DNS settings (or lack thereof) have caused numerous support requests. It is VERY important that DNS is setup and functioning correctly and reliably 100% of the time. DNS issues usually result in K2.net Server being unable to resolve users and/or user email addresses against Active Directory.
Delegation (Full or Constrained)
Delegation is required on Windows 2003 Servers to impersonate other servers/users/services.
K2.net Upgrade Considerations
This section describes general information regarding upgrading existing installations of K2.net 2003 in an organization. New installation considerations are discussed in a separate section in this document.
Operating Systems
See installation documentation for supported OS platforms.
Integrated Systems/Processes
If upgrading applications integrating with K2.net, research both K2.net and the application's compatibility and supportability information. Also test thoroughly prior to implementation into the production system.
K2.net Databases - Transaction ('K2') and Log ('K2Log')
K2.net databases may require schema alterations during an upgrade.

Always back up existing K2.net K2/K2Log databases prior to beginning a K2.net upgrade. Customization of the K2.net 2003 databases is not supported by K2.net technical Support teams. Additionally, in cases where customizations have been implemented, these may be lost when a K2.net upgrade is performed.

Re-installing K2.net over an existing K2.net installation
This section describes general information regarding reinstalling K2.net components on systems with K2.net components already installed on them.
K2.net Installation Settings
It is highly encouraged that previous configuration settings be used during subsequent re-installs of K2.net unless the settings are believed to be the reason for the re-installation (see section on K2.net Installations for recommendations on documenting the settings).

Ensure you have a copy of the current K2.net Server License key prior to re-installation since you will be asked for a valid License key during installation. This License key can be obtained from the K2.net Server Properties dialog in K2.net Service Manager.

Occasionally K2.net and SharePoint may conflict over use of the IIS default web. Test the settings thoroughly prior to implementation into the production system.
Uninstalling SPS may not always thoroughly remove all traces of the application from the Windows Registry or other operating system areas. Be aware of any additional scripts or utilities required for a clean uninstall.
K2.net Databases - Transaction ('K2') and Log ('K2Log')
When upgrading K2.net, de-select the databases on the first installation screen, otherwise the installer will attempt to create new databases with the same names (which will generate an error and halt the installation). An option is presented.
Troubleshooting/Monitoring Tools and Utilities
This section describes some common utilities and applications that can be helpful in tracking system conditions, application events, and other information that can be used in supporting K2.net and related systems/resources.
A limitation of using these utilities is that they all operate independently of the other (not integrated), so manual synchronization and review of multiple reports is required.
Third Party (non-K2.net) Utilities
Note: K2.net Support did not develop and does support these tools. They are only for your reference and are used entirely at the risk of the user. Contact the respective companies for support and additional information.
PerfMonStandard monitoring tool installed by default.
Event ViewerStandard system events available by default.


A third-party utility for tracing application installation and local resource calls by applications.
NetMonMicrosoft application available via Add/Remove programs for tracing network activities (machine to machine). It is not installed by default and is available within the IIS install options.
SQL AnalyzerCaptures SQL Server connections and requests including SQL statements / Stored Procedures executed/called.
Network Packet monitoring ("sniffer")Network administration hardware/software utilities for capturing network traffic/package contents. Implementation varies by organization.
Authentication diagnostic tool "wfetch.exe"Authentication methods used by client machines for access server resources/environments.
Active Directory Testing "adsvw.exe"Active Directory testing utility. Utility available in a Windows SDK. Google this term for more info/resources or go to one of the following links:
Other Microsoft Resources / UtilitiesThe Microsoft Product Support Reporting Tool facilitates the gathering of critical system and logging information used in troubleshooting support issues. Microsoft Downloads
K2.net-Centric Utilities
Below is a list of K2.net application options to facilitate troubleshooting.
Running K2.net Server in debug mode

K2.net Knowledgebase Article KB000065

ADUM debugging/tracingContact K2.net Support for K2.net SP2/2a Debug version of ADUM.dll and instructions for implementing it
K2Smartforms.dll debug versionCaptures calls made by K2.net SmartForm controls.