Recommended Practices

We strongly advise that you keep the software versions (e.g., 1.x.x) and subversions (e.g., 1.2.x) across your system match exactly. Software build numbers (e.g., 1.2.0.xxxxx) may differ slightly in case you are using 64-bit and 32-bit editions.

Setup

When carrying out new installations, especially if you are new to this product, we advise that the following configuration priority is maintained:

1. Servers and failover clusters

2. Networks (connections)

3. Devices and channels

4. Users

5. Events and actions

6. Other features, in any order

In such a way, the optimum course of actions is maintained; in the sense that, if everything is set up properly, you will not have to go through the same configuration section multiple times. This makes the setup process logical and transparent. For instance, if you go to user setup first and then switch to adding servers and devices, you will still have to go back to the users' section in order to add corresponding privileges; so, the suggested priority is not obligatory, but it is advisable for efficient implementation.

You may have noticed that quick setup wizards have the same configuration order as described above. This is due to an analysis of our own and our customers' wide experience in system deployment and configurations, and thus this scheme has been brought to you as a recommended practice.

For existing (running) installations, when only a partial settings update is intended, the scheme above may not make sense; any specific settings can be changed later on independently via corresponding sections of the Macula Console management application. However, if you are adding a new server, it would be sensible to follow the procedure partially (steps 2 to 5).

Groups

Another important pragmatic recommendation for enterprise installations is the usage of groups. In case of large number of users, servers, devices and other resources splitting them into groups makes the overall deployment process easier and enables more comprehensible and easier utilization of the system for the end-users.

Grouping is heavily dependent on the actual target system and should take into account the peculiarities of the system. Segregation may be logical, virtual, actual, based on location or access type; the main idea is to facilitate the usage, so, the needs of the end-user should be properly understood first.

A striking example of the advantage of groups is in situations when you need to add permissions for multiple users: instead of browsing the whole user list and searching for those required, you only have to click one group to assign permissions to all users inside it. Different types of groups can be used, with not just dividing resources, but also having overlapping categories for better manageability.