Active Directory Lightweight Directory Service Part 3

This article continues the discussion of the Active Directory Lightweight Directory Service by demonstrating the procedure for creating an AD LDS instance and a corresponding application directory partition.

In my previous article, I showed you how to install the Active Directory Lightweight Directory Service. In this article, I want to continue the discussion by showing you how to create an AD LDS instance.

The concept of an instance is unique to AD LDS (as opposed to the Active Directory). As I mentioned in a previous article, a single Windows 2008 server can host multiple directories. Each of these directories is referred to as an instance.

You must assign a name to each instance that you create. The name that you choose is used as a mechanism for uniquely identifying the instance on the server.

In addition to assigning the instance a name, you will also have to assign the instance a port number. Normally, LDAP communications take place over port 389 and SSL encrypted LDAP communications take place over port 636. You can use these port numbers for AD LDS, but only if you do not plan to install the Active Directory Directory Services on the server.

One thing to keep in mind is that each AD LDS instance requires a unique port number. Of course this holds true only when there are multiple AD LDS instances present on a single server. If you have a dedicated server for each AD LDS instance, then each instance will be able to use Ports 389 and 636 (assuming that the server isn’t also acting as a domain controller).

Finally, each AD LDS instance has a corresponding application directory partition. When you create an application directory partition, you will be required to provide it with a name. The name that you use can be in either X.500 format or it can be in FQDN format.

Now that I have explained what elements are required for creating an AD LDS instance, let’s go ahead and create one. Begin the process by opening the Active Directory Lightweight Directory Services Setup Wizard. You can find a shortcut to this wizard on the server’s Administrative Tools menu.

When the Active Directory Lightweight Directory Services Setup Wizard starts, click Next to bypass the wizard’s Welcome screen. At this point, you will see a screen similar to the one shown in Figure 1, asking if you want to create a unique instance or a replica of an existing instance. Since we are setting up a new instance, choose the A Unique Instance option. I will be discussing replica instances in Part 4.

Figure 1. Tell Windows that you want to create a unique instance.

Click Next and you will be promoted to provide a name and an optional description for the instance that you are creating, as shown in Figure 2. For the sake of demonstration I will be using the default instance name (which is Instance1). In the real world however, I recommend using a more descriptive name.

Figure 2.You must provide a name and an optional description for the instance that you are creating.

When you click Next, you will be taken to the screen shown in Figure 3. As you can see in the figure, Windows defaults to using port number 50,000 for LDAP communications with the new instance, and port number 50,001 for SSL encrypted LDAP communications. You can change these port numbers to anything that you want (including 389 and 636) so long as those port numbers are not already in use on the server and you do not plan to make the server a domain controller.

Figure 3.Windows defaults to using ports 50,000 and 50,001 for use with the new AD LDS instance.

Click Next, and you will be taken to the screen shown in Figure 4. As you can see in the figure, this screen asks you if you want to create an application directory partition. The application directory partition is essentially a directory enabled repository that you can use for storing application data.

Figure 4.You will almost always want to go ahead and create an application directory partition

Since the whole point of creating an AD LDS instance is to allow for application data to be stored in a directory partition, you will almost always choose the option that creates a new application directory partition. There are really only two situations in which you would not want to create an application directory partition. You would obviously not want to create an application directory partition if you wanted to manually create the partition later on. The other situation in which you wouldn’t want to create an application directory partition would be when you plan to install an application that automatically creates the necessary partition itself.

As I explained earlier, you must provide a name for the application directory partition. You must enter this name as a distinguished name. According to TechNet “AD LDS supports both X.500 style and Domain Name System (DNS) – style distinguished names for top level directory partitions”. Having said that, I have to tell you that I have never seen a DNS style distinguished name used for an application directory partition in the real world. If you look back at Figure 4, you can see that even Microsoft seems to give preference to X.500 style distinguished names because the example distinguished name shown in the screen capture is in X.500 style format.

Regardless of the type of distinguished name that you choose to enter, it is important to get the name right on the first try. Otherwise, Windows will allow you to get all the way to the end of the wizard before giving you an error.

After you have provided a distinguished name for the partition that you are creating, click Next and you will be prompted to specify a path beneath which to store the data files and the data recovery files that are to be used with the AD LDS instance. This portion of the wizard, which you can see in Figure 5, should seem familiar to anyone who has ever set up an Active Directory domain controller.

Figure 5. You must provide a path to be used by the AD LDS database.

In an Active Directory environment, it is usually acceptable to use the default path. When it comes to AD LDS however, you may want to redirect the data files and the data recovery files to a high speed or fault tolerant array, depending on how extensively the AD LDS instance will be used.

After providing the necessary paths, click Next and you will be prompted to provide a service account for use with the AD LDS instance. You can use a network service account, or you can provide a domain service account. Of course servers that host AD LDS instances are not always domain members, so in some cases you may be forced to use network service accounts.

Click Next, and you will be prompted to specify the name of a user or a group who should have administrative access to the partition that you are creating. By default, Windows will use the account that you are logged on with when you create the account, as shown in Figure 6, but you are usually going to be better off manually specifying an administrative group.

Figure 6. Specify the name of the user or group that should have administrative control over the AD LDS instance

After clicking Next, you should see a screen asking you which LDIF files you want to import. The LDIF files that you select will establish the schema for the instance. You are free to select any of the LDIF files or any combination of the files. The documentation for the application that will be making use of the AD LDS instance should provide you with guidance as to which LDIF files to import.

When you click Next, you should see a summary of the options that you have selected throughout the wizard. Assuming that everything appears to be correct, click Next and the AD LDS instance will be created.  When the process completes, click Finish to close the wizard.

Conclusion

In this article, I have shown you how to go about creating an AD LDS instance and the corresponding application data partition. In Part 4, I will show you how to create a replica of the partition that you have just created.

Setting up Transactional Replication in SQL Server 2008 R2.

Replication is one of the High Availability features available in SQL Server. Transactional Replication is used when DML or DDL schema changes performed on an object of a database on one server needs to be reflected on the database residing on another server. This change happens almost in real time (i.e. within seconds). In this article, I will demonstrate the step by step approach to configuring transactional replication in SQL Server 2008 R2.

Scenario: An Address table which belongs to the Person schema in the Adventureworks Database is replicated to the Adventureworks_Replication database residing on the same server. The Adventureworks_Replication database acts as a subscriber. The subscriber is normally present on a  separate database server.

Before we start with the configuration, we need to understand three important terms:

1. Publisher
2. Subscriber
3. Distributor Database

Let’s discuss each these in detail.

Publisher:

The Publisher can be referred to as a database on which the DML or DDL schema changes are going to be performed.

Subscriber:

The Subscriberis the  database which is going to receive the DML as well as DDL schema changes which are performed on the publisher. The subscriber database normally resides on a different server in another location.

Distribution Database:

A database which contains all the Replication commands. Whenever any DML or DDL schema changes are performed on the publisher, the corresponding commands generated by  SQL Server are stored in the Distribution database. This database can reside on the same server as the publisher, but it is always recommended to keep it on a separate server for better performance. Normally, I have observed that if you keep the distributoion database on the same machine as that of the publisher database and if there are many publishers then it always has an impact on the performance of the system. This is because for each publisher, one distrib.exe file gets created.

Let us now begin with the Configuring of the Transactional Replication.

There are 3 steps involved for Configuring the Transactional Replication:

1. Configuring the Distribution Database.

2. Creating the publisher.

3. Creating the subscriber.

Configuring the Distribution Database

1. Connect to the Microsoft SQL Server 2008 R2 Management Studio.

2.  Right Click on the Replication node and Select Configure Distribution as shown in the screen capture below:

3. A new window appears on the screen as shown in the screen capture below:

4. Click  the Next> button and a new window appears on the screen as shown in the screen capture below:

5. As you can see in the above screen capture, it gives the user two choices. The first choice says that whether the server on which the Replication will be configured will be Hosting the distribution database. The second choice asks the user whether some other server will be Hosting the distribution database. The user can select any one of the either choices are per his/her requirements. I decide to use the First option, i.e. the server on which the Replication is configured will itself be holding the distribution database. Then Click on the Next> button as shown in the screen capture above.

6. A new window appears as shown in the screen capture below:

7. Select the first option, i.e. Yes, configure the SQL Server Agent service to start automatically and click on the Next> button as shown in the screen capture above.

8. A new window appears on the screen as shown in the screen capture below:

As you can see in the above screen capture, you are asked where the Snapshot folder should reside on the Server. Let us first understand what the Snapshot folder exactly is.

The Snapshot Agent prepares snapshot files containing schema and data of published tables and database objects, stores the files in the snapshot folder. This folder should never be placed on the C drive of the server i.e. the drive which is hosting the Operating System.

Create a folder on any other drive to hold the Snapshot folder and Click on the Next> button as shown in the screen capture above.

9. A new window appears as shown in the screen capture below:

As you can see in the above screen capture, it displays information such as what will be the distribution database name, the location where the data and the log file will reside. Click on the Next> button as shown in the screen capture above.

10. A new window appears as shown in the screen capture below:

11. Click on the Next> button.

12. Click on the Next> button as shown in the screen capture below:

13. Click on the Finish button as shown in the screen capture below:

14. Once done, a new database named distribution gets created. In order to confirm it just expand the System Database node and you shall be able to view the distribution database, please refer the screen capture below:

Creating the Publisher

The following steps need to be followed while creating the publisher.

1. Right Click on Local Publications and select New Publications, please refer the screen capture below:

2. Click on the Next> button as shown in the screen capture below.

3. Select the database which is going to act as a publisher. In our case, I select the AdventureWorks database. Please refer the screen capture below and Click on the Next> button.

4. Select Transactional Replication from the available publication type and Click on the Next> button as shown in the screen capture below:

5. Select the Objects that you want to publish. In this example, we will select a table named Person which we need to Replicate. Select the table as shown in the screen capture below and Click on the Next> button. One important point to note is that Only those tables can be replicated in Transaction Replication which has a Primary Key column in it.

6. Since there are no filtering conditions, Click on the Next> button as shown in the screen capture below:

7. Check the first radio button as shown in the screen capture below and Click on the Next> button.

8. Click on the Security Settings tab as shown in the screen capture below.

A new window appears as shown in the screen capture below.

Select Run under the SQL Server Agent service account as the account under which the Snapshot Agent process will run and Connect to the publisher By impersonating the process account as shown in the screen capture below and then Click on the OK button.

Click on the Next> button as shown in the screen capture below.

9. Click on the Next> button as shown in the screen capture below.

10. Give a suitable name to the publisher ad Click on the Finish button as shown in the screen capture below.

Creating the Subscriber

Once the publisher is created the next step is to create the subscriber for it.

The following steps needs to be performed for creating the subscriber.

1. Right Click on the publisher created and select New Subscriptions as shown in the screen capture below.

2. Click on the Next> button as shown in the screen capture below.

3. Click on the Next>  button as shown in the screen capture below.

4. Click on the Next> button as shown in the screen capture below.

5. As shown in the screen capture below, it asks for the Subscriber name as well as the subscription database. The subscriber database can be created by restoring the publisher database at the start itself or by creating a new database as shown in the screen capture below.

If you have already restored the backup of the database which is a publisher, then the database name will appear in the dropdown as shown in the screen capture below:

If we wan’t to now create the subscriber database then it can be done as follows:

Click on New Database as shown in the screen capture below.

A new window appears as shown below. Give a suitable database name as well as the path where the data and log file are going to reside.

Click on the OK button.

If the subscriber is some other server, then the following steps need to be performed.

Click on the down arrow available on the Add Subscriber button as shown in the screen capture below.

Click on Add SQL Server Subscriber as shown in the screen capture above.

A new window appears which asks for the SQL Server Name as well as the Authentication neeed to connect to the SQL Server, please refer the screen capture below.

6. Click on the Next> button as shown in the screen capture below.

7. Click on the button as shown in the screen capture below. Here we need to specify

Process account as well as the connection options for the distribution agent.

.  A new window appears as shown in the screen capture below.

9. Specify the distribution agent to run under the SQL Server Agent Service Account. Also connect to the distributor as well as the subscriber by impersonating the process account. Please refer the screen capture below.

10. Click on the OK button as shown in the screen capture above.

11. Click on the Next> button as shown in the screen capture below.

12. Ensure that the Agent is scheduled to Run Continuously and then click on the Next> button as shown in the screen capture below.

13. Ensure that the Subscriber is initialized immediately and then click on the Next> button as shown in the screen capture below.

14. Click on the Next> button as shown in the screen capture below.

15. Click on the Finish button as shown in the screen capture below.

16. This creates a subscriber for the corresponding publisher.

17. Expand the publisher node and you shall be able to view the subscriber as shown in the screen capture

Thus, we have successfully set the Transactional Replication in SQL Server 2008 R2.