Why would you need a subordinate licensing server?

A few days ago, I had a discussion on why you would ever want to have a subordinate licensing server in an RMS Design. In this posting, I will walk through some of the discussion points:

In the RMS world, a licensing cluster can only issue Use Licenses from the licensing server where the originating publishing license was generated. The root cluster (certification) still handles user enrollments, proxying of workstation enrollments, revocation of subordinate licensing servers, server licensor certificate. What this means is that there is still traffic generated over the WAN link, so if you are trying to avoid network usage, this is not the best option.

A subordinate licensing server is best used in situations where a department (e.g. R&D) needs to be completely isolated from rest of the company and to ensure that only use licenses are granted to users who are in R&D (assuming the user publishing content is in R&D). This ensures that the super user group, who can decrpt RMS protect dcoument, is only known by that department and not the root cluster. There are other scenarios where a subordinate licensing server might come into play, including high usage, slow networks or DMZ, but these all have severe downfails which I usually veer away from.

If we take placing a subordinate licensing server in a DMZ for instance, and its being done so that external users can obtain use licenses for internally published content, then you will run into issues authenticating those users. This is where something like ADFS or creating external user accounts would come into play and is outside the expertise of RMS.

For a high usage scenario, this is really not a feasible option simply because RMS should be clustered together at the root server and nodes added to the cluster as capacity increases. There are several reasons for this, most notably for ease of administration.