Design Guide for Directory-Enabled Applications


JC Cannon
Microsoft Corporation

April 2001

Summary: This article discusses the benefits that Microsoft Active Directory can bring to applications, adding value to products and decreasing development time. (23 printed pages)



Single Sign-On
Integrated Authorization
Service Publication
Registry Administration
Extending the Schema
Extending ADSI
Project Collaboration and Document Publishing
Application Management and Monitoring


With the arrival of Microsoft® Active Directory™ Service, the management of computers, users, and networks has reached a whole new level of simplicity. The productivity of users and administrators has improved tremendously since its release.

Lower Development Cost and Increased User Value

Here are the benefits that Active Directory can provide to Independent Software Vendors (ISVs).

  • Centralized administration of users and computers
  • Consolidated member storage
  • Integrated authentication (Single Sign-On)
  • Integrated authorization (Roles)
  • Centralized administration of application settings
  • Easy discovery of services and devices
  • Fewer roundtrips to the desktop


The Directory-Enabled Application (DEA) initiative for Microsoft® Windows® 2000 focuses on helping customers and partners identify the benefits that Active Directory can bring to their applications. Trying to understand Active Directory in its entirety can be somewhat daunting, let alone trying to identify its integration points.

There are many ways in which Active Directory can improve the productivity of users, developers, administrators, and other groups. In this document, we will look at the integration points that will directly affect the development of your application. You will get an overview of several areas of Active Directory from the standpoint of how they can add value to your products and decrease your development time. There will also be pointers to other documents that will give you more detailed information on development strategies, including sample code.

Here are the areas on which this document will focus:

  • Single sign-on
  • Integrated authorization
  • Service publication
  • Registry administration
  • Active Directory schema extension
  • ADSI extension

The following areas are included, even though they are not directly related to DEA, because of their close association with application deployment.

  • Application monitoring and management with WMI
  • Project collaboration and document publishing with DFS


Active Directory Developer Resources

Directory-Enabled Networking

Microsoft IntelliMirror

See the "Active Directory Programmers' Guide" section of the Platform SDK in the MSDN Library.

Single Sign-On

Single Sign-On (SSO) is the ability of users to authenticate themselves to a network one time, and thereafter have access to all authorized network resources without additional authentication. The network resources in question can range from hardware devices, such as printers, to applications, files, and other types of data, all of which may be spread throughout an enterprise on servers of various types, possibly in different domains, and running different operating systems.

SSO also enables customers to create and maintain one master user list that is valid across the network, thus reducing the amount of administrative work associated with identity management and the potential for invalid access to resources. This concept of a master list can be extended to applications such that applications no longer have to keep a separate member database. Instead, Active Directory can be used to store the same member information.

SSO is provided natively in Windows 2000 through the built-in Kerberos, NTLM, and Secure Sockets Layer (SSL) protocols. These protocols also provide standards-based SSO within mixed networks.

Customer Benefits

Microsoft provides an integrated, comprehensive, easy-to-use SSO capability as part of Windows 2000 that allows a dramatic reduction in the "Total Cost of Ownership" (TCO) for a computing enterprise by improving user and administrator productivity while improving security. The greatest benefits are derived from implementing Windows 2000 homogeneous domains, but customers can derive significant benefits even when deploying Windows 2000 in heterogeneous networks. Furthermore, because SSO for Windows 2000 is compatible with so many other vendors' operating systems, it is the best choice to serve as an SSO hub in heterogeneous networks.

Customers who implement SSO through Windows 2000 can expect the following benefits:

  • Improved user productivity. Users are no longer required to remember multiple logons, nor remember multiple passwords, in order to access network resources. This is also a benefit to Help desk personnel, who will field fewer requests for forgotten passwords.
  • Simpler administration. SSO-related tasks are performed transparently as part of normal maintenance, using the same tools that are used for other administrative tasks.
  • Better administrative control. All SSO-specific information is stored in a single repository, the Active Directory. This means that there is a single, authoritative listing of each user's rights and privileges. This allows the administrator to change a user's privileges and know that the results will propagate throughout the network.
  • Better network security. All SSO methods available under Windows provide secure authentication and a basis for encrypting the user's session with the network resource. Eliminating multiple passwords also reduces the common source of security breaches—users writing down their passwords.
  • Consolidation of heterogeneous networks. By joining disparate networks, administrative efforts can be consolidated, ensuring that administrative best practices and corporate security policies are being consistently enforced.


All system services within Windows 2000 and all Microsoft BackOffice® family products use Kerberos as the default authentication method. Likewise, all third-party products that carry the BackOffice logo use Kerberos as the default authentication. Developers can easily implement Kerberos authentication within new or existing applications by means of the Security Support Providers Interface (SSPI), which is an application-programming interface that provides the security services of Windows 2000, including Kerberos authentication services.

Developers can use SSPI to leverage the security architecture and participate in SSL authentication. Using the CryptoAPI programming interface, they can access the Windows 2000 Public Key Infrastructure (PKI) and request certificate-handling functions.

Many vendor applications are constructed around their own storage mechanism for users. Application vendors can benefit from SSO with minimum changes in their code and thus avoid the need for users to login to the application. The GetUserNameEx() call can be made to retrieve the current user's GUID or other unique information, which then maps to the user's record in the application's data store or retrieves their Active Directory information. For example, the following line of code can be used to retrieve the user's GUID:

GetUserNameEx(NameUniqueId, szBuffer, &dwBufferLength);


Single Sign-On for Windows Networks

See the "Security Support Provider Interface (SSPI)" section of the Platform SDK in the MSDN Library.

See the "Mutual Authentication Using Kerberos" section of the Platform SDK in the MSDN Library.

Integrated Authorization

Single Sign-On permits authentication of users, but it doesn't necessarily give users access to resources. With Active Directory, customers can maintain a single master user list that is integrated with their application and valid throughout the enterprise. By integrating the user list for an application with Active Directory, Active Directory-based groups can be used, thereby avoiding the need to implement this in the application.


Roles represent part of the user's identity inside an application. Many applications support "roles" and there is wide market interest for universal adoption of this concept. A user may have to fulfill multiple roles in order to get his job done. Active Directory supports a similar concept in the form of groups. Group memberships, in addition to the individual user information, establish the complete user identity in a Windows network. Roles and groups can be established in an abstract form, representing a way of managing responsibilities based upon tasks or job definition rather than individuals. Roles and groups can also be used as a tool to express shared requirements for more than one individual.

Simple Authorization

Groups in Active Directory can be set up to take the place of roles in applications. Users' access rights can be controlled by their inclusion or exclusion from these groups. When users attempt to access an application's resources, their ability to do so will be governed by their membership in a group. For example, access to salary information can be controlled by a group named "Salary Admins."

Granular Authorization

The existence of a user in a group only provides a binary authorization mechanism. For most applications this is not sufficient to control certain access restrictions, such as viewing salaries, without the ability to modify them. For a more precise means of controlling access to an application resource, you would create a group that simulates the resource. For example, the group "Salaries" could be created. The access control list (ACL) on this group would indicate which individuals or groups could access salaries and the type of access that would be permitted. ACLs in Windows 2000 already provide for standard read, write, and delete access rights. For an access right that falls outside of the standard ones, an "Extended Right" could be created. For example, an extended right could be created to represent the ability to modify salaries.

Customer Benefits

Customers who implement integrated authorization through Windows 2000 can expect the following benefits:

  • Maintenance of one master user list that is always accurate, highly available, and replicated throughout the enterprise
  • Centralized management of security, which can be delegated to business owners or local administrators without change of application code
  • C2-certifiable security mechanisms
  • Application components that can share authorization principles across technologies or systems


When developing an integrated authorization strategy, research the materials on MSDN. Security is a serious issue. You should take time to ensure that proper guidelines are followed. The following code shows how a user can be routed on a non-secure site based on their group membership:

strUser = "LDAP://CN=JohnS, CN=Users, DC=microsoft, DC=com"
Set objLDAP = GetObject("LDAP:")
Set objDomain = objLDAP.OpenDSObject("LDAP://DC=microsoft, DC=com", _
                                     "CN=guest, CN=Users, DC= microsoft, DC=com", _
                                     "guest", ADS_SECURE_AUTHENTICATION)
Set objGroup = objDomain.GetObject("Group", "CN=MyGroup, CN=Users")
If objGroup.IsMember(strUser) Then
     Response.Redirect "http://PremierPage"
     Response.Redirect "http://DefaultPage"
End if


See the following sections of the Platform SDK in the MSDN Library:

"What Application and Service Developers Need to Know About Groups"
"Controlling Access to Active Directory Objects"
"Control Access Rights"

Service Publication

A service is a server process that performs a specific system function and often provides an Application Programming Interface (API) for other processes to call. A server process provides one or more threads that accept requests from client processes. It implements a set of services that it makes available to clients running on one or more computers in a distributed network. Although Windows 2000 services are enabled for remote procedure calls (RPC), meaning that their API routines can be called from remote computers, they do not require RPC.

Service Publication is the creation, storage, and maintenance of information about a service in the Active Directory. Network clients and network administrators can use this information to find, connect to, and manage a service. Active Directory also enables clients and administrators to view the distributed network as a collection of services rather than as a collection of individual computers.

Binding to a Service

For systems running Microsoft® Windows NT® version 4.0 and earlier, client processes and administrative programs require the computer name or the Internet Protocol (IP) address of the computer on which the service exists. The name or address is needed to find and connect to a service. In contrast, Active Directory enables client processes and administrative programs to locate and bind to a service by using the keywords attribute. This attribute enables the client to locate the proper service instance and retrieve other object properties, such as the service display name or GUID, to find services like Dynamic Host Configuration Protocol (DHCP).

To publish a service in Active Directory, a directory-enabled service must store, as a minimum requirement, its binding information. Service bindings are the information a client uses to connect, or bind, to an instance of a given service. The information needed to bind to a service includes the service name and its location. For example, a World Wide Web browser binds to a Web server by using a Uniform Resource Locator (URL).

Customer Benefits

Service publication offers the following benefits:

  • Central administration of application services
  • Easy modification of application services and server locations without affecting clients
  • Ability to search and bind to application services based upon information other than the name or physical connection


A connection point object contains information about one or more instances of a service available in the network. The connectionPoint object class is the abstract base class from which Active Directory objects representing "connectable resources" are derived. The following illustration shows some of the object classes derived from the connectionPoint object class.

The following table describes the immediate subclasses of the connectionPoint class.

Object Class Description
serviceConnectionPoint Service Connection Point (SCP) objects are used for publishing information that client applications can use to bind to a service.
RpcEntry This is an abstract class whose subclasses are used by the RPC Name Service (Ns), which is accessed through the RpcNs* functions in the Microsoft Win32® API.
ServiceInstance This object class is used by the Windows Sockets Registration and Resolution (RnR) name service, which is accessed through the Windows Sockets WSA* APIs.
PrintQueue This object class is used to publish network printers.
Volume This object class is used to publish file services.

The following table lists attributes used when creating a Service Connection Point class.

Attribute Description
keywords This is used to identify your service. It is included in the global catalog and indexed, which means that clients can easily and quickly find your service. You would store the company or product name and version information. The exact keywords you should include in your SCP depend on how clients will search for your service. The best keywords to use are GUID strings because GUIDs are guaranteed to be unique in a forest.
serviceDNSName This is typically the DNS name of the service's host computer. Your service installation program can call the GetComputerNameEx function to get the DNS name of the local computer.
serviceDNSNameType Indicates the type of DNS name specified by serviceDNSName. Usually "A" if serviceDNSName contains a host name or "SRV" if serviceDNSName contains a SRV record name.
serviceBindingInformation A multi-valued property that contains string values that store information needed to bind to a service. In the simplest form, the binding information consists of a port number on the service's host computer.
serviceClassName A single-valued property that identifies the class of service represented by the SCP. This is a descriptive string specific to the service that published the SCP, for example, SqlServer. For services that support mutual authentication, clients use this property (along with the DNS name of the service's host computer) to form a service principal name (SPN).


See the "Service Publication" section of the Platform SDK in the MSDN Library.

Registry Administration

Registry-based policy is the simplest and most common type of policy setting. This type of policy can be implemented using the Administrative Templates extension snap-in in the Group Policy snap-in to configure which policies are applied from the server side.

Registry-based policy settings are stored in any of the four Group Policy keys in the following list. These are considered the approved registry locations for policy settings.

For Computer policy settings:

  • HKLM\Software\Policies (the preferred location)
  • HKLM\Software\Microsoft\Windows\CurrentVersion\Policies

For User policy settings:

  • HKCU\Software\Policies (the preferred location)
  • HKCU\Software\Microsoft\Windows\CurrentVersion\Policies

These locations have security permissions that prevent a standard user from changing these keys to disable or change the behavior of applied policies. The keys are created when the Group Policy Object (GPO) is applied. If the GPO that applied the keys is ever removed, the registry keys associated with it will also be removed at that time.

Independent Software Vendors (ISVs) will often use the registry to store configuration information for their applications. It is often difficult to create and maintain registry settings, especially when it requires modifying these settings across multiple client and server machines each time a configuration value changes. The use of Administrative Template (ADM) files and the Group Policy Editor (GPE), shown in the following figure, simplifies this process.

The ADM file is a text file that consists of a hierarchy of categories and subcategories, which together define how the registry settings are displayed in the GPE. The ADM file also contains the following properties:

  • The registry location for each setting
  • The restrictions on any of the settings, such as maximum value or length
  • The default value to use if a selection is activated
  • An explanation string that describes the registry setting

An ADM file is extensible to allow independent software vendors and administrators to create custom group policies. In Windows NT 4.0, the System Policy Editor (Poledit.exe) also uses ADM files. These files have been updated with Explain and Version tags for Windows 2000. Windows NT 4.0 ADM files can also be read and used in Windows 2000.

Customer Benefits

Registry-based policy offers the following benefits:

  • The use of a graphical interface makes registry administration easier.
  • Vendors can create ADM files for their applications, making them easier to configure.
  • ADM files permit the inclusion of help text.
  • ADM files provide restrictions for registry settings.
  • Administrators can easily configure multiple computers from one location.
  • Registry settings can be applied to users based on their OU affiliation.


To define the user interface settings that administrators can configure, the group policy snap-in uses either ADM files or Microsoft Management Console (MMC) extension snap-ins to the group policy snap-in. You can create custom ADM files to extend the capabilities of the group policy editor snap-in.

The ADM file is a Unicode file and should be created and edited using a Unicode-capable editor such as Notepad.

Adding ADM files

ADM files allow administrators to implement group policy settings. You can also write additional ADM files.

To add your ADM files

  1. Under either the Computer Configuration or the User Configuration node in the Group Policy Editor, click Administrative Templates.
  2. From the Task menu, click Add/Remove Templates.

Applications that create ADM files must properly store their ADM file settings in the registry. If your application offers management capabilities by using ADM files, it must store these settings under the following registry keys:

  • HKCU\Software\Policies for user-specific policy settings
  • HKLM\Software\Policies for computer-specific policy settings

When you add an ADM file, that file is added to the distributed SYSVOL share under the Sysvol\<Domain name>\Policies\<GPO_GUID>\ADM folder where <GPO_GUID> represents the currently selected group policy object. The group policy snap-in namespace is defined by the hierarchy of category and subcategory names specified in the ADM file. Node names that are identical, but appear in different ADM files, are displayed only once in the namespace. This differs from the way System Policy Editor works; the System Policy Editor displays them more than once in such cases.

When you create custom entries in an ADM file for the Administrative Templates node, you should create the namespace using the \CompanyName\Product\Version (or \CompanyName\Product&Version) naming convention that is also used in the registry.

Sample ADM File

The following is a sample of an ADM file for maximum connections.

#if version > = 3 


   KEYNAME  !!MyKey 

   POLICY "Maximum Connections" 
   EXPLAIN "This policy indicates the maximum number of allowed permanent and temporary user connections." 

     PART "Number of Permanent Connections" Numeric 
       VALUENAME Permanent 
       DEFAULT 10 MAX 20 
     END PART 

     PART "Number of Temporary Connections" Numeric 
       VALUENAME Temporary 
       DEFAULT 128 MAX 1024 
     END PART 

     PART "Publish Connections" CHECKBOX 
       VALUENAME Publish 
     END PART  




   KEYNAME !!MyKey 

   POLICY "Home Directory" 
   EXPLAIN "The user's home directory for this application." 

     PART "Directory Name" EditText 
       VALUENAME Name 
       MaxLen 255 
     END PART 





Sample Display

This dialog box represents the "MACHINE" section of the above administrative template file.


Implementing Registry-Based Group Policy

Windows Group Policy

See the "Administrative Template File Format" section of the Platform SDK in the MSDN Library.

Extending the Schema

The schema can be extended by adding or modifying schema objects. This is very useful when the existing class and attribute definitions in the schema do not meet the needs of your application. The Active Directory schema can be extended dynamically. That is, an application can extend the schema with new attributes and classes and use the extensions immediately. Schema updates are accomplished by creating new or modifying existing schema objects that are stored in the directory, using the exact same method as used to manipulate any other object in the directory. This allows you to make object definitions that are particularly meaningful to your application available in the directory.

Note   As is true for every object in Active Directory, schema objects are protected by access control lists (ACLs), so only authorized users can alter the schema.

Adding or modifying class and attribute definitions in the schema involves adding or modifying the corresponding classSchema and attributeSchema objects, respectively. The operations involved in this process are similar to adding or modifying any object in Active Directory except that additional checks are performed to ensure that the changes do not create contradictions or inconsistency problems in the current schema.

When to Extend the Schema

Modifying the schema is a major change that can have an impact throughout the directory. It is recommended that you modify the schema only when it is absolutely necessary. Many schema modifications cannot be reversed, so you must ensure that changes are thoroughly researched and well planned before they are implemented. Inconsistencies and contradictions in the schema can cause significant problems that may impair or disable Active Directory. There is no room for trial and error when modifying the schema, as resulting problems may not be immediately evident.

Planning for schema modification involves examining the default schema that comes with Active Directory to verify that using the existing classes or attributes is insufficient for your needs. It is then necessary to understand the types of modifications that can be made and the types of modifications that cannot be changed once made. The following are the modifications that can be made to the schema:

  • Creating classes
  • Modifying existing classes
  • Creating attributes
  • Modifying existing attributes
  • Deactivating classes and attributes

There are three ways to effectively define a new class:

  • Extend an existing class by adding attributes or additional possible parents. This method essentially reuses an existing class by simply extending its definition.
  • Derive a new subclass from an existing class. The subclass has all the attributes of the original class and any additional attributes that you specify.
  • Create an entirely new class with any attributes necessary to the class.

Extending an existing class may be necessary when the following conditions apply:

  • The existing class requires additional attributes to meet your needs. For example, you may want to add a purchasingLimit attribute to the User class and add values for this attribute to the user object for people who are cost center managers and have purchasing authority.
  • It is not necessary to identify the extended class as a distinct class from the original class.
  • You want to use the existing Active Directory Users and Computers console in MMC to manage the extended attributes of the objects. This requires the addition of property pages to the set defined for the object you are extending.
Note   You should derive a subclass only when the new subclass must be identified as a distinct class from the original.


The recommended implementation practice is to strictly control the schema updates at most customer sites. If a service or application requires schema extensions, it must be possible to install the schema extensions separately by using one of the following methods:

  • Extend the schema using the Active Directory Schema MMC snap-in.
  • Extend the schema by using LDIF scripts in conjunction with the LDIFDE tool that comes with the Windows 2000 product. This allows customers to update the schema separately and in advance of the rest of the installation.
  • Extend the schema programmatically using Microsoft® Visual C++®, Microsoft Visual Basic®, or a scripting language.
Note   The schema installation program must allow the user to exit the program prior to it making any changes to the schema.

Sample LDIF file

The following LDIF script, when processed through the LDIFDE tool, will add an attribute called prefix-My-Attribute to the current schema. The X should be replaced with the domain name.

dn: CN=prefix-My-Attribute,CN=Schema,CN=Configuration,DC=X
changetype: Add
objectClass: attributeSchema
ldapDisplayName: prefix-MyAttribute
adminDisplayName: prefix-My-Attribute
adminDescription: prefix-My-Attribute
attributeId: 1.2.840.113556.
omSyntax: 64
isSingleValued: TRUE
systemOnly: FALSE
searchFlags: 0
schemaIdGuid:: hRToJ7Cxi0q+3c4ZqDfibg==
showInAdvancedViewOnly: TRUE


The Application Specification for Windows 2000

See the "Extending the Schema" section of the Platform SDK in the MSDN Library.

Extending ADSI

Although one of the important goals of Active Directory is to enable information sharing and consolidation, in some cases it is not advisable to simply store data in a directory and assume that all applications will use the data correctly. For example, a user's spending_limit attribute may not be a singular static value in Active Directory. The actual value, returned in response to a particular spending limit request, may be contingent on the type of spending request and whether a higher-level manager has delegated the proper authority for the change.

In other cases, the information an application requires may be the result of business rules performed on a combination of data kept in Active Directory and other data sources. For example, an application may create a workflow_queue object in Active Directory that contains information about a particular queue. However, it may be inappropriate to also store the contents of the queue in Active Directory, because entries will change frequently as documents are processed. Also, every application that wants to examine the queues would have to be programmed to understand the various data structures and access methods required by the application that owns the queue.

To address these needs, the Active Directory Services Interface (ADSI) provides a feature called the ADSI Extension model. This feature allows application developers to extend the list of standard ADSI Interfaces (for example, those designed to facilitate access to users, machines, devices, and other directory-based objects) with application-specific functionality. Developers of new applications can use Visual Basic, Visual C++, or scripting to call ADSI Extensions.

Customer Benefits

The ADSI extension model offers the following benefits:

  • Developers creating ADSI clients do not have to learn a new programming model. The extensions are part of ADSI. They would use the same paradigm for searching, data manipulation, and securing objects.
  • Administrators can manage related directory-enabled applications using extensions.
  • Extension consumers can view an ADSI object and extension as one integrated object.
  • Existing components may be integrated with ADSI, which allows extensions to leverage existing investments and create a powerful synergy between components.


Based on the spending_limit example above, the accounting application could provide an ADSI Extension that dynamically associates a method called SpendingLimit, which takes PurchaseType as a parameter, with standard Active Directory user objects. The following is a code sample that illustrates the use of such an extension:

Dim ou as IADsContainer
Set ou = GetObject("LDAP://OU=Sales, DC=Microsoft, DC=COM")
ou.Filter = Array("user")

For each user in ou
    Debug.Print user.Get("cn")
    Debug.Print user.SpendingLimit(HARDWARE_PURCHASE)

The implementation of this method can read required information from Active Directory, apply business rules, and return an appropriate dollar value.


ADSI Overview

See the "ADSI Extensions" section of the Platform SDK in the MSDN Library.

Project Collaboration and Document Publishing

Active Directory, along with the Distributed File System (DFS), provides a great infrastructure for team collaboration and document publishing. Active Directory can be used for storage and discovery of information such as projects and teams. DFS can be used to manage file shares and the distribution of files.

What is DFS

DFS provides the ability to logically group-share folders on different servers and to transparently link shared folders into a single hierarchical namespace.

As networks continue to grow in size and as organizations begin to consolidate the use of existing storage (both internally and externally) for purposes such as intranets, mapping a single drive letter to individual shares becomes inefficient. Despite their ability to directly reference UNC naming, the increasing number of places to which they must gain access to retrieve data can overwhelm users.

DFS solves these problems by linking file servers and shared folders to a simpler, more meaningful namespace. This new namespace permits shared folders to be related to each other within a single hierarchy. Because DFS maps the physical storage to a logical representation, the net benefit is that the physical location of data becomes transparent to users and applications.

Where Active Directory Comes In

Active Directory serves as a backend for the storage of information used by DFS and the File Replication Service (FRS). The DFS MMC snap-in is used to administer DFS shares and replication.

Active Directory can also be used in conjunction with DFS to define and implement concepts such as projects and teams. A project could have a DFS share or collection of files that are associated with the project. Information such as this, associated with a project, can be stored in Active Directory in an object that represents the project. A team can be defined in Active Directory using a security group or a distribution list. The ACLs on the file shares, to which DFS points, can be adjusted to restrict access to members of the team exclusively.

File Replication

DFS permits replicas to be created for the purpose of storing copies of files from one of the other DFS shares. Files located in any of the replicas will be copied to the other replicas regardless of where the file was created. FRS performs this replication. Some of the features of FRS are:

  • Multi-master replication of files and folders for allowing updates to occur independently on any server in the domain
  • Site-aware clients (Windows 2000, Windows NT version 4.0, Windows 95, and Windows 98 with the Active Directory add-on) for locating nearby servers hosting DFS content
  • Configurable schedules for replicating DFS content between sites
  • Automatic replication of folder and file attributes including ACLs

The following diagram shows a network topology that can accommodate two possible scenarios:

Scenario 1. Members of the team modify their documents on their client machines. The Staging Server has a DFS root defined that points to a shared folder on each of the three client machines. There is also a replica defined on the Production Server. Each time the documents are updated they get automatically copied to the Production Server.

Scenario 2. Members of the team modify documents on the Staging Server. The Staging Server has a defined DFS root that points to the local shared folder where the documents are located. There is also a replica defined on the Production Server. Each time the documents are updated they get automatically copied to the Production Server.

Customer Benefits

DFS offers the following benefits:

  • Provides a unified view of shared folders that you can customize for individual users and groups. A single drive mapping can reflect hundreds of shared folders.
  • Provides increased administrative flexibility. You can move shared folders between servers or disk drives without affecting the users' access to the data.
  • Using replicas keeps important data accessible at all times, even when a server or disk drive fails or when a shared folder or file becomes corrupted. It randomly distributes file access across multiple disk drives or servers to balance loads and improve response time during peak usage periods.
  • Uses standard Windows 2000 file and directory permissions for easy administration and secure access.
  • Supports shared folders on heterogeneous network operating systems such as Microsoft MS-DOS, Windows version 3.x, Windows 95, Windows 98, and Windows NT 4.0 and earlier.


A DFS Root, the associated shares, and replicas can be easily created with the DFS MMC snap-in shown in the following figure.

To modify the replication schedule for replicas, find the replica entry in the Active Directory Users and Computers MMC under the System->File Replication Service container. Select Properties, then Change Schedule. See the following figure.

To organize a set of individuals into a project team, create a security group or distribution list in Active Directory Users and Computers and add the desired members. For multiple project teams, nested groups can be used to represent this structure.

The Storage class is used to store generic file information. It can also be used to define the structure for project files. For example, here is how it would store the following projects:

Name: Lunar Project

Project Path: \\MyDomain\DFSRoot\LunarFiles

Name: Mars Project

Project Files: \\MyDomain\DFSRoot\Mars\MarsFile1



Storage Object1:

Common Name: Lunar Project

Keywords: Space Projects

Moniker Display Name: \\MyDomain\DFSRoot\LunarFiles

Managed By: CN=ProjectGroup,CN=Users,DC=MyDomain,DC=MyCompany,DC=com

Storage Object2:

Common Name: Mars Project

Keywords: Space Projects

Moniker Display Name: \\MyDomain\DFSRoot\Mars\MarsFile1



Managed By: CN=ProjectGroup,CN=Users,DC=MyDomain,DC=MyCompany,DC=com

Following is an example of how it would look in Active Directory Users and Computers.


Step-by-Step Guide to Distributed File System

Introduction to FRS

Application Management and Monitoring

Microsoft® Windows Management Instrumentation (WMI) is a key component of the Microsoft Windows management services. WMI provides a consistent and richly descriptive model of the configuration, status, and operational aspects of applications and systems. Based on the Desktop Management Task Force (DMTF) Common Information Model (CIM), WMI supports uniform system, device, and applications management in Windows operating systems.

WMI provides a unifying access mechanism to both standard and proprietary instrumentation methods, allowing your applications to be managed as both discrete elements and as integrated and inter-related parts of a larger enterprise. By exposing a common access mechanism to all management instrumentation, WMI simplifies the task of developing well-integrated management applications.

Customer Benefits

Customers gain the following benefits when your products use WMI:

  • Management and managed products built on broadly adopted industry management standards.
  • A logically organized, consistent model of Windows and Windows application operation, configuration, and status.
  • Solutions that manage local and remote systems and applications transparently through a common, operating system-based management infrastructure.


This section presents recommendations for creating products that are compliant with WMI. For the purposes of this discussion, the use of the terms application or product means user mode applications with a desktop graphical user interface and applications written as one or more services.

Access management data through WMI

WMI provides access to a wide variety of Windows system management information through the CIMV2 namespace, a Win32 extension of the CIM schema. Using WMI, an application has access to various management objects, including Win32, Performance Monitor, Registry, Windows Installer service, and Event Log data.

If your product uses management functions and data provided by the system and/or other products, and that data is available in the CIMV2 namespace, it is recommended that your product use WMI to access that management information rather than native APIs.

Provide management data to WMI

If your product has management functions and data that permit control or monitoring of your product by other management applications, it should be exposed through WMI according to the following recommendations (see the WMI SDK for development details and schema extension rules):

  • Use or extend the existing CIM classes in the CIMV2 namespace or create another namespace with new classes that represent the management functions and data.
  • Rules for extending CIMV2 are documented in the WMI SDK (formerly called the WBEM SDK).
  • Where new classes or instances should not be added to CIMV2 (as defined by the SDK documentation), another namespace must be created.
  • Provide instances for the newly defined classes. This is accomplished by using static instances defined in a Managed Object Format (MOF) file or dynamic instances generated at runtime by a WMI Provider. If instances are provided through an MOF file, the vendor is responsible for ensuring the MOF file is compiled by the WMI MOF compiler during product setup.
  • An event Provider should be implemented for the events that are generated by the application. The event Provider sends notifications of events to WMI, which then forwards the events to products registered to receive those events. The implementation guidelines for event Providers are included in the WMI SDK documentation.


Exploring Management Services

Windows Management Instrumentation: A Simple, Powerful Tool for Scripting Windows Management

©2001 Microsoft Corporation. All rights reserved.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Due to ongoing development efforts and because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, the BackOffice logo, BackOffice, MSN, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

Other product or company names mentioned herein may be the trademarks of their respective owners.

Microsoft Corporation · One Microsoft Way · Redmond, WA 98052-6399 · USA