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)
Contents
Introduction
Overview
Single Sign-On
Integrated Authorization
Service Publication
Registry Administration
Extending the Schema
Extending ADSI
Project Collaboration and Document Publishing
Application Management and Monitoring
Introduction
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
Overview
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
References
Active Directory Developer Resources
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.
Implementation
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);
References
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
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
Implementation
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"
Else
Response.Redirect "http://DefaultPage"
End if
References
See the following sections of the Platform SDK in the MSDN Library:
"What Application and Service Developers Need to Know About Groups"
"AccessCheckByType"
"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
Implementation
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). |
References
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.
Implementation
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
- Under either the Computer Configuration or the User Configuration node in the Group Policy Editor, click Administrative Templates.
- 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 CLASS MACHINE CATEGORY !!MyProd 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 VALUEON NUMERIC 1 VALUEOFF NUMERIC 0 END PART END POLICY END CATEGORY CLASS USER CATEGORY !!MyProd KEYNAME !!MyKey POLICY "Home Directory" EXPLAIN "The user's home directory for this application." PART "Directory Name" EditText VALUENAME Name MaxLen 255 END PART END POLICY END CATEGORY #endif [strings] MyKey="software\policies\MyCompany\MyProduct\7.5 MyProd="MyProduct"
Sample Display
This dialog box represents the "MACHINE" section of the above administrative template file.

References
Implementing Registry-Based 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.
Implementation
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.1.6.1.1.1682 attributeSyntax: 2.5.5.12 omSyntax: 64 isSingleValued: TRUE systemOnly: FALSE searchFlags: 0 schemaIdGuid:: hRToJ7Cxi0q+3c4ZqDfibg== showInAdvancedViewOnly: TRUE
References
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.
Implementation
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)
Next
The implementation of this method can read required information from Active Directory, apply business rules, and return an appropriate dollar value.
Recommendations
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.
Implementation
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
\\MyDomain\DFSRoot\Mars\MarsFile2
\\MyDomain\DFSRoot\Mars\MarsFile3
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
\\MyDomain\DFSRoot\Mars\MarsFile2
\\MyDomain\DFSRoot\Mars\MarsFile3
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.

References
Step-by-Step Guide to Distributed File System
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.
Implementation
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.
References
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