Determining Domain Migration Strategies
Determining Domain Migration Strategies |
|
If you are performing an in-place upgrade, you might consider upgrading your resource domains. Resource domains were used in Windows NT to hold the computer accounts of resources such as servers and client computers. Resource domains existed primarily to:
In Windows NT, the maximum size recommended for the Security Account Manager (SAM) account database is 40 MB. In a domain containing user accounts, security groups, and Windows NT client and server accounts, this might equal less than 20,000 user accounts. To scale an organization with more than this number, user and computer accounts need to be stored in separate domains, that is, account domains for user accounts, and resource domains for computer accounts. This is the norm for Windows NT, where resource domains are usually created with explicit one-way trusts to either a single account domain (master domain model) or a number of account domains (multiple-master domain model).
In a decentralized organization with geographically disparate facilities, it is often desirable to have local personnel authorized to administer resources. To allow this kind of decentralized responsibility in Windows NT systems, it was recommended that resource domains be created with their own administrative structure. As with scaling beyond SAM size limits, this resulted in master or multiple-master domain structures with explicit one-way trusts to the account domains in the organization. The one-way nature of these trusts ensured that resource domain administrators only had administrative scope over the resource domain.
Note
As part of your upgrade plan, your administrative model must reflect the implications of upgrading a resource domain. If you have already upgraded the account domain, and then you upgrade the resource domain as a child of the account domain, a transitive trust is established between them. For this reason, you need to consider how this transitive trust affects local administration of resources.
If you do not want administrative permissions to extend beyond the resource domain, you might consider other options, which include:
You might rethink your domain structure and consider merging your resource domains as organizational units (OUs) into the upgraded account domain at a later time. This option would obviously influence your thinking on the order of domain upgrade.
You can upgrade your resource domain to be in the same forest as the account domain(s) and use Windows 2000 delegation of administration features to limit the capabilities of the local administrators. Before you do this, check the administrative groups in the resource domain and remove all administrators who are not administrators in the account domains. If there are only local resource domain administrators, add one or more of your account domain administrators. These administrators will be able to administer the domain while it is being upgraded. As a further precaution, make sure that resource domain administrators do not have administrative access to the domain controllers through local computer accounts.
After the PDC is upgraded, you might create a new domain local group to hold your resource administrators, and use Windows 2000 delegated administration to grant them sufficient privilege to carry out their roles.
You can upgrade your resource domain and make it a tree in a new forest, linking the tree to the account domain through an explicit one-way trust. This would effectively mirror the structure that existed before the upgrade.