ARS Planning and Architecture FAQ
From ActiveRoles
ActiveRoles Server planning and architecture frequently asked questions.
Active Directory
Q: Does ARS Service require domain admins rights in a domain I am going to manage with ARS?
No, this is not required. It is recommended to use an account with domain privileges as an override account for a managed domain. However, you can select any account and a minimum set of required permissions are described in the ARS QuickStart Guide, Configuring the Administration Service Account section.
Q: What protocols and APIs does ActiveRoles Server use to communicate to AD?
ARS uses Microsoft ADSI LDAP provider to communicate to AD. ADSI LDAP provider is a public and recommended API to operate with AD. SDK documentation is available on MSDN. This provider is implemented as a set of in-process COM objects, which use mainly LDAP API to communicate with Active Directory service on DC. For password reset ADSI LDAP provider can also use RPC.
Overview of AD protocols is available in the Windows 2000 Resource Kit: Protocols and Interfaces to Active Directory.
To bind (e.g. to open a connection) to AD, ARS uses ADsOpenDSObject API call, specifying ADS_SECURE_AUTHENTICATION flag ([1]). This tells ADSI LDAP Provider to "use Kerberos, and possibly NTLM, to authenticate". To provide additional encryption, you can enable LDAP over SSL for your AD and force AR Server to use this feature.
Q: Are there any issues managing same domain by multiple independent ARS instances?
Running two independent, non-replicated instances of ARS over the same domain/environment is not recommended. Such features as dynamic groups, Group Families, user account deprovisioning, policy compliance check would be affected and might work with errors. For example, user considered as deprovisioned in one ARS instance would be considered as "live" in another. Or, different group population rules might overwrite group membership for the same user account with each next change, back and forth depending on which ARS instance processed the change. Do not run multiple non-replicated ARS instanced over the same domain, regardless of their versions. Configure replication between instances or share same configuration DB.
During upgrade of ARS there is a recommended practice to run a limited pilot of new version before rolling it out for the entire enterprise. For this pilot you might want to manage same domain as you do with your current version of ARS. In this case, it is recommended to split management activities between current and new ARS instances, by tasks or by managed scopes. For example, during pilot you can manage same domain with your current and new versions of ARS, but perform all group management operations in new ARS, and not the current one. Or, you can perform all management activities for a selected OU in new ARS, and not in the current one.
Q: How ARS handle forests with different schema extensions?
ARS can be used to manage domain from multiple forests. Those forests does not necessary should have identical schema. One forest can be extended with additional classes and attributes, absent in other forests. For example, user class in one forest can be extended with customAttributeA.
ARS Service consolidates schemas from all managed forests on start into one consolidated schema, so user class in ARS has one set of attributes. For a particular object, if an attribute is not present in the object home forest, the entry for this attribute would be disabled on UI. If you customize Web UI to present custom attribute on user form, Web UI would display an UI entry for this attribute on user form regardless of user account forest. The UI entry would be disabled for user accounts located in forests other then forest with extended schema.
If you want Web UI to hide UI entry for such user accounts you can use a workaround. You can create two different commands and web forms for user properties, one for forest with extended schema, another for other forests, first with UI entry for custom attribute added to form, another - without UI entry. Then you can configure ARS Web UI to show/hide appropriate command depending on user forest. The easiest way would be creating a separate command "Custom Properties" with its own form, presenting custom attribute(s). And define rules to show or hide this command depending on user account forest. To define conditions, you can use Visibility tab of the Web UI command properties (starting with 6.1), or define IsCommandAllowedFilters element in the customization XML document (see ARS SDK for details)
Q: What is the difference between DirSync DC and Operational DC?
(6.1 and below) DirSync DC is a DC that ARS Administration Service uses to communicate with AD. By default, Administration Service selects any available (nearest) DC for a managed domain. This is a per-Serivce per-domain setting. To change this setting, use DirSync Servers tab, either on the managed domain object property sheet (located in the Configuration/Server Configuration/Managed Domains/ folder), or service configuration object property sheet (located in the Configuration/Server Configuration/EDM Servers/ folder).
The DirSync DC is used by Service to load directory data, receive change notification events from AD, lookup information in AD and execute other AD operations. Plus, Service uses DirSync DC by default for all client operations - operations, requested by a particular connected client, until client specified it's own Operational DC.
Operational DC is a DC, specified by client application that is used by Service to execute AD operations, requested by that client. User can set Operational DC for a domain in Snap-in (All Tasks -> Change Operational DC command on the domain object), or in Web Interface (Change Operational DC command on the domain object). User can select "Any writable Domain Controller" option on this dialog, which means usage of DirSync DC for that client. Both Snap-in and Web Interface stores Operational DC between sessions (Snap-in in MSC file, Web Interface in the browser cookie).
When DirSync DC becomes unavailable, Service selects another DC, if "use any available DC (default)" or "use any available DC from this site" options are used. When Operational DC becomes unavailable, Snap-in and Web Interface display an error message and provides user an ability to select another DC.
Q: How ARS Administration Service select Domain Controller to perform AD operations?
(6.1 and below) ARS Administration Service selects DC on start. Every AD operation, either requested by client or by service internal function, is forwarded to this DC. This DC is referred as DirSync DC (this DC used to track changes in AD using the DirSync feature of AD). User can specify other DC for his operations, using the Operational DC command in ARS Snap-in or Web Interface.
By default, Administration Service selects any nearest available DC for a managed domain. This behavior can be configured on per-Serivce per-domain bases. To configure this behavior, use DirSync Servers tab, either on the managed domain object property sheet (located in the Configuration | Server Configuration | Managed Domains folder), or service configuration object property sheet (located in the Configuration | Server Configuration | Administration Services folder).
In addition to nearest available DC, ARS Administration Service selects nearest available Global Catalog server. Selected GC server can be different from selected DirSync DC.
To select a DC, ARS Service uses a standard API function DSGetDCName (link to MSDN). This function returns the nearest DC. Depending on DirSync DC settings described above this function returns "nearest" domain DC from particular site or from any site of the domain. According to Microsoft: "The DC Locator does use optimized logic to provide the DC information as quickly as possible. It also uses cached information at the site to contact the closest DC." For details, please refer to the Domain Controller Location Process article in the Distributed Systems Guide, Windows 2000 Resource Kit.
Each 10 minutes Admin Service validates the availability of the selected DirSync DC. If Service identifies that DC is not available, it selects another DC, until "Only specified domain controller" settings is configured. Until Service selects another DC, every user that does not specify Operational DC will receive an error when trying to perform any operation with AD. Consequently, domain may become unavailable for up to 10 minutes interval.
Additional information:
- If you have DC in the same site with the Administration Service, and that DC become unavailable for some reason (for example, it was restarted), Administration Service will select DC from other site. After the DC in its home site become available, Service will switch back to DC in its home site.
- If you have multiple DCs in the same site with Administration Service, it will not randomly switch from one DC to other each 10 minutes. When other than current DC was identified as nearest DC, Service switch to new DC only if new one is in its home site and current DC is located in another site, e.g. Service never switch between 2 available DCs in the same site.
- When Service selects another DC, it does not reload domain cache. Microsoft implemented DirSync API in such a way that you can switch to other DC and continue receiving changes in AD.
SQL Server
Q: Does ARS support SQL Server 2008?
ARS 6.1 does not support SQL Server 2008. Support for SQL Server 2008 is planned for ARS 6.5, that is going to be released at Q4 2009.
Q: Why ARS requires sysadmin rights on the target SQL Server?
ActiveRoles Server provides simplified replication configuration through the ARS MMC Console. For example, user can promote an Administration Service to Publisher role or to add a replication partner from the ARS MMC Snap-in. In that case ARS MMC Snap-in sends a request to the Administration Service, and Administration Service performs required configuration changes on the SQL Server where the configuration DB is hosted.
To perform replication configuration tasks in SQL Server, the ARS Service database account (used to connect to SQL Server) must belong to sysadmin role. For details see the "Access to SQL Server" section in the Quick Start Guide.
If you do not want to include ARS Service database account to sysadmin role, you can configure required permissions by following instruction in the Solution 8720 (required logon to Quest Support site). This solution is applicable to ARS versions 5.2, 6.0 and 6.1.
Q: What edition of SQL Server should be used with ARS?
SQL Server 2005 comes in different editions ([2]). In your production environment you can use ARS with Enterprise, Standard, Workgroup and Express editions.
Only Express edition does not require you to purchase any SQL CAL or processor licenses. The major limitation of Express edition for ARS deployment is that you can't use it as a publisher in replicated environment. However, you can use SQL Server 2005 Express Edition as a subscriber in replication group with publisher running by Enterprise, Standard or Workgroup editions.
Enterprise, Standard and Workgroup editions can be used for ARS, and in typical environment you would not hit the limitations for Workgroup or Standard editions. Notice that when you license your SQL Server by CAL you may need to purchase a CAL per each user connected to ARS Service. Microsoft calls such SQL Server usage as "multiplexing", details provided here: [3].
Note, that you won't be able to use Quest Knowledge Portal product for advanced reporting management if you are using SQL Server Express with Advanced Services.
For detailed comparison of different editions please refer to this article: [4]
Q: What are SQL Server security best practices while using ARS?
SQL Server Security Best Practices
Hardware
Q: What would be the hardware recommendations for my environment?
Please, refer to the Resource Usage Calculator document, located on the product CD, \Documentation\ActiveRoles Server 6.0\English folder.
Q: What are the reasons of choosing 64-bit platform instead of 32-bit?
Microsoft reports on significant increase of performance for components on which ActiveRoles Server relies to. For example, IIS x64 response time is more than 4 times shorter in comparison with IIS x86. CPU utilization rate (for ISS worker process) is highly improved (34 percent versus 64 percent). Also, there are dramatic improvements for SQL Server and Active Directory performance.
Here are some articles for your consideration:
Inside Microsoft.com: Making the Move to x64
Active Directory Performance for 64-bit Versions of Windows Server 2003
Microsoft SQL Server 2005: Advantages of a 64-bit Environment
ARS Components
Q: Should I install ARS in each remote location?
No, this is not necessary in most cases. Even when connecting to ARS from a remote site, user can specify the DC they need their operation to be forwarded to (called Operational DC). Typically this would be a DC in the user' home site. To select an operational DC, in ARS MMC Snap-in right-click a domain object, click All Tasks and select Operational DC command. In ARS Web UI, click the domain object and select Operational DC command from the left pane. You should consider installing ARS in a remote location if you have multiple delegated admins in that site, they constantly perform management tasks through ARS, and you have low bandwidth connection or connection with high delays (like satellite link) with central site.
Q: What ports should I open if I want to put ARS behind the firewall?
Please, see ARS:Communication Ports for details.
Q: How fault tolerance and redundancy is provided in ActiveRoles Server?
ActiveRoles Server consists of multiple components. To provide maximum fault tolerance level, consider the following guidelines:
- Install multiple Administration Services and combine them into a replication group or share same configuration DB.
- Having only one Administration Service, the Service becomes a single point of failure. It is critical to have at least two Services, combined into replication group or sharing the same configuration database.
- Keep configuration database for publisher on clustered SQL Server.
- ARS relies on SQL Server for replication of configuration data and management history. SQL Server utilizes Publisher/Subscribers replication model. In case of Publisher failure, ARS users will be able to continue managing AD and network resources, but configuration data and change history will not be replicated. To reduce risks and time of replication outage, it is recommended to install SQL Server for publisher on a cluster.
- Install multiple Web Interface instances and optionally combine them into NLB cluster.
- It is recommended to install at least two Web Interfaces, and configure them to share common customization settings. To prevent Web Interface outages in case particular Service goes down, it is recommended to follow one of these two scenarios:
- Install each Web UI on the machine running ARS Service and configure Web UI to connect to the local Service. In this case, integrated authentication will be used for Web UI sites. When underlying Admin Service becomes unavailable, then client trying to access the website will recieve an error: ‘Error: The ActiveRoles Administration Service is not available on <my domain>. Access is denied.’Upon receiving this error message user may go directly to another balancer website which is focused to another Admin Service expected to be functioning.
- Install Web UI on a separate machine and configure it to use any Administration Service. In this case, integrated authentication does not work and basic authentication is selected. It is recommended to configure SSL for Web UI sites to protect user logon credentials passed to Web UI.
- Install each Web UI on the machine running ARS Service and configure Web UI to connect to the local Service. In this case, integrated authentication will be used for Web UI sites. When underlying Admin Service becomes unavailable, then client trying to access the website will recieve an error: ‘Error: The ActiveRoles Administration Service is not available on <my domain>. Access is denied.’
- Configure Administration Service to select any DC for a managed domain (default option).
- To perform operations with AD, Administration Service is permanently listening DirSync DC for AD changes related to ARS configuration workflow (Dynamic Groups, Managed Units membership etc.) Administration Service periodically checks for DirSync DC status. If current DC becomes unavailable then the Administration Service will ask AD for another ‘best DC’ and switch to it. The DirSync DC parameter is set on Managed Domain properties and provide three fault tolerance options: any available DC (default), any available DC from the site, and only specified DC. Last option is not recommended because Service will stop operating with the domain if that DC goes down.
To know what can happen if one of ARS architeсture components stop functioning refer to ARS other frequently asked questions section.
Q: How the network traffic is distributed between ActiveRoles Server components?
Network traffic and the way ARS executes changes and quick search against AD are core factors to be considered at ARS Deployment planning at large scale enterprise. Understanding of the factors brings insight on stress loading on different components and how to distribute available hardware across the deployment, where to expect a cause of performance degradation and potentially where to add new hardware if needed.
In picture above network traffic metrics are chosen in relative numbers in respect to the traffic generated by connection of Admin Service listening DirSync DC which is taken as 100%.
IE client – Web Service (10%): IE opens ARS Website and sends AD change requests to Admin Service (though Web Service) and Web Service sends compiled html pages to a Client back returning answers from Administration Service (show AD object properties, Quick Search results etc.)
Web Service – Admin Service (ARS Management Consol mmc – Admin Service) (30%): Web Service sends requests to Administration Service, receives results back (like OU browsing, AD Object Properties, Quick Search results etc.) compiles html pages and offloads them IE client
Admin Service – Operational DC (25%): (DC-focusing) All AD browsing and change requests are send to the Operational DC (like OU browsing, AD Object Properties, Quick Search results, Changes applied etc.).
Admin Service – DirSync DC (100%): Admin Service listen DirSync DC permanently for changes related to ARS configuration (like Dynamic Groups, Managed Units Membership update etc.)
Admin Service – SQL Configuration db (1%): when user binds to Administration Service (via Website, ARS Consol mmc or ADSI Provider Script) ARS checks the user on what permissions it has inside ARS delegation workflow to view, read, write, modify etc. stored at Configuration db.
Admin Service – SQL Configuration db (10%): when user successfully applies change to AD a Change History Record is recorded at Management History db.
SQL Replication (1%+10%): Configuration db and Management History db are replicated in order to enforce integrity across all deployed ARS instances.
Q: How ARS snap-in and web UI selects Administration Service to connect?
When client application - Snap-in or ADSI Provider, or Web Interface through ADSI Provider - selects an Administration Service to connect, it searches Global Catalog of its home domain for all available Services. Services that did not update its information in AD for the last 2 days are filtered out. Then, client divides all Services into two groups: first goes all Services from client home site, then all other Services. Client sorts Services in each group by load: Services with least load goes first. Then, client tries to connect to the first Service in the first group. If fail, it tries next, and so on. If client fail to connect to the last Service in the second group, then it reports an error message.
In addition, ADSI Provider caches the sorted list of available services and selects the first successfully connected Service for all subsequent connections. The Service list cache has an expiration period that is equal to the period Service used to update information in AD, by default it is 10 minutes.
If Snap-in loose connection to the Service for some reason, it displays an error message and forces user to reconnect. If Web Interface loose connection it displays an error message once and after clicking Refresh it re-connects to another Service (if administrator does not specify a particular Admin Service to connect when deploying Web Interface).
Q: What functionality is missing in ARS Web UI in comparison to ARS MMC Snap-in?
Although ARS Web UI and MMC Snap-in provides similar functionality, they target different audience. ARS Web UI targets delegated admins and IT stuff with Admin and Help Desk web sites, and regular company employees with Self-Service site. Most items listed below as missing in Web UI are not intended for use by the audience. ARS MMC Snap-in targets ARS service admins and people with high IT skills. You should also understand ARS Web UI has its own advantaged over ARS MMC Snap-in.
These are functions, exist in ARS MMC Snap-in (6.1 and below) that are missing in Web UI:
- Configuration node is not provided through Web UI
- Delegate Control, Enforce Policy and Check Policy commands are missing
- Dynamic Groups and Group Families can't be managed with Web UI
- Advanced Properties command is missing, but you customize Web UI with point-and-click customization capabilities to show required attributes on object properties form)
- Edit Native security command is missing
- Additional Account Info page for a user account is missing, but most of the info from this page can be added to user form in Web UI with point-and-click customization capabilities
- Exchange Query Based Distribution Groups cannot be created and managed
Q: What does the Reset command on computer account do?
Reset computer account command sets the computer account password to the following value: first 14 symbols of computer logon name (sAMAccountName), without last "$" symbol. This command is available on member server account only, and not available on a DC computer account. See MSDN KB article 216393 for details.
