Controlling Rights Synchronization in IRM 11g
By Martin Abrahams-Oracle on Apr 04, 2011
A colleague recently asked how you can control the periodic synchronization of rights and audit data in IRM 11g – and what are the defaults? What factors should you consider when deciding whether the default synch schedule is right for your organisation, and how does synching impact the performance of the client and the server in large deployments? What exactly is synchronized on each occasion?
By default, synchronization occurs Monday to Friday between the hours of 9am and 5.30pm. The admin UI for the synch schedule is pretty self-explanatory…
Each IRM Desktop evaluates that time window according to its local time zone, so if you have users scattered around the world, they will each synch during their respective working days. You’ll note that the time window is quite large – a full working day. This ensures that the server is not hit by large peaks of requests in large deployments. There is usually no great urgency to get the synch done at a particular time, so we set a broad window.
Each IRM Desktop will pick a random time during each time window – again so that they don’t all try at once – and automatically tries again at intervals in the event of failure. If the network is disconnected at the time, the IRM Desktop will watch for the next connection and try again. All of this is transparent to the user.
What exactly gets synchronized? Synchronization is a two-way activity. The server provides the client with a fresh statement of the user’s rights and resets the offline periods so that the user rarely, if ever, hits the expiry time. In most configurations, this provides the user with a cached copy of ALL of their rights. Our classification model makes this viable even at large scale – there might be thousands or millions of documents, but they are usually organised for policy purposes into a few classifications, and each user has rights to a few classifications. So, each IRM Desktop only needs to receive a small amount of policy information in order for the user to have access to thousands of documents. There is no need for a user to be sent any information about classifications that they do not have any right to use, so the set of information sent to each user is usually quite small.
The server can also take the opportunity to inform the client of a change to the synch schedule, and to remind the client of the correct time from the server’s perspective.
In return, the client provides the server with the audit trail generated by its user since the previous synch event. This means that the server gets regular updates about offline usage of sensitive information. Some solutions only provide audit trail for events that involve contacting the server – so offline use is often invisible.
So why might you change the defaults? The most common reason is simply that your working week might not be Monday to Friday. If you have users in the Middle East, for example, you might configure the schedule accordingly. Alternatively, if you have a service in which rights rarely change, or you are not particularly worried about how quickly policy changes propagate out to users, you might reduce to a weekly schedule rather than daily – but the amount of traffic generated by synching is pretty modest so most customers stick with the defaults.
Another reason would be if you are not using the out-of-the-box classification model. If you are managing rights file-by-file or using some other model that involves a lot of policy configuration, then there might be a lot of information to synch to each user.
Another might be that it is REALLY important that policy changes be propagated rapidly or that audit trail be collected more frequently – so you might configure a lot of smaller windows during each day. Or you might modify some or all roles to achieve similar effects. You increase the traffic, but gain greater control and visibility.
Also, if appropriate, you can configure some or all roles to disable offline auditing. This reduces the amount of data that the client needs to send to the server. This might be useful if users are using a lot of sealed content and you are not too interested in the audit trail. Again, you choose which roles to exempt from auditing.
Thus, out-of-the-box we provide a powerful mechanism for ensuring timely propagation of policy changes and frequent upload of offline audit data – but we also give you a variety of controls to play with if needed.