Windows Platform Considerations

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 tasks that Microsoft faces. Trust me, I dealt with this issue when I was working on Active Accessibility. Because of the naming of ADSI, many developers believe that installing the ADSI package is all that is required to work with Active Directory. However, ADSI provides only a portion of what's needed.

Active Directory has its own set of components, which includes the various administrative programming interfaces, user interface resources such as dialog boxes and menus, and functions that support low-level access to Active Directory (DsXXX functions) and extend the Windows shell namespace to allow browsing the directory. These components and ADSI are part of Windows 2000 and the forthcoming release of Windows, code-named "Whistler."

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.


Consumer Versions of Windows

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 remain unsupported for this and future releases of consumer-oriented versions of Windows.


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

Using the WinNT Provider with Active Directory

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

ADSI Versions

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 (DsXXX) 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 name, you can improve performance by using the ADS_SERVER_BIND flag with the ADsOpenObject function or the OpenDSObject method of the IADsOpenDSObject interface. This option is discussed in Chapter 4.

A tombstone 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 isDeleted attribute to True. Although most of the object's attributes are deleted to save space, others that uniquely identify the object, such as objectGUID and RDN, are retained. After 60 days (the default value), the object is completely removed from the directory. By not deleting the object immediately, Active Directory prevents fragmentation of the NTDS.dit file, which improves performance for very large directories.

Determining the ADSI Version

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

GetVersion

String

Complete ADSI version number in text form

GetMajorVersion

Long

ADSI major version number

GetMinorVersion

Long

ADSI minor version number

GetLocale

String

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.

 ` ADsVersion.vbs
` 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."
Else
    ` 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 = ""
        End If
        ` Query the computer
        ` Note: If the remote computer cannot be contacted, no error
        ` is generated and version data will be incorrect
        objADsVersion.Connect strComputer
        ` Build string with version data
        strVersionInfo = "ADSI Version Information" & vbNewLine
        strVersionInfo = strVersionInfo & "Computer: " & strComputer & _
            vbNewLine
        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: " & _
            objADsVersion.GetLocale
        ` Display the string
        WScript.Echo strVersionInfo
    End If
End If

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.



MicrosoftR WindowsR 2000 Active DirectoryT Programming
MicrosoftR WindowsR 2000 Active DirectoryT Programming
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 108

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net