Developers of Active Directory applications need to ensure that their applications run on various versions of Windows. In a perfect world, everyone would use the latest version of Windows and whenever a new version was released it would be instantly propagated to all computers. The reality is that many organizations still run Windows 98 or even Windows 95 on most of their desktop computers. Upgrading these machines to Windows 2000 would give network administrators more stability and better management of resources, but upgrades aren't always practical.
In many cases, applications developed to work with Active Directory will need to run on various versions of Windows, and the developers of those applications must take into account the different levels of API support that are available with older versions of Windows.
Installing new technologies on older versions of Windows is one of the toughest
Active Directory has its own set of
You can download the latest version of ADSI for various platforms and languages at http://www.microsoft.com/adsi/ or http://www.microsoft.com/windows2000/. However, this download includes only the ADSI components and the LDAP provider; it does not include the modules for the Active Directory functions.
To solve this problem, Microsoft provides the Active Directory Client. This package updates previous versions of Windows to include the ADSI components and Active Directory components. This package also contains components that rely on Active Directory to function—the Distributed File System, for example—and provides a specialized user interface designed to search for Active Directory objects. An example of this UI is the Find Printer tool on the Find option on the Start menu.
The package for Windows 95 and Windows 98, named DSClient.exe, is available in the Clients\Win9x folder on the Windows 2000 Server and Windows 2000 Advanced Server CD-ROMs. DSClient.exe is also available on this book's companion CD in the DSClients folder.
With Windows Millennium Edition (Me), the recent upgrade to Windows 98, Microsoft made a major change to its support policy. Windows Me marks a clear separation between business and consumer operating systems. Officially, Microsoft does not support ADSI on Windows Me. That's not to say ADSI won't work, but since Windows Me is intended for home use only, there isn't specific ADSI support available.
If you are planning on using Windows Me at home and dialing into your company's network via RAS or VPN, be aware of this limitation.
Windows XP Home Edition is slated to be the replacement for Windows Me. Although Windows XP Home Edition is in beta testing as of this writing, I would expect that ADSI will
A version of the Active Directory Client for Windows NT 4.0 was released in February 2001 and is included on the book's companion CD in the DSClients folder. It is also expected to be included in Service Pack 7 for Windows NT 4.0. The latest version of the Active Directory Client can be found at http://www.microsoft.com/windows2000/.
In Windows NT 4.0, domain data was contained in the Security Account Manager (SAM) database. This data includes information about computers and users, groups, security settings, and shared printers and folders.
Before ADSI was available, applications could call various APIs to create users, manipulate printers, and perform other operations on items contained in the SAM database. In fact, the WinNT provider calls these APIs (which have the format Net XXX) to perform the actions required. This use of the WinNT provider is a good example of how ADSI provides a common, object-oriented programming model on top of language-specific, monolithic APIs.
Now that ADSI is established, a lot of code, particularly network administration scripts and ASP-based applications, use the WinNT provider to work with Windows NT 4.0 domains. That code will continue to work with Active Directory under Windows 2000 because Active Directory is backward compatible with Windows NT 4.0. However, new features in Active Directory are not available through the Net XXX APIs, so applications using the WinNT provider cannot access them.
While it's not necessary to rush out and start converting your code that uses the Net XXX APIs or the WinNT provider, you should follow the example in this book and use the LDAP provider exclusively to access Active Directory. Obviously, in a mixed Windows NT and Windows 2000 environment, you must use the WinNT provider, but be sure to let the IT department know of all the nifty features you could have in your application if it didn't have to limit itself.
Windows 2000 includes an updated version of ADSI 2.5. This version includes support for Active Directory tombstone objects and various bug fixes.
The Windows 2000 version of ADSI also includes support for the NameTranslate , WinNTSystemInfo , and ADSystemInfo objects. This support is not included in the basic ADSI 2.5 package for Windows 95, Windows 98, and Windows NT 4.0 because the necessary Directory Service ( Ds XXX) APIs are not available. Installing the Active Directory Client provides support for the NameTranslate object.
Windows 2000 Service Pack 1 contains a new option that speeds access to known directory objects. In a program using the LDAP provider, if the binding string includes a server
is the information left behind when Active Directory is told to delete an object. Instead of deleting an object's entire content, Active Directory moves it to a Deleted Objects folder and sets the
attribute to True. Although most of the object's attributes are deleted to save space, others that uniquely identify the object, such as
are retained. After 60 days (the default value), the object is completely removed from the directory. By not deleting the object immediately, Active Directory
How do you know whether the computer your application is running on has the correct components? The ADSI resource kit, part of the ADSI 2.5 SDK included on the companion CD, comes with an unsupported but useful component, contained in the file ADsVersion.dll, that you can use to determine the version of ADSI. This component exposes the ADsVersion object and associated IADsVersion interface. This interface includes properties that contain ADSI version information. These properties are listed in Table 11-1.
|IADsVersion Property||Data Type||Description|
Complete ADSI version number in text form
ADSI major version number
ADSI minor version number
Current locale identifier (two-character string)
Table 11-1 The properties of the IADsVersion interface, used to obtain version information about ADSI.
The IADsVersion interface also contains a Connect method for gathering the information remotely. Connect specifies which computer to retrieve ADSI version information from. No error is generated when a remote computer cannot be contacted.
Listing 11-3 shows code from the VBScript sample included on the companion CD that uses the ADsVersion object and displays the information available. In order for this script to run properly, the file ADsVersion.dll must be registered using Regsvr32.exe.
` Display ADSI version information
` Requires AdsVersion.dll to be registered
` Create ADsVersion object and catch any errors
On Error Resume Next
Set objADsVersion = CreateObject("ADsVersion")
` Check for error
If Err.Number <> 0 Then
` CreateObject failed
WScript.Echo "Error getting ADSI version information." & _
vbNewLine & "Ensure AdsVersion.dll is registered."
` Prompt for computer to query
strComputer = InputBox( _
"Computer Name to get ADSI version:" & vbCrLf & _
"(enter * for local machine):", "ADSI Version", "*")
If strComputer <> "" Then
If strComputer = "*" Then
strComputer = ""
` Query the computer
` Note: If the remote computer cannot be contacted, no error
` is generated and version data will be incorrect
` Build string with version data
strVersionInfo = "ADSI Version Information" & vbNewLine
strVersionInfo = strVersionInfo & "Computer: " & strComputer & _
strVersionInfo = strVersionInfo & "Version String: " & _
objADsVersion.GetVersion & vbNewLine strVersionInfo = strVersionInfo & "Major Version Number: " & _
objADsVersion.GetMajorVersion & vbNewLine
strVersionInfo = strVersionInfo & "Minor Version Number: " & _
objADsVersion.GetMinorVersion & vbNewLine
strVersionInfo = strVersionInfo & "Locale: " & _
` Display the string
Listing 11-3 ADsVersion.vbs uses the ADsVersion object to determine the ADSI version installed on the specified computer.
Figure 11-5 shows the information that is displayed when you run this script.
Figure 11-5 Output of the ADsVersion.vbs sample.
A modified version of this program, named ADsClientVersion.wsf, is also included on the companion CD. In addition to determining ADSI version information, this expanded version gathers Windows Script and operating system information.