Blue Prism Installation Engineer cheat sheet

Blue Prism interactive clients and application servers run on Windows Server or Windows desktop editions; the runtime resource must match the OS version supported by the target release notes.

A single-server (standalone) install places application server, database, and interactive client on one host; a multi-server install separates the application server tier from the database tier.

Minimum sizing baseline: 4 vCPU and 8 GB RAM per application server host; add memory for concurrent interactive clients because each session consumes a separate worker process.

Database tier requires a dedicated SQL Server instance sized for the expected session and log volume; do not co-locate the production database on the application server host.

Runtime resources need a Windows user account with 'Log on as a batch job' and 'Log on as a service' rights, plus local administrator on the resource host for installation.

Network prerequisites: inbound TCP 443 (or the configured app server port) from clients to application servers, and TCP 1433 from application servers to SQL Server.

Blue Prism licenses are issued per environment and bound to the environment's database; the license file must be applied before the environment is usable.

Time synchronization across all hosts (same NTP source, same time zone) is required; clock skew causes authentication and audit failures.

Plan separate environments (Development, Test, Production) each with its own database and license; resources cannot be shared across environments.

Supported backend is Microsoft SQL Server; create an empty database with a case-insensitive collation (for example SQL_Latin1_General_CP1_CI_AS) before running the Blue Prism database creation script.

The creating account needs dbcreator (or sysadmin) on the instance; the runtime service account needs db_owner on the Blue Prism database only.

Database creation is performed with the Blue Prism-provided script or the server configuration tool; the schema version recorded in the database must match the installed Blue Prism version exactly.

Set the database recovery model to Full for production and schedule regular transaction log backups; Simple recovery risks point-in-time recovery loss.

Enable TCP/IP in SQL Server Configuration Manager and confirm the SQL Browser service or an explicit port is used for named instances.

Connection strings use the format 'Server=<instance>;Database=;Integrated Security=SSPI' for Windows authentication; SQL authentication requires explicit user and password.

Configure max degree of parallelism and sufficient tempdb files per SQL Server vendor guidance; Blue Prism workloads are session-heavy and benefit from multiple tempdb data files.

Grant the runtime service account 'Log on as a service' and confirm it can open a connection to the database before starting the Blue Prism server service.

Install order: database first, then Blue Prism server (application server) components, then interactive clients, then runtime resources.

The Blue Prism Server Windows service hosts the application server; it must run under a dedicated domain or service account, never LocalSystem, when connecting to a remote database.

Each application server host requires a server configuration entry (connection to the database and a listening port); multiple servers can point to one database for load distribution.

Interactive clients connect to the application server by name and port configured in the client's connection settings; the client does not connect directly to SQL Server.

Runtime resources are registered in the Blue Prism client under System > Resources, then the Blue Prism Runtime Resource service is installed on the host and pointed at the application server.

The runtime resource service runs under a Windows account with interactive logon rights on the resource host; the account must be the same one registered for the resource.

Verify installation by confirming the Blue Prism Server service is Running, the client can log in, and the resource shows as Connected in the System tab.

Ports must be opened on the application server host firewall for each configured listening port; a mismatch between configured port and firewall rule is a common install failure.

Blue Prism supports native (Blue Prism) authentication and Active Directory (single sign-on) authentication; the mode is chosen at the environment level, not per user.

With Active Directory authentication, users log in with their Windows credentials and group membership maps to Blue Prism roles; native mode uses Blue Prism-stored credentials.

Roles define permissions (for example System Administrator, Developer, Process Owner); users are assigned to roles, and access to processes and objects is governed by role permissions.

The built-in admin account is used only for initial setup; create named user accounts and disable or rotate the default admin credentials immediately after installation.

Audit logging records user logins and configuration changes; the audit log is stored in the database and should be retained per organizational policy.

Encryption keys protect stored credentials; back up the encryption key material with the database, because a database restore without the keys leaves credentials unreadable.

Least privilege: runtime resource accounts should have only the permissions required to run assigned processes, not System Administrator rights.

Service accounts for the application server and runtime resources should be dedicated, non-interactive where possible, and excluded from password-expiry policies via managed service accounts.

Validate the database connection first: a failing server service usually indicates an incorrect connection string, disabled TCP/IP, or a missing db_owner grant.

If the client cannot connect, check the application server service state, the configured port, and firewall rules between client and server before inspecting the database.

A resource showing as Disconnected indicates the runtime resource service is stopped, the service account cannot log on interactively, or the registered resource name does not match the host.

Version mismatch errors between client, server, and database schema require aligning all components to the same Blue Prism release.

Check the Windows Event Viewer (Application log) for Blue Prism Server and Runtime Resource service errors; the services log startup and connection failures there.

Clock skew, expired service account passwords, and expired licenses are the three most common causes of sudden environment-wide authentication failures.

Collect a baseline validation record after install: service states, port bindings, database schema version, license expiry, and a successful login and process run.

Upgrade order: back up the database and encryption keys, upgrade the database schema with the release's upgrade script, then upgrade application servers, then clients and runtime resources.

Blue Prism does not support skipping major versions in place; upgrade sequentially through each supported intermediate release as documented in the release notes.

Before upgrading, confirm the target release supports the installed SQL Server version and Windows OS versions on every host.

Migration between environments uses export/import of releases (packages) rather than copying databases; database copies break license binding and audit integrity.

After an upgrade, re-verify the license, re-run the validation checklist, and confirm all resources reconnect and scheduled processes execute.

Maintenance: apply SQL Server patches and Windows updates in a test environment first; keep the Blue Prism database backup schedule aligned with the recovery point objective.

Decommissioning a host requires removing its resource registration and revoking the service account before shutting down the machine, to avoid orphaned resource entries.