Foreword

Foreword

Redmond, Washington. Friday afternoon, April 9, 1999. This was a big day for us. We were going to upgrade Microsoft Corporation's Windows NT 4.0 domain to an Active Directory domain. Approximately 30,000 user accounts—most of Microsoft's employees in Redmond—depended on the success of this upgrade, and we were still months away from releasing Active Directory to the public. In case problems arose, a few of the developers, testers, and program managers from the Active Directory team would spend the night in the data center. With a touch of the Enter key by a few of the team's members, the upgrade process began. The result? Everything went smoothly. Instead of fixing bugs, those spending the night had fun watching movies until dawn. One developer summed up the experience very well: "It's like watching your child's first step." It was an incredible feeling! That day was the first that Active Directory ran in a live production environment.

Of course, everything I've described here didn't happen automatically. The Active Directory team had been preparing for this day for a long time. There is a common practice at Microsoft called "eating your own dog food," so the Active Directory team and other groups in the Windows NT development team had been running Active Directory long before D-Day. The day-to-day productivity of our team depended heavily on the availability of Active Directory servers. Developers and testers carried pagers and fixed critical problems on the spot, day or night. The consequences should Active Directory become unavailable were severe—the team would not be able to log on, check e-mail, or access secured files, file shares, or internal Web sites. The trial runs paid off, and we learned as we made progress.

Development of Active Directory and the Active Directory Service Interfaces (ADSI), the group of COM-based interfaces that provide access to Active Directory, started before the Windows 2000 project. In fact, the first time Microsoft previewed Active Directory was at the Professional Developer Conference in 1996, and the first version of ADSI predates Active Directory. I was fortunate enough to be part of the team in its early development. We were a small team, occupying only the first floor of building 26 North on Microsoft's Redmond campus. "Dynamic," "fun," and "exciting" are a few of the words that come to mind to describe this team. Everyday, it seemed, a new idea was born. New terms like dcpromo, forest, upn, well-known guid, guid binding, object category, display specifier, dsgetdc, crackname, or spn were common topics of conversations in the hallways. Although you might not recognize all of these terms, many come from ideas that were driven by customer requirements, other Microsoft groups, independent software vendors (ISVs), and the need to simplify directory information for developers, administrators, and end users.

Directory services technology itself is silent and enabling. However, together with directory-enabled applications, it produces useful solutions for customers. Active Directory is no exception. During early development, the Active Directory team worked actively with many groups within Microsoft as well as with several ISVs. Most of the ISVs' existing products ran as stand-alone applications, but when integrated with Active Directory, their products were enhanced dramatically. For example, the Domain Name System (DNS) is integrated into Active Directory to take advantage of Active Directory replication, the Distributed File System (Dfs) utilizes the Active Directory Sites topology to find the closest Dfs server, and group policy uses the hierarchical nature of Active Directory storage to govern how to apply its policies. Microsoft Exchange 2000 is also integrated with Active Directory. All these improvements enhance the customer experience and increase productivity tremendously.

Application developers have a great opportunity to enhance their existing and future applications by integrating them with Active Directory. For example, an application can store global application configuration information in Active Directory and let Active Directory take care of replication and the availability of this information. Your application can advertise its existence to the directory so that other client applications can find it. Your application can extend the Active Directory schema by including application-specific user information. Then, each time a user logs on, your application can greet the user with the specific information you store in Active Directory. These are just a few of the truly endless possibilities.

Looking forward, we don't yet see the finish line. While evidence encourages us to believe that we're heading in the right direction, there is so much work still ahead of us. Active Directory technology must continue to evolve to meet changing market requirements. In the future, you can expect our continued quest for simplicity, reliability, scalability, and seamless integration with Microsoft's .NET technologies.

In Microsoft Windows 2000 Active Directory Programming, Charles Oppermann walks you through Active Directory and ADSI programming with his fresh, friendly approach to explaining concepts, procedures, and code samples. He derives his explanations and expertise from his own experience at Microsoft and from conversations with developers and administrators working with this technology every day. Charles covers all the topics necessary for you to make a great Active Directory–enabled application, including ADSI, the Active Directory schema, the Active Directory user interface, searching Active Directory, and much more. For developers who need to access Active Directory or are interested in enhancing their applications by integrating them with Active Directory, this book is a must read.

Andy Harjanto
Program Manager, Active Directory
Microsoft Corporation