> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.itential.com/itential-platform/6/configure/network/server/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.itential.com/_mcp/server. # Configure server > How to configure the serverId property in the Itential Platform properties.json file for server identification. Itential Platform reads `properties.json` at startup to get its basic configuration, including the `serverId` property described below. The `serverName` property was removed in Platform 6 and replaced with `serverId`. See [Server name property replaced](/itential-platform/release-notes/breaking-changes/server-name-property-replaced) for migration guidance. ## serverId property Don't use a colon (`:`) in `serverId`. Redis uses colons as queue name delimiters; a colon in `serverId` causes Platform to broadcast to the wrong queue, which can result in a service outage. Use `serverId` to assign a unique name to each Itential Platform server in your environment. Set in `properties.json`, it provides a consistent alternative to generated IP addresses. You can also use `serverId` in Blue-Green deployments. | Property | Type | Description | | ---------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `serverId` | String | A unique identifier for the server. Must be unique within a Platform instance. If not provided, Platform defaults to a hashed value derived from the server's MAC address. | ### Sample configurations #### Single server ```json "serverId": "iap-1" ``` #### Multi-server ```json "serverId": "IAP1.primary" "serverId": "IAP2.primary" "serverId": "IAP3.primary" ``` ```json "serverId": "IAP1.secondary" "serverId": "IAP2.secondary" "serverId": "IAP3.secondary" ``` ### Implement serverId If you change or add `serverId` and restart Platform, tasks in a running state that aren't one of the following types are orphaned: * `childJob` * `manual` * `forEach` * `eventListener` This only happens the first time you set or change `serverId`. Subsequent restarts don't orphan jobs as long as `serverId` doesn't change. Pause the task worker and verify no jobs are running before setting `serverId`. #### Disaster recovery stacks If your Platform stack uses Disaster Recovery (DR), don't reuse `serverId` values from the primary cluster in the DR cluster. Platform checks for duplicates at the cluster level only, not globally. Duplicates across clusters can cause tasks to be orphaned when the load balancer switches from DR to the primary cluster. > How to configure the serverId property in the Itential Platform properties.json file for server identification.