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.

Active Directory Lightweight Directory Service Part 1

Introduction

many directory services requirements for an organization. However, AD DS also has many dependencies that make its deployment and management a complex task. Because AD DS provides the core authentication and authorization services for most organizations, it can also be very difficult to make changes such as schema changes to the directory. At the same time, many organizations are deploying applications that use an external directory service. These applications may require the directory service to provide authentication services or to store application configuration information.

Although AD DS could be configured to support these applications, this may not be the best solution because of the issues related to incompatible schema change, replication traffic, or the risks of making changes to the infrastructure directory. As an alternative, Windows Server 2008 provides the Active Directory Lightweight Directory Services (AD LDS) server role, which you can use to deploy a Lightweight Directory Access Protocol (LDAP)–compliant directory service to provide support for these directory-enabled applications. AD LDS provides much of the same directory service functionality as AD DS but does not require the deployment of domains or domain controllers. AD LDS provides a much more flexible deployment model; for example, you can run multiple instances of AD LDS concurrently on a single computer, with an independently managed schema for each AD LDS instance. You can also configure AD LDS replication so that the same AD LDS data is distributed across multiple computers.

AD LDS Overview

The Lightweight Directory Service is useful for situations in which applications need access to a directory service, but you do not want to risk compromising your Active Directory database. In this article, you will be introduced to the Lightweight Directory Services, its uses, and capabilities.

When Microsoft introduced the Active Directory with Windows 2000, it didn’t take long before people began to realize that the Active Directory was really little more than a centralized database, and that the Active Directory could be used for purposes for which it was never intended.

For a while, it seemed as though almost every software vendor was designing their wares to be Active Directory integrated. Many such applications stored their configuration information in the Active Directory, and some even whet so far as to actually treat the Active Directory as an alternative to a SQL database and store actual application data in the Active Directory database.

Today, most of the third party software publishers seem to take less invasive approach to the way that they interface with the Active Directory. Many applications read Active Directory data, but not nearly as many applications seem to store data within the Active Directory as did a few years back. Although I can only speculate on the reasons for this, I suspect that it has something to do with the fact that the Active Directory has become a critical component of the network infrastructure, and many administrators are reluctant to perform unnecessary schema extensions (which are almost always necessary to support applications that store data within the Active Directory).

Even though software publishers may not use the Active Directory to quite the extent that they once did, I think that it is safe to say that the Active Directory can be very useful for supporting various applications. To show you what I mean, consider the fact that Microsoft still designs many of their server applications with a high degree of Active Directory integration. Exchange Server 2007 and Exchange Server 2010 for example, are designed in such a way that all of the server configuration information is stored in the Active Directory, rather than being stored locally on the server. The advantage to doing so is that it makes it possible to regenerate a failed server on the fly.

Suppose for instance that you had a catastrophic hard disk failure on an Exchange 2010 server that was hosting the Hub Transport Server Role. Because of the way that Exchange stores its configuration information in the Active Directory, you wouldn’t even have to restore a backup in order to fix the problem. Instead, you would start out by resetting the Computer account for the failed server within the Active Directory. You would then install Windows and any applicable service packs onto a new server. Next, you would assign that server the same computer name as your failed server had used, and join the new server to the Active Directory. Because you reset the Active Directory computer account, the new server is able to use it.

From there, fixing the problem is as simple as running Exchange Server’s Setup program with a special switch. Setup installs the necessary binaries, and then configures the server according to the configuration information found in the Active Directory. The new server can be up and running in less than an hour, and without ever restoring a backup.

My point is that the Active Directory can be very useful for application support, but that many software publishers are reluctant to use it to the extent that Microsoft does, because of the stigma that’s attached to making Active Directory schema extensions.

Another reason why you don’t see more software publishers storing a lot of data in the Active Directory has to do with Active Directory replication. Generally speaking, any data that is stored in the Active Directory must be replicated to all of the domain controllers in the domain (possibly even all of the domain controllers in the forest). As such, if an application were to store a large volume of data in the Active Directory, that data could impact the speed of the normal replication process – especially if that data changes frequently.

In spite of these challenges, there is a way to reap the benefits of Active Directory integration, without impacting your Active Directory database in the process. Windows Server 2008 and Windows Server 2008 R2 include a service called the Active Directory Lightweight Directory Service, or AD LDS.  A similar service also exists in Windows Server 2003, but goes by the name Active Directory Application Mode (or ADAM).

Conclusion

Now that I have talked about what the AD LDS means and what it is used for, I want to turn my attention to using this service in your own organization. In Part 2, I will begin discussing the hardware and the software requirements for using AD LDS.

In case you are not familiar with AD LDS, it provides you with an environment that is very similar to, but completely separate from, the Active Directory. AD LDS is a standalone service that has no dependency on the Active Directory Directory Service. In fact, it is common to deploy AD LDS in environments in which no Active Directory domains exist.

A perfect example of such a situation is Microsoft Exchange Server. Earlier I said that Exchange Server 2007 and 2010 are both designed to store all of their configuration information in the Active Directory database. There is one big exception to this however.

Exchange Server defines a series of roles that dictate how an Exchange Server is configured, and what tasks the server performs. All but one of the server roles are designed to store the server configuration in the Active Directory.

The server role that does not use the Active Directory is known as the Edge Transport Server Role. The Edge Transport Server is designed to reside at the network perimeter and keep the other Exchange Servers from being directly exposed to the Internet.

Because the Edge Transport Server is exposed to various Internet based threats, making it a member of an Active Directory domain could be a potential security risk. If someone were able to compromise the edge transport server, they may be able to use it to gain information about the Active Directory.

To keep this from happening, the Edge Transport Server cannot be a domain member, and it cannot host any other Exchange Server roles. Even so, the Edge Transport Server does require access to a minimal amount of Active Directory information so that it can do its job. Rather than provide the server with direct access to the Active Directory, Microsoft has designed the Edge Transport Server role to use AD LDS.

One of the backend Exchange Servers reads the required information from the Active Directory, and sends the information to the AD LDS partition on the Edge Transport Server. That way, the Edge Transport Server has access to the information that it needs, without being able to access the Active Directory. Incidentally, the Edge Transport Server also stores its own configuration information in the AD LDS partition, just as other Exchange Server roles store configuration information in the Active Directory.

Whats new in windows 2008 Active Directory

As an Active Directory administrator very curies about the windows 2008 features compare to the earlier version like windows 2003, Windows 2008 comes with the whole bunch of features, and am going to discuss specific about the features of Active Directory server roles in 2008

First I will list the features of Active directory 2008 and will discuss in detail of each in my upcoming article

Auditing

Now you can know the previous and present values for the changed attributes of the active directory object using the new auditing feature in windows 2008, as per the windows 2003 auditing you will only know the present values of the changed attribute

This is very useful features in windows 2008 since you can revert back the changes using the previous value of the attribute

Fine-Grained Passwords

By default in windows 2003 all the user account in the domain should use the same password policy configured in domain level, thats why we called domain is a security boundary, if you require a different password policy then you have to create new domain

In windows 2008 password policy can be configured for specific group of peoples with in the domain

Read-Only Domain Controller

Every one know about the BDC (backup domain controller) and it’s a same as the BDC but it only take the advantages from the BDC and it’s specifically designed for the today’s requirements like branch office setup and to managing the branch office

We all know how difficult to design and manage the domain controller from the branch office, some time it lead to the lingering object, but using the Read-Only Domain Controller
In the branch office where the physical security of the domain controller is in question, or domain controllers that host additional roles, requiring other users to log on and maintain the server

In any Active Directory environment if one Domain Controller not replicated with the partner Domain Controller more then one month, then it’s a very critical issue you have to rectify the replication problem as soon as possible or the Domain Controller needs to be decommissioned with in the tombstone lifetime, since its read-only domain controller no worries about the tombstone time.

Restartable Active Directory Domain Services

Hey good new, now no need to restart the domain controller for every time for the active directory maintenance.

In windows 2008 active directory is a services, you can stop or restart the services for maintenance without restarting the domain controller and restarting it in Directory Services Restore Mode is not required for most maintenance functions, however still some maintenance function require Directory Services Restore Mode

Database Mounting Tool

Active Directory Database mounting tool in Windows Server 2008 to create and view snapshots of data that is stored in Active Directory Domain Services, and no need to restart the domain controller. A snapshot is a shadow copy created by the Volume Shadow Copy Service, at different times so that you can better choose which data to restore after object deletion. This reduces the administrator time and no need to restore multiple backups to compare the Active Directory data.

Active Directory Database mounting tool can be called Snapshot Viewer, Snapshot Browser, and Active Directory data mining tool.

Active Directory Recycle Bin

You can restore the accidentally deleted Active Directory object, without Active Directory authoritative restore, this can be used for single object restore like a accidental deletion of user or OU and you can reduce the domain controller downtime

Active Directory module for Windows PowerShell

PowerShell available on windows 2003 itself, however it’s not fully supported for Active Directory, you can’t manage the Active Directive using the PowerShell in windows 2003

In windows 2008 Windows PowerShell provides command-line scripting for administrative, configuration, and diagnostic tasks

You can manage the Active Directory with Exchange Server, Group Policy, and other services and it’s very easy to use like a windows commands, you can easily pipe cmdlets to build complex operations

Active Directory Administrative Center

It’s new tool in windows 2008 R2 to manage active directory, we already have active directory users and computer to manage the active directory, using this new tool you can manage active directory in a new way

As an administrator you perform most of the task commonly that is daily, some how it’s hard to open an active directory user and computer and find the object and do the task, in this new tool Active Directory Administrative Center it’s very easy to do a common task like password reset and search the Active Directory object and others

Active Directory Best Practices Analyzer

This can be helped to identify and implement the best practices in the configuration of your active directory environment, this will scan your network and find the best practice violations,
Then you can correct that, to get the best out of Active Directory services in windows 2008.

Active Directory Web Services

Active Directory Web Services is give you the Web service interface to Active Directory domains and AD LDS instances (Active Directory Lightweight Directory Services)

Active Directory Database Mounting Tool uses the Active Directory Web Services as a front end, like that Windows PowerShell and Active Directory Administrative Center is used the Active Directory Web Services to access the directory service instances.

Offline domain join

Offline domain join makes to join a member server to the domain even the domain controller not reachable from the member server

And this can be very useful for bulk deployment, when the system starts, it will automatically joined to the domain, this will reduce the administrative effort

Managed Service Accounts

Normally applications and services uses the Local Service and Network Service and Local System accounts, it’s easy to configure and shared among multiple applications and services and cannot be managed on a domain level

You can use the domain account for the application (services), this can isolate the privileges for the application, but it’s very hard to manage these domain accounts like password management

We have two new types of accounts, Managed service accounts and virtual accounts in windows 2008, now you can easily manage the service principal names (SPNs), it will provide Automatic password management

Active Directory Management Pack

You can monitor the Active Directory service on windows 2008 using the Active Directory Management Pack (MOM, SCOM)

Designed specifically to monitor the performance and availability of Active Directory Domain Services (AD DS), also monitors the overall health of AD DS and alerts you to critical performance issues.

Active Directory Lightweight Directory Service

Introduction

The Lightweight Directory Service is useful for situations in which applications need access to a directory service, but you do not want to risk compromising your Active Directory database. In this article, you will be introduced to the Lightweight Directory Services, its uses, and capabilities.

When Microsoft introduced the Active Directory with Windows 2000, it didn’t take long before people began to realize that the Active Directory was really little more than a centralized database, and that the Active Directory could be used for purposes for which it was never intended.

For a while, it seemed as though almost every software vendor was designing their wares to be Active Directory integrated. Many such applications stored their configuration information in the Active Directory, and some even whet so far as to actually treat the Active Directory as an alternative to a SQL database and store actual application data in the Active Directory database.

Today, most of the third party software publishers seem to take less invasive approach to the way that they interface with the Active Directory. Many applications read Active Directory data, but not nearly as many applications seem to store data within the Active Directory as did a few years back. Although I can only speculate on the reasons for this, I suspect that it has something to do with the fact that the Active Directory has become a critical component of the network infrastructure, and many administrators are reluctant to perform unnecessary schema extensions (which are almost always necessary to support applications that store data within the Active Directory).

Even though software publishers may not use the Active Directory to quite the extent that they once did, I think that it is safe to say that the Active Directory can be very useful for supporting various applications. To show you what I mean, consider the fact that Microsoft still designs many of their server applications with a high degree of Active Directory integration. Exchange Server 2007 and Exchange Server 2010 for example, are designed in such a way that all of the server configuration information is stored in the Active Directory, rather than being stored locally on the server. The advantage to doing so is that it makes it possible to regenerate a failed server on the fly.

Suppose for instance that you had a catastrophic hard disk failure on an Exchange 2010 server that was hosting the Hub Transport Server Role. Because of the way that Exchange stores its configuration information in the Active Directory, you wouldn’t even have to restore a backup in order to fix the problem. Instead, you would start out by resetting the Computer account for the failed server within the Active Directory. You would then install Windows and any applicable service packs onto a new server. Next, you would assign that server the same computer name as your failed server had used, and join the new server to the Active Directory. Because you reset the Active Directory computer account, the new server is able to use it.

From there, fixing the problem is as simple as running Exchange Server’s Setup program with a special switch. Setup installs the necessary binaries, and then configures the server according to the configuration information found in the Active Directory. The new server can be up and running in less than an hour, and without ever restoring a backup.

My point is that the Active Directory can be very useful for application support, but that many software publishers are reluctant to use it to the extent that Microsoft does, because of the stigma that’s attached to making Active Directory schema extensions.

Another reason why you don’t see more software publishers storing a lot of data in the Active Directory has to do with Active Directory replication. Generally speaking, any data that is stored in the Active Directory must be replicated to all of the domain controllers in the domain (possibly even all of the domain controllers in the forest). As such, if an application were to store a large volume of data in the Active Directory, that data could impact the speed of the normal replication process – especially if that data changes frequently.

In spite of these challenges, there is a way to reap the benefits of Active Directory integration, without impacting your Active Directory database in the process. Windows Server 2008 and Windows Server 2008 R2 include a service called the Active Directory Lightweight Directory Service, or AD LDS.  A similar service also exists in Windows Server 2003, but goes by the name Active Directory Application Mode (or ADAM).

In case you are not familiar with AD LDS, it provides you with an environment that is very similar to, but completely separate from, the Active Directory. AD LDS is a standalone service that has no dependency on the Active Directory Directory Service. In fact, it is common to deploy AD LDS in environments in which no Active Directory domains exist.

A perfect example of such a situation is Microsoft Exchange Server. Earlier I said that Exchange Server 2007 and 2010 are both designed to store all of their configuration information in the Active Directory database. There is one big exception to this however.

Exchange Server defines a series of roles that dictate how an Exchange Server is configured, and what tasks the server performs. All but one of the server roles are designed to store the server configuration in the Active Directory.

The server role that does not use the Active Directory is known as the Edge Transport Server Role. The Edge Transport Server is designed to reside at the network perimeter and keep the other Exchange Servers from being directly exposed to the Internet.

Because the Edge Transport Server is exposed to various Internet based threats, making it a member of an Active Directory domain could be a potential security risk. If someone were able to compromise the edge transport server, they may be able to use it to gain information about the Active Directory.

To keep this from happening, the Edge Transport Server cannot be a domain member, and it cannot host any other Exchange Server roles. Even so, the Edge Transport Server does require access to a minimal amount of Active Directory information so that it can do its job. Rather than provide the server with direct access to the Active Directory, Microsoft has designed the Edge Transport Server role to use AD LDS.

One of the backend Exchange Servers reads the required information from the Active Directory, and sends the information to the AD LDS partition on the Edge Transport Server. That way, the Edge Transport Server has access to the information that it needs, without being able to access the Active Directory. Incidentally, the Edge Transport Server also stores its own configuration information in the AD LDS partition, just as other Exchange Server roles store configuration information in the Active Directory.

Now that I have talked about what the AD LDS is and what it is used for, I want to turn my attention to using this service in your own organization. In Part 2, I will begin discussing the hardware and the software requirements for using AD LDS.

The Planning Process

Planning for the deployment of AD LDS can actually be something of a trial and error experience because Microsoft really doesn’t give you a lot to go on. If you look at Microsoft’s AD LDS Overview on TechNet, you can see that the Hardware and Software Considerations section consists of a block of text telling you to “Use performance counters, testing in the lab, data from existing hardware in a production environment, and pilot roll outs to determine the capacity needs of your server.”

So what is Microsoft really saying here? Well, I think that the statement in the paragraph above can best be summarized like this:

In order to deploy AD LDS, one needs only to have a server that is capable of running Windows Server 2008. However, depending on how AD LDS is being used the server may have to support a considerable workload. It is therefore necessary to take measures to ensure that your server hardware is up to the job.

If this statement is true, then the most logical approach to AD LDS planning is to take a look at the types of resources AD LDS consumes, and base any capacity planning efforts on those types of resource consumption.

Being that Microsoft doesn’t seem to provide a lot of clear guidelines for AD LDS capacity planning, I tend to think that one of the best approaches is to treat the capacity planning process similarly to the capacity planning process that you would use for domain controllers. After all, an AD LDS server is very similar to a domain controller. Both AD LDS servers and domain controllers host nearly identical directory services. Of course there are differences that you have to keep in mind. Active Directory capacity planning usually takes the number of users into account, while AD LDS capacity planning is usually more about anticipating the number of LDAP requests that will be made against the server. However, both Active Directory and AD LDS capacity planning often require you to plan for things like topology and replication.

The Differences between Domain Controllers and AD LDS Servers

Of course even though domain controllers and AD LDS servers are very similar at the architectural level, the simple fact that domain controllers are used to authenticate logins and implement Windows security policies means that there are some aspects of domain controller planning that simply will not apply to the planning process for AD LDS.

One such difference is that AD LDS does not use the concept of forests like the Windows Active Directory does. In an Active Directory environment, a forest is a collection of domains. Every forest is completely independent, although forests can be joined together through the use of federated trusts.

AD LDS does not use the concept of forests and domains like Windows domain controllers do. Instead, the primary structural element used by AD LDS is that of a service instance (which Microsoft often refers to as an instance).  An instance refers to a single AD LDS partition. Each instance has its own individual service name, directory data store, and service description.

As I’m sure you probably already know, a Windows domain controller can only service a single domain. In contrast, a single server running AD LDS can host multiple instances. This means that a single AD LDS server can contain multiple directories.

Of course this raises an interesting question. In an Active Directory environment, clients communicate with domain controllers using the Lightweight Directory Access Protocol (LDAP). Like most other protocols, LDAP is designed to use specific port numbers. For example, LDAP typically uses port 389 for directory queries. If LDAP communications need to be encrypted then port 636 is uses instead. Domain controllers that are functioning as global catalog servers use ports 3268 and 3269 for global catalog related functions. With all of this in mind, you may be wondering which ports AD LDS uses.

Well, AD LDS does not have to worry about performing any global catalog functions, so we can rule out the use of ports 3268 and 3269 right off the bat. AD LDS does however make use of ports 389 and 636 in exactly the same way that a domain controller would.

So what happens if a server is hosting multiple AD LDS instances? Typically, the first instance to be created would be assigned to use ports 389 and 636. When the second instance is created, Windows sees that these ports are in use, and begins scanning for unused ports beginning with port 50,000. Assuming that port 50,000 is available it will be used for standard LDAP communications with the second AD LDS instance. Port 50,001 will be used for SSL encrypted LDAP communications with the second AD LDS instance.

If you were to create a third AD LDS instance on the server, then Windows would see that ports 389 and 636 were in use, so it would begin looking for unused ports starting with 50,000. Since ports 50,000 and 50,001 have already been assigned, the third LDAP partition will be assigned to ports 50,002 and 50,003.

DNS Requirements

Another difference between the Active Directory and AD LDS is that the Active Directory is totally dependent on DNS servers. Without DNS, the Active Directory cannot function. AD LDS on the other hand does not require DNS.

In some ways this makes sense. The Active Directory uses DNS as a mechanism for maintaining the domain hierarchy. There is no domain hierarchy associated with AD LDS, so DNS is unnecessary.

Installing the Active Directory Lightweight Directory Service

Installing AD LDS is actually a very simple process. To do so, open the Server Manager, and then click on the Add Roles link. When you do, Windows will launch the Add Roles Wizard. Click Next to bypass the wizard’s welcome screen and you will be taken to a screen that displays all of the available server roles.

Select the Active Directory Lightweight Directory Services check box, as shown in Figure A.

Figure A: Active Directory Lightweight Directory Service.

Click Next, and you will see an introductory screen that explains what the AD LDS is and what it does. Click Next and Windows will display a confirmation message indicating that the AD LDS server role is about to be installed. Click theInstall button to begin the installation process.

The entire installation process usually only takes about 30 seconds to complete. After the server role finishes installing, click the Close button to complete the installation process. Unlike some of the Windows 2008 server roles, installing the AD LDS role does not require you to reboot the server.

Conclusion

In this article, I have explained some of the differences between the Active Directory and AD LDS. In Part 3 of this series, I will begin showing you the basics of working with AD LDS.

Windows 2008 Server Role Servers Explained

A server on a network – standalone or member – can function in a number of roles. As the needs of your computing environment change, you may want to change the role of a server. By using the Server Manager and the Add Roles Wizard, you can install Active Directory Domain Servers to promote a member server to a domain controller, or you can install individual roles or combinations of various roles, such as DHCP, WINS, and DNS.

It is also relatively straightforward to demote a domain controller to a simple role server or remove any number of roles and features from a server.

Server Manager is the key configuration console you will use for installing server roles and features on your server. It can be configured to open automatically as soon as you log in to the
Windows console or desktop.

Types of roles

Let’s look at the various roles and features you can install on Windows Server 2008.

Active Directory Certificate Services (AD CS)
AD CS role services install on a number of operating systems, including Windows Server 2008, Windows Server 2003, and Windows 2000 Server. Naturally the fullest implementation of AD CS is only possible on Windows Server 2008. You can deploy AD CS as a single standalone certification authority (CA), or you can deploy multiple servers and configure them as root, policy, and certificate issuing authorities. You also have a variety of Online Responder configuration possibilities.

Active Directory Domain Services (AD DS)
This is the role in the Windows Server 2008 operating system that stores information about users, computers, and other resources on a network. AD DS is also used for directory-enabled applications such as Microsoft Exchange Server.

Active Directory Federation Services (AD FS)
AD FS employs technology that allows users over the life of a single online session to securely share digital identity and entitlement rights, or ‘”claims” across security and enterprise boundaries. This role – introduced and supported on all operating systems since Microsoft Windows Server 2003 R2 – provides Web Single Sign-On (SSO) services to allow a user to access
multiple, related Web applications.

Active Directory Lightweight Directory Services (AD LDS)
This service is ideal if you are required to support directory-enabled applications. AD LDS is a Lightweight Directory Access Protocol (LDAP) compliant directory service.

Active Directory Rights Management Services (AD RMS)
This service augments an organization’s security strategy by protecting information through persistent usage policies. The key to the service is that the right management policies are bound to the information no matter where it resides or to where it is moved. AD RMS is used to lock down documents, spreadsheets, e-mail, and so on from being infiltrated or ending up in the wrong hands. AD RMS, for example, prevents e-mails from being accidentally forwarded to the wrong people.

The Application Server role
This role supports the deployment and operation of custom business applications that are built with Microsoft .NET Framework. The Application Server role lets you choose services for applications that require COM+, Message Queuing, Web services, and Distributed Coordinated Transactions.

DHCP and DNS
These two roles install these two critical network service services required for every network. They support Active Directory integration and support IPv6. WINS is not classified as a key role for Windows Server 2008, and you install it as a feature, discussed later.

Fax Server role
The fax server lets you set up a service to send and receive faxes over your network. The role creates a fax server and installs the Fax Service Manager and the Fax service on the server.

File Server role
This role lets you set up all the bits, bells, and whistles that come with a Windows file server. This role also lets you install Share and Storage Management, the Distributed File System (DFS), the File Server Resource Manager application for managing file servers, Services for Network File System (NFS), Windows File Services, which include stuff like the File Replication Service (FRS), and so on.

Network Policy and Access Services
This provides the following network connectivity solutions: Network Access Protection (NAP), the client health policy creation, enforcement, and remediation technology; secure wireless and wired access (802.1X), wireless access points, remote access solutions, virtual private network (VPN) services, Radius, and more.

Print Management role
The print services provide a single interface that you use to manage multiple printers and print servers on your network.

Terminal Services role
This service provides technologies that enable users to access Windows-based programs that are installed on a terminal server. Users can execute applications remotely (they still run on the remote server) or they can access the full Windows desktop on the target server.

Universal Description, Discovery, and Integration (UDDI)
UDDI Services provide capabilities for sharing information about Web services. UDDI is used on the intranet, between entities participating on an extranet, or on the Internet.

Web Server role
This role provides IIS 7.0, the Web server, ASP.NET, and the Windows Communication Foundation (WCF).

Windows Deployment Services
These services are used for deployment of new computers in medium to large organizations.

Features

Server Manager also lets you install dozens of features on Windows Server 2008. These so-called features are actually programs or supporting layers that support or augment the functionality of one or more roles, or simply add to the functionality of the server. A good example of a feature is the clustering service. Now called Failover Clustering, this feature can be used to support mission-critical roles such as File Services, Printer Services, and DHCP Server, on server clusters. This provides for higher availability and performance.

Other features you will likely install include SMTP Server, Telnet Client and Server, Group Policy Management (for use with Active Directory), Remote Assistance, and more.

Invoke Best Practices Analyzer on remote servers using PowerShell

Best Practices Analyzer (BPA) is a management tool integrated in Windows Server 2008 R2 used to scan server roles according to Microsoft best practice guidelines.

Included in the initial release for Windows Server 2008 R2 are the following BPA models:

• Active Directory Domain Services
• Active Directory Certificate Services
• Domain Name System (DNS) Server
• Remote Desktop Services
• Web Server (IIS)

Since then several new BPA models are released and available both as separate downloads as well as through Windows Update:

• Active Directory Rights Management Services (AD RMS)
• Application Server
• DHCP
• File Services
• Hyper-V
• Network Policy Server (NPS)
• Windows Server Update Services (WSUS)

At the time of this writing, a BPA model for 12 of 17 server roles in Windows Server 2008 R2 are available.
The 5 that are not available are:

• Active Directory Federation Services (ADFS)
• Active Directory Lightweight Directory Services (AD LDS)
• Fax Server
• Print and Document Services
• Windows Deployment Services

In Server Manager, a BPA summary are available for each installed server role that an BPA Model exists for:

When looking at the properties for an item in BPA you get more information as well as a link to Microsoft TechNet where more information are available for the specific subject:

BPA are built as a PowerShell module, meaning that a PowerShell cmdlet (Invoke-BPAModel) are run in the background when you scan a server role from Server Manager:

This is a great feature to examine if your server roles are configured according to Microsoft`s best practices, however, if you got many servers it will take some time to log on to each server and scan each server role. In addition you don`t get any centralized reporting this way.

Since BPA are based upon Windows PowerShell it`s possible to solve this using the BPA PowerShell module and PowerShell remoting:

I`ve created a sample script to accomplish this, named Invoke-BPAModeling, with the following functionality:

• Invoke BPA for all available server roles on specified remote servers
• E-mail reporting
• File reporting to CSV and HTML

You need to customize the initial variables on the top of the script. You can enable/disable reporting using these variables, as well as specify which servers to work against, SMTP server for e-mail reporting and paths to CSV/HTML reports.
By default, only items with a severity of “Error” and “Warning” are reported. You can change this to also include “Informational” severities by configuring IncludeAllSeverities to true.
On the server running the script from, the Active Directory module for PowerShell must be installed if you want to retrieve computer names from Active Directory. In the sample,  the script are configured to retrieve all computer accounts listed with Windows Server 2008 R2 as operating system.
You might choose alternate methods, like importing the computer names from a csv-file.
.
I would recommend that you approve the new BPA models mentioned at the beginning of this blog post in WSUS prior to running the script.
The script requires that PowerShell remoting are enabled and configured on the remote servers. Also note that there is a known issue with the BPA module; When the PowerShell execution policy are set to any other than “Undefined” or “Unrestricted” , an error occurs. I`ll update this blog-post as soon as a fix are provided from Microsoft.

When the script executes, it displays the progress based upon the total number of computers running against:

Sample e-mail report containing both CSV and HTML reports as attachment:

Sample HTML-report:

Sample CSV-report converted to an Excel spreadsheet:

Feel free to customize the script for your needs, as well as suggest improvements.

Resources

Best Practices Analyzer on Microsoft TechNet

Active Directory Domain Administration Tools

• Active Directory Domain and Trusts: Manages trusts, domain and forest functional levels, and user principal name suffixes. It is located in administrative tools from either the control panel or the start menu
• Active Directory Schema Snap-in: This tool will not appear unless is is enabled with the command “regsvr32.exe  schmmgmt.dll”. Then it is only available by adding it to a custom-built MMC. It allows the modification of the schema for AD DS directories or AD LDS instances. It is best not to change anything here. That’s probably why it’s so difficult to find this tool.
• Active Directory Sites and Services: Active Directory Domain Controllers automatically update records between themselves, but if a domain is split between two physical locations, it may not be feasible to have the Domain Controllers choose their own replication scheme. This may result in the waste of bandwidth as they replicate across the WAN multiple times in both directions. ADSS allows an administrator to manage replication so that it only crosses the WAN once. The servers that communicate across the WAN are called bridgehead servers, and they replicate to all other Domain Controllers within their site. Active Directory Sites and Services are where you choose all of your replication schemes according to subnet. It can also be specified by server to force a direct replication between two servers in the same site.
• Active Directory Users and Computers: The tool that every one knows. It manages user, groups, and domain specific FSMO roles. FSMO stands for Flexible Single Master Operation. FSMO deals with the roles that domain controllers fulfill are…
  • RID master: Relative ID master maintains group membership when users or computers are moved between the domains. Also manages security principles. RID is part of the SID (System Identifier). Only one of these exist per domain.
  • Infrastructure master: Maintains GUID (Globally unique IDs) in the domain and maintains groups and users from other domains and their membership in local groups. Only one of these exist per domain.
  • PDC Emulator: Originally, Active Directory domains could only have on domain controller. That primary domain controller updated, deleted, and managed records in the domain. For backwards compatibility, one domain controller will still act as that primary domain controller. Only one of these exist per domain.
• ADSI Edit: Active Directory Service Interface will modify query, and edit directory objects and attributes. It is a bit obtuse, but some times required. One example is when you need to create a password settings object.
• Best Practices Analyzer: This is not just one tool, but a whole slew of tools available for download from Microsoft. It is available for lots of applications such as WSUS, DNS, Hyper-V, etc. Clearly, not all of them apply to Active Directory.
• csvde.exe: A command line tool used to bulk add users to the domain from a csv file. A csv (comma separated value) file may be created in Word, Excel, or Notepad. It may be used to move users from one domain to another and list users in the domain.
• dcdiag.exe: Diagnoses and creates a report on the status of Active Directory.
• dcpromo.exe: Command line tool used to create or remove active directory. Can also be used start the GUI version of the installation process.
• dfsradmin.exe: Used to manage Distributed File System Replication, which is only available in Windows Server 2008 functional level. This checks the replication of the SYSVOL folder, which is where the information for Active Directory is stored. In 2008 forests, DFSR replaced FRS (file replication service) which was the old method for replication.
• DNS Manager: A GUI console for managing the Domain Name Server and the records that it maintains.
• dnscmd.exe: Command line utility used to manage DNS and all of its aspects.
• dsacls.exe: This command line tool can be used to modify the ACL (access control list) on objects in Active Directory. All items in Active Directory will have NTFS permissions. This is just a way to modify them in command line.
• dsadd.exe: Command used to add users, computers, or groups to an Active Directory domain. May be used in a command or incorporated into a script.
• dsamain.exe: This command line utility is used to browse backups (.dit) of Active Directory.
• dsbutil.exe: This command line utility is installed with Active Directory Lightweight Directory Services. It is used to maintain, view, and configure AD LDS ports.
• dsget.exe: This command is used to retrieve data from Active Directory about an object.
• dsmgmt.exe: This command line utility manages application partitions and FSMO roles in Active Directory. It will also clean meta data left behind by AD DCs and LDS servers that were removed without being uninstalled.
• dsmod.exe: This command line utility is used to modify users, computers, and groups in Active Directory.
• dsmove.exe: This command will move an object to a new location in the same directory. It can also be used to rename an object.
• dsquery.exe: Command line utility to search for objects in Active Directory using defined characteristics.
• dsrm.exe: Command line utility used to remove objects from Active Directory.
• Event Viewer: A tool that has purposes other than DNS. However it does keep a record of changes in Active Directory. If auditing changes in Server 2008, it will log the old and new values for the change.
• gpfixup.exe: After renaming the domain, some Group Policy objects and Group Policy links may be not working properly. This command line utility repairs them.
• Group Policy Management Console: This console is used to create, manage, back up, and restore GPOs.
• ipconfig: While this is typically used in networking, this command line tool may indicate that the reason that users are unable to authenticate to the domain is because their network configuration is not correct.
• ksetup.exe: Not actually specific to a Windows Server operating system, this command will prepare a client for a Kerberos v5 realm instead of an Active Directory domain.
• ktpass.exe: This command line utility is used to configure a non-Windows Kerberos service  to be used with an Active Directory domain.
• ldifde.exe: This command line tool will import entries into AD LDS (Active Directory Lightweight Directory Services).
• ldp.exe: This tool is invoked from command line and opens in the GUI. It is used to perform LDAP (Lightweight Directory Access Protocol) operations against the directory.
• movetree.exe: This command line tool which may be downloaded from Microsoft is used to move objects from one domain to another in a forest. It is not available in Windows Server 2008.
• netdom.exe: This command line tool allows the management of computer and user accounts and trust relationships. This is available on client versions of Windows as well.
• nltest.exe: This command line tool is used to verify trust relationships or check replication status. This is available on client versions of Windows as well.
• nslookup.exe: Used in the command line, nslookup.exe is used to diagnose DNS problems and view information on name servers. This is available on client versions of Windows as well.
• ntdsutil.exe: This command line tool is used to perform maintenance on AD DS/AD LDS.
• repadmin.exe: This command line tool is used to check replication between domain controllers that use the FRS (File Replication Service). FRS was the replication method of the SYSVOL folder that contains all the information about the Active Directory domain. In a Windows Server 2008 forest, the replacement service is DFSR (Distributed File Replication Service).
• Server Manager: This GUI tool in Windows Server 2008 is used to manage many aspects of a Windows Server 2008. Active Directory management happens to be a part of it. It is similar to the “Manage Your Server” tool in Server 2003 or Computer Management in other operating systems.
• System Monitor: A console used to create baseline references (benchmarks) and create charts and graphs of server performance.
• ultrasound.exe: A console (not available in Windows Server 2008) that is used to troubleshoot replication of FRS. It is invoked via command line and relies on WMI (Windows Management Instrumentation.)
• w32tm.exe: Kerberos relies heavily on the fact that all systems in the domain have the same time. The command line tool w32tm.exe is used to view, manage, or diagnose problems with Windows Time. This tool is available on many Windows operating systems.
• Windows Server Backup (wbadmin.exe): Backs up or restores many parts of a windows operating system. Introduced in Server 2008. The older version was called simply called backup (ntbackup.exe). It can be used to back up the whole computer or only certain sections such as DNS, AD, AD LDS