Contact Us

To help prevent spam, Javascript is required in order for you to use this form.
Or schedule a call

Comet Server configuration 

Overview 

Comet Server can be configured either via the Setup Wizard, or by editing the configuration file directly.

This guide will include screenshots of the Setup Wizard where appropriate, and also include references to the configuration file.

Setup Wizard 

You can configure Comet Server via the Setup Wizard.

You can access the Setup Wizard by logging in to the Comet Server web interface, clicking About this server, then clicking Setup Wizard button.

Configuration file 

As an alternative to the Setup Wizard, it is possible to edit the Comet Server's configuration via the cometd.cfg file. You can edit this file if you are experiencing any issues accessing the Comet Server web interface.

File validation and access 

The configuration file is in JSON format. Any changes made to this file must be valid JSON syntax. This mostly boils down to escaping backslash characters in text strings - wherever you intend for a backslash (\) character to appear, please use two backslashes (\\) instead.

The Comet Server application may overwrite any changes to the cometd.cfg file, unless it is stopped first. After making changes, you should then restart the server software following the instructions in the previous "Install the server application" section.

On Windows, if the application has been installed in the Program Files directory, then it may be necessary to run the editor as Administrator in order to save changes to the file. On Linux, the file may be owned by the root or cometd users, and it may be necessary to run the editor as a different user in order to save changes to the file.

Windows 

On Windows, Comet Server Service Manager includes a built-in configuration file editor that

  • automatically checks for valid JSON syntax, and
  • ensures that all Administrator user operations are handled correctly.

We would recommend using the Comet Server Service Manager feature to edit the cometd.cfg file on Windows.

Serial number 

Enter your serial number.

In cometd.cfg, this field can be set in the License section > SerialNumber property.

Server branding 

You can configure the appearance of the Comet Server web interface.

The top-left section of the Comet Server can be configured to display either a Comet brand logo, custom text, or a custom image.

In cometd.cfg,

  • the Branding section contains properties which can be used to modify the appearance of the Comet Server's built-in web interface.
  • the BrandName property sets the text displayed in the top-left corner.
  • if the LogoImage property is set to the path to an image on the local filesystem, this logo image will be displayed replacing the logo text
  • the CSSTheme property sets the theme used for the web interface. This property has the following possible values:
    • The value $default$, which instructs the Comet Server to load the default theme.
    • Any path to a *.css file on the local filesystem.

Additionally you can change the Comet Client Branding.

Email 

Comet Server can be configured to send email reports. To use this functionality, you should configure how email is sent.

You should set the "Send as" properties to configure how email appears to the recipient.

In cometd.cfg, these properties can be set in the Email section > FromEmail and FromName properties.

Delivery method 

You can choose to send email via one of four options:

None (Do not send email) 

Select this option to disable sending email from the Comet Server.

The Comet Server will be unable to send email. You can use this option if you want to disable all outbound email from a Comet Server.

In cometd.cfg, this option can be set in the Email section > set the Mode property to "" (empty string).

MX Direct 

MX Direct allows you to send email from this Comet Server without needing to configure a custom SMTP server. However, there is a greater chance of the email being discarded as spam.

In cometd.cfg, this option can be set in the Email section > set the Mode property to "builtin".

Troubleshooting for failed email delivery:

Make sure the reverse DNS has been configured for your domain to help ensure the email delivery is successful. The forward DNS should match the reverse DNS.

If you do not have the access necessary to configure reverse DNS then you will need to find out who owns your IP block (usually this is your ISP or hosting provider) and contact them to configure it.

Also, you may need to configure your domain's SPF record to allow the Comet server to send emails on behalf of this domain. An SPF record is added to your domain's DNS zone file as a TXT record and it identifies authorized SMTP servers for your domain.

Example for an inclusion: include:yourserver.example.com

SMTP Server 

If this option is enabled, Comet will send email via an SMTP server.

The following options should be configured:

  • Send as (display name):
  • Send as (email):
  • Deliver via: SMTP Server
  • SMTP server address:
  • SMTP server port:
  • Username:
  • Password:
  • Accept invalid SSL certificate from the remote SMTP server
  • Connect using TLS, instead of plain+STARTTLS
  • Allow sending emails over an insecure connection

Gmail account 

If this option is enabled, Comet will send email via a Gmail account. Internally, this uses known configuration information for Gmail's SMTP server.

The following options should be configured:

  • Send as (display name):
  • Send as (email): example@gmail.com
  • Deliver via: Gmail account
  • Email address: example@gmail.com
  • Password: GMAILPASSWORD

Gmail accounts with two factor authentication

If you are using two factor authentication for your email account then you will need to create a Gmail Application-Specific password or the email will not work.

Log into your Google account and visit your App passwords page. You may be asked to sign in to your Google account.

Click Select app and select Mail. Click Select device and select Other.

Type in the name of the device (Comet Server) and click Generate.

You will be given a password which you will use when setting up the Gmail account with Comet.

If your Gmail is not working with Comet then you will have to enable the "Allow less secure apps" setting.

Log into your Google account and open the security settings.

Scroll down until you see Allow less secure apps and turn it ON.

Network 

Configure which network interfaces and URLs the Comet Server will be accessible on.

The Comet Server can listen on multiple addresses, ports, and interfaces.

Change host/port, or use multiple ports 

By default, the Comet Server listens for connections on 127.0.0.1 port 8060. It is expected that this would be changed to e.g. port 80 or 443. Once the hostname and port are configured for the first time, they should be kept the same so that any installed client software will still be able to log in.

In cometd.cfg, each listener is configured with an object under the ListenAddresses section. Each object entry in the ListenAddresses section has (at minimum) a ListenAddress property, which should be a text string in the format ip:port.

Comet Server supports binding to an IPv6 address. You may need to enter IPv6 bind addresses using square-bracket syntax (e.g. [0000:1111::2222]).

Configure SSL Certificate 

Configuring an SSL certificate is very strongly recommended to improve security, as malicious network operators are no longer able to intercept passwords.

Using an SSL certificate with Comet Server also increases performance. The server will only negotiate an HTTP/2 pipelined connection if an SSL certificate is configured. This significantly improves TCP utilization.

In addition to this, some web browsers will show a warning

  • if the login page is not protected by SSL (e.g. Chrome 56, released January 2017), or
  • if the website is not protected by SSL (e.g. Chrome 68, released in July 2018).

Use an existing SSL certificate 

In cometd.cfg, in one object within the ListenAddresses section, make the following changes:

  • Change the ListenAddress property to use the port 443.
  • Set the new SSLCertPath property, to be a path to a local certificate file. The certificate should be in X.509 (PEM) format, including any intermediate certificates.
  • Set the new SSLCertKey property, to be a path to a local certificate key file. The key file should be in X.509 (PEM) format and should not be encrypted.

Self-signed certificates are supported, however, you should consider using a free certificate from Let's Encrypt as described below.

Certificate file formats 

Comet takes SSL certificates in X.509 (PEM) format. These files usually have a *.crt, *.cer, *.pem, or *.key file extension. They do NOT have a *.der, *.pks, *.jks, *.pfx, *.p12, *.p7b, or *.p7c extension; if your SSL certificate is in another file format, it should be converted to X.509 format.

The X.509 format is a plain-text format. You can inspect the files with a plain-text editor, like Notepad or Nano. The certificate file should start with the text -----BEGIN CERTIFICATE-----. The key file should start with the text -----BEGIN PRIVATE KEY-----.

Intermediate certificates 

If you have an intermediate certificate, you should combine your certificate with the intermediate certificates. You can open the files with a plain-text editor like Notepad or Nano, and paste your certificate, followed by the intermediate certificates, to build a combined file. You should use this instead of the certificate file above.

The Nginx web server requires the same process. You may find more information online about configuring intermediate certificates for Nginx.

On Linux, you can easily combine files with a command like (cat original.crt; echo; cat intermediate.crt) > combined.crt. In this example, placing echo between each cat command ensures that each file starts on a new line in the combined file.

Comet Server will probably work without the intermediate certificate, however, some web browsers may experience issues. We recommend using the third-party website https://www.ssllabs.com/ssltest/ to validate your SSL configuration for any hidden issues.

Troubleshooting 

Please check the Comet Server logs for more information.

Once your Comet Server is functional on the HTTPS address, we recommend using the third-party website https://www.ssllabs.com/ssltest/ to validate your SSL configuration for any hidden issues.

"tls: failed to parse private key" or "tls: failed to find any PEM data in key input" errors

This error message can mean that the key file is either encrypted, or, in the wrong format.

Open the file with a plain-text editor, like Notepad or Nano:

  • If the file contains unreadable characters, it is in the wrong file format. You should convert it to X.509 (PEM) format before using it with Comet.
  • If the file contains readable characters, but it starts with -----BEGIN ENCRYPTED PRIVATE KEY-----, then the encryption must be removed before using it with Comet.

Use a free, automatically-renewing SSL certificate 

Comet Server integrates Let's Encrypt support, allowing you to receive a free valid SSL certificate for the Comet Server. The certificate is trusted by all major web browsers, it will be renewed automatically, and requires no intervention from the server administrator. The only requirements for this feature are

  • The server must be listening on port 443; and
  • (since January 2018) the server must be able to listen to port 80 if necessary; and
  • the domain name must be publicly accessible, and the DNS for the domain name must point to this specific Comet Server instance.

In order to enable this feature, in the configuration file, make the following changes to your object entry under the ListenAddresses key;

  • Set the ListenAddress property to :443
    • You may specify a specific IP address (ip:443) if necessary. If your server is behind NAT, you should specify the LAN address.
  • Set the new AutoSSLDomains property to a comma-separated list of domain names for which the SSL certificate should be valid.
Troubleshooting 

Please check the Comet Server logs for more information.

The Comet server must be able to access letsencrypt.org in order to issue the SSL certificate.

Non-functioning IPv6

We are aware of one server with non-functioning IPv6 connectivity, that experienced repeated timeouts connecting to addresses under letsencrypt.org until IPv6 was disabled.

Provider downtime

You can check the status of the Let's Encrypt service at https://letsencrypt.status.io/ .

Rate limits

The SSL certificate provider has rate limits on certificate issuances.

  • To avoid reissuing the same certificate every time the Comet Server is restarted, Comet will automatically cache the generated SSL certificate.
  • If you modify your SSL configuration very frequently, you may encounter a rate limit from the SSL certificate provider, preventing the SSL certificates from being generated.
  • Current rate limits can be seen on https://letsencrypt.org/docs/rate-limits/ .

Error "Can't supply TLS certificate for domain XYZ: acme/autocert: host not configured"

When Let's Encrypt is used, the Comet Server associates your domain name with the valid SSL certificate.

However, if someone tries to connect to the server using https:// {direct IP} or https:// {wrong domain name} there is a problem as Comet does not have a valid certificate for the request. In the past, Comet would serve the certificate, but the client would see a mismatched-certificate error and fail. As of Comet 17.3.12, Comet Server will instead just drop the connection since there is an obvious misconfiguration.

If you see this error message including a wrong domain name:

  • There is a misconfiguration. Either a client is unintentionally connecting using the wrong domain name, or, you have misconfigured Let's Encrypt to not mention a domain name that should be included.
  • A researcher may be scanning the entire IPv4 internet using the Reverse DNS (RDNS) name of your server. It's possible that the RDNS name is out of date compared to the expected domain name for accessing this server.

If you see this error message including an IP address:

  • It's possible that someone tried to connect to your server on https:// {direct IP}. At the time of writing, it is not possible to receive a Let's Encrypt certificate for a bare IPv4 address.
  • A researcher may be scanning the entire IPv4 internet, and connecting to the open :443 port using the IP address of your server.

IP rate limiting 

Comet Server 17.12.9 and later support IP-based rate limiting. This reduces the bandwidth for the entire Comet Server.

To use this feature, follow these example changes to the cometd.cfg file:

"IPRateLimit": {
    "Rules": [
        {
            "MatchRegex": ".*",
            "BytesPerSecond": 1048576
        }
    ]
},

You can configure multiple rules. Each rule creates a rate-limiting domain. Incoming requests are matched against a domain, and the domain is limited as a whole. Incoming requests will be assigned to the first rate-limiting domain that matches.

Rate limits apply separately to ingress and egress traffic (e.g. a 10 MB/s limit will allow simultaneous 10 MB/s upload and 10 MB/s download).

Admin accounts 

In cometd.cfg, each object entry in the AdminUsers section represents a user who can log in to the Comet Server interface.

Username 

There are no character nor length restrictions on administrator usernames.

Usernames are case-sensitive.

Password 

There are no character nor length restrictions on administrator passwords.

Change or reset administrator password 

You can reset the administrator password by clicking the 'Reset' button.

In cometd.cfg,

  1. Find the object entry for the user in question under the AdminUsers section.
  2. Change the PasswordFormat value to 0 (zero).
  3. Change the Password field to the desired password.
  4. The password will be hashed and encrypted after first login.

Allow login via 

Comet Server supports two-factor authentication for administrators. For more information, please see the Configure two-factor authentication section in the Comet Server usage document.

You can configure which sets of information are sufficient in order to log in to the Comet Server:

  • Password alone: if this option is checked, the password alone is sufficient to log in to the Comet Server. If you are enabling two-factor support, this option should normally be disabled.
  • Password and TOTP together: if this option is checked, the combination of password + TOTP code will allow the administrator to log in to the Comet Server.
  • Password and FIDO U2F together: if this option is checked, the combination of password + FIDO U2F hardware token will allow the administrator to log in to the Comet Server.

In cometd.cfg,

  • the AllowPasswordLogin property sets whether a valid password alone is sufficient to log in.
  • the AllowPasswordTOTPLogin property sets whether both the Password and TOTP together are sufficient to log in.
  • the AllowPasswordU2FLogin property sets whether both the Password and FIDO U2F hardware token together are sufficient to log in.

Comet 18.8.x and older also support an option to log in with "TOTP Alone". This option was removed in Comet 18.9.0.

IP Whitelist 

It is possible to restrict the IP address of an Administrator logging in to Comet Server.

This feature is not currently configurable in the web-based Setup Wizard owing to the high likelihood of locking yourself out. You must make this change in the server's configuration file: that ensures you have a way to remove it, if necessary.

In the configuration file cometd.cfg,

  1. Find the object entry for the user in question under the AdminUsers section.
  2. Add a IPWhitelist field, with the value, a regular expression to match against IP addresses.

For example:

"AdminUsers": [
    {
        "Username": "my-user-account",
        "IPWhitelist": "127\\.0\\.0\\.1",

You should use \\. to represent a literal . character - one slash is required at the regex-level, and the second slash is required because the configuration file is a JSON document.

An example of how to use a regular expression to allow for dynamic IP:

"AdminUsers": [
      {
          "Username": "my-user-account",
          "IPWhitelist": "127\\.0\\.0\\.[0-9]{1,3}",

To whitelist multiple addresses you must use a vertical line "|" between each IP.

An example of how to whitelist multiple addresses:

"AdminUsers": [
      {
          "Username": "my-user-account",
          "IPWhitelist": "127\\.0\\.0\\.1|172\\.0\\.0\\.1",

Policies (Administrator account) 

It is possible to restrict the actions of administrator accounts in Comet Server.

As of Comet 17.8.0, the following restrictions are available:

  • Prevent viewing and editing server settings
  • Prevent shutting down and restarting server

Authentication Role 

The Comet server software is split into separate roles, as described in the "Application Architecture" section. If this server is expected to only play a storage role or an authentication role in your infrastructure, the other roles should be disabled.

In cometd.cfg, the AuthenticationRole > RoleEnabled option configures whether the Authentication Role is enabled.

The Authentication Role is the part of Comet Server responsible for managing users and job history logs. When this role is enabled, the following data files are used:

  • cometd-users.db - This file contains user profile information for all users. The expected file-size is small.
  • cometd-jobs.db - This file contains textual job information for all job history. The file-size may grow to some tens of MB, or larger, depending on the retention and volume of job entries.

It is not safe to copy these .db files while Comet Server is running.

Configuring Storage Role servers for Storage Vault registration (Optional) 

The Request Storage Vault section is used to manage default storage options which are available when requesting a new storage vault for a user.

Authentication Role Replication 

Authentication Role Replication replicates this server's authentication role data (i.e. user profiles and policy group configurations) to the other Comet server in one direction (the replica doesn't replicate data back to the main).

You can have your Replication server store the data using a cloud service provider or using your own storage.

Server logs and job logs are not replicated.

For Storage Role Replication (i.e. storage buckets and their content) refer to the Storage Role Replication documentation.

Summary for setting up the Replication server: 

  • Install a new Comet server meeting the system requirements (can be installed on a virtual machine)

  • On the Replication server, configure the Storage Role (can store data using a cloud service provider or your own storage)

  • On the main server, configure the Authentication Role / Storage Role replication settings in the setup wizard, to point to the replica

Authentication Role Properties 

Keep job logs for: XX day(s) is how long to keep job logs in the job history before it automatically deletes after the specified time. Job history is located under Accounts > Job History.

Missed Backups 

The Authentication Role is responsible for maintaining historical logs of each job. Comet Server can generate a virtual "missed" job corresponding to when a backup job was expected to run on schedule but no backup job was found. You can control generation of Missed Backup jobs via the AuthenticationRole > GenerateMissedBackupEvents property. This property defaults to true, but has no effect if the Authentication Role is disabled.

In general, we would suggest leaving this property enabled for primary servers, and disabling it for replica servers.

Missed backups are detected the following basis:

  • A background task performs calculations every half-hour.
  • If a scheduled backup job was expected to run at time T, and no backup job for the same username, Protected Item, and Storage Vault occurred within the time range T - 5m ... T + 15m, then a missed backup job will be injected with the start and stop time set to T.

Storage Role 

The Storage Role is the part of Comet Server responsible for receiving and replicating any data uploaded by a Comet Backup account. When this role is enabled, the following data files are used:

  • cometd-buckets.db - This file contains metadata and authentication information for all Storage Vaults. The expected file-size is small.

It is not safe to copy these .db files while Comet Server is running.

In cometd.cfg, the StorageRole > RoleEnabled option configures whether the Storage Role is enabled.

Locations 

You must configure a location where this Comet Server can store data. The path might be a local disk path, or a network account, or a cloud storage provider. For more information about the supported storage types, please see the Storage Configuration documentation.

Storage Role Replication 

Storage Role Replication replicates this server's storage role data (i.e. storage buckets & its content) to the other Comet server in one direction (the replica doesn't replicate data back to the main).

You can have your Replication server store the data using a cloud service provider or using your own storage.

For Authentication Role Replication (i.e. user profiles and policy group configurations) refer to the Authentication Role Replication documentation.

Summary for setting up the Replication server: 

  • Install a new Comet server meeting the system requirements (can be installed on a virtual machine)

  • On the Replication server, configure the Storage Role (can store data using a cloud service provider or your own storage)

  • On the main server, configure the Authentication Role / Storage Role replication settings in the setup wizard, to point to the replica

Software Build Role 

The Software Build Role is the part of Comet Server responsible for generating branded client software installers and making them available for download. When this role is enabled, the Download client software page appears in the Comet Server web interface.

Comet Client Branding 

The Comet Client Branding is for how you want to brand your company with the Comet client (click here for Server branding). When you set the branding, the next time you update the users Comet client it will automatically change (If you need to update branding for multiple devices then use the Bulk Update feature).

  • The Product name is what the Comet client will be named (the shortcut will automatically change to this name).

  • The Comet client will refer to the Company name when making changes within the Comet client.

  • Setting the Help URL will add a "Help" tab on the client with your URL of choice (not required).

  • The Default server URL will prefill the Server field when logging into the Comet client.

Icon (Windows / macOS) 

You can set a custom icon used for the software on Windows and macOS.

On Windows, the file must be in *.ico format. On macOS, the file must be in *.icns format.

Other file formats (e.g. PNG and JPEG) are not supported.

  • Use of an unsupported format may result in a invalid icon file error message on Windows, or a blank icon display on macOS.

However, you can convert a PNG or JPEG image into this format using a dedicated program. At the time of writing, we suggest the following programs:

Software Runs on Price Produces
Greenfish Icon Editor Pro Windows, Linux Free and open-source *.ico, *.icns
Icon Composer 2x macOS Free and open-source *.icns
IcoFX Windows Commercial, with a free-trial *.ico, *.icns
Axialis IconWorkshop Windows Commercial, with a free-trial *.ico, *.icns
ImageMagick Command-line
(Windows, Linux, macOS)
Free and open-source *.ico, *.icns

A future version of Comet may support PNG and JPEG files for icons.

Client new account registration 

Comet supports new account registration from within the client software. You can enable this feature by setting the AccountRegisterURL property in cometd.cfg. If this property is non-empty, then any generated software will contain a 'Register' button on the login screen that opens the property as a URL in the system default web browser.

This allows you to create a custom signup workflow that calls into the Comet Server API to actually create the account. This offers an MSP the chance to capture other information such as email address, contact details, and billing / payment details.

By deferring to an external URL for new account registration, this system is deliberately flexible. For instance, it would be possible for MSPs using this system to

  • offer the choice of multiple plans, or
  • create the account on a specific Comet Server, or
  • automatically request a first storage vault, or
  • create a "free trial" system.

Codesigning 

Recent versions of Windows and macOS have introduced measures to encourage distributing code-signed installers.

Codesigning for Windows (Authenticode) 

You can enable Authenticode signing of generated installers. Signing the installer may reduce "SmartScreen" / "unknown publisher" prompts when installing the software.

Authenticode signing requires obtaining a certificate from a commercial certificate provider. At the time of writing, the following providers offered Authenticode certificates compatible with current versions of Windows:

Once you have purchased a certificate, you can enable it in your Comet Server by setting the following properties in the cometd.cfg file:

  • WindowsCodeSignPKCS12FilePath - a path to the PKCS12 (*.pfx, *.p12 etc) file on the local disk.
  • WindowsCodeSignPKCS12Password - the password to decrypt the PKCS12 file
  • WindowsCodeSignPKCS12PasswordFormat - set to 0 when first entering a password in the WindowsCodeSignPKCS12Password field; Comet will then encrypt the password, and use this field to indicate the encryption format.

When you do NOT have a codesigning certificate enabled, the Windows software download is in the form of a zip file, containing a small loader .exe (Authenticode-signed by a partner company of Comet Software Ltd) and a data file. When you DO have a codesigning certificate enabled, the Windows software download is in the form of a zip file containing a single signed .exe.

Codesigning for macOS 

Comet Server is not able to automatically sign or notarize a macOS installer.

However, you can download the .pkg file and sign it yourself, and host it for downloading on your own website.

  1. Purchase a developer ID certificate from Apple
  2. Sign the installer: productsign --sign '3rd Party Mac Developer Installer: My Company Limited' 'original-installer.pkg' 'signed-installer.pkg
  3. Check the signature: pkgutil --check-signature 'signed-installer.pkg'

A future version of macOS will also require you to upload the generated software to Apple for notarizing. Please see https://developer.apple.com/developer-id/ for more information.

A future version of Comet Server may be able to streamline the above process.

Software updates 

When a software update is applied, Comet tries to silently install an updated .pkg file from the Comet Server. This file will be unsigned. Comet 17.12.8 and later pass the -allowUntrusted flag to Installer.app to allow installing a software update from an unsigned .pkg file.

Codesigning for Android 

You must configure a codesigning certificate for Android before the resulting .apk file can be installed.

UPCONFIG: A future version of Comet Server will enable this feature.

Codesigning for Linux 

Linux applications do not contain embedded codesigning. You can achieve codesigning support for Linux by GPG-signing the hash of the binary and making this information available on your website independently.

A future version of Comet Server may add built-in support for package signing when hosting an apt-compatible repository for .deb packages.

Options 

Enable/disable the ability to download the Comet client for anyone visiting the Comet Servers web interface.

Constellation Role 

The Constellation Role is the part of Comet Server responsible for providing global insight across multiple Comet Servers.

Recall that Comet is designed to separate the Authentication and Storage roles to allow independent scaling.

  • A small MSP using Comet software might have only a single Comet Server,
  • A large MSP might have one Authentication Role server and a dozen Storage Role servers,
  • A white-label MSP might have a dozen different Authentication Role servers all backed by a single Storage Role server.

These latter cases are perfectly valid scenarios, but present some complexity when answering questions like "which user accounts are using this bucket" and "is this bucket safe to delete". The Constellation role communicates with all your Comet Servers to produce a global overview of your entire cluster to help answer these questions.

The Constellation role is optional. However, it is necessary if you want to automatically remove unused storage buckets from your Storage Role servers.

The Constellation role was formerly known as the "Overseer" role.

Choose one (and only one) of your servers to have the Constellation role. You can then use the Report features inside Comet Server > Cluster menu > "About this Cluster" to find which buckets are in-use by which accounts.

In cometd.cfg, you can enable the Constellation Role by setting the property ConstellationRole > RoleEnabled to true.

Targets 

When setting up the Constellation role you must add the other Authentication role/Storage role servers to manage.

In cometd.cfg, fill the Servers array with all your servers (including the Constellation), in the same format as for replication targets and remote storage buckets.

Properties 

The Constellation role will automatically produce a bucket usage report every hour, listing for each bucket (A) which servers the bucket exists on, and (B) which users have a Storage Vault configured pointing to this bucket. This information is sufficient to identify unused buckets in order to reclaim storage space on your Comet Server.

In the default configuration, no data will be deleted as a result of running this report. Once you are happy with the result of this report, you can enable the deletion feature to allow the Constellation role to delete unused buckets automatically.

Please keep an eye on the server logs in order to draw attention to any correctness issues with the report.

In cometd.cfg, you can configure this option via the ConstellationRole section > DeleteUnusedData property.

Risks 

It is essential that the Constellation has access to every single one of your Comet servers. If a new Authentication Role server is added to your infrastructure, but not added to the list of servers managed by the Constellation Role, then Constellation will see that the buckets are unused and remove them.

Such an issue should be obvious when the customer's next backup job fails to run. If the issue is noticed early, then recovery should be possible by reverting to an earlier filesystem snapshot (if available) or by re-uploading the data. However, if backup jobs are performed infrequently, or if the issue occurs at the same time as another outage, it may be more difficult to recover from the issue.

If an Authentication Role server is found to reference a Storage Role server outside the Constellation's vision, then a warning message will be added to the log file.

Saving changes 

If you are applying changes via the Comet Server web interface, the Comet Server will restart to save your changes. The Comet Server will be automatically restarted by the service system. Any running backup jobs will resume automatically.