By Robbie Allen, Laura E. Hunter
Book Price: $49.99 USD
£35.50 GBP
PDF Price: $39.99

Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Getting Started

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you are familiar with the O'Reilly Cookbook format that can be seen in other popular books, such as the Perl Cookbook, Java Cookbook, and DNS and BIND Cookbook, then the layout of this book will be familiar to you. The book is composed of 23chapters, each containing 10 to 30 recipes for performing a specific Active Directory task. Within each recipe are four sections: Problem, Solution, Discussion, and See Also. The Problem section briefly describes the task that the recipe focuses on. The Solution section contains step-by-step instructions on how to accomplish the task. The Discussion section contains detailed information about the problem or solution. The See Also section contains references to additional sources of information that can be useful if you still need more information after reading the discussion. The See Also section may reference other recipes, MS Knowledge Base (https://support.microsoft.com ) articles, or documentation from the Microsoft Developers Network (MSDN; https://msdn.microsoft.com).

When we first began developing the content for the book, we struggled with how to capture the fact that you can do things multiple ways with Active Directory. You may be familiar with the famous Perl motto: There Is More Than One Way To Do It; well with Active Directory, there are often At Least Three Ways To Do It. You can perform a task with a graphical user interface ( GUI), such as ADSI Edit, LDP, or the Active Directory Users and Computers snap-in; you can use a command-line interface (CLI), such as the ds utilities (i.e., dsadd, dsmod, dsrm, dsquery, dsget), nltest, netdom, ldifde, or freeware tools such as adfind and admod from https://www.joeware.net; and, finally, you can perform the same task using a scripting language, such as VBScript or Perl.

Since people prefer different methods, and no single method is necessarily better than another, we decided to write solutions to the recipes using one of each. That means instead of just a single solution per recipe, we include up to three solutions using GUI, CLI, and programmatic examples; in some cases you'll find more than one option for a given solution, as in the case where there is more than one command-line utility to perform a particular task. However, in cases where one of the methods cannot be used or would be too difficult to use to accomplish a given recipe, only the applicable methods are covered.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Approach to the Book

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you are familiar with the O'Reilly Cookbook format that can be seen in other popular books, such as the Perl Cookbook, Java Cookbook, and DNS and BIND Cookbook, then the layout of this book will be familiar to you. The book is composed of 23chapters, each containing 10 to 30 recipes for performing a specific Active Directory task. Within each recipe are four sections: Problem, Solution, Discussion, and See Also. The Problem section briefly describes the task that the recipe focuses on. The Solution section contains step-by-step instructions on how to accomplish the task. The Discussion section contains detailed information about the problem or solution. The See Also section contains references to additional sources of information that can be useful if you still need more information after reading the discussion. The See Also section may reference other recipes, MS Knowledge Base (https://support.microsoft.com ) articles, or documentation from the Microsoft Developers Network (MSDN; https://msdn.microsoft.com).

When we first began developing the content for the book, we struggled with how to capture the fact that you can do things multiple ways with Active Directory. You may be familiar with the famous Perl motto: There Is More Than One Way To Do It; well with Active Directory, there are often At Least Three Ways To Do It. You can perform a task with a graphical user interface ( GUI), such as ADSI Edit, LDP, or the Active Directory Users and Computers snap-in; you can use a command-line interface (CLI), such as the ds utilities (i.e., dsadd, dsmod, dsrm, dsquery, dsget), nltest, netdom, ldifde, or freeware tools such as adfind and admod from https://www.joeware.net; and, finally, you can perform the same task using a scripting language, such as VBScript or Perl.

Since people prefer different methods, and no single method is necessarily better than another, we decided to write solutions to the recipes using one of each. That means instead of just a single solution per recipe, we include up to three solutions using GUI, CLI, and programmatic examples; in some cases you'll find more than one option for a given solution, as in the case where there is more than one command-line utility to perform a particular task. However, in cases where one of the methods cannot be used or would be too difficult to use to accomplish a given recipe, only the applicable methods are covered.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Where to Find the Tools

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

For the GUI and CLI solutions to mean much to you, you need access to the tools that are used in the examples. The Windows 2000 Server Resource Kit and Windows Server 2003 Resource Kit are invaluable sources of information, along with providing numerous tools that aid administrators in daily tasks. More information on the Resource Kits can be found at the following web site: https://www.microsoft.com/windows/reskits/. The Windows 2000 Support Tools package, which in Windows Server 2003 is called the Windows Support Tools package, contains many essential tools for people that work with Active Directory. The Microsoft installer (MSI) for the Windows Support Tools can be found on a Windows 2000 Server, Windows Server 2003, or Windows Server 2003 R2 CD in the \support\tools directory. You can also use the Tool Finder feature available on the ActiveDir web site, located at https://www.activedir.org/TF/Default.aspx.

You'll also find a number of references to third-party command-line tools such as adfind, admod, oldcmp, findexpacc, and memberof. These tools were developed by Microsoft Directory Services MVP Joe Richards, and he has made them available for free download from his web site at https://www.joeware.net. While these tools are not native to the Windows operating system, they have become an invaluable addition to many Active Directory system administrators' toolkits, and we include them here to showcase their capabilities.

Once you have the tools at your disposal, there are a couple other issues to be aware of while trying to apply the solutions in your environment, which we'll now describe.

A best practice for managing Active Directory is to create separate administrator accounts that you grant elevated privileges, instead of letting administrators use their normal user account that they use to access other Network Operating System (NOS) resources. This is beneficial because an administrator who wants to use elevated privileges has to log on with his administrative account explicitly instead of having the rights implicitly, which could lead to accidental changes in Active Directory. Assuming you employ this method, then you must provide alternate credentials when using tools to administer Active Directory unless you log on to a machine, such as a domain controller, with the administrative credentials.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Getting Familiar with LDIF

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Even with the new utilities available with Windows Server 2003, native support for modifying data within Active Directory using a command-line tool is relatively weak. The dsmod tool can modify attributes on a limited set of object classes, but it does not allow you to modify every object type.

One reason for the lack of native command-line tools to do this is that the command line is not well suited for manipulating objects, for example, that have multivalued attributes. If you want to specify more than just one or two values, a single command could get quite long. It would be easier to use a GUI editor, such as ADSI Edit, to do the task instead.

The LDAP Data Interchange Format ( LDIF) was designed to address this issue. Defined in RFC 2849, LDIF allows you to represent directory additions, modifications, and deletions in a text-based file, which you can import into a directory using an LDIF-capable tool.

The ldifde utility has been available since Windows 2000 and it allows you to import and export Active Directory content in LDIF format. LDIF files are composed of blocks of entries. An entry can add, modify, or delete an object. The first line of an entry is the distinguished name. The second line contains a changetype, which can be add, modify, or delete. If it is an object addition, the rest of the entry contains the attributes that should be initially set on the object (one per line). For object deletions, you do not need to specify any other attributes. And for object modifications, you need to specify at least three more lines. The first should contain the type of modification you want to perform on the object. This can be add (to set a previously unset attribute or to add a new value to a multivalued attribute), replace (to replace an existing value), or delete (to remove a value). The modification type should be followed by a colon and the attribute you want to perform the modification on. The next line should contain the name of the attribute followed by a colon, and the value for the attribute. For example, to replace the last name attribute with the value Smith, you'd use the following LDIF:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Programming Notes

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the VBScript solutions, our intention was to provide the answer in as few lines of code as necessary. Since this book is not a pure programming book, we did not want to provide a detailed explanation of how to use ADSI or WMI. If you are looking for that, we recommend Part III of Active Directory, Third Edition, by Joe Richards et al. (O'Reilly).

The intent of the VBScript code is to provide you the basics for how a task can be automated and let you run with it. Most examples only take some minor tweaking to make them do something useful for you.

Just as with the GUI and CLI solutions, there are some important issues to be aware of when looking at the VBScript solutions.

We mentioned earlier that in the GUI and CLI examples we did not provide instructions for targeting a specific domain controller to perform a task. Instead, we rely on serverless binds in most cases. The same applies to the API solutions. A serverless bind for the RootDSE looks like the following in VBScript:

	set objRootDSE = GetObject("LDAP://RootDSE")

That code will query the RootDSE for a domain controller in the domain of the currently logged on user. You can target a specific domain instead by simply specifying the domain name in the ADsPath:

	set objRootDSE = GetObject("LDAP://apac.rallencorp.com/RootDSE")

And similarly, you can target a specific domain controller by including the server name in the ADsPath:

	set objRootDSE = GetObject("LDAP://dc1/RootDSE")

So depending on how your environment is set up and what forest you want to query, you may or may not need to specify a domain or server name in the code.

Just as you might need to run the GUI and CLI tools with alternate credentials, you may also need to run your scripts and programs with alternate credentials. One way is to use the runas method described earlier when invoking the script. A better option would be to use the Scheduled Tasks service to run the script under credentials you specify when creating the task. And yet another option is to hardcode the credentials in the script. Obviously, this is not very appealing in some scenarios because credentials can change over time, and as a security best practice you do not want the username and password contained in a script to be easily viewable by others. Nevertheless, it is a necessary evil, especially when developing against multiple forests, and we'll describe how it can be done with ADSI and ADO. As an alternative, you can configure a script to prompt you for the username and password during the actual running of the script.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Replaceable Text

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This book is filled with examples. Every recipe consists of one or more examples that show how to accomplish a task. Most CLI-and VBScript-based solutions use parameters that are based on the domain, forest, OU, user, etc, that is being added, modified, queried, and so on. Instead of using fictitious names, in most cases, we use replaceable text. This text should be easily recognizable because it is in italics and surrounded by angle brackets (<>). Instead of describing what each replaceable element represents every time we use it, we've included a list of some of the commonly used ones here:

<DomainDN>

Distinguished name of domain (e.g., dc=amer,dc=rallencorp,dc=com)

<ForestRootDN>

Distinguished name of the forest root domain (e.g., dc=rallencorp,dc=com)

<DomainDNSName>

Fully qualified DNS name of domain (e.g., amer.rallencorp.com)

<ForestDNSName>

Fully qualified DNS name of forest root domain (e.g., rallencorp.com)

<DomainControllerName>

Single label or fully qualified DNS hostname of domain controller (e.g., dc01.rallen-corp.com)

<UserDN>

Distinguished name of user (e.g., cn=administrator,cn=users,dc=rallencorp,dc=com)

<GroupDN>

Distinguished name of group (e.g., cn=DomainAdmins,cn=users,dc=rallencorp, dc=com)

<ComputerName>

Single label DNS hostname of computer (e.g., rallen-xp)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Where to Find More Information

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

While it is our hope that this book provides you with enough information to perform most of the tasks you need to do to maintain your Active Directory environment, it is not realistic to think every possible task has been covered. In fact, working on this book has made us realize just how much Active Directory administrators need to know.

Now that Active Directory has been around for a few years, a significant user base has been built, which has led to other great resources of information. This section contains some of the useful sources of information that we use on a regular basis.

If you have any questions about the complete syntax or usage information for any of the command-line tools we use, you should first take a look at the help information for the tools. The vast majority of CLI tools provide syntax information by simply passing /? as a parameter. For example:

	> dsquery /?

The Microsoft Support web site is a great source of information and is home of the Microsoft Knowledge Base ( MS KB) articles. Throughout the book, we include references to pertinent MS KB articles where you can find more information on the topic. You can find the complete text for a KB article by searching on the KB number at the following web site: https://support.microsoft.com/default.aspx. You can also append the KB article number to the end of this URL to go directly to the article: https://support.microsoft.com/?kbid=.

If you look up Knowledge Base articles on a regular basis, you can even add a Registry entry to allow your workstation to go directly to a KB article in Internet Explorer. Open your Registry Editor and navigate to the HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\SearchUrl key. Create a new sub-key called KB. Underneath this subkey, create a REG_SZ value containing the following data:

	https://support.microsoft.com/?kbid=%s

Now close the Registry Editor and open up Internet Explorer. In the address bar, type KB 875357 (or any other KB number) and the associated page on the Microsoft web site will open.

MSDN contains a ton of information on Active Directory and the programmatic interfaces to Active Directory, such as ADSI and LDAP. We sometimes reference MSDN pages in recipes. Unfortunately, there is no easy way to reference the exact page we're talking about unless we provided the URL or navigation to the page, which would more than likely change by the time the book was printed. Instead we provide the title of the page, which you can use to search on via the following site:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Chapter 2: Forests, Domains, and Trusts

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To the layperson, the title of this chapter may seem like a hodgepodge of unrelated terms. For the seasoned Active Directory administrator, however, these terms represent the most fundamental and, perhaps, most important concepts within Active Directory. In simple terms, a forest is a collection of data partitions and domains; a domain is a hierarchy of objects that is replicated between one or more domain controllers; a trust is an agreement between two domains or forests to allow security principals (i.e., users, groups, and computers) to access resources in either domain.

Active Directory domains are named using the Domain Name Service (DNS) namespace. You can group domains that are part of the same contiguous DNS namespace within the same domain tree. For example, the sales.rallencorp.com, marketing.rallencorp.com, and rallencorp.com domains are part of the rallencorp.com domain tree. A single domain tree is sufficient for most implementations, but one example in which multiple domain trees might be necessary is with large conglomerate corporations. Conglomerates are made up of multiple individual companies in which each company typically wants to maintain its own identity and, therefore, its own namespace. If you need to support noncontiguous namespaces within a single forest, you will need to create multiple domain trees. For example, rallencorp.com and mycompany.com can form two separate domain trees within the same forest.

For more information on configuring DNS namespaces, see DNS on Windows Server 2003 by Cricket Liu et al (O'Reilly).

Assuming that each company within the conglomerate wants its Active Directory domain name to be based on its company name, you have two choices for setting up this type of environment. You could either make each company's domain(s) a domain tree within a single forest, or you could implement multiple forests. One of the biggest differences between the two options is that all the domains within the forest trust each other, whereas separate forests, by default, do not have any trust relationships set up between them. Without trust relationships, users from one forest cannot access resources located in the other forest. In our conglomerate scenario, if you want users in each company to be able to access resources within their own domain, as well as the domains belonging to other companies in the organization, using separate domain trees can create an easier approach than separate forests. (However, it's important to keep in mind when designing your network that forests form the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Introduction

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To the layperson, the title of this chapter may seem like a hodgepodge of unrelated terms. For the seasoned Active Directory administrator, however, these terms represent the most fundamental and, perhaps, most important concepts within Active Directory. In simple terms, a forest is a collection of data partitions and domains; a domain is a hierarchy of objects that is replicated between one or more domain controllers; a trust is an agreement between two domains or forests to allow security principals (i.e., users, groups, and computers) to access resources in either domain.

Active Directory domains are named using the Domain Name Service (DNS) namespace. You can group domains that are part of the same contiguous DNS namespace within the same domain tree. For example, the sales.rallencorp.com, marketing.rallencorp.com, and rallencorp.com domains are part of the rallencorp.com domain tree. A single domain tree is sufficient for most implementations, but one example in which multiple domain trees might be necessary is with large conglomerate corporations. Conglomerates are made up of multiple individual companies in which each company typically wants to maintain its own identity and, therefore, its own namespace. If you need to support noncontiguous namespaces within a single forest, you will need to create multiple domain trees. For example, rallencorp.com and mycompany.com can form two separate domain trees within the same forest.

For more information on configuring DNS namespaces, see DNS on Windows Server 2003 by Cricket Liu et al (O'Reilly).

Assuming that each company within the conglomerate wants its Active Directory domain name to be based on its company name, you have two choices for setting up this type of environment. You could either make each company's domain(s) a domain tree within a single forest, or you could implement multiple forests. One of the biggest differences between the two options is that all the domains within the forest trust each other, whereas separate forests, by default, do not have any trust relationships set up between them. Without trust relationships, users from one forest cannot access resources located in the other forest. In our conglomerate scenario, if you want users in each company to be able to access resources within their own domain, as well as the domains belonging to other companies in the organization, using separate domain trees can create an easier approach than separate forests. (However, it's important to keep in mind when designing your network that forests form the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Creating a Forest

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to create a new forest by creating a new forest root domain.

Using a graphical user interface

Run dcpromo from a command line or by clicking on Start → Run.

On a Windows 2000 domain controller:

1. Select "Domain controller for a new domain" and click Next.
2. Select "Create a new domain tree" and click Next.
3. Select "Create a new forest of domain trees" and click Next.
4. Follow the rest of the configuration steps to complete the wizard.

On a Windows Server 2003 domain controller:

1. Select "Domain controller for a new domain" and click Next.
2. Select "Domain in a new forest" and click Next.
3. Follow the rest of the configuration steps to complete the wizard.

Using a command-line interface

dcpromo can also be run in unattended mode. See Recipe 3.5 for more details.

The act of creating a forest consists of creating a forest root domain. To do this, you need to use dcpromo to promote a Windows 2000 or Windows Server 2003 server to be a domain controller for a new domain. The dcpromo program has a wizard interface that requires you to answer several questions about the forest and domain you want to promote the server into. After dcpromo finishes, you will be asked to reboot the computer to complete the promotion process.

Recipe 2.3 for creating a domain, Recipe 3.1 for promoting a domain controller, Recipe 3.5 for automating the promotion of a domain controller, MS KB 238369 (How to Promote and Demote Domain Controllers in Windows 2000), and MS KB 324753 (How to Create an Active Directory Server in Windows Server 2003)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Removing a Forest

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to tear down a forest and decommission any domains contained within it because you no longer need it.

To remove a forest, you need to demote (using dcpromo) all the domain controllers in the forest. When you run dcpromo on an existing domain controller, you will be given the option to demote the machine to a member server. After that is completed and depending on how your environment is configured, you may need to remove WINS and DNS entries that were associated with the domain controllers and domains unless they were automatically removed via WINS deregistration and dynamic DNS ( DDNS) during demotion. The following commands can help determine if all entries have been removed:

	> netsh wins server \\<WINSServerName> show name <DomainNetBiosName> 1b
	> netsh wins server \\<WINSServerName> show name <DomainNetBiosName> 1c
	> nslookup <DomainControllerDNSName
	> nslookup -type=SRV _ldap._tcp.gc._msdcs.<ForestDNSName
	> nslookup <ForestDNSName>

You should run the first two commands for every domain in the forest if the forest contained more than one.

You will also want to remove any trusts that have been established for the forest (see Recipe 2.22 for more details). For more information on how to demote a domain controller, see Recipe 3.4.

The method described in this solution is the graceful way to tear down a forest. You can also use a brute force method to remove a forest by simply reinstalling the operating system on all domain controllers in the forest. This method is not recommended except in lab or test environments. The brute force method is not a clean way to do it because the domain controllers are unaware the forest is being removed and may generate errors until they are rebuilt. You'll also need to make sure any DNS resource records for the domain controllers are removed from your DNS servers since the domain controllers will not dynamically remove them like they do during the demotion process.

If you need to forcibly remove a single domain from an AD forest, you can also use the ntdsutil command-line utility; see Recipe 2.4 for more information.

Recipe 2.19 for viewing the trusts for a domain, Recipe 2.22 for removing a trust, and Recipe 3.4 for demoting a domain controller

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Creating a Domain

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to create a new domain that may be part of an existing domain tree or the root of a new domain tree.

Using a graphical user interface

Run dcpromo from a command line or Start → Run.

On a Windows 2000 domain controller, select "Domain controller for a new domain" and then you can select one of the following:

• Create a new domain tree → Place this new domain tree in an existing forest
• Create a new child domain in an existing domain tree

On a Windows Server 2003 domain controller, select "Domain controller for a new domain" and then you can select one of the following:

• Domain in a new forest
• Child domain in an existing domain tree
• Domain tree in an existing forest

Using a command-line interface

dcpromo can also be run in unattended mode. See Recipe 3.5 for more details.

The two options dcpromo offers to create a new domain are adding the domain to an existing domain tree or starting a new domain tree. If you want to create a new domain that is a child domain of a parent domain (i.e., contained within the same contiguous namespace), then you are creating a domain in an existing domain tree. If you are creating the first domain in a forest or a domain that is outside the namespace of the forest root, then you are creating a domain in a new domain tree. For example, if you've already created the rallenhome.corp domain and then install the first DC in the amer.rallenhome.corp domain, then amer.rallenhome.corp is a child domain. Conversely, if you want to create a domain that is part of the rallenhome.corp forest but uses an entirely different naming convention (such as rallenasia.corp), then you are creating a new domain tree within an existing forest.

Recipe 3.1 for promoting a domain controller, Recipe 3.5 for automating the promotion of a domain controller, Designing the Active Directory Logical Structure from the Windows Server 2003 Deployment Guide, MS KB 238369 (How to Promote and Demote Domain Controllers in Windows 2000), and MS KB 255248 (How to Create a Child Domain in Active Directory and Delegate the DNS Namespace to the Child Domain)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Removing a Domain

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to remove a domain from a forest. You may need to remove a domain during test scenarios or if you are collapsing or reducing the number of domains in a forest.

Removing a domain consists of demoting each domain controller in the domain, which is accomplished by running dcpromo on the domain controllers and following the steps to remove them. For the last domain controller in the domain, be sure to select "This server is the last domain controller in the domain" in the dcpromo wizard so that the objects associated with the domain get removed. If you do not select this option for the last domain controller in the domain, take a look at Recipe 2.5 for how to remove an orphaned domain.

If the domain you want to remove has child domains, you have to remove these child domains before proceeding.

After all domain controllers have been demoted, depending on how your environment is configured you may need to remove any WINS and DNS entries that were associated with the domain controllers and domain that were automatically removed via WINS deregistration and DDNS during the demotion process. The following commands can help determine if all entries have been removed:

	> netsh wins server \\<WINSServerName> show name <DomainNetBiosName> 1b
	> netsh wins server \\<WINSServerName> show name <DomainNetBiosName> 1c
	> nslookup <DomainControllerName>
	> nslookup -type=SRV _ldap._tcp.dc._msdcs.<DomainDNSName>
	> nslookup <DomainDNSName>

You will also want to remove any trusts that have been established for the domain (see Recipe 2.22 for more details). For more information on how to demote a domain controller, see Recipe 3.4.

The "brute force" method for removing a forest as described in the "Discussion" for Recipe 2.2 is not a good method for removing a domain. Doing so will leave all of the domain controller and server objects, along with the domain object and associated domain naming context hanging around in the forest. If you used that approach, you would eventually see a bunch of replication and file replication service (FRS) errors in the event log caused by failed replication events from the nonexistent domain. You would need to remove the metadata associated with the removed domain using

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Removing an Orphaned Domain

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to completely remove a domain that was orphaned because the domain was forcibly removed, or the last domain controller in the domain failed or was otherwise decommissioned improperly.

Using a command-line interface

The following ntdsutil commands (in bold) would forcibly remove the emea.rallencorp.com domain from the rallencorp.com forest. Replace <DomainControllerName> with the hostname of the Domain Naming Flexible Single Master Operation (FSMO; pronounced fiz-mo) for the forest:

	> ntdsutil "meta clean" "s o t" conn "con to server
	     <DomainControllerName>" q q
	metadata cleanup: "s o t" "list domains"
	Found 4 domain(s)
	0 - DC=rallencorp,DC=com
	1 - DC=amer,DC=rallencorp,DC=com
	2 - DC=emea,DC=rallencorp,DC=com
	3 - DC=apac,DC=rallencorp,DC=com
	select operation target: sel domain 2
	No current site
	Domain - DC=emea,DC=rallencorp,DC=com
	No current server
	No current Naming Context
	select operation target: q
	metadata cleanup: remove sel domain

You will receive a message indicating whether the removal was successful.

Removing an orphaned domain consists of removing the domain object for the domain (e.g., dc=emea,dc=rallencorp,dc=com), all of its child objects, and the associated crossRef object in the Partitions container. You need to target the Domain Naming FSMO when using ntdsutil because that server is responsible for creation and removal of domains.

In the solution, shortcut parameters were used to reduce the amount of typing necessary. If each parameter were typed out fully, the commands would look as follows:

	> ntdsutil "metadata cleanup" "select operation target" connections
	    "connect to server <DomainControllerName>" quit quit
	metadata cleanup: "select operation target" "list domains"
	Found 4 domain(s)
	0 - DC=rallencorp,DC=com
	1 - DC=amer,DC=rallencorp,DC=com
	2 - DC=emea,DC=rallencorp,DC=com
	3 - DC=apac,DC=rallencorp,DC=com
	select operation target: select domain 2
	No current site
	Domain - DC=emea,DC=rallencorp,DC=com
	No current server
	No current Naming Context
	select operation target: quit
	metadata cleanup: 

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Finding the Domains in a Forest

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want a list of all domains in an Active Directory forest.

Using a graphical user interface

Open the Active Directory Domains and Trusts snap-in (domain.msc). The list of the domains in the default forest can be browsed in the left pane.

Using a command-line interface

You can retrieve this information using ntdsutil, adfind, or dsquery, as shown here:

	> ntdsutil "d m" "sel op tar" c "co t s <DomainControllerName>"
	q "l d" q q q
	> dsquery * -filter "objectcategory=domainDNS" -scope subtree
	> adfind –root –s subtree –f "objectcategory=domainDNS" -dn

Using VBScript

	' This code gets the list of the domains contained in the
	' forest that the user running the script is logged into.
	strForestRoot = "<ForestRootDN>" ' i.e., dc=rallencorp, dc=com
	strADsPath = "<LDAP://cn=Partitions,cn=Configuration," & _
	    strForestRoot & ">;"
	strFilter = "(netbiosname=*);"
	strAttrs = "dnsRoot;"
	strScope = "SubTree"
	set objConn = CreateObject("ADODB.Connection") objConn.Provider = "ADsDSOObject"
	objConn.Open "Active Directory Provider"
	set objRS = objConn.Execute(strADsPath & strFilter & strAttrs & strScope)
	objRS.MoveFirst while Not objRS.EOF
	    For Each root in objRS.Fields("dnsRoot").Value
	        WScript.Echo(root)
	    Next
	    objRS.MoveNext
	wend

Using a graphical user interface

If you want to view the domains for an alternate forest than the one you are logged into, right-click on "Active Directory Domains and Trusts" in the left pane and select "Connect to Domain Controller." Enter the forest name you want to browse in the Domain field. In the left pane, expand the forest root domain to see any subdomains.

Using a command-line interface

In the ntdsutil example, shortcut parameters were used to reduce the amount of typing needed. If each parameter were typed out fully, the command line would look like:

	> ntdsutil "domain management" "select operation target" connections "connect 
	to server <DomainControllerName>" quit "List domains" quit quit quit

Using VBScript

In the VBScript solution, we use ADO to query the Partitions container for crossRef objects that refer to domain objects within the forest.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Finding the NetBIOS Name of a Domain

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to find the NetBIOS name of a domain. Although Microsoft has moved to using DNS for its primary means of name resolution, the NetBIOS name of a domain is still important, especially with down-level clients that are still based on NetBIOS instead of DNS for name resolution.

Using a graphical user interface

1. Open the Active Directory Domains and Trusts snap-in (domain.msc).
2. Right-click the domain you want to view in the left pane and select Properties.

The NetBIOS name will be shown in the "Domain name (pre-Windows 2000)" field.

You can also retrieve this information using LDP, as follows:

1. Open LDP and from the menu, select Connection → Connect.
2. For Server, enter the name of a domain controller (or leave blank to do a serverless bind).
3. For Port, enter 389.
4. Click OK.
5. From the menu select Connection → Bind.
6. Enter credentials of a domain user.
7. Click OK.
8. From the menu, select Browse → Search.
9. For BaseDN, type the distinguished name of the Partitions container (e.g., cn=partitions,cn=configuration,dc=rallencorp, dc=com).
10. For Scope, select Subtree.
11. For Filter, enter:

    	(&(objectcategory=crossref)(dnsHostName=<DomainDNSName>)(netbiosname=*))
    

12. Click Run.

Using a command-line interface

To find the NetBIOS name of a Windows domain, use the following command:

	> dsquery * cn=partitions,cn=configuration,<ForestRootDN> -filter
	"(&(objectcategory=crossref)(dnsroot=<DomainDNSName>)(netbiosname=*))" -attr
	netbiosname

Or you can use the AdFind utility as follows:

	> adfind -b cn=partitions,cn=configuration,<ForestRootDN>
	-f "(&(objectcategory=crossref)(dnsroot=<DomainDNSName>))" cn netbiosname

Using VBScript

	' This code prints the  
NetBIOS name for the specified domain
	' ------ SCRIPT CONFIGURATION -----
	strDomain = "<DomainDNSName>" ' e.g. amer.rallencorp.com
	' ------ END CONFIGURATION --------
	set objRootDSE = GetObject("LDAP://" & strDomain & "/RootDSE")
	strADsPath = "<LDAP://" & strDomain & "/cn=Partitions," & _
	            objRootDSE.Get("configurationNamingContext") & ">;"
	strFilter = "(&(objectcategory=Crossref)" & _
	             "(dnsRoot=" & strDomain & ")(netBIOSName=*));
	strAttrs = "netbiosname;"
	strScope = "Onelevel"
	set objConn = CreateObject("ADODB.Connection")
	objConn.Provider = "ADsDSOObject"
	objConn.Open "Active Directory Provider"
	set objRS = objConn.Execute(strADsPath &  strFilter &  strAttrs &  strScope)
	objRS.MoveFirst
	WScript.Echo "NetBIOS name for " &  strDomain &  " is " &  objRS.Fields(0).Value

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Renaming a Domain

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to rename a domain, for example due to organizational changes, legal restrictions, or because of a merger, acquisition, or divestiture. Renaming a domain is a very involved process and should be done only when absolutely necessary. Changing the name of a domain can have an impact on everything from DNS, replication, and GPOs to DFS and Certificate Services. A domain rename also requires rebooting all domain controllers, member servers, and client computers in the domain!

Under Windows 2000, there is no supported process to rename a domain. There is one workaround for mixed-mode domains in which you revert the domain and any of its child domains back to Windows NT domains. This can be done by demoting all Windows 2000 domain controllers and leaving the Windows NT domain controllers in place, or simply by rebuilding all of the 2000 DCs. You could then reintroduce Windows 2000 domain controllers and use the new domain name when setting up Active Directory. The process is not very clean and probably won't be suitable for most situations, but you can find out more about it in MS KB 292541.

A domain rename procedure is supported if a forest is running all Windows Server 2003 domain controllers and is at the Windows Server 2003 forest functional level. Microsoft provides a rename tool (rendom.exe) and detailed white paper describing the process at the following location: https://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx.

Although the domain rename procedure is greatly simplified in Windows Server 2003, we highly recommend reading the entire white paper before attempting the procedure, as well as attempting the procedure in a test lab before performing it against a production environment.

The domain rename process can accommodate very complex changes to your domain model. You can perform the following types of renames:

• Rename a domain to a new name without repositioning it in the domain tree.
• Reposition a domain within a domain tree.
• Create a new domain tree with a renamed domain.

One thing you cannot do with the domain rename procedure is reposition the forest root domain. You can rename the forest root domain, but you cannot change its status as the forest root domain. Another important limitation to note is that you cannot rename any domain in a forest that has had Exchange 2000 installed, though an Exchange Server 2003 is capable of handling domain renames. See the web site mentioned in the solution for more information on other limitations. The

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Raising the Domain Functional Level to Windows 2000 Native Mode

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to change the mode of a Windows 2000 Active Directory domain from mixed mode to native mode. You typically want to do this as soon as possible after installing a Windows 2000 domain to take advantage of features that aren't available with mixed-mode domains. (See this link for more information on the features available at the different functional levels: https://technet2.microsoft.com/WindowsServer/en/Library/b3674c9b-fab9-4c1e-a8f6-7871264712711033.mspx).

Using a graphical user interface

1. Open the Active Directory Domains and Trusts snap-in (domain.msc).
2. Browse to the domain you want to change in the left pane.
3. Right-click on the domain and select Properties. The current mode will be listed in the Domain Operation Mode box.
4. To change the mode, click the Change Mode button at the bottom.

Using a command-line interface

To change the mode to native mode, create an LDIF file called change_domain_mode.ldf with the following contents:

	dn: <DomainDN>
	changetype: modify
	replace: ntMixedDomain
	ntMixedDomain: 0
	-

Then run ldifde to import the change.

	> ldifde -i -f change_domain_mode.ldf

Alternately, you can use the AdMod utility to update your domain to native mode using the following syntax:

	> admod -b dc=rallencorp,dc=com "ntMixedDomain::0"

Using VBScript

	' This code changes the mode of the specified domain to native
	' ------ SCRIPT CONFIGURATION ------
	strDomain = "<DomainDNSName>" ' e.g. amer.rallencorp.com
	' ------ END CONFIGURATION ---------
	set objDomain = GetObject("LDAP://" &  strDomain)
	if objDomain.Get("nTMixedDomain") > 0 Then
	   Wscript.Echo " 
Changing mode to native … "
	   objDomain.Put "nTMixedDomain", 0
	   objDomain.SetInfo
	else
	   Wscript.Echo "Already a native mode domain"
	end if

The mode of a domain restricts the operating systems the domain controllers in the domain can run. In a mixed-mode domain, you can have Windows 2000 (and Windows Server 2003) and Windows NT domain controllers. In a native-mode domain, you can have only Windows 2000 (and Windows Server 2003) domain controllers. There are several important feature differences between mixed and native mode. Mixed mode imposes the following limitations:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Raising the Functional Level of a Windows Server 2003 Domain

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to raise the functional level of a Windows Server 2003 domain. You should raise the functional level of a domain as soon as possible after installing a new Windows Server 2003 domain or upgrading from Windows 2000 to take advantage of the new features and enhancements.

Using a graphical user interface

1. Open the Active Directory Domains and Trusts snap-in (domain.msc).
2. In the left pane, browse to the domain you want to raise, right-click it, and select Raise Domain Functional Level.
3. Select the new functional level and click OK.

After a few seconds you should see a message stating whether the operation was successful.

Using a command-line interface

To retrieve the current functional level using DSQuery, use the following command:

	> dsquery * <DomainDN> -scope base -attr msDS-Behavior-Version

DSQuery will return the following output in a mixed mode domain:

	> msDS-Behavior-Version
	> 0

Or you can use the AdFind utility from www.joeware.net as follows:

	> adfind -s Base -b <DomainDN> msDS-Behavior-Version

AdFind will return the following output in a mixed mode domain:

	> AdFind V01.27.00cpp Joe Richards (joe@joeware.net) November 2005
	>
	> Using server: dc1.rallencorp.com:389
	> Directory: Windows Server 2003
	>
	> dn:dc=rallencorp,dc=com
	>> msDS-Behavior-Version: 0
	>
	>
	> 1 Objects returned

To change the functional level to Windows Server 2003, create an LDIF file called raise_domain_func_level.ldf with the following contents:

	dn: <DomainDN>
	changetype: modify
	replace: msDS-Behavior-Version
	msDS-Behavior-Version: 2
	-

Next, run ldifde to import the change.

	> ldifde -i -f raise_domain_func_level.ldf

Alternately, you can use the AdMod utility to raise the domain functional level using the following syntax, with the output that follows:

	> admod -b dc=rallencorp,dc=com "msDS-Behavior-Version::2"
	>
	> AdMod V01.06.00cpp Joe Richards (joe@joeware.net) June 2005
	>
	> DN Count: 1
	> Using server: dc1.rallencorp.com
	> Modifying specified objects…
	> DN: dc=rallencorp,dc=com…
	>
	> The command completed successfully

Using VBScript

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Raising the Functional Level of a Windows Server 2003 Forest

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to raise the functional level of a Windows Server 2003 forest. You should raise the functional level of a forest as soon as possible after installing a new Windows Server 2003 forest or upgrading from a Windows 2000 forest to take advantage of the new features and enhancements available in Windows Server 2003.

Using a graphical user interface

1. Open the Active Directory Domains and Trusts snap-in (domain.msc).
2. In the left pane, right-click on Active Directory Domains and Trusts and select Raise Forest Functional Level.
3. Select Windows Server 2003 Functional Level and click OK.

After a few seconds you should see a message stating whether the operation was successful.

Using a command-line interface

To retrieve the current forest functional level, use the following command:

	> dsquery * <ForestRootDN> -scope base -attr msDS-Behavior-Version

Or you can use the AdFind utility found at https://www.joeware.net, producing the following output:

	> adfind -b <ForestRootDN> -s base ms-DS-Behavior-Version
	>
	> AdFind V01.27.00cpp Joe Richards (joe@joeware.net) November 2005
	>
	> Using server: dc1.rallencorp.com:389
	> Directory: Windows Server 2003
	>
	> dn:cn=Partitions,CN=Configuration,dc=rallencorp,dc=com
	> >ms-DS-Behavior-Version: 0
	>
	>
	> 1 Objects returned

To change the functional level to Windows Server 2003, create an LDIF file called raise_forest_func_level.ldf with the following contents:

	dn: cn=partitions,cn=configuration,<ForestRootDN>
	changetype: modify
	replace: msDS-Behavior-Version
	msDS-Behavior-Version: 2
	-

Next, run ldifde to import the change.

	> ldifde -i -f raise_forest_func_level.ldf

Or else you can use the AdMod utility as follows:

	> admod -b <ForestDN> "msDS-Behavior-Version::2"

This will display results similar to the following:

	> AdMod V01.06.00cpp Joe Richards (joe@joeware.net) June 2005
	>
	> DN Count: 1
	> Using server: dc1.rallencorp.com
	> Modifying specified objects…
	> DN: cn=Partitions,cn=Configuration,dc=rallencorp,dc=com…
	>
	> The command completed successfully

Using VBScript

	' This code changes the functional level of the the forest the
	' user running the script is logged into to Windows Server 2003.
	set objRootDSE = GetObject("LDAP://RootDSE")
	set objDomain = GetObject("LDAP://cn=partitions," &_
	                           objRootDSE.Get("configurationNamingContext") )
	if objDomain.Get("msDS-Behavior-Version") < 2 then
	   Wscript.Echo "Attempting to change forest to " &  _
	                "Windows Server 2003 functional level … "
	   objDomain.Put "msDS-Behavior-Version", 2
	   objDomain.SetInfo
	else
	   Wscript.Echo "Forest already at Windows Server 2003 functional level"
	end if

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Using AdPrep to Prepare a Domain or Forest for Windows Server 2003

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to upgrade your existing Windows 2000 Active Directory domain controllers to Windows Server 2003. Before doing this, you must run the AdPrep tool, which extends the schema and adds several objects in Active Directory that are necessary for new features and enhancements.

First, run the following command on the Schema FSMO with the credentials of an account that is in both the Enterprise Admins and Schema Admins groups:

	>  
adprep /forestprep

After the updates from /forestprep have replicated throughout the forest (see Recipe 2.11), run the following command on the Infrastructure FSMO in each domain with the credentials of an account in the Domain Admins group:

	>  
adprep /domainprep

If the updates from /forestprep have not replicated to at least the Infrastructure FSMO servers in each domain, an error will be returned when running /domainprep. To debug any problems you encounter, see the AdPrep logfiles located at %SystemRoot%\System32\Debug\Adprep\Logs.

AdPrep can be found in the \i386 directory on the Windows Server 2003 CD. The tool relies on several files in that directory, so you cannot simply copy that file out to a server and run it. You must either run it from a CD or from a location where the entire directory has been copied.

The adprep command prepares a Windows 2000 forest and domains for Windows Server 2003. Both /forestprep and /domainprep must be run before you can upgrade any domain controllers to Windows Server 2003 or install new Windows Server 2003 domain controllers.

The adprep command serves a similar function to the Exchange 2000 setup /forestprep and /domainprep commands, which prepare an Active Directory forest and domains for Exchange 2000. The adprep /forestprep command extends the schema and modifies some default security descriptors, which is why it must run on the Schema FSMO and under the credentials of someone in both the Schema Admins and Enterprise Admins groups. In addition, the adprep /forestprep and /domainprep commands add new objects throughout the forest, many of which are necessary for new features supported in Windows Server 2003 Active Directory.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Determining WhetherAdPrep Has Completed

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to determine whether the AdPrep process, described in Recipe 2.12, has successfully prepared a Windows 2000 domain or forest for Windows Server 2003. After AdPrep has completed, you will then be ready to start promoting Windows Server 2003 domain controllers.

To determine whether adprep /domainprep completed, check for the existence of the following object where <DomainDN> is the distinguished name of the domain:

	cn=Windows2003Update,cn=DomainUpdates,cn=System,<DomainDN>

To determine whether adprep /forestprep completed, check for the existence of the following object where <ForestRootDN> is the distinguished name of the forest root domain:

	cn=Windows2003Update,cn=ForestUpdates,cn=Configuration,<ForestRootDN>

As described in Recipe 2.12, the AdPrep utility is used to prepare a Windows 2000 forest for the upgrade to Windows Server 2003. One of the nice features of AdPrep is it stores its progress in Active Directory. For /domainprep, a container with a distinguished name of cn=DomainUpdates,cn=System,<DomainDN> is created that has child object containers cn=Operations and cn=Windows2003Update. After AdPrep completes a task, such as extending the schema, it creates an object under the cn=Operations container to signify its completion. Each object has a GUID for its name, which represents some internal operation for AdPrep.

For /domainprep, 52 of these objects are created. After all of the operations have completed successfully, the cn=Windows20

• HOME
• ABOUT
• AUCTIONS
• SHIPPING
• FEES
• TOOLS
• HOW
• FAQ
• CONTACT

 

Original Source | Taken Source