Blue Prism Installation Engineer common mistakes
Blue Prism Installation Engineer · Understand the traps and how to avoid them.
Sizing the database server and SQL Server edition from a rough user count instead of from the documented hardware and software prerequisites for the target Blue Prism version, then discovering the chosen SQL Express edition's 10 GB per-database limit will be exceeded.
Candidates treat the database as an afterthought and rely on general impressions of 'small' workloads, forgetting that Blue Prism publishes explicit minimum specifications and that Express editions carry hard capacity caps that silently break once session logs and audit data accumulate.
What to do instead
Before any install, produce a written prerequisites checklist that maps each component (database engine and edition, CPU, RAM, disk, OS version, .NET version, browser) to the published specification for the exact Blue Prism version being deployed, and explicitly state why Express is or is not acceptable given expected log growth and retention.
Installing every Blue Prism component (interactive client, application server, database) on a single machine in a design answer, then failing scenario questions about scaling, high availability, or separating the runtime resource from the control room.
A single-box install is the easiest way to get a working lab, so candidates generalise it to production and never internalise the three-tier model of database, application server, and client/runtime resource.
What to do instead
Draw and memorise the reference topology: dedicated SQL Server, one or more application servers behind a load balancer, interactive clients for developers and control room, and separate runtime resources. For each component, state what can be co-located and what must be separated for performance, security, or availability reasons.
Creating the Blue Prism database with default collation, default recovery model, and default file growth settings, or restoring a database without verifying collation compatibility.
Candidates focus on getting the schema created and never consider that collation mismatches cause errors during installation or later queries, and that autogrow in small increments plus full recovery without log backups leads to fragmentation and runaway transaction logs.
What to do instead
Specify the required collation for the Blue Prism database, set an appropriate initial size and fixed autogrowth increments for data and log files, choose the recovery model that matches the backup strategy, and verify collation before restoring a database to a new server.
Granting the Blue Prism service account sysadmin or db_owner on the SQL Server instance because the connection 'works that way', rather than provisioning a least-privilege login mapped to the correct database role.
Permission errors during setup are frustrating and sysadmin removes them instantly, so candidates take the shortcut and never learn which rights the application actually requires.
What to do instead
Create a dedicated SQL login for the application server, map it to the Blue Prism database with only the documented role membership, and confirm the service starts and processes run with that account. Reserve sysadmin for DBAs and document the exact grants in the build guide.
Running the application server and Blue Prism services under a built-in account such as LocalSystem or a personal interactive user, and using the same credentials for every component.
Default service installation options and convenience push candidates toward built-in accounts, and the difference between service account, database login, and Blue Prism user is never clearly separated in their mental model.
What to do instead
Define a dedicated domain service account per role, grant it 'log on as a service' and the required database rights, register SPNs if Kerberos is used, and keep Blue Prism application users (for login and role assignment) distinct from the Windows service identity.
Configuring authentication by choosing an option in the install wizard without planning how users will actually log in, then being unable to explain how to add the first administrator or how single sign-on interacts with Blue Prism roles.
Candidates memorise that multiple authentication modes exist but not the consequences: which mode allows native Blue Prism logins, how the initial admin is created, and how directory groups map to Blue Prism roles.
What to do instead
For each authentication mode, write down the login flow, where users and roles are defined, how the first administrator is bootstrapped, and what happens if the directory is unavailable. Practise mapping an Active Directory group to a Blue Prism role and state the order of operations.
Skipping post-install validation and treating a successful installer exit as proof of a working environment, without checking service status, database connectivity, encryption scheme, or a test login from a client machine.
The installer reports success even when downstream configuration is incomplete, and candidates have no habit of a defined smoke test, so latent faults surface only in production.
What to do instead
Adopt a fixed validation sequence: confirm services are running under the intended account, verify the application server is reachable from a client, log in with a test user, check the audit log records the session, run a trivial process end to end, and record each result in a sign-off checklist.
Diagnosing connection failures by guessing, for example reinstalling the client or disabling the firewall entirely, instead of working through the layered path from client to application server to database.
Blue Prism connection errors are often generic, and candidates lack a structured troubleshooting method, so they change multiple variables at once and cannot identify the true cause.
What to do instead
Use a layered isolation method: test DNS resolution and port reachability to the application server, check the application server's own connection string and service account, then check database reachability and login permissions. Change one variable at a time and confirm the effect in logs and the Windows event viewer.
Planning an upgrade as a simple in-place installer run on the production environment with no backup, no staging rehearsal, and no consideration of database schema upgrade order across application servers.
Candidates equate upgrade with patching a desktop application and underestimate that the database schema, application servers, and clients must all be at compatible versions, and that rollback requires a verified backup.
What to do instead
Produce an upgrade runbook: full database and configuration backup with a tested restore, rehearsal in a non-production copy, documented component order (database, then application servers, then clients and runtime resources), a maintenance window, and explicit rollback criteria and steps.
Treating migration or maintenance as a file copy, moving the database or configuration without capturing encryption keys, connection strings, scheduled tasks, credentials, and environment-specific settings, and without a decommissioning step for the old environment.
Candidates see the database as the whole system and forget that secrets, schedules, and per-environment configuration live outside it, so the migrated environment authenticates or schedules incorrectly.
What to do instead
Build a migration checklist covering database backup and restore, encryption key handling, application server configuration, credentials and their re-entry or transfer, schedules, audit retention, and client connection settings. Validate with an end-to-end test in the new environment, then document decommissioning of the old one.