Some of the main topics in this chapter are
Windows NT Server provides an enterprise model capable of supporting from one server and one user up to 40,000 users in a single domain. Through the use of multiple domains you can create an enterprise with more than 100,000 users, and you can partition your users into different functional units to suit your business. Domains run on Windows NT Server 4.0 have the capacity for up to 75,000 users, with some enterprises that run Exchange messaging services in a multidomain enterprise existing at the 150,000 node level. This chapter examines some companies that have deployed Windows NT in large organizations, what they hoped to achieve, and what architecture they adopted to fit their business model.
A large-scale organization is, for the purposes of this chapter, one that requires multiple security databases and therefore multiple master domains to accommodate its user account load. From a practical standpoint, the range is typically from 40,000 users on up. Many organizations begin to adopt the practices of a large-scale organization at the 12,000-15,000 user level.
Large-scale organizations have a strong and adequate IT support staff. They are neither afraid of complexity nor lack the resources to embrace complex network solutions to achieve their goals. Many large-scale organizations require complex solutions because they contain legacy systems and data that cannot be replaced and must be embraced as part of any Windows NT solution.
Consider a conglomerate that contains several business lines under a corporate umbrella. Each of the businesses involved establishes a single master domain that captures their user and machine accounts. The corporation as a whole establishes resource domains to ensure that resources are shared throughout the corporation and don't require duplication. This is referred to as the multiple lines of independent business model, and it is often implemented not only for units engaged in different activities but also for units widely separated on a geographical basis.
In a multiple independent lines of business scenario, often each unit has profit and loss responsibility to the central organization. The central organization might choose to keep each master domain separate from each other, and each of those master domains would be managed by its own network administrators. That is, each line is truly independent--independent of the holding company.
Figure 63.1 shows an example of the multiple lines of independent business model. Each business unit is its own separate master domain, whereas each of the operations units such as Public Relations, Printing, and Advertising are shared by the entire group of business as resource domains. Certain umbrella organizations work under this business model, giving each business unit autonomy. However, it is our experience that most large organizations require some kind of centralized control.
The multiple lines of independent business model is a useful model for a large organization that is divided into separate operating units.
We think that the most common implementation of the multiple master domain model in large corporations is the so-called secure domains model. In this model, every master domain is linked to every resource domain in a one-way trust relationship. As before, the master domain is the trusted domain, and the resource domains are the trusting domains. One (or more) of the resource domains is also connected to the other domains by a set of one-way trust relationships. That domain is therefore essentially isolated from the other resource domains and is referred to as the secure domain. The secure domain is the trusted domain in the relationship with other resource domains, which are the trusting domains. Secure domains can access all other master domain resources but cannot be accessed.
Figure 63.2 illustrates the secure domain model. In this model, the Human Resources and Finance domains are secure and isolated master domains. The MIS domain serves the role of trusted domain to these other master domains. However, because the MIS domain is the trusted domain to all the other resource domains, all validation requests flow through that domain. Remember, the difference between a resource domain and a master domain is that master domains contain SAMs with user, account, and group information in them. Resource domains in this model can be functioning business units.
The secure domain business model enables an organization to isolate sensitive business functions from other business units.
Companies establish the secure domain model to isolate business units that require the most confidentiality. Often finance and human resources departments are secure domains in large BackOffice enterprise solutions.
Table 63.1 shows you the characteristics of the different domain types.
| Domain Attributes | Single Domain | Single Master Domain | Multiple Master Domain | Independent Single Domains with Trust Relationships |
| Less than 40,000 users/domain | X | X | ||
| More than 40,000 users/domain | X | |||
| Centralized account management | X | X | X* | |
| Centralized resource management | X | |||
| Decentralized account management | X* | X | ||
| Decentralized resource management | X | X | X | |
| Central MIS | X | X | X | |
| No central MIS | X |
At the heart of centralized domain planning is an understanding of the capabilities and loading limits of NT Server. In a BackOffice environment, a domain is defined as a collection of computers that share the same security database, and by extension the same Windows NT Directory Services. The Security Account Management (SAM) database resides on the primary domain controller (PDC), whose role is to validate requests for network services by users.
Network services include logon validation, file and directory access, network services such as databases in SQL Server, e-mail in Microsoft Exchange, intranet or Internet services through Internet Information Server (IIS), access to printers, and other network resources. Anywhere you see the familiar logon dialog box where the challenge/response security mechanism is displayed, you are seeing the validation services in action. After you are logged on to a domain from whatever workstation you log on at, the SAM database validates requests for services without displaying any dialog boxes, or by posting a momentary message box. Many of these events are logged to one of the three Windows NT event log files as they occur. A whole lot of validatin' goin' on.
Validation can keep your PDC happily chugging away like the Little Engine that Could, and validation services are a primary factor in network performance. Try logging on to a large domain when everyone arrives for work in the morning (and might be changing their passwords), and you see the effect. To share the load and provide a measure of fault tolerance, a domain can have up to ten backup domain controllers (BDCs), each of which has a replicated copy of the SAM. The PDC offloads validation requests to the BDCs in a round-robin fashion. Each domain controller can accommodate about 2,000 users, enabling a potential domain size of about 22,000 users.
Fault tolerance is provided through promotion of the BDC to a PDC when the PDC fails. In fact, this is the only method you can use to retain your network settings and security database when your PDC goes rubber feet up because the database stores unique internal system identification numbers (SIDs) for specific computers (machine accounts) and for user accounts. The SAM doesn't need to be fully replicated on the BDC for it to be promoted to a PDC. Reestablishing a security database for any more than a handful of users is a daunting task.
Starting with NT Server 3.51, Microsoft introduced a new algorithm that validates user requests about 100 times faster than the one found in NT Server 3.1. Also, in this operating system an entirely new replication system was introduced that updates only modified account records and processes replication as a background activity. To alter the rate and frequency of updates between the PDC and BDC, you can change the ReplicationGovernor setting in the Registry, which has the effect of altering the size of the buffer used to communicate SAM data over a WAN link. The new system makes replication across WANs much more tolerable and improves the domain loading significantly from early versions of BackOffice.
Every NT Server contains its own SAM, even non-domain controllers (NDCs). An NDC validates requests for the services it provides (that is, whatever component of BackOffice it is running) but plays no role in domain validation requests. Access to an NDC is controlled by the domain security database, and further access to a resource controlled by an NDC, such as file and print services, is controlled by the NDC. If you use the same password for each level of logon, you won't see the second challenge/response dialog box for the NDC service in this second layer of security.
With an NDC, you can remotely administer domain servers, provide for improved security by isolating service authorization from domain authorization, and provide for better performance and load balancing by locating the NDC appropriately.
There is a current practical limit to the size of the security database of around 40M. This size affects the number of users, groups, and machine accounts that you can define and the maximum size of users in a domain that was stated at the very start of this chapter.
The speed of your domain server has a modest effect on this limit, but the number of BDCs has no effect on the size (although it helps out with performance).
It is recommended that you have enough RAM in your PDC to load the entire SAM database into memory. Table 63.2 presents some practical hardware requirements for configuring your domain controllers based on the number of user accounts.
| SAM Size | Number of * User Accounts | Server Required | Required RAM# |
| 5M | <= 3,000 | 32M | |
| 10M | 7,500 | 486DX/66 | 32M |
| 15M | 10,000 | Pentium, Alpha AXP | 48M |
| 20M | 15,000 | Pentium, Alpha AXP | 64M |
| 30M | 20,000-30,000 | Pentium, Alpha AXP | 128M |
| 40M | 30,000-40,000 | Pentium, MIPS, Alpha AXP | 166M |
The three accounts you can define in a domain and their sizes are:
You can partition the SAM in any combination of these three accounts that you want according to the following simple formula:
where X = # of user accounts, Y = # of group accounts, and Z = # of machine accounts.
A typical partition of a fully loaded domain would be:
The calculation of this partition would be:
These figures are based on the performance of NT Server 3.51 and will change in future versions of BackOffice. Although there is a 40,000-user limit in a domain, your network infrastructure can affect your ability to reach this limit. In designing a domain structure, it is logical to consider each LAN as a candidate for a separate domain first to avoid slower WAN connections.
At Microsoft, there is a rule that the company uses its own products whenever possible. Many of the principles described in this section arise out of the published experiences of the Information Technology Group (ITG) and their experiments at configuring Microsoft as an NT-enterprise.
Microsoft is a large, but by no means the largest, corporate NT-Enterprise. As of late 1996, there were 16,000 user accounts and 35,000 network nodes evenly divided between local Redmond, Washington sites and remote offices in 150 sites in 52 countries worldwide. The corporate model provides for any user to log on to the system from any location, have her account verified, and get access to e-mail and information resources. ITG provides centralized administrative support for the corporate networked assets, with second-tier administrative duties shared between ITG and the responsible parties for that domain (MIS, developers, user groups, and so on).
The domain model chosen was a two-tier multiple master domain with a small number of defined first-tier domains. Microsoft felt that it was easier to grow the enterprise by subdividing domains than by consolidating them. Because remote sites are often networked with slow 64K WAN connections, PDCs and BDCs were placed remotely to provide internetwork recovery without requiring full synchronization of the SAM to a domain's PDC.
In the Microsoft model, every user and global group account exists in a master domain, and all the domains in the company trust every master domain. ITG administers first-tier domains and has administrative privileges in all domains. This allows the MIS group at Microsoft to perform network backup and software upgrades remotely. A person is assigned an account in one of the master domains based on the Human Resources database and reassigned when he moves about in the company.
The multiple master domain model requires some administrative compromises. Administration of global groups is troublesome because the groups are large and require constant comparison to the Human Resources database. The Microsoft ITG maintains the global groups based on department accounts and then compares those records to the ones maintained at HR. Some global groups are not maintained at HR and are reviewed by ITG individually as required.
A user is added to a particular master account domain when she moves to the geographical area that that domain services. For example, a user moving from Redmond to a foreign country would have her account removed from the Redmond domain and re-created in the other country's domain. The new account would require that any permissions or granted access be newly established or re-created.
TCP/IP is used for WAN connections to authenticate services. Any server in the master user domain can process a logon request. Microsoft has DHCP/WINS (Dynamic Host Configuration Protocol/Windows Internet Naming Service) servers throughout its enterprise to route internetwork traffic appropriately. At the second-tier domain level, every NT Server is running a Remote Access Service (RAS) and permits dial-up access from any location.
Any product development group can establish a second-tier domain with trust relationships to the master domains. Therefore, domains such as Apps-Word, Apps-Excel, Sys-WFW, and Sys-NT exist, with a naming convention based on the business group and the product line. When a development business unit is formed, that group creates a second-tier domain and incorporates the activities of the component product groups.
In the past, computers running the Windows for Workgroups operating system use to appear in second-tier domains so that they could fully access the Microsoft domain structure. A WfW user account was found in the master domain, and the resources that the account used is in the second-tier domain. This let a WfW user be managed by the domain security structure in place on the master domain. Microsoft has phased out their use of WfW computers in their enterprise.
Domains are also established to support remote sites. Therefore, each location can create a resource domain with trust relationships to the master user domains. Domains exist for USA-Atlanta, USA-Chicago, FRA-Paris, GER-Munich, and so on. The site city and country provide the domain name for geographical locations.
Remote sites can be either first-tier or second-tier domains depending on the level of network activity, network topology, and geographical limitations. A PDC for master user domains of North America and South America are located in Redmond. BDCs for sites in these regions are provided at local data centers. Remote sites are supported by RAS located in the second-tier domains. The trust relationship that is in place in the multiple master domain model ensures that a user can dial into a RAS server and access any trusting domain anywhere at Microsoft without any further validation or authorization required.
Other worldwide domain PDCs are placed in their geographic regions. Europe, for example, has a master user domain located in England with BDCs for the master user domain in each European country where Microsoft has an office. Figure 63.3 shows you the Microsoft worldwide domain model.
The Microsoft worldwide domain model enables a diverse worldwide organizational structure.
The global master user domain is accessed through a set of BDCs placed at network hubs throughout the world.
The master user account domains contain user accounts for any domain, even remote ones. BDCs at remote domains validate authentication requests to lower WAN activity. Replication of the security database is a WAN function.
To isolate the human resources database and secure their information, the domain for that department is on a secure network with no network connections to any other part of Microsoft. The Microsoft Human Resource Group has its own master domain.
Microsoft also has a separate master domain established for vendor access. The vendor domain has one-way trust relationships to other Microsoft domains. This restricts vendor access to corporate resources to the vendor domain but allows corporate access of the vendor domain through the Microsoft organization.
The "Windows NT Server Networking Guide" from the NT Server Resource Kit (Microsoft Press) creates a fictitious company called Terra Flora to illustrate how an organization would grow a Microsoft enterprise in a heterogeneous computing environment. This example is detailed in almost 200 pages of that book and is abstracted here. You might want to review the original source material to get full installation descriptions and more complete discussions. You should also note that the Terra Flora model as originally described contains some inaccuracies that were addressed in the "Windows NT Server Resource Kit Version 4.0 Supplemental Guide."
Terra Flora is an international company that sells flowers retail in the U.S. and Europe. It performs the following business functions:
Terra Flora has three divisions: Retail Services, Supply and Manufacturing, and Nursery Products. The corporate and division headquarters are in Sacramento, California, with each division having sites in America and Europe. Each of these divisions ran its own separate computer network. The goal of the reorganization project described in the Resource Kit was to centralize all the disparate computer resources into a single client/server solution while maintaining legacy data on the different systems that already exist.
For example, the Retail Services division operates a Sun Solaris SPARC version 2.5 server running an ORACLE database with its various business services: inventory, accounting, order processing, distribution, and delivery scheduling. A Banyan VINES 6.22 server provides file and print services, and mail messaging services to Beyond Mail. Other divisions contained other legacy solutions such as IBM AS/400 computers, DECaxp 150 running DEC UNIX and PATHWORKS, and so on.
In the reorganization of Terra Flora, services were divided into an integrated network model where the computers provide services to the company overall rather than to any specific division. Four categories or layers were defined:
By integrating different corporate entities into a hierarchy of this type, Terra Flora was able to centralize the information staff in one location, centralize the network support functions, and provide for centralized budgeting of services and capital items.
Terra Flora adopted the TCP/IP as its primary network protocol and installed a proxy agent on the network for protected Internet access. The proxy agent is essentially a firewall because there is no direct connection to the Internet through any other means at Terra Flora.
Terra Flora retained the System Networking Architecture (SNA) protocol to provide the connection to its legacy systems throughout the organization. Both DHCP and WINS services were installed on the PDC at Terra Flora at the enterprise level. Computers running Windows NT Server DHCP service are configured to provide for BOOTP DHCP relay service so that clients on one subnet can access a DHCP server located on another subnet. WINS servers are replicated across the enterprise as push and pull partners at the enterprise level because the DHCP database is not automatically replicated.
Most small- and medium-scale enterprises do not install Domain Name Service (DNS) servers as a network service. They instead rely on their Internet Service Provider to provide DNS services. In a large-scale enterprise like Terra Flora where there is a heterogeneous mixture of equipment and operating systems, a DNS server was installed to improve the performance of name resolution in situations where name resolution using WINS wasn't practical. These situations arise when fully qualified domain name (FQDN) must be resolved. Several different scenarios outlining the integration of WINS and DNS services for different divisions of Terra Flora are outlined in the Windows NT Server Resource Kit.
At Terra Flora, a centralized network logon service was established at the enterprise level. Windows NT Server provides this service because it is capable of logging on to all the different heterogeneous networks that Terra Flora owns. Three domains were established at Terra Flora: one for California, another for the Northeast (U.S.), and a third for Europe.
To support UNIX clients, Intergraph DiskShare was installed and configured on Windows NT Server. This product allows the Solaris UNIX server to access Windows NT Server as a client. DiskShare provides a graphical interface that an administrator can use to edit the password file and a method for mapping Windows NT user accounts and passwords so that a UNIX user can have the same permissions that Windows NT users have after the mapping is complete. With this system, a user logging on to Windows NT will be simultaneously authenticated for access to the UNIX network.
To support NetWare servers used at Terra Flora mainly for file and print services, the client service for NetWare (CSNW) was installed on Windows NT Workstation. This NT network service provides for directory access to the NetWare Bindery. The Bindery plays the same roles as the Windows NT directory service. NetWare clients can access an NT network by using the File and Print Services for NetWare, with NetWare authentication being passed through to Windows NT.
The Gateway Service for NetWare (GSNW) was also installed on Windows NT Server. This service lets an NT Server access a NetWare server as if it were another NetWare client, provided that a high performance connection is not required between Windows NT Server and the NetWare server. Requests for access to a NetWare server do not require a client redirector to be available on the IPX/SPX protocol stack. GSNW also requires that the NWLink protocol and the NWLink BIOS be installed on NT Server.
After CSNW and GSNW are installed on NT client and servers, access to a Novell NetWare network and to NetWare servers is transparent to the user. A single logon is all that is required. Shared resources like NetWare volumes can show up as mapped volumes on NT Server in the NT Explorer.
The final network connection at Terra Flora was to a Banyan VINES server. The user accounts and passwords established at the Banyan server were matched to the ones that exist or were created in Windows NT. StreetTalk Access for Windows NT allows Banyan clients to access file and print services on NT Server.
Finally, because this is a widely heterogeneous case study, numerous clients are described, as are their connection, authentication, and logon to the Terra Flora network. The network supports:
Remote access of clients is supported by the Point-to-Point Tunneling Protocol (PPTP). Computers in Spain, for example, dial up a Remote Access Service (RAS) connection to the Internet Information Server (IIS) running on an enterprise server in California. Using this method, a secure transmission at local access charges can be used to provide for international corporate communication. Connection can be through an ISP, or directly to a RAS server within the corporation.
Another goal of this study was to provide for centralized management of the network on a single console. The case study details the different administrative tools used to provide these services. They include: FTP, Telnet, and X/Windows for UNIX; Syscon, Rconsole, and Pconsole for NetWare; Manage.com, Mservice.com, and Muser.com for Banyan VINES; and the User Manager, Server Manager, and Internet Homepage for Windows NT Server.
Centralized network management is a Microsoft design goal for Windows NT 5. An interface for building administration utilities called the Microsoft Management Console (MMC), which is part of the "Slate" project is designed to allow an administator to centrally manage an enterprise (including routing functions) from a single workstation. This program is a container utility that takes different management tools called "Snap-Ins." The concept is similar to the architecture being employed by the Windows Explorer but uses the Multiple Document Interface (MDI) and ActiveX interfaces for its Snap-Ins. You can think of this architecture as being similar to Control Panel applets. When finally released, MMC can be used with both NT 4 and NT 5 Servers.
Clearly, as the hypothetical case study of the Terra Flora Company in the previous section indicates, a full treatment of most enterprise solutions can be a lengthy story indeed. Microsoft has collected several hundred case studies and listed them on its site in a database.
The section of the Microsoft Web site that contains these case studies is called Solutions in Actions. To go to this section, enter the following URL into your browser:
A site search query using the keyword "case studies" will also lead you to this area of Microsoft's Web site. Figure 63.4 shows you the search engine for the Solutions in Action section. You will note that you can extract case studies based on Microsoft products, the vertical market, and industry. There is no way to differentiate returned abstracts based on enterprise size.
Figure 63.5 shows the returned abstracts for a search for all industries (vertical markets) using NT Server as the product searched on. These items represent records in the Knowledge
Base, and the results are dynamically returned based on your selection criteria. This search returns 285 entries, mostly from large companies. The descriptions of the solutions deployed range from special accounting packages, order inventory systems, full enterprise solutions, BackOffice deployments, as well as a whole host of heterogeneous solutions where NT Server and Workstation have made their way into organizations.
The Solutions in Action section on the Microsoft Web site and the search engine for case studies.
Obviously, the more specific you can be concerning the industry you want to learn about the better. The abstracts presented aren't very detailed or technical, but they do link in many cases to a more detailed presentation. This presentation is usually in the form of a downloadable case file (usually a Word document in compressed format). The organization often tells you its size, focus, distribution, design goals, solution needs, and what finally got implemented. You'll find everything in these case studies from huge messaging applications to database warehousing to mainframe data connectivity.
You'll get the best descriptions and fullest explanation from the companies that have an enterprise product that they are interested in selling you. Not too surprisingly, the most interesting solutions from large enterprises aren't fully documented. You won't find a full explanation of the organization's architecture in the accompanying documentation.
The returned search of case study abstracts that are returned by Solutions in Action.
Many aspects of the current domain model make Windows NT Server 3.5x/4 based enterprises attractive to system administrators: a single logon for network services, remote administration, the challenge/response security mechanism, data replication, and distributed network services, among others. In several important aspects, the BackOffice domain model is both difficult to work with and severely limited in its scope. The domain system is difficult to scale, doesn't provide for flexible resource management like failover well, can't address external resources easily, and isn't particularly flexible to configure for advanced distributed security and replication.
Microsoft has a vision of the enterprise where services are both distributed and infinitely scalable. The plan is to create a network operating system (NOS) that uses the same organizational principles for a single server/client pair as it does for one containing thousands or even millions of connected users. Some network systems such as communications services manage large numbers of transient sessions, and Microsoft wants those enterprises running BackOffice as well. So the new directory stores and manages both persistent and transient connections.
The Directory Service can be seen to play a central role in the organization and management of future BackOffice enterprises. Every network application in the suite, and some of the central NOS services rely on the Directory Service for vital information without which transactions could not occur.
Managing separate operating system and application security schemes is a major network headache. Active Directory builds on the model established by NT for merging NOS and applications schemes, expanding on it to add controls and features. Reviewers of Active Directory have likened the changes between the NT 4 and NT 5 Directory Services to the magnitude of the change between Novell NetWare 3.11 and 4. Many large companies with a significant investment in NT are very interested in this new technology but are taking a "wait and see" approach to its implementation.
In Microsoft's view, BackOffice resources can be both private and found on a LAN/WAN or intranet, or public on the intranet and still be managed by the network directory without concern. This is an ambitious plan that must solve several pressing problems, not the least of which is that different namespaces must be accommodated. In essence, the new Directory Services are the equivalent of a sophisticated Domain Naming Service (DNS) server.
NT 5's Directory Services offers the systems manager an integrated hierarchical view or schema of their enterprise, where assets such as servers, workstations, printers, netmodems, users, distribution lists, and applications are objects that can be assigned properties or attributes.
Standard objects include: Domains, OU, User, Group, Machine, Volume, PrintQueue, and connections (such as Winsock, RPC, or DCOM services).
All objects other than connections are static objects. Connections are an example of volatile objects that can be tracked by Directory Services. A volatile object is stored separately in the directory and replicated with a lower priority because chances are that the object will disappear before replication can occur. You can even create and publish new objects that you want to manage just as SMS tracks objects you want to inventory. Both static and volatile objects show up in the domain hierarchy.
The hierarchy is called a domain tree, with each domain being an independent partition in the tree. You can now search for assets against the database that manages them, reassign names, and through drag-and-drop operations promote, demote, or alter the assignments you have given them previously. Objects of like type inherit attributes from their parents in the schema.
This view also allows a system administrator to further assign a domain into organizational units (OUs), which provides a finer granularity for enterprise management. Each OU can have its own individual administrator. An OU can serve the function of an enterprise division--administration, finance, human resources, and so forth. As the organization scales, you can add more domains to the tree; each bounded by its own security features. Additionally, you can add more OUs inside a domain, and a domain's OUs also form a hierarchical tree structure. Domains are containers for OUs, and both have the feature that they inherit the attributes of their parents in the domain hierarchy. Figure 63.6 shows a hypothetical domain structure in this new model.
Whereas current domains can manage up to 100,000 users but more typically max out at around 30,000 to 40,000 users, Microsoft's current estimate is that a next-generation domain can contain up to 10 million tracked objects. When you create a hierarchy of domains in a domain tree, you greatly increase the number of users that an enterprise can manage. As you scale an enterprise, each domain in a domain tree keeps a reference to other objects in the domain tree but manages its own individual directory store. This makes the directory scalable to track objects in the hundreds of millions.
Security features such as access permissions are inherited from parent to child. However, the role of the container object provides an additional layer with which to isolate assigned roles. An administrator can be assigned full domain privileges, control over a subtree of OUs, or limited to just a single OU. Because you can now subdivide a domain, there is less need to agonize over the nature of trust relationships. Trust relationships still exist, but the new model allows for two-way or transitive trust relationships (instead of using two one-way relationships), which simplifies matters greatly.
This is a domain tree.
The directory stores a logical view of your enterprise, and this is the view that your users see. The physical location of an asset, the nature of the network it is on, where directory replicas are stored, and where shared volumes and printers are located are tracked by the directory but are not of concern to users. If you need to find a particular resource, you can query the directory in a natural language to locate a particular resource.
When coupled with Microsofts Distributed File System (DFS), this system decouples the absolute path to an object or resource from its purpose in the logical schema. Therefore, you can take a server running a service on a server such as Exchange offline and reroute its traffic through an internal assignment to another server running Exchange, and without having to inconvenience users in any way. The whole operation is transparent to users. In DFS, a share name and DFS volume name are independent of the server running DFS. You can redirect traffic to another server running DFS in your network. A DFS volume requires special formatting, and the service runs on your server and requires additional management using server utilities that Microsoft will supply.
The physical structure of the Active Directory is organized around domain servers
and sites. In the new directory, all servers contain a replica of the domain, with
pointers on where to locate specific information about resources in the enterprise.
A particular domain server might know a printer by name and not store its attributes,
but would know where to get the missing details. A site is a group of resources in
the enterprise linked with a fast connection. Sites are important because they determine
the nature of how and where directories are replicated.
The Active Directory services are available to programmers through three different APIs:
These APIs provide a means by which third-party developers can extend and complement in the box services that Microsoft provides. For example, developers can create plug-in APIs to manage other vendors' directory services.
Whereas developers will program in C++ to create OLE database interfaces, print or backup utilities, and so forth, system administrators and end users can program in Visual Basic or use a scripting language to perform important network functions.
The Component Object Model (COM) is the organizational structure and messaging apparatus by which software works together. Both OLE and ActiveX controls are part of this model, and any control using COM is an ActiveX control. A program containing an ActiveX control is an ActiveX container.
If it moves and shakes, it is dubbed "Active" by the movers and shakers in Redmond. If it just sits here and there and looks at you, it is "distributed." The distributed component model, (DCOM) which is embraced by both the Distributed File System and Distributed Security models, and are part of the NT Server 5 release, are examples of DCOM technology. DCOM was part of NT Server 4 and is being added to Windows 95 and Solaris. DCOM also makes possible multitier application development, where client/server technology can be developed by using special application servers. The Microsoft Transaction Server is specifically meant to help create scalable applications where processing is offloaded from the client onto this middleware server.
Active Platform is Microsoft's slogan for the technologies that make Active Desktop
and Active Server possible. In Active Desktop, a client's screen can serve as the
page on which information is delivered by network services: either through the network
or from the Internet. For example, you can be working on a document while watching
a real-time stock ticker running across the screen. To enable Active Desktop, a system
of client HTML browsing, scripting, and components work in concert with system services.
Active Server is the component of the technology that provides server HTML transmission,
scripting components, and network services. The Distributed Services Technology Preview
shows you some of these features.
A Windows NT Server 5 domain controller in a mixed domain controller environment containing other NT Server 3.x/4 domain controllers will appear as if it is an older generation domain controller. Many organizations will choose to implement the new services by installing an NT 5 domain as a BDC on a new server and then promoting the new BDC to a PDC when they feel confident of its operation. Alternatively, a BDC running NT Server 3.x /4 can be upgraded directly to an NT 5 BDC. Figure 63.7 shows you a proposed migration scheme for upgrading a domain.
When an NT 5 Server is promoted to the PDC, it contains both the master copy of the domain directory and the Global Catalog for the enterprise. At that point, all the new administrative tools that enable drag-and-drop domain configuration and maintenance can be used, and Organizational Units can be defined. All BDCs continue to operate unaware of the new features in the PDC that were enabled by the upgrade. When you have older version 3.5x/4 down level domain controllers, any of the new features enabled by domain trees or by the new security schemes for Internet/intranet access aren't available.
You can upgrade the BDCs at any time to domain controllers (DC). A domain controller contains a replica of the domain directory and becomes the peer of the PDC. Account updates can be made on any DC in the new system, and not just on the PDC. A DC running NT Server 5 participates in multimaster replication. You add a domain into the domain tree of your enterprise after all the domain controllers in that domain are upgraded.
There is a plan to upgrade current Microsoft Exchange directories into a new version of the NT Directory Services and to provide a migration tool for this task.
This is a migration scheme for upgrading a domain.
The enterprise database storing all the objects and attributes in the directory can grow quite large. Therefore, Directory Services partitions the information into a Global Catalog (GC) and the individual domain databases. The GC stores object references and serves as an index to the distributed directory contained in the domain databases. The GC stores users, services, and machine references and allows the collection of a global address book. This limits the size of the GC to something manageable.
The intent of the GC is to provide a small high-performance database distributed (replicated) across the enterprise that can be queried for most of the typical queries required. Because new objects are added infrequently to the GC, nearly all the activity is in the form of queries, and few updates are performed. This system forces Directory Services to aggressively replicate changes to the GC.
Directory Services relies on a distributed security scheme based on the access control list (ACL) model used by Windows NT Server itself. The Directory Services database maintains the store for the security system, replacing the Windows NT Registry, and becoming a trusted component of the Local Security Authority (LSA).
Internal system users still log on to the system by using the Windows NT LAN Manager (NTLM) authentication protocol, and this logon continues to be used for pass-through network authentication, remote file access, or RPC connections. Security is handled through encryption and through security certificates and keys when an NT 5 enterprise communicates over unsecured network connections like the Internet.
© Copyright, Macmillan Computer Publishing. All rights reserved.