Provider Settings

When a Provider (formerly known as a “Distributor”) is created, the Provider settings are specified in an XML file in the <Distributor> XML block. The Provider is then created using this XML file. After this point, the Provider settings can be changed using the Admin Console.

In the sections below each setting is identified by the name used in the Admin Console. The associated XML tag used during setup follows the name in parenthesis.

To secure the login to the Admin Console you could setup a single IP in the Admin Console using the LOGIN_IP setting. Only logins from this IP address are allowed (that also provide correct user login credentials).

API Settings (<APIAccess> XML block)

You can define whether a Provider is allowed to access the Registration Server using the API interface as described in the API documentation.

If the <APIAccessEnabled> tag is set to $false all settings in this section will be ignored. NOTE: This setting must be enabled to use the Admin Console.


API access is only allowed from a single IP address. Two different providers can not use the same IP address, because the IP address will be used to identify the Provider. This is done for security reasons, as you may only access your own customers, licenses, and other data belonging to your Provider.

Exception: The Admin Console (which uses API functions) allows each Provider to login if the above value <APIAllowSettingDistributor> is enabled. It’s also possible to add more than one IP address if you want to access the API from different machines.

API_REDIRECT (<APIRedirect> tag)

This value will be returned for various API calls if the calling user belongs to another Provider. For more details, please look in the API documentation.

API_CREATE_DEFAULT_LICENSE (<CreateDefaultLicense> tag)

By default each user will get a default license. You can disable this if you want the possibility of creating or assigning a license created by an API call.

REG_NAME_COMPLEXITY (<RegNameComplexity> tag)

This value must be identical to the value set in the DISTRIBUTOR file. For further details, see reg-name-complexity (default: basic-ascii).

API_SEND_EMAIL (<APISendEmail> tag)

If set to``$true``, the user will be sent an activation email if registered via the API.


When developing or testing the API functions it may be easier to disable checksum checks. This value can only be set in the admin console (see Administrative Guide).


If your host server can communicate using HTTPS, you could enable SSL communication between the admin console and host server API. This value can only be set in the admin console (see Administrative Guide).


License reference value when creating licenses using the admin console.

EMAIL Settings (<Email> XML block)

EMAIL_SENDER_EMAIL (<RegistrationSenderEmail> tag)

The activation mail will list this email address as the sender.

EMAIL_REPLYTO (<InvitationEmailReplyTo> tag)

This address will be used for invitation mails. Its usage depends on the value in <UseSenderEmail>.

EMAIL_DEFAULT_LANG (<DefaultEmailLanguage> tag)

If the user is using a language which is not listed in <AllowedEmailLanguage>, the <DefaultEmailLanguage> will be used instead.

EMAIL_ALLOWED_LANG (<AllowedEmailLanguage> tag)

Each Provider Code defines a comma separated list of languages allowed for the emails. A set of templates is required for each language. The language used depends on the language setting of the user’s record.

ACTIVATION Settings (<Activation> XML block)

ACTIVATION_DEFAULT_LANG (<DefaultActivationLanguage> tag)

The activation page’s language depends on the chosen language of the user. If the language of the user is not supported, the default language specified here will be used. The default HTML pages must always be available.

ACTIVATION_ALLOWED_LANG (<AllowedActivationLanguage> tag)

This is a comma separated list of languages allowed.

TDNS Settings (<TDNS> XML block)

If TDNS access is enabled for the Registration Server, each Provider needs its own ServerID and Checksum.


The ID of the Provider’s entry in the TDNS.


The checksum which will be added to the checksum over the request which will be send to the TDNS. For more details please look at TeamDrive Name Server (TDNS).

CLIENT Settings (<Client> XML block)

USE_EMAIL_AS_REFERENCE (<UseEmailAsReference> tag)

Enable if you want to use the email address to reference your users between your own system and the Registration Server. In this case usernames will be automatically generated when using the API. All further API requests which require the username can then use the email instead.

ALLOWED_DIST_CODES (<AllowedDistCodes> tag)

A list of allowed Client Provider Codes, besides the Provider’s own code (value specified in the <TicketPrefix> tag). This refers to the Provider Code in the TeamDrive Client’s DISTRIBUTOR file. The default value is ‘*’, which means all codes are allowed. ‘*.’ means all Provider which exists on this Registration Server are allowed.

This setting caters for Provider that have a specific version of the TeamDrive Client and want to ensure that only this type of client is used by the Provider’s users. Such versions are identified by the Provider Code specified in the DISTRIBUTOR file. Since the DISTRIBUTOR file is signed it cannot be manipulated on the client side, and therefore, this value can be trusted.


It is highly recommended that Provider always allows the standard TeamDrive Client (which has the TMDR code) in addition to any others.


License reference value for default licenses.

CLIENT_NETWORKS (<ClientNetworks> tag)

This is a list of networks (in CIDR notation) or IP addresses that identify users of the Provider. Using this setting, a Provider can determine that certain networks “belong” to the Provider. For example, any company that has been allocated a Provider Code can take ownership of own networks (as determined by global IP address ranges), and use this fact to control TeamDrive Clients started in those networks.

When a TeamDrive Client connects to the Registration Server, and before the user has logged in, the server determines the client’s IP address and checks whether the client is running in a network that has been specifically allocated to a Provider. If so, then the Provider Code is sent to the client and this overrides Provider Code in the DISTRIBUTOR file. This way, if the user registers after this point, the user will be automatically allocated to the Provider that owns the network in which the client was started.

PRE_LOGIN_SETTINGS (<PreLoginSettings> tag)

These settings are sent to the TeamDrive Client before login or registration. As a result, they can be used to configure login and registration in the same manner as settings within the DISTRIBUTOR file. Settings from the server always override client-side settings, so these settings will also override the values in the DISTRIBUTOR file.

The Provider of the user must be ascertained before the pre-login settings can be sent to the client. Before login or registration, the Provider of the user is either determined by the Provider Code in the DISTRIBUTOR file or the IP address of the client, if it is found to be in a network belonging to a specific Provider. The IP address has priority over the DISTRIBUTOR file.

CLIENT_SETTINGS (<DistClientSettings> tag)

These settings are sent to the client after registration or login. Theses settings can be used to configure the behaviour of the TeamDrive Client as required by the Provider. They will override any settings made on the client-side, and also override the global Registration Server ClientSettings setting as describe in Client Settings.

Note that after registration or login, the user’s Provider is fixed, and therefore the Provider Code in the DISTRIBUTOR file, or the network (see Client Settings) in which the client is stated doesn’t play a role any more.

FREE CLIENT Settings (<FreeClient> XML block)

This block will handle the free client limitations. Because we support both WebDAV servers and the TDPS, it’s not enough to use the storage account limitation of the Hosting Service. To limit the amount of data which can be administrated using a non full licensed client, you must define the limits here. The value also depends on the Provider.

DEFAULT_FREE_FEATURE (<FreeClientDefaultLicense> tag)

Numerous features can be bound to a license. The default features are set using this parameter. This value uses a bit-mask for enabling or disabling the individual feature; each feature has an assigned value (which is a power of 2) and the value of this setting is equal to the sum of all enabled feature values:

1 = Banner
2 = WebDAV
4 = Personal
8 = Professional

Example: For TeamDrive Systems, the Banner and WebDAV features are set for a free client. The Banner feature has the value 1 and WebDAV feature has the value 2. So to use both, the parameter value would be 1 + 2 = 3.

For more details about the features, please have a look at TeamDrive Client <–> Server interaction.

FREE_LIMIT_SIZE (<FreeClientMaxDataSize> tag)

This is the value in bytes to limit the amount of data which can be handled by a free client over all Spaces. The limitation will be shown in the client if he is reaching the 75 % border. A progress bar will be visible right above the status bar in the client. If the user will reach the 100 % he can still synchronize data, but the client is switching to meta data synchronisation. Downloading the contents of the files must be initiated manually by the user for each single file and version.


This value can only be set in the Admin Console, because the license key must be created after the server was setup. This value overrides the DEFAULT_FREE_FEATURE setting (<FreeClientDefaultLicense> tag).

UPDATE Settings (<ClientUpdate> XML block)

The TeamDrive Client checks if there are updates available for its version. You can use the following settings to define the supported languages for the update notification. How the update notification will be configured using the Admin Console is described in chapter.

MINIMUM_CLIENT_VERSION (<MinimumClientVersion> tag)

Any clients with a version below this may not register a new device.

UPDATE_DEFAULT_LANG (<AutoUpdateDefaultLanguage> tag)

Which update information HTML page will be displayed for the user, depends on the chosen language of the user. The language of the displayed update information HTML page depends on the user’s language. If the language of the user is not supported, the default language specified here will be used. The default HTML pages must always be available.

UPDATE_ALLOWED_LANG (<AutoUpdateAllowedLanguage> tag)

A comma separated list of allowed languages.


A test user can be defined using the Admin Console. This user will always get the update notification in their client even if they are already using a newer version. This allows you to test the update notification without up- and downgrading a TeamDrive client version.


A TeamDrive Enterprise Host-Server is registered using a provider code and the URL of the Registration Server. You can also use the Admin Console to define a default Host-Server for clients which register using said provider code.

The main provider of a Registration Server is allowed to configure any host-server on the Registration Server to accept users with different provider codes. This way it’s possible to use only one host server for multiple providers on a Registration Server.


Please choose a server from the list to use as the default depot server for new clients.


The URL of the Host-Server will automatically be entered in this field after you have selected a host server from the HOST_SERVER_NAME list above.


The size of the depot for the user in bytes. Default is: 2 GB = 2147483648 Bytes


The monthly allowed traffic for the user in bytes. Default is: 20 GB = 21474836480 Bytes


You can configure a Referral-Program for users which got invited by an existing user.


A “referral” is only valid if:

  1. The invited user did not have an account before being invited
  2. The user was invited by email
  3. The invited user registered with the email address the invitation was sent to (so that a match can be made)

The background task as described in “Move Store Forward Messages”-Task will do the matching, increasing the depot values and sending the notification mails (see Templates for Client actions). The background task must be running and be active. You also need an active host server and default depots for your users (see above HOSTSERVER Settings).


The maximum amount of new users which can be invited by an existing user.


The promotions upgrade size in bytes. The depot limit and free client limit are increased for both the new and for the existing user.


The settings for the CSV import can only be set using the Admin Console.

Users can be created using a CSV import. The CSV file is uploaded using the Admin Console and will be stored in the database. A cronjob must be configured (see Administrative Guide) so that the uploaded files will processed. The success or error logs can be downloaded using the Admin Console.

For backward compatibility you can still use the upload folder in the file system by defining the following optional CSV folders. The file will be imported into the database and then processed from the database entry.


Controls whether CSV import will be used.

CSV_UPLOAD_DIR (optional)

CSV hot folder. If not defined, the CSV processing will just use the database. If defined, the contained files will be imported to the database and processed from the database record. Processed CSV files can be downloaded again from the admin console, if necessary.

CSV_ERROR_DIR (optional)

Error logs for not imported users will be written to this folder. If not defined, you will find the value in the database using the admin console.

CSV_SUCCESS_DIR (optional)

Success logs for imported users will be written to this folder. If not defined, you will find the value in the database using the admin console.


This value will control, whether users not present in the CSV file are disabled. The additional “department” column must be filled in the CSV file. Username and department must match the existing record in the database.

AUTHSERVICE Settings (<AuthService> XML block)

These settings are used to configure access to an external Authentication Service (see External Authentication).

When referenced by the TeamDrive Client, all URLs (except VERIFY_AUTH_TOKEN_URL) below include the parameters specified for all REDIRECT URLs (see below).

USE_AUTH_SERVICE (<AuthServiceEnabled> tag)

Set to $true if you want to use an external Authentication Service.

AUTH_LOGIN_URL (<AuthServiceLoginURL> tag)

This URL points to the Login page of the external Authentication Service.

AUTH_REGISTER_URL (<AuthServiceRegisterURL> tag)

This URL points to the Registration page of the external Authentication Service.

AUTH_LOST_PWD_URL (<AuthServiceLostPasswordURL> tag)

This URL points to the Lost Password page of the external Authentication Service.

AUTH_CHANGE_EMAIL_URL (<AuthServiceChangeEmailURL> tag)

This URL points to the Change Email page of the external Authentication Service.

VERIFY_AUTH_TOKEN_URL (<VerifyAuthTokenURL> tag)

This URL is used by the Registration Server to verify an Authentication Token, sent by the client after login using the Authentication Service.

AUTH_VERIFY_PWD_FREQ (<VerifyPasswordFrequency> tag)

Maximum length of time (in minutes) user may remain logged in before they are required to enter their password again. If this value is 0, users are never promoted to re-enter their password.


The REDIRECT settings determine the landing pages reached when links are clicked or activated in the TeamDrive Client. These settings cannot be configured in the XML configuration file when creating a Provider.

The banner URLs are not covered by these settings. The HTML document that defines any given banner specifies where its links lead.

The first stop reached when a link is clicked or activated in the client is the determined by the RedirectorURL setting. The Registration Server implementation of this page re-directs the user as specified by the settings below.

A number of URL parameters are passed to the landing pages. These parameters can be used within the target landing pages to generate the content.

  • page and distr: These parameters are used to determine the target page of the re-direct. Normally you will not need to evaluate these parameters because the target page is specified by the settings below.
  • lang: The international language code of the current language of the client.
  • platf: Specifies the platform of the client: mac, win, linux, ios, android or unknown.
  • size: The size of the display area for the requested page: width x height in pixels (ex: 400x500).
  • user: Base 64 encoded username. This parameter is only supplied for the REDIRECT_PURCHASE URL.
  • product: Specifies the product ordered. Only provided for the REDIRECT_ORDER URL. Currently the only possible value is TDPS.
  • cookie: This is the cookie stored by the client which was passed to the client after a successful external user authentication (see Login Procedure).


This URL redirects to a page where the Provider’s version of TeamDrive can be downloaded.


This URL redirects to the Provider’s forum page.


This URL redirects to the Provider’s tutorials page.


This URL redirects to the Provider’s FAQ (frequently asked questions) page.


This URL redirects to the Provider’s page for ordering licenses (parameter ‘user‘ is the base 64 encoded user name).


This URL redirects to the Provider’s user-invite-user page.


This URL redirects to the Provider’s product order page (parameter ‘product‘ can currently only be ‘tdps’).


Will be opened after an uninstall operation to present a survey to the user asking why they uninstalled the software.