U-M Windows Forest
ITS Windows-Based Services
How-To Documents
Frequently Asked Questions
Help
Contact Us
U-M Windows Forest Main

History of the Design of the U-M Windows Forest

The Windows forest at the University of Michigan was designed to accommodate the needs of a large, diverse, and somewhat autonomous computing community spread across the U-M campus. A strategic goal in creating a single Windows forest for the University of Michigan is to facilitate the sharing of Windows resources across the university. Our desire was to be inclusive, and to provide a Windows forest that can be "joined" in a number of ways, serving the needs of each individual unit that may wish to join.

The original design of the forest occurred during the pre-release and early days of Windows 2000 and Active Directory. As time passed and we (and the world at large) learned more about the features, constraints and boundaries of elements of a Windows forest, our ideas about the ideal forest design evolved from a multi-domain, multi-tree configuration to a single domain configuration. The net result is a forest that bears the scars of this evolution, with multiple domains, and even trees of domains.

U-M Forest Design

The University of Michigan Windows AAD Forest prior to Fall 2010 View Larger [+]

 

July 2000 The U-M Windows forest was designed to provide a root domain unpopulated by users or computers (the empty root model), to minimize risk to the U-M Windows forest. The root domain was called UMROOT (adsroot.itcs.umich.edu)
August 2000 While it was hoped that the U-M forest could be designed as a single tree, because of restrictions on allowable DNS names at umich.edu, the College of Engineering chose to migrate their NT4 domain into a domain, ENGIN, in a separate tree (ads.engin.umich.edu).
September 2000 To allow other campus units to join the forest in a unified DNS domain space while retaining the empty root, the UMICH domain was estalished (ads.itcs.umich.edu). Other units who required separate domains would be built as child domains of UMICH and within UMICH would be an Organizational Unit (OU) structure that would support the needs of most of campus.
January 2001 Based on this design, the School of Business migrated their NT4 domain into a child domain to UMICH, BUS (bus.ads.itcs.umich.edu).
April 2001 Kerberos integration was established, including population of the Active Directory with a complete set of Kerberos principals from the campus MIT Kerberos environment into the People OU within the UMICH domain. Using this enhancement, users could login to the Active Dirctory using their MIT Kerberos credentials, eliminating the necessity to separately create accounts and populate passwords in AD.
June 2001 Further testing of Windows Kerberos interoperability with the existing U-M Kerberos "umich.edu" realm dictated a change in plan, however. For Windows Kerberos interoperability, also known as "pass-thru logon", to work correctly from all domains in the forest, centrally maintained Active Directory user objects must reside in the forest root domain. Therefore, the People OU was re-established in the UMROOT domain, leaving the UMICH domain as a "placeholder" domain, not containing any non-administrative users or delegated OU's. No further domains would be allowed to join the forest under the UMICH domain, and if at some future point the School of Business decides to rejoin the forest under UMROOT, the UMICH domain will be decommissioned.

The College of Literature, Science and the Arts joined the forest after these best practices had been established as the LSA domain (lsa.adsroot.itcs.umich.edu). This domain resulted from the migration of the large LSA domain infrastructure into a single child domain to UMROOT.

At this time, the first delegated OU's were created in the UMROOT domain. This would allow units who had no need to incur the overhead of running their own domain to participate in the campus forest. The delegated OU's would provide a forest presence for non-user objects, such as servers, workstations, printers, etc.
January 2002 The final domain to be added to the campus tree was the Housing domain (housing.adsroot.itcs.umich.edu). While other domains within the campus forest were driven to join as separate domains as a logical upgrade path from existing NT4 domains, Housing did not have this issue. However, Housing needed to support a terminal services application that required the ability to set attributes on their user objects. They also wished to follow the campus convention of using the uniqname (netid) for access to computing services across campus. Because their users already existed in the UMROOT domain, but they were unable to manage the necessary attributes of these users, they chose to manage them separately in their own domain.
July 2003 It was recognized that the need to administer user objects (as presented by Housing) was not unique. A project was initated to delegate administration of the accounts in the UMROOT domain to departmental administrators. After looking at different ways to accomplish this, it was decided that this would be best done by moving users out of the People OU into delegated departmental OUs. A new Accounts OU was created at the same level as People and Organizations. A sub-OU within the Accounts OU would be created for each department that wants to manage centrally populated users.

Participating departments would be able to submit a list of users that they wish to have moved to their Accounts OU, allowing them to manage user attributes and apply group policy to their OU, but not be able to create other objects in the OU. A sub-OU in the Organizations OU serves the need for a resource container.
January 2004 While initially the desire was to allow units to join the campus forest as domains to provide a security boundary, we now understand that a domain does not offer that protection and that the security boundary is actually the forest. In addition, the added functionality of being able to locally administer centrally-provisioned accounts removes the largest barrier to participating as an OU instead of as a domain. As a result, adding domains to the campus forest is being actively discouraged.
June 2004 The largest independent domain (LSA) decided to move their user objects into the UMROOT domain, facilitating collaboration and interoperability with central Windows services and a goal of eventually dismantling the LSA domain. Other domains are encouraged to follow suite, but have not yet made that commitment.
February 2005 A web application was released to be used by admins to perform the necessary steps for maintaining their delegated Accounts OU, including specifying affiliations that identify their users and requesting users to be moved from the People into their departmental delegated Accounts OU.
2009-10 Campus domains merge with the UMROOT domain, creating a single-domain forest.
2010 The Business & Finance Forest joins the campus domain.