Creating a Test Network and Development Environment

While writing this book, I spent many hours creating and re-creating a development environment in which to write the sample programs. The next few sections offer some guidance to help you create your own test and development network. The approach I describe is just one of many ways that a Windows 2000 domain can be set up. If you aren't familiar with Windows 2000 networking concepts and technologies such as domains, DNS, TCP/IP, DHCP, and the rest of the alphabet soup, I'd encourage you to do some background reading before working with the samples in this book. The Microsoft Domain Name System (DNS), a crucial component of a network, uses Active Directory to manage network addresses and computer names. Through experience, you'll find that even relatively minor problems in the configuration of DNS or Active Directory can cause problems later on. Planning and careful deployment are essential.

Server Setup

First you'll need an operational Windows 2000 domain. A Windows 2000 domain is different from the older Windows NT domains. If your organization is running Windows 2000 and you have security access to view and manipulate the organization's Active Directory, you have all you need, but I don't recommend using your organization's Active Directory for your development environment, particularly if you want to modify the schema. That kind of operation should always be carefully planned and deployed in a test lab environment first.

If you create your own Windows 2000 domain, or set up a child domain within an existing Windows 2000 domain, you'll need a server-class computer, one with a fast processor (500 MHz or higher) and at least 128 megabytes of memory. This should be considered the minimum configuration; working interactively at the server will require more memory. If more than one developer is going to access this domain's directory, you might consider additional servers and spread services such as DNS and DHCP to the other computers. This is particularly true if you plan on working with Microsoft Exchange 2000 Server for e-mail and collaborative applications. Windows 2000 Server should be installed on each server you use. Windows 2000 Advanced Server can also be used if support for more than four processors or clustering and failover capability is desired.

To begin the process of creating a domain, you can run Configure Your Server by clicking the Start button, pointing to Programs, pointing to Administrative Tools, and then clicking Configuring Your Server. As an alternative, you can run the DCPromo program from the Run dialog box. How you configure your server depends on many factors, such as Internet connectivity, Internet domain name registration, and personal preference. For more information, read the Microsoft Windows 2000 Server Resource Kit (Microsoft Press, 2000) and refer to the Windows 2000 Planning and Deployment Guide, which can be found at http://www.microsoft.com/windows2000/library/planning/default.asp.

I recommend running DCPromo.exe rather than using the Configure Your Server tool for creating an Active Directory domain. People seem to get less confused at the prompts the DCPromo wizard presents.

Many people starting out with Active Directory run into difficulty with the initial setup procedure. As I mentioned, Active Directory is sensitive to the DNS configuration of the network as well as the network hardware and protocols. I strongly recommend a thorough reading of the books cited previously.

Microsoft product support offers a lot of information about the issues that people encounter when upgrading from Windows NT or creating new Active Directory domains. This information can be found at http://support.microsoft.com/support/win2000/dns.asp.

Microsoft provides an updated Domain Controller Diagnostic tool (DCDiag) with new features to diagnose domain controller problems. This tool is available for download from http://www.microsoft.com/technet/win2000/win2ksrv/dnsreq.asp.

Development Workstation

For your development workstation, I recommend using Windows 2000 Professional, although you could use the same computer that is running Active Directory. As I mentioned earlier, you can use Windows NT 4.0 with the Active Directory Client or Windows 98 with the Active Directory Client, but I do not recommend either. When you install Windows 2000 Professional, make sure you join the domain you plan on working with. If you already have Windows 2000 running on your development computer, use the Network Identification tab under System Properties to join the domain you plan to use.

The code samples for this book were written using Visual C++ 6.0 and Visual Basic 6.0 with Service Pack 4 installed. Visual C++ developers should note that the files required for ADSI are not included in Visual C++. You can find them as part of the Platform SDK. The components of the Platform SDK that you will need are "Build Environment\Network and Directory Services\Active Directory Services Interface" and "Build Environment\Win32 API\Win32 API." You can download these components of the Platform SDK from http://msdn.microsoft.com/downloads. The files from the Platform SDK required to compile the code samples presented in the book are included on the companion CD. Be sure to configure Visual C++ to access these header and library files, which should be placed at the top of the directories list. The illustration below shows the Directories tab of the Options dialog box with the required Platform SDK header files at the top of the directories list.

Visual Basic users will need to reference the Active DS Type Library in their Visual Basic project, as shown here.

If you intend to use only the scripting examples, Visual C++ and Visual Basic are not required. The Microsoft Script Debugger can be helpful when working with scripts. It is included with Windows 2000 and is available for download from Microsoft's Web site at http://msdn.microsoft.com/scripting/. Other development environments, such as Borland's Delphi, might work with Active Directory; however, you are on your own, as I have used only the previously mentioned software for writing this book.

To manage Active Directory remotely, you should install the Administration Pack on the Windows 2000 development computer by running the Adminpak.msi file found in the I386 folder on the Windows 2000 Server or Windows 2000 Advanced Server CD. This Microsoft Installer package will load the necessary management consoles that you can use to manage Active Directory. These same tools are automatically installed on the server when a domain is created. Other helpful tools are found on the Windows 2000 CD (all versions). The Windows 2000 Support Tools contain a number of good network diagnostic tools, including an LDAP browser and the powerful ADSI Edit tool. I'll describe the use of these tools in more detail near the end of Chapter 2. To install the support tools, run Setup.exe in the Support\Tools folder of the Windows 2000 CD.

Test Workstation

Although not a requirement, I recommend that you use a third workstation as your test environment. This computer should be configured similarly to the computers that most of the network users have. It should also contain only the software that's deployed in your organization. It's amazing how many programs that run fine on a development workstation crash or refuse to run on a target user's computer. This is generally the result of DLL conflicts or an assumption that a particular configuration exists.

If your programs need to run on Windows 98, Windows NT 4.0, or both, you should install the appropriate Active Directory Client (available on the companion CD). Also, make several disk partitions on this test workstation and install each operating system separately. Do not mix operating systems on the same partitions, as that will invariably cause conflicts. Each operating system partition should be clean, just as a user's will be when they get a new computer. Also, consider having multiple partitions of Windows 2000—one formatted with the FAT file system and another with NTFS. Using these multiple partitions can expose errors related to file and folder security permissions.