4.2 Deploying DSfW in a Name-Mapped Setup

A name-mapped setup refers to a setup where a new DSfW forest is created on an existing eDirectory tree using either a part or the entire eDirectory tree. This enables you to utilize all the user information and other associations in the eDirectory tree. The creation of a DSfW forest into an existing eDirectory tree starts from a specific container. Association of the DSfW forest to a specific container is called mapping and the container is called a mapped container. Different DSfW domains in the DSfW forest are mapped to different DSfW containers. As a prerequisite, the mapped containers must be partitioned.

Though an already existing eDirectory tree can be used for a name-mapped setup, an OES server already configured as an eDirectory server cannot be used to create a domain controller for a DSfW domain. A new server should be added to configure a DSfW domain controller. Before you start the process of installation, refer Installation Prerequisites for a Name-Mapped Setup.

Figure 4-5 represents an example of a name-mapped setup where an existing eDirectory tree T=Global has organization type containers America, Asia, and Europe. Consider a scenario where the container Asia needs to be mapped to a DSfW domain asia.com. As a prerequisite, you must first partition the Asia container and then introduce a new OES server in your eDirectory tree and install DSfW pattern. With successful installation and provisioning of DSfW, the container O=Asia becomes root partition of the DSfW domain. This allows you to utilize all the preexisting users and associations under the subtree starting from the container Asia.

Figure 4-5 Deploying DSfW in an Existing eDirectory Tree

It is also possible to map the partitions underneath O=Asia to a new child domain and skip any levels of containers underneath. Refer section Section 4.2.1, Deploying DSfW by Skipping Containers. So, you can map the OU=India partitioned container to create a new child DSfW domain or directly map OU=Delhi or OU=Sales partitioned container.


Consider the following restrictions while configuring a name-mapped setup:

4.2.1 Deploying DSfW by Skipping Containers

After successful mapping of a container to a DSfW domain, you can map any underlying container to a new DSfW child domain and skip any level of containers in between. For instance, the second level container from a mapped container can be mapped to the immediate DSfW child domain, thus skipping the first level container.

Consider a scenario with an eDirectory tree, as represented in the following figure.

Figure 4-6 Existing eDirectory Tree

As illustrated in Figure 4-7, a domain named asia.com is created which is mapped to the partition o=asia. Now, you can map the partition ou=bangalore to a child domain named blr.asia.com, by excluding the partitions between the domains asia.com and blr.asia.com. The child domain excludes the partition ou=branches. This provides you with an advantage of avoiding an unnecessary server addition and its management in order to maintain the hierarchy.

Figure 4-7 Deploying DSfW by Skipping Containers

4.2.2 Custom Domain Name

DSfW enables you to choose a domain name that need not match the mapped container's typeless RDN. As illustrated in Figure 4-7, you can map the partition ou=bangalore to a DSfW child domain named blr.asia.com. Here the domain component blr is used to map a container with typeless RDN as bangalore.