Resulting Application Categories

In the model we use two main criteria to determine the application category:

(1) Integration depth in Active Directory

Examples for "High": The application depends on many different Active Directory objects to be migrated, especially security principals like users and groups, or the objects have to be migrated and cannot be simply re-created or the objects require synchronization after migration.

Example: Exchange must be rebuilt in the new environment; mailbox related Active Directory data must be migrated.

(2) Integration depth in the application or service

Examples for "High": The application contains many references to Active Directory or there is only little knowledge about where these references are hidden or changing the references requires code changes or when migrating application related data, many ACLs or name mappings have to be renewed. The service relocation (name change) requires changes in client-side applications.

Figure 3 Application categories according to integration depths

A main parameter that highly influences the effort and cost is whether the service or application has to be moved or can be re-created in the new environment.

Business applications will have to be moved in most cases, while management services such as System Center Configuration Manager (SCCM) or System Center Operation Manager (SCOM) have to be created in the new environment. Since this might be the case for a number of applications, we created a separate category for these.

The resulting application categories are described in the following paragraphs.

8.3.2.5.1 C1: HIGH AD integration depth, HIGH service integration depth -Complex integration

The application uses a large number of objects in Active Directory. These objects are of different object types and are highly distributed in the Active Directory environment. This application category requires the greatest effort and cost to migrate servers, clients, data, and Active Directory objects. The migration of these

applications requires the migration of application data (inside and outside of the Active Directory environment) as well as the reconfiguration of client-side applications.

These applications often have special requirements on the sequence of user and group migrations and on the state of associated users in both forests (active/passive, passive/active). Therefore, these applications are the drivers for user and application migration. They determine when a certain user and group can be migrated and all other applications have to follow and adapt to the approach.

These applications also create the need to keep associated objects in both forests in sync.

Example: Microsoft Exchange migration from the existing Exchange organization to the new Exchange organization in the new forest.

8.3.2.5.2 C2: HIGH AD integration depth, LOW service integration depth

The service uses many Active Directory objects of different types. The application does not use Windows security principals from AD DS directly, except for a few service and administrative accounts. Instead, it uses LDAP queries and mappings based on user or group names to make access decisions. The application usually reads from the Active Directory database, but writing to the Active Directory database is not excluded.

Thus, we also include Active Directory provisioning solutions like Identity Management solutions here.

The service configuration, though, is very simple to change (for example, change the base DN) and the number of affected application configuration items and servers is also low, that is, fewer than 10 servers, less than 25 configuration items, or other factors that are easily changed and required little effort.

Although the service can be reconfigured quite easily, the service-related objects are mostly security principals. With the migration progress, these security principals may be distributed between the FTM and new forest during the migration and transition phase. This fact must be taken into account specifically.

Synchronization and provisioning tools are often required to support the migration of these applications. In some cases, a virtual directory intermediate directory solution might be required to support the applications during the migration.

If SID mapping is used and there are many configuration objects to change since the SID principals change during migration, the application will rather fall into category C1 or C3.

8.3.2.5.3 C3: LOW AD integration depth, HIGH service integration depth

The service uses a small number of Active Directory objects, in most cases this will be groups. The service configuration, though, is very complex to change and the number of affected servers is also high, that is, more than 10 servers, more than 25 configuration items, or other factors that are more complex to change and require a great deal of effort. Examples are applications that use many folders and files on many NTFS volumes and shares that are protected by ACLs. These ACLs contain the SIDs of groups from the DTM domain.

For this category, the migration of the related Active Directory objects is not the most costly part of the migration. Instead it is the cost of reconfiguring the applications, depending on the available knowledge about where the configuration has to be executed, the number of required changes, and what toolset is available for this task.

8.3.2.5.4 C4: LOW AD integration depth, LOW service integration depth

The service uses a small number of Active Directory objects; in most cases, these will be configuration items.

The application does not use Windows security principals from the Active Directory database, except for a small number of service and administrative accounts. There are no or only a few dependencies on other applications or services.

8.3.2.5.5 C5: Create new service instance in new environment

Special cases are applications that can’t be migrated or when it is a better option to reinstall them without a migration. In principal, these applications can fall in one of the before-mentioned application categories; but from an application, operation, or other perspective, the preferred option is to create a new service instance in the new environment. In most cases, these will be applications that support IT management and

operations tasks and processes.

In this case, migration means to set up a new instance of the service in the new forest. There might be the requirement to integrate or sync both instances to get consolidated views. This is not feasible for all such type of services.