Deployment considerations
This section addresses issues concerning the deployment of the Active Roles Administration Service. Information for this section was collected from:
- Feedback from our current customers who have enterprise class deployments with multiple sites/locations
- Extensive testing of Active Roles in our software development labs
- Comparisons and testing of Active Roles to competitors’ solutions
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:
- Business workflow
- Hardware requirements
- Need for availability
- Replication traffic
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.
Business workflow
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:
- Centralized at one location and performed by one group
- Centralized at one location or LAN site and performed by multiple groups
- Distributed at multiple sites but performed by one business group
- Distributed at multiple sites and performed by multiple independent business groups
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.
Hardware requirements
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:
- It is not recommended that the Administration Service be installed on a domain controller.
- Typically, organizations install the Administration Service on other application, file, or print servers.
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.
Web Interface: IIS Server required
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.
Availability and redundancy
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.
Major sites
Two guidelines should be followed for major sites:
- Our customers typically deploy two Administration Services per major location/site where AD data administration and user management is performed. This redundant service solution would be effective if both the primary Administration Service and all connections to other sites failed.
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.
- Most customers do not place all of their Administration Services at one location/site. If access to that one location/site should fail, all Administration Service of AD would stop. Instead, they install Administration Services at two or sometimes more sites.
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.
Remote sites
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.
- If few AD administration tasks are performed at a site, then local administrators might access a remote Administration Service. Administrators at remote sites can access an Administration Service at a major location/site. If necessary, native Windows administrative tools can be used to force AD to replicate the changes so that they appear on the local domain controller as soon as possible.
- If local administrators at a site do not normally need access to AD, then an Administration Service would not have to be installed in that site. An administrator at a major site can make changes for a user at a remote site, and if necessary forced replication can cause the changes to appear quickly at the user’s local domain controller.
NOTE: With Active Roles user interfaces, the administrator can deliberately choose the domain controller where to apply the changes, thus eliminating data replication delays.
- An organization might provide one or more administrators at each site with permissions to AD. For example, if a site has five administrators, one administrator would be given permissions to AD. This solution would be acceptable for most sites, except for small sites managed by very low-level administrators.
NOTE: Active Roles allows administrators to push (synchronize) permissions from Active Roles to Active Directory, thus making it easier to manage permissions to AD.