If you are familiar with the O’Reilly Cookbook format, which 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 21 chapters, 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 (http://support.microsoft.com) articles, or documentation from the Microsoft Developers Network (MSDN; http://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 computer science motto: TIMTOWTDI, or There Is More Than One Way To Do It. 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, or freeware tools such as adfind and admod from http://www.joeware.net; and, finally, you can perform the same task using a scripting language, such as VBScript, Perl, or PowerShell. 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.
Note
Windows Server 2008 introduces the Server Core installation option, which is a limited Windows installation footprint that includes limited GUI functionality and no local access to the .NET Framework (and, by extension, PowerShell). A Server Core computer can be configured as an Active Directory domain controller. A Server Core DC can be managed locally using command-line tools and scripting languages such as VBScript, or it can be managed remotely using GUI tools and PowerShell.
We also took this approach with the programmatic solutions; we use VBScript for the programming language, primarily because it is widely used among Windows administrators and is the most straightforward from a code perspective when using Active Directory Service Interface (ADSI) and Windows Script Host (WSH). For those familiar with other languages, such as Visual Basic, Perl, and JScript, it is very easy to convert code from VBScript.
The downside to using VBScript is that it does not have all of the facilities necessary to accomplish some complicated tasks. Therefore, we use Perl in a few recipes that require a complicated programmatic solution. For those of you who wish that all of the solutions were written with Perl instead of VBScript, you can go to http://www.rallenhome.com/books/adcookbook2/code.html to download the code.
A special note regarding PowerShell coverage in this text:
PowerShell is a new command-line and scripting language
introduced by Microsoft. PowerShell’s claim to fame is its use of a
predictable Verb-Noun syntax that can be leveraged
regardless of the technology that it is managing:
Get-Object, Get-ChildItem,
Get-Mailbox, etc. This predictable syntax is driven
by the use of cmdlets (pronounced “command-lets”)
that can be created by individuals and software vendors alike. The first
Microsoft product to rely on PowerShell was Exchange 2007, which
includes a rich set of cmdlets to perform Exchange management tasks. In
fact, there are certain tasks in Exchange 2007 that can
only be performed using PowerShell!
The challenge that Active Directory administrators face with PowerShell lies in the fact that, as of the release of Windows Server 2008, a set of PowerShell cmdlets has not been produced by Microsoft to support Active Directory administration tasks. AD administrators still have the ability to leverage PowerShell in other ways, most notably through the use of cmdlets that have been created by third-party vendors or members of the Directory Services community. Many of these third-party cmdlets are freely available for download from the Internet; as we reference these third-party cmdlets throughout the text, we will also reference their source. The downside is that, since these cmdlets are provided by third-party vendors or individual contributors, there are currently significant “gaps” in what can be done with these cmdlets.
If you are familiar with .NET programming, it is possible to use
PowerShell to interface with Active Directory by using native .NET
classes and methods, such as the DirectoryEntry and DirectorySearcher classes within System.DirectoryServices. We have chosen to
focus on tasks in this book that can be accomplished relatively easily
using these native .NET classes and methods; readers who are looking for
more in-depth coverage of these topics should consult The .NET
Developer’s Guide to Directory Services Programming
referenced in the Recipe 1.6
section at the end of this chapter. PowerShell can also access the
Active Directory Scripting Interface (ADSI) in a similar manner to
VBScript; in these cases, PowerShell syntax will largely resemble the
VBScript syntax to perform the same task. Additionally, you will find
several references to third-party PowerShell cmdlets such as those
released by Quest (http://www.quest.com) and SDM
Software (http://www.sdmsoftware.com).
Another challenge with writing this book is that there are now multiple versions of Active Directory deployed on most corporate networks. The initial version released with Windows 2000 was followed by Windows Server 2003 and an incremental update to Windows Server 2003 R2, and recently Microsoft released Windows Server 2008, which provides a lot of updates and new features. We’ve decided to go with the approach of making everything work under the most recent version of Active Directory first, and earlier versions of Windows second. In fact, the majority of the solutions will work unchanged with Windows 2000, 2003, and R2. For the recipes or solutions that are specific to a particular version, we include a note mentioning the version it is targeted for. In particular, since the Windows 2000 operating system is nearing the end of its supported lifecycle, the majority of our focus will be on Windows Server 2003 and later. Most GUI and programmatic solutions will work unchanged with all three versions, but Microsoft introduced several new CLIs with Windows Server 2003 and R2, most of which cannot be run on the Windows 2000 operating system. Typically, you can still use these newer tools on a Windows XP or later computer to manage Windows 2000 Active Directory.
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 http://technet.microsoft.com/en-us/windowsserver/bb633748.aspx. 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 website, located at http://www.activedir.org/TF/Default.aspx. In Windows Server 2008, the notion of Resource Kit and Support Tool utilities has been abandoned in favor of including only fully supported utilities packaged with the Active Directory binaries. Almost all of the Support Tools from Windows Server 2003 are included within the Windows Server 2008 standard distribution.
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 website at http://www.joeware.net/freetools. 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.
There are several options for specifying alternate credentials.
Many GUI and CLI tools have an option to specify a user and password to
authenticate with. If the tool you want to use does not have that
option, you can use the runas command
instead. The following command would run the enumprop command from the Resource Kit under
the credentials of the administrator account in the
adatum.com domain:
> runas /user:administrator@adatum.com /netonly "enumprop "LDAP://dc1/dc=adatum,dc=com""
You can also open up a Windows command prompt using alternate
credentials, which will allow you to run commands using these elevated
credentials until you close the command prompt window. To open a command
prompt using the runas command,
simply type runas
/user:administrator@adatum.com cmd.
To run a Microsoft Management Console (MMC) console with alternate
credentials, simply use mmc as the
command to run from runas:
> runas /user:administrator@adatum.com /netonly "mmc"
This will create an empty MMC console from which you can add consoles for any snap-ins that have been installed on the local computer.
Note
The /netonly switch is
necessary if the user you are authenticating with does not have local
logon rights on the machine you are running the command from, such as
a user ID from a nontrusted domain.
There is another option for running MMC snap-ins with alternate credentials. Click on the Start menu and browse to the tool you want to open, hold down the Shift key, and then right-click on the tool. If you select Run As, you will be prompted to enter credentials to run the tool under.
Another issue to be aware of when following the instructions in the recipes is whether you need to target a specific domain controller. In the solutions in this book, we typically do not target a specific domain controller. When you don’t specify a domain controller, you are using a serverless bind and there is no guarantee as to precisely which server you will be hitting. Depending on your environment and the task you need to do, you may want to target a specific domain controller so that you know where the query or change will be taking place. Also, serverless binding can work only if the DNS for the Active Directory forest is configured properly and your client can query it. If you have a standalone Active Directory environment that has no ties to your corporate DNS, you may need to target a specific domain controller for the tools to work.
Even with the new utilities available with Windows Server 2003 and Windows Server 2008, 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 numerous attributes of an object simultaneously. If you want to specify more than just one or two values that need to be modified, 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 (http://www.rfc-editor.org), 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:
dn: cn=jsmith,cn=users,dc=adatum,dc=com changetype: modify replace: sn sn: Smith -
Modification entries must be followed by a line that only contains a
hyphen (-). You can put additional modification actions following the
hyphen, each separated by another hyphen. Here is a complete LDIF example
that adds a jsmith user object and then
modifies the givenName and sn attributes for that object:
dn: cn=jsmith,cn=users,dc=adatum,dc=com changetype: add objectClass: user samaccountname: jsmith sn: JSmith dn: cn=jsmith,cn=users,dc=adatum,dc=com changetype: modify add: givenName givenName: Jim - replace: sn sn: Smith -
See Recipes 4.28 and 4.29 for more details on how to use the ldifde utility to import and export LDIF files.
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 Active Directory, Fourth Edition, by Brian Desmond 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 do 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 scripted 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.adatum.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.
With ADSI, you can use the IADsOpenDSObject::OpenDSObject method to
specify alternate credentials. You can quickly turn any ADSI-based
example in this book into one that authenticates as a particular
user.
For example, a solution to print out the description of a domain might look like:
set objDomain = GetObject("LDAP://dc=apac,dc=adatum,dc=com")
WScript.Echo "Description: " & objDomain.Get("description")Using OpenDSObject, it takes
only one additional statement to make the same code authenticate as the
administrator in the domain:
set objLDAP = GetObject("LDAP:")
set objDomain = objLDAP.OpenDSObject( _
"LDAP://dc=apac,dc=adatum,dc=com", _
"administrator@apac.adatum.com", _
"MyPassword", _
0)
WScript.Echo "Description: " & objDomain.Get("description")It is just as easy to authenticate in ADO code as well. Take the
following example, which queries all computer objects in the
apac.adatum.com domain:
strBase = "<LDAP://dc=apac,dc=adatum,dc=com>;"
strFilter = "(&(objectclass=computer)(objectcategory=computer));"
strAttrs = "cn;"
strScope = "subtree"
set objConn = CreateObject("ADODB.Connection")
objConn.Provider = "ADsDSOObject"
objConn.Open "Active Directory Provider"
set objRS = objConn.Execute(strBase & strFilter & strAttrs & strScope)
objRS.MoveFirst
while Not objRS.EOF
Wscript.Echo objRS.Fields(0).Value
objRS.MoveNext
wendNow, by adding two lines (in bold), we can authenticate with the administrator account:
strBaseDN = "<LDAP://dc=apac,dc=adatum,dc=com>;"
strFilter = "(&(objectclass=computer)(objectcategory=computer));"
strAttrs = "cn;"
strScope = "subtree"
set objConn = CreateObject("ADODB.Connection")
objConn.Provider = "ADsDSOObject"
objConn.Properties("User ID") = "administrator@apac.adatum.com"
objConn.Properties("Password") = "MyPassword"
objConn.Open "Active Directory Provider"
set objRS = objConn.Execute(strBaseDN & strFilter & strAttrs & strScope)
objRS.MoveFirst
while Not objRS.EOF
Wscript.Echo objRS.Fields(0).Value
objRS.MoveNext
wendTo authenticate with ADO, you need to set the User ID and Password properties of the ADO connection
object. We used the UPN of the administrator for the user ID. With ADSI
and ADO, you can use a UPN, NT 4.0 style account name (e.g., APAC\Administrator), or distinguished
name for the user ID.
An important part of any script is error checking. Error checking allows your programs to gracefully identify any issues that arise during execution and take the appropriate action. Another best practice is to define variables before you use them and clean them up after you are done with them. In this book, most of the programmatic solutions do not include any error checking, predefined variables, or variable cleanup. Admittedly, this is not setting a good example, but if we included extensive error checking and variable management, it would have made this book considerably longer with little added value to the reader. The goal is to provide you with a code snippet that shows you how to accomplish a task, not provide robust scripts that include all the trimmings.
Error checking with VBScript is pretty straightforward. At the beginning of the script include the following declaration:
On Error Resume Next
This tells the script interpreter to continue even if errors
occur. Without that declaration, anytime an error is encountered the
script will abort. When you use On Error Resume
Next, you need to use the Err object to check for errors after any step
where a fatal error could occur. The following example shows how to use
the Err object:
On Error Resume Next
set objDomain = GetObject("LDAP://dc=adatum,dc=com")
If Err.Number <> 0 then
Wscript.Echo "An error occured getting the domain object: " & Err.
Description
Wscript.Quit
end ifTwo important properties of the Err object are Number, which if nonzero signifies an error,
and Description, which will contain
the error message.
As far as variable management goes, it is always a good practice to include the following at the beginning of every script:
Option Explicit
When this is used, every variable in the script must be declared
or an exception will be generated when you attempt to run the script.
Variables are declared in VBScript using the Dim keyword. After you are done with a
variable, it is a good practice to set it to Nothing so you release any resources bound to
the variable, and don’t accidentally re-use the variable with its
previous value. The following code shows a complete example for printing
the display name for a domain with error checking and variable
management included:
Option Explicit
On Error Resume Next
Dim objDomain
set objDomain = GetObject("LDAP://cn=users,dc=adatum,dc=com")
if Err.Number <> 0 then
Wscript.Echo "An error occurred getting the domain object: " & Err.Description
Wscript.Quit
end if
Dim strDescr
strDescr = objDomain.Get("description")
if Err.Number <> 0 then
Wscript.Echo "An error occurred getting the description: " & Err.Description
Wscript.Quit
end if
WScript.Echo "Description: " & strDescr
objDomain = Nothing
strDescr = NothingThis 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=adatum,dc=com)
<ForestRootDN>Distinguished name of the forest root domain (e.g., dc=adatum,dc=com)
<DomainDNSName>Fully qualified DNS name of domain (e.g., amer.adatum.com)
<ForestDNSName>Fully qualified DNS name of forest root domain (e.g., adatum.com)
<DomainControllerName>Single-label or fully qualified DNS hostname of domain controller (e.g., dc01.adatum.com)
<UserDN>Distinguished name of user (e.g., cn=administrator,cn=users,dc=adatum,dc=com)
<GroupDN>Distinguished name of group (e.g., cn=DomainAdmins,cn=users,dc=adatum, dc=com)
<ComputerName>Single-label DNS hostname of computer (e.g., adatum-xp)
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 number of 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 website 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 website: 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/kb/<ArticleNumber>.
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: http://msdn.microsoft.com/library.
- Microsoft Active Directory Home Page (http://www.microsoft.com/ad)
This site is the starting point for Active Directory information provided by Microsoft. It contains links to white papers, case studies, and tools.
- Microsoft PowerShell Home Page (http://www.microsoft.com/PowerShell)
This site is the starting point for PowerShell information provided by Microsoft. This will be an interesting site to keep an eye on as new and updated PowerShell support is released by the various Microsoft product groups.
- Microsoft Webcasts (http://support.microsoft.com/default.aspx?scid=fh;EN-US;pwebcst)
Webcasts are on-demand audio/video technical presentations that cover a wide range of Microsoft products. There are several Active Directory-related webcasts that cover such topics as disaster recovery, upgrading to Windows Server 2003 Active Directory, and Active Directory tools.
- DirTeam Blogs (http://blogs.dirteam.com)
The DirTeam collection of blogs features content from very active members of the Directory Services MVP community.
- Code for this book
Code for this book can be found at http://techtasks.com/code/viewbook/2.
- joe Richards’ Home Page (http://www.joeware.net)
This is the home of the joeware utilities that you’ll see referenced throughout this book; you can always download the latest version of adfind, admod, etc., from joe’s site, as well as browse FAQs and forums discussing each of the utilities.
- Petri.co.il by Daniel Petri (http://www.petri.co.il/ad.htm)
This is another site that’s run by a Microsoft MVP that contains a number of valuable links and tutorials.
- Ask the Directory Services Team (http://blogs.technet.com/askds)
This site features regularly updated content from members of the Directory Services support organization within Microsoft.
- ActiveDir Home Page (http://www.activedir.org)
This is the home page for the ActiveDir Active Directory mailing list. It includes links to active Directory Services blogs, as well as articles, tutorials, and links to third-party tools.
- Directory Programming (http://www.directoryprogramming.net)
Just as the ActiveDir list is crucial for AD administrators, this site is extremely valuable for AD developers. It also includes user forums where participants can post questions about AD programming topics.
- microsoft.public.windows.server.active_directory
This is a very active newsgroup where several top-notch Active Directory experts answer questions posed by users.
- microsoft.public.windows.server.dns
This is another good resource if you have a DNS question you’ve been unable to find an answer for; odds are someone on this newsgroup will have an answer.
- microsoft.public.adsi.general
If you have questions about ADSI, this is another very active newsgroup where you can find answers.
If you have a question about a particular topic, a good starting point is to search the newsgroups using Google’s Groups search engine (http://groups.google.com). Just like its web search engine, the group search engine is very fast and is an invaluable resource when trying to locate information.
- ActiveDir (http://www.activedir.org)
The ActiveDir mailing list is where the most advanced Active Directory questions can get answered. The list owner, Tony Murray, does an excellent job of not allowing topics to get out of hand (as can sometimes happen on large mailing lists). The list is very active and it is rare for a question to go unanswered. Some of Microsoft’s Active Directory program managers and developers also participate on the list and are very helpful with the toughest questions. Keeping track of this list is a must-have for any serious Active Directory administrator.
- Microsoft Identity Integration Server Users Group (http://tech.groups.yahoo.com/group/MMSUG/)
Though it still bears the name of the previous edition of the ILM product, MIIS, this community-run mailing list is an active resource for anyone who is active in the Identity and Access Management space.
- Microsoft Exchange Yahoo Group (http://tech.groups.yahoo.com/group/exchange2007/)
This mailing list provides an excellent resource for discussions of all aspects of the Microsoft Exchange product.
In addition to the Resource Kit books, the following books are good sources of information:
- Active Directory, Fourth Edition, by Brian Desmond et al. (O’Reilly)
This is a good all-purpose book on Active Directory. A few of the topics the fourth edition covers are new Windows Server 2008 features, designing Active Directory, upgrading from Windows 2000, Active Directory Lightweight Directory Services (AD LDS), Exchange 2007, and Active Directory automation.
- The .NET Developer’s Guide to Directory Services Programming, by Joe Kaplan and Ryan Dunn (Addison-Wesley)
Written by two notables in the Directory Services programming community, this book is a practical introduction to programming directory services, using both versions 1.1 and 2.0 of the .NET Framework.
- Windows IT Pro (http://windowsitpro.com/)
This is a general-purpose monthly magazine for system administrators who support Microsoft products. The magazine isn’t devoted to Active Directory, but generally there are related topics covered every month.
Get Active Directory Cookbook, 3rd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
