--- title: New doc slug: custom-main-prod createdAt: 2025-08-21T09:54:58.659Z --- [First docc](docId\:TFhYJjWtsqqxh5qI35siw) BrightSign players in large, distributed networks should meet certain provisioning and recovery requirements. Partners who want to set up their own provisioning and recovery systems, rather than using BSN.cloud, should make sure that those systems meet the following requirements. Each player must be able to provision itself, and once provisioned, periodically check in with the server for updates if configured to do so. The player and server must also be able to initiate a recovery process should the player enter an error state that cannot be fixed by rebooting (for example, filesystem corruption caused by power loss or failure of the storage device). To meet these requirements, two separate but complementary systems must be developed: - A set of *autorun.brs* files that can play content, facilitate fault recovery, or provision the player for an HTML/JavaScript playback environment - A *request handler* server to process recovery/provisioning HTTP requests sent by the player. The request handler delivers an autorun file or other HTTP response depending on player information contained within the header of the request. The request handler database can also contain conditional flags for each player, that enable new autorun scripts to be pushed to specific players in the field. If a partner-specific request handler is not specified in the registry, BSN.cloud provides a default request handler. # Player Provisioning BrightSign player provisioning integrates the player into your environment, primarily by changing registry settings to reflect that environment and usually by downloading an application or Setup package to the player. The following settings are configured within the registry during BrightAuthor\:connected or BSN.cloud provisioning: - BSN.cloud account, username, password, and group - Recovery/provisioning URL, error notification URL, crash report URL - Timezone ## Player Registry Entries  The following player registry entries are associated with the provisioning and recovery process. These keys can be modified by accessing the registry’s “networking” section using the [roRegistry](docId\:YTpSfntswYFMXx8PCqJLf) BrightScript object. | **Registry Key** | **Description** | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `ub` | The URL prefix that is applied to the URLs of the ru, eu, and cu key values. This prefix is not applied to a key value containing a colon. | | `ru` | The provisioning/recovery URL used by the player to download an autorun script | | `eu` | The URL to which error notifications are posted | | `cu` | The URL to which crash reports are posted | | `p` | The *password* to the recovery handler (`ru`) that is specified above | The following registry keys are specific to BSN.cloud but can be modified by partners to affect the BSN.cloud registration. You should not store your own information in these sections because it can affect BSN.cloud operations: | **Registry Key** | **Description** | | ---------------- | --------------------------------------------------------------------------- | | `a` | The name of the BSN.cloud *account* to which the player belongs. | | `u` | The name of the BSN.cloud *user* in the account to which the player belongs | | `g` | The BSN.cloud *group* within the account to which the player belongs | :::hint{type="info"} The account, username, and group registry keys are used for provisioning/recovery with BSN.cloud. A request handler may use these keys, but they are not required. ::: ## Player Startup Processes These processes occur when a BrightSign player boots: 1. The player connects to a network and obtains an IP address. 2. The player checks the storage device for an autorun. If an autorun is found, the player will execute the autorun and if none is found, it will proceed with the steps below. See [Player Storage](docId\:o4YzospNpFaGbgLdUleee) for more information about storage devices and device priority (if you have multiple storage devices). 3. If an IPv4 address exists, the player will attempt to provision over the network. 4. The player will check for a recovery URL (ru): - If a DHCP Option 43 recovery URL (ru) is found, it will override any registry value for `ru` until the end of the DHCP lease. This URL can be set through DHCP Option 43. See [Option 43](docId:5RglQFftt-PxzAhHl8gL3) to configure a DHCP server to communicate this URL to a BrightSign player. - If DHCP Option 43 ru is not found, the ru that is set in the registry will be used. - If there is no registry value for the ru, this step will be skipped. 5. If the recovery URL is blank, the player will attempt: - **Well-known host** **provisioning**: Also known as custom name mapping in your network's DNS server. If an IP address is mapped to *brightsign-b-deploy*, then the player will attempt to use the associated IP to provision itself automatically. - **B-Deploy cloud provisioning**: See [B-Deploy/Provisioning APIs](docId\:wccw4TQERZPXV7KJq_a3P). - **multicast DNS (mDNS)**: The player will automatically check the standard mDNS location (*http\://brightsign-b-deploy.local/)* and if there is a server on your network with that address, the player will automatically provision itself. However, no other provisioning methods can be active if you want to provision with mDNS. See the Appendix at the end of this page for more information about this option. 6. The player will retry the provisioning process every 30 seconds until there is a successful response or interruption. ## URL Request Parameters These parameters are used for communicating between a player and the request handler.  ## Player Request Parameters