This section is used to assign file repositories to the clients of a container (see Distributed File Repositories). This allows you to specify where the clients should get their data for client commands and ACMP updates (content types) from. It must be ensured that all clients have access to both updates and client commands, as a file repository also can contain only one content type. If this is not the case, the clients will not have the appropriate content type.
By default, inheritance is enabled for all new containers to ensure that they use the same file repositories as their parent containers. Containers on the top level use the standard file repository when inheritance is activated. If inheritance is disabled for a container, file repositories can be assigned manually. All child containers for which inheritance is enabled, will also use these file repositories.
If inheritance is disabled for a container, this will be indicated by a folder icon in the main view of the container. All containers that inherit their file repositories from this container are characterized by a grayed out folder icon. If a container inherits a container from the default file repository, no marking is shown.
In the console, the assigned file repositories are listed in their sequence of access, beginning with priority 1. In addition to the name, availability as well as the status of the corresponding file repositories is displayed. Availability defines the number of clients that were able to connect with the file repository during the previous connection attent. If a file repository is not accessible, the file repository with the next higher priority is used. If a file repository is not fully synchronized, the operation will fails and the clients will not receive any updates and client commands, since no attempt will be made to connect with another file repository.
Container: File repositories / updates
If a client is located in multiple containers, the priority of each container is of secondary importance for the selection of the file repository. In the first place, the containers for which inheritance is disabled and/or those that inherit from such containers will be preferred. Only when a client is in several of these containers is, the priority of the containers is decisive.
A client always uses only the file repositories of one container. It is recommended to create a specific container structure for the repository settings in which each client only appears once.
Cancel/restore inheritance
If file repositories are to be assigned manually to a containers, inheritance must be disabled. This is done via the Cancel inheritance for this container button. Then you can select if the file repositories inherited so far should be adopted or if no file repositories are to be assigned. In the latter case, it must be ensured that the affected clients do not automatically use the default file repository and thus do not receive any updates and client commands if no file repositories are assigned to a container. Then you can additional one, remove existing ones or change the file repository priorities.
Container: Cancel inheritance
Add/remove file repositories
File repositories can be added to the container by starting a little dialog with the Add file repository button, through which you can select the appropriate file repository.
After having assigned the necessary file repositories to the container, you can define the priority of the file repositories. In this way, you can determine the sequence in which the file repositories will be addressed by the clients until a connection is established with one of the file repositories.
If you want to delete a file repository from the assignment, select it and click the Remove file repository button.
Last change on 10.03.2014