Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Getting Started

Content preview·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 not be anything new to you. The book is composed of 18 chapters, each containing 10-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 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 (MS KB) (http://support.microsoft.com/) articles, or documentation from the Microsoft Developers Network (MSDN) (http://msdn.microsoft.com).

When I first began developing the content for the book, I 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, or ldifde; and, finally, you can perform the same task using a scripting language, such as VBScript or Perl.

Since people prefer different methods, and no one method is necessarily better than another, I decided to write solutions to the recipes using one of each. That means instead of just a single solution per recipe, I include up to three solutions using GUI, CLI, and programmatic examples. That said, some recipes cannot be accomplished with one of the three methods or it is very difficult to do so. In that case, 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 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 not be anything new to you. The book is composed of 18 chapters, each containing 10-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 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 (MS KB) (http://support.microsoft.com/) articles, or documentation from the Microsoft Developers Network (MSDN) (http://msdn.microsoft.com).

When I first began developing the content for the book, I 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, or ldifde; and, finally, you can perform the same task using a scripting language, such as VBScript or Perl.

Since people prefer different methods, and no one method is necessarily better than another, I decided to write solutions to the recipes using one of each. That means instead of just a single solution per recipe, I include up to three solutions using GUI, CLI, and programmatic examples. That said, some recipes cannot be accomplished with one of the three methods or it is very difficult to do so. In that case, 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 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. For this reason, in the majority of cases and unless otherwise noted, I only used tools that are part of the default operating system or available in the Resource Kit or Support Tools. 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 their daily tasks. More information on the Resource Kits can be found at the following web site: http://www.microsoft.com/windows/reskits/. The Windows 2000 Support Tools, which is called the Windows Support Tools in Windows Server 2003, contain many "must have" 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 or Windows Server 2003 CD in the \support\toolsdirectory. The Appendix A contains a complete list of the tools used within this book, where they can be found, and what recipes they are used in.

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 I'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 reprint rights for this chapter

Even with the new utilities available with Windows Server 2003, 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 any object type.

One reason for the lack of command-line tools to do this is 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 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 reprint rights for this chapter

In the VBScript solutions, my intention was to provide the answer in as few lines of code as necessary. Since this book is not a pure programming book, I did not want to provide a detailed explanation of how to use ADSI or WMI. If you are looking for that, I recommend Part 3 of Active Directory, Second Edition. 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.

I mentioned earlier that in the GUI and CLI examples I did not provide instructions for targeting a specific domain controller to perform a task. Instead, I 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 you do not want the username and password contained in the script to be easily viewable by others. Nevertheless, it is a necessary evil, especially when developing against multiple forests, and I'll describe how it can be done with ADSI and ADO.

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 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, I 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 I use it, I'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.rallencorp.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

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 reprint rights for this chapter

While it is my 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, there is easily another three to four chapters I could have included in this book, but due to space and time considerations, it was not possible for this edition. Working on this book has made me realize just how must stuff 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 I use on a regular basis.

If you have any questions about the complete syntax or usage information for any of the command-line tools I 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, I 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: http://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: http://support.microsoft.com/?kbid=.

MSDN contains a ton of information on Active Directory and the programmatic interfaces to Active Directory, such as ADSI and LDAP. I sometimes reference MSDN pages in recipes. Unfortunately, there is no easy way to reference the exact page I'm talking about unless I provided the URL or navigation to the page, which would more than likely change by the time the book was printed. Instead I provide the name of 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 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 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. The domains that are part of a common DNS namespace are considered to be in the same domain tree. For example, the amer.rallencorp.com, emea.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 when multiple domain trees are necessary is with large conglomerate corporations. Conglomerates are made up of multiple individual companies. Each company typically wants to maintain its own identity and, therefore, its own namespace. Describing the conglomerate scenario is a good way to show the relationships between forests, domains, domain trees, and trusts.

Assuming 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 trust each other. Without the trust relationships, users from one forest cannot access resources in the domains of the other forest. If you want users to be able to access resources within each company's domains, using separate domain trees is an easier approach than separate forests. Transitive trusts are established between the root domains of each domain tree within a forest. As a result, every domain within a forest, regardless of which domain tree they are in, is trusted. Figure 2-1 illustrates an example with three domain trees in a forest called

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 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 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. The domains that are part of a common DNS namespace are considered to be in the same domain tree. For example, the amer.rallencorp.com, emea.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 when multiple domain trees are necessary is with large conglomerate corporations. Conglomerates are made up of multiple individual companies. Each company typically wants to maintain its own identity and, therefore, its own namespace. Describing the conglomerate scenario is a good way to show the relationships between forests, domains, domain trees, and trusts.

Assuming 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 trust each other. Without the trust relationships, users from one forest cannot access resources in the domains of the other forest. If you want users to be able to access resources within each company's domains, using separate domain trees is an easier approach than separate forests. Transitive trusts are established between the root domains of each domain tree within a forest. As a result, every domain within a forest, regardless of which domain tree they are in, is trusted. Figure 2-1 illustrates an example with three domain trees in a forest called

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 reprint rights for this chapter

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

Section 2.1.2.1: Using a graphical user interface

Run dcpromo from a command line or 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.

Section 2.1.2.2: Using a command-line interface

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

The act of creating a forest consists of creating a forest root domain. To do this, you need to use the dcpromo executable 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.

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 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 <ForestDNSName> 1c
> nslookup <DomainControllerDNSName>
> nslookup -type=SRV _ldap._tcp.gc._msdcs.<ForestDNSName>
> nslookup <ForestDNSName>

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.3.

The method described in the 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.

Recipe 2.19 for viewing the trusts for a domain, Recipe 2.22 for removing a trust, and Recipe 3.3 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 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.

Section 2.3.2.1: 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

Section 2.3.2.2: Using a command-line interface

dcpromo can also be run in unattended mode. See Recipe 3.4 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 subdomain (contained within the same namespace) of a parent domain, you are creating a domain in an existing domain tree. If you are creating the first domain in a forest or a domain outside the namespace of the forest root, you are creating a domain in a new domain tree.

Each domain increases the support costs of Active Directory due to the need for maintaining additional domain controllers and time spent configuring and maintaining the domain. When designing an Active Directory forest, your goal should be to keep the number of domains that are necessary to a minimum.

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 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 that 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 subdomains, you have to remove the subdomains before proceeding.

After all domain controllers have been demoted 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 domain unless they 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 <DomainDNSName> 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.3.

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 from failed replication events.

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 reprint rights for this chapter

You want to completely remove a domain that was orphaned because "This server is the last domain controller in the domain" was not selected when demoting the last domain controller, the domain was forcibly removed, or the last domain controller in the domain was decommissioned improperly.

Section 2.5.2.1: 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) 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 the ntdsutil command 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:

               [RETURN]

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 reprint rights for this chapter

You want a list of the domains in a forest.

Section 2.6.2.1: Using a graphical user interface

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

Section 2.6.2.2: Using a command-line interface

> ntdsutil "d m" "sel op tar" c "co t s <DomainControllerName>"  q "l d" q q q

Section 2.6.2.3: Using VBScript

' This code gets the list of the domains contained in the 
' forest that the user running the script is logged into.

set objRootDSE = GetObject("LDAP://RootDSE")
strADsPath =  "<GC://" & objRootDSE.Get("rootDomainNamingContext") & ">;"
strFilter  = "(objectcategory=domainDNS);"
strAttrs   = "name;"
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
    Wscript.Echo objRS.Fields(0).Value
    objRS.MoveNext
wend

Section 2.6.3.1: 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.

Section 2.6.3.2: 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

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 reprint rights for this chapter

You want to find the NetBIOS name of a domain. Although Microsoft has moved to using DNS for primary 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 naming.

Section 2.7.2.1: Using a graphical user interface

1. Open the Active Directory Domains and Trusts snap-in.
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.

Section 2.7.2.2: Using a command-line interface

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

Section 2.7.2.3: 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 reprint rights for this chapter

You want to rename a domain due to organizational changes or legal restrictions because of an acquisition. 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 that all domain controllers and member computers in the domain are rebooted!

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. 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:

http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx

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.

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

Changing the Mode of a Domain

Content preview·Buy reprint rights for this chapter

You want to change the mode of a Windows 2000 Active Directory domain from mixed to native. 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.

Section 2.9.2.1: Using a graphical user interface

1. Open the Active Directory Domains and Trusts snap-in.
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.

Section 2.9.2.2: Using a command-line interface

To retrieve the current mode, use the following command:

> dsquery * <DomainDN> -scope base -attr ntMixedDomain

Or you can use the enumprop command found in the Windows 2000 Resource Kit.

> enumprop /ATTR:ntMixedDomain "LDAP://<DomainDN>"

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

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

Then run the ldifde command to import the change.

> ldifde -i -f change_domain_mode.ldf

Section 2.9.2.3: 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

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 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 log files 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

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 if ADPrep Has Completed

Content preview·Buy reprint rights for this chapter

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

To determine if 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 if 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.10, 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=Windows2003Update object is created to indicate /domainprep has completed.Figure 2-2 shows an example of the container structure created by /domainprep.

Figure 2-2: DomainPrep containers

For /forestprep, a container with the distinguished name of

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

Checking Whether a Windows 2000 Domain Controller Can Be Upgraded to Windows Server 2003

Content preview·Buy reprint rights for this chapter

You want to determine if a domain controller is ready to be upgraded to Windows Server 2003.

Insert a Windows Server 2003 CD into the Windows 2000 domain controller or map a drive to the files contained on the CD. Run the following command from the \i386 directory:

> winnt32 /checkupgradeonly

The /checkupgradeonly switch simulates the initial steps for upgrading a server to Windows Server 2003. It verifies, among other things, that adprep has completed and that any installed applications are compatible with the new operating system.

Recipe 2.11 for determining if adprep has completed and MS KB 331161 (List of Fixes to Use on Windows 2000 Domain Controllers Before You Run the Adprep/Forestprep Command)

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 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.

Section 2.13.2.1: Using a graphical user interface

1. Open the Active Directory Domains and Trusts snap-in.
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.

Section 2.13.2.2: Using a command-line interface

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

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

Or you can use the enumprop command found in the Windows 2000 Resource Kit.

> enumprop /ATTR:msDS-Behavior-Version "LDAP://<DomainDN>"

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 the ldifde command to import the change.

> ldifde -i -f raise_domain_func_level.ldf

Section 2.13.2.3: Using VBScript

' This code changes the functional level of the specified domain to 
' the Windows Server 2003 domain functional level
' ------ SCRIPT CONFIGURATION ------
strDomain = "<

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 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.

Section 2.14.2.1: Using a graphical user interface

1. Open the Active Directory Domains and Trusts snap-in.
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.

Section 2.14.2.2: 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 enumprop command found in the Windows 2000 Resource Kit.

> enumprop /ATTR:msDS-Behavior-Version "LDAP://<ForestRootDN>"

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 the ldifde command to import the change.

> ldifde -i -f raise_forest_func_level.ldf

Section 2.14.2.3: 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!

Creating a Trust Between a Windows NT Domain and an AD Domain

Content preview·Buy reprint rights for this chapter

You want to create a one-way or two-way nontransitive trust from an AD domain to a Windows NT domain.

Section 2.15.2.1: Using a graphical user interface

1. Open the Active Directory Domains and Trusts snap-in.
2. In the left pane, right-click the domain you want to add a trust for and select Properties.
3. Click on the Trusts tab.
4. Click the New Trust button.
5. After the New Trust Wizard opens, click Next.
6. Type the NetBIOS name of the NT domain and click Next.
7. Assuming the NT domain was resolvable via its NetBIOS name, the next screen will ask for the Direction of Trust. Select Two-way, One-way incoming, or One-way outgoing, and click Next.
8. If you selected Two-way or One-way Outgoing, you'll need to select the scope of authentication, which can be either Domain-wide or Selective, and click Next.
9. Enter and re-type the trust password and click Next.
10. Click Next twice to finish.

Section 2.15.2.2: Using a command-line interface

> netdom trust <NT4DomainName> /Domain:<ADDomainName> /ADD[RETURN]
         [/UserD:<ADDomainName>\ADUser> /PasswordD:*][RETURN]
         [/UserO:<NT4DomainName>\NT4User> /PasswordO:*][RETURN]
         [/TWOWAY]

For example, to create a trust from the NT4 domain RALLENCORP_NT4 to the AD domain RALLENCORP, use the following command:

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 Transitive Trust Between Two AD Forests

Content preview·Buy reprint rights for this chapter

This recipe requires the Windows Server 2003 forest functional level in both forests.

You want to create a transitive trust between two AD forests. This causes the domains in both forests to trust each other without the need for additional trusts.

Section 2.16.2.1: Using a graphical user interface

1. Open the Active Directory Domains and Trusts snap-in.
2. In the left pane, right click the forest root domain and select Properties.
3. Click on the Trusts tab.
4. Click the New Trust button.
5. After the New Trust Wizard opens, click Next.
6. Type the DNS name of the AD forest and click Next.
7. Select Forest trust and click Next.
8. Complete the wizard by stepping through the rest of the configuration screens.

Section 2.16.2.2: Using a command-line interface

> netdom trust <Forest1DNSName> /Domain:<Forest2DNSName> /Twoway /Transitive /ADD[RETURN]
         [/UserD:<Forest2AdminUser> /PasswordD:*][RETURN]
         [/UserO:<Forest1AdminUser> /PasswordO:*]

For example, to create a two-way forest trust from the AD forest rallencorp.com to the AD forest othercorp.com, use the following command:

> netdom trust rallencorp.com /Domain:othercorp.com /Twoway /Transitive /ADD[RETURN]
         /UserD:administrator@othercorp.com /PasswordD:*[RETURN]
         /UserO:administrator@rallencorp.com /PasswordO:*

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 Shortcut Trust Between Two AD Domains

Content preview·