IT:AD:K2:Environment:Installation

/*

*/

Install the following before installing K2:

  • MSDTC has to be setup:
    • Ensure running
    • Start\Component Services
    • Expand Console Root/Component Services/Computers/My Computer/Dis…TC/Lcoal DTC/Properties
    • Network DTC:Checked
    • Allow Remote CLient:Checked
    • Allow Inbuond:Checked
    • Allow Outbound:Checked
    • Alow incoming Caller Authentication Required:true
  • Firewall.
    • First connection to K2 Workspace will state actively refuse it.
    • Create a TCP Port 5252 rule. That

Set up the following before installing K2:

  • Groups required:
    • K2-Grp-Admins
    • K2-Grp-Deployers
  • User accounts required:
    • K2-Usr-Admin
      • Member of K2-Grp-Admins
      • K2-Usr-Deployer
      • Member of K2-Grp-Deployers
      • Note:
        • Users that will deploy SharePoint Workflow Integration processes must be part of the following groups:
          • Farm Administrators group
          • Site Collections group
        • TODO: Expand

      * Service Accounts required:

    • K2-Svc-WS:
      • a K2 Svc Account to run the K2 Windows Service.
      • Member of:
        • TODO: Local admin?
        • Member of SharePoint Site Collection Administrators group for all Site Collections that will be using K2.
      • K2-Svc-AP:
      • a K2 Svc Account to be the K2 admin WebSite's AppPool Identity.
      • Member of:
        • TODO: Any others?
      • K2-Svc-WS-xxxx:
      • A windows svc account for a Windows Service that may start workflows.
      • K2-Svc-AP-xxxx:
      • A svc account for the AppPool of an MVC website that will start/stop activities.

      ### DNS Entries ###

Note:

  • Only use physical Host (A) records in your domain. Alias (CNAME) records may be tempting but there is a known Kerberos delegation problem between an Internet Explorer client and a Windows server that resolves CNAME records to Host A records, causing authentication to fail (see Microsoft KB911149).
  • Use Host (A) records like aliases:
    • Use a Host (A) record that points to your active Web server.
      • The web server should be configured to use a host header that matches your service principle name (SPN) Kerberos record.
      • During failover and maintenance scenarios, you update your Host

      (A) record to point to the IP address of your standby server. This precludes any Active Directory changes and subsequent replication wait times, and has the added benefit of not invalidating active Kerberos tickets.

Set up the following before installing K2:

Optionally, create a HOSTS File Entry:

127.0.0.1 k2.local

In an AD hosted environment, Browsers get their DNS records from AD, and ignore the HOSTS file (although Consoles do use it, so PING will continue to work, therefore things can fake out novices), unless you specically remove it from the list in the Browser:

IE / Menu Internet Options / Connections / LAN Settings / 

* Use a proxy server: true
* Address:...
* Port:...
* Click Advanced...
* Enter Exceptions: 'k2.local' and '*.k2.local'

The WS service account that runs K2 SmartObject Services requies access to the http namespace that will be hosting endpoints as well as cross-domain policies.

  • Easy (Dev environment):
    • Use lusrmgr.msc in order to add the K2-Svc-WS account to the Local Admin group.
  • Prod:
    • use the following command line:

Example:

netsh http add urlacl url=http://skydev01.DEV.local:8888/ user=DEV\K2-Svc-WS

CORP:

Web:

For Dev stations, if installing Sharepoint and K2 on the same box, install SharePoint after installing K2 is better.

Observed behavior is that if SharePoint is installed first, K2 then blows out small stuff. Themes stopped working, popups stopped working, etc.

Check that K2 server is running:

SC QUERY "K2 Blackpearl Server"
SC START "K2 Blackpearl Server"

Navigate to: http://k2.local:81/workspace/Navigation/Navigation.aspx

After installing K2, create a baseline backup of the K2 databases.

Access is typically not restricted until permissions have been assigned.

Therefore, as soon as the K2 server is installed and verified to being property configured, lock it down by assigning rights to the server.

Server Rights

Server (as compared to Proccess) Rights control:

  • who can deploy processes and SmartObjects to the server,
  • who can see items such as:
    • the Report Designer,
      • the Notifications and Custom Event designer,
      • the Management Console in K2 Workspace.

      This is done using the options in K2 Workspace and the Management Console.

  • See: User

The choices are:

  • Admin: full administrative rights on the K2 server
    • eg: K2-Usr-Admin (server rights cannot yet be assigned to Groups).
  • Export: only can export (deploy) to the K2 Server
    • eg: K2-Grp-Deployer (server rights cannot yet be assigned to Groups).
  • Impersonate: has internal impersonation rights within the K2 workflow context, not to be confused with Kerberos impersonation.
    • Only assign this right for accounts that execute code requiring impersonation rights within K2.
    • Use of Kerberos impersonation over K2 impersonation is prefered:
      • it is more secure,
      • more scalable and
      • K2 does not act as an authentication mechanism

    #### Process Rights ####

It is best practice to assign Process rights to Groups, not Individuals.

Process rights are:

  • Admin
  • Start
    • Assign to K2C-Svc-WS-xxxx
    • Assign to K2C-Svc-AP-xxxx
    • Assign to K2-Grp-Admins
    • It may be necessary to assign to individual users – but try avoiding this.
  • View
  • View Part
  • Server Event
    • Assign to K2C-Svc-AP-xxxx

Ensure scheduled backups are in place.

  • /home/skysigal/public_html/data/pages/it/ad/k2/howto/install.txt
  • Last modified: 2023/11/04 01:47
  • by 127.0.0.1