This section addresses issues concerning the deployment of the Active Roles Administration Service. Information for this section was collected from:
There are no technical requirements for installing many Administration Services in a location or in different locations. The number of Administration Services in a location and the number of locations with Administration Services depends on an organization’s needs and expectations, the current infrastructure and hardware, and the business workflow. When considering an To add the Active Roles console (MMC Interface) to the pilot deployment, simply install the new version of the console on an appropriate server and have the console connect to your pilot Administration Service. deployment, administrators should consider the following issues:
When an organization has gathered and assessed the information above, it will be able to determine the locations and number of Administration Services to be installed. The last sub-section provides network diagrams that illustrate potential Active Roles deployments.
This factor focuses on Active Directory (AD) data management processes and practices, including who will perform these tasks and from where they access the management services. Generally, these tasks will be divided among several groups, which might include both high- and low-level administrators, a Help Desk, HR personnel, and work group managers.
Possible business workflows for AD data management processes might be:
Organizations should diagram the locations/sites at which AD data management is done, their network connections, the number of users performing tasks, the type of work they do. For example, Help Desk personnel will make more use of the Administration Service than regular employees who are occasionally changing their personal information.
Finally, the number of users at each site should be added to the diagram. Current customers report that there has been no need to install additional services in order to improve Active Roles performance. Adding the number of users is not intended to indicate the workload on or the performance of the Administration Service. The number of users is intended to help organizations to estimate and understand their own administration workload and how Active Roles will fit into that workload.
After calculating the resource usage of an Administration Service and mapping the business workflow of the network sites, an organization will have the necessary information to start assessing any need for additional hardware.
There is no technical need for installing the Administration Service on dedicated hardware. In fact, current customers do not use only dedicated hardware. They use a combination of dedicated and shared hardware to host the Administration Service. For example, a current customer manages 2,000,000 AD objects in a global deployment with a total of five Administration Services, two of which are dedicated and the other three are shared with other applications.
An organization’s current infrastructure, including existing servers, sites and connections, will greatly determine the need for additional hardware to run Active Roles. The Administration Service can be installed on any server, although organizations should consider these two guidelines:
Depending on service level agreements or goals, if existing servers are currently fully loaded or overloaded, then a new server should be purchased, and the Administration Service and additional services should be moved onto the new equipment. Not only will this enable Active Roles deployment, it will also improve the performance of the currently deployed services. Since Active Roles is often deployed during migration to Active Directory, Active Roles deployment can be included in planning for new hardware and server consolidation.
The need for redundancy and availability also will affect the hardware requirements. See the sub-section “Availability and Redundancy” for further details.
If an organization plans to use the Active Roles Web Interface, IIS must be installed on the server running the Web Interface.
It is recommended that organizations use the Active Roles Web Interface because it offers more flexibility than the MMC Interface. Users can access it from almost anywhere on the network. It shows administrators only the data they can administer and the tasks they can perform, which makes it easy to learn and highly secure.
One of the benefits of Active Roles is that administrators do not need permissions on Active Directory to perform user management and other tasks. This forces administrators to use Active Roles and assures secure administration with the enforcement of “Rules and Roles” provided by Active Roles. However, this lack of AD permissions might be a problem if the Administration Service becomes unavailable. The impact of this potential problem depends on the specifics of the situation, but the problem can be addressed with the following guidelines.
Two guidelines should be followed for major sites:
Again, organizations should use their administration framework and their experience with other management services, such as SMS, to determine the need for an Administration Service at a site.
In most scenarios, even if the server hosting the Administration Service fails, connections to other sites will be maintained. Administrators can access Administration Services at another site and force AD replication to make the changes appear on the local domain controller as soon as possible.
Three approaches can be used for remote sites where either no or only a low level of administration work is performed (e.g., creating a few users, updating employee information, or unlocking accounts). One or more approaches can be used, and they should eliminate the possible problem of administrators not having AD permissions and an Administration Service failing. The approaches used depend on business workflow.
NOTE: With Active Roles user interfaces, the administrator can deliberately choose the domain controller where to apply the changes, thus eliminating data replication delays.
NOTE: Active Roles allows administrators to push (synchronize) permissions from Active Roles to Active Directory, thus making it easier to manage permissions to AD.