Table of Contents New Trust Wizard terminologyDNS Secondary zoneConditional forwarderADI Conditional forwarderStub zoneUsing Conditional Forwarders vs. Using Secondary ZonesDifference Between Forwarder and Stub ZoneNSLOOKUP SRV Records Registered by Net LogonTroubleshooting SRV Record RegistrationBelow ports should be opened in all the DCs for AD/DNS.TRUST Creating the trustThere are few things you keep remember for troubleshhoting the trust. UPN Suffix-Routing name suffixes across forestsModifying Name Suffix Routing SettingsAuthentication type i) Forest wide:-ii) Selective authentication:-Trust Type Forest TrustExternal trustTree-root trustParent-child trustShortcut trustExternal trustForest trustRealm trustTrust PasswordWindows trust refresh intervalHow the the trust is stored in AD?Q:-( Kerberos Authentication Over An External Trust – Is It Possible? Auditing Windows Active Directory Trust RelationshipsKnown Issues for Creating Domain and Forest TrustsTrust Event IDs Active Directory Audit EventsADMTActive Directory Migration – High Level Steps and FlowchartHow to Migrate Users Across forest (Cross Forest) using ADMT 3.2 with sid and PasswordsInterforest Migration with ADMT 3.2 - Part 1ADMT Service Account - Permission and ConfigurationTroubleshooting ADMT Log File IssuesExamine Migration Logs for ErrorsADMT log locationADMT 3.2 releasedAskds blogs of ADMTTroubleshooting ADMT Checklist: Performing an Interforest MigrationDeveloping a Test Plan for Your MigrationCreating a Rollback PlanCreating an End-User Communication PlanBackground Information for Restructuring Active Directory Domains Within a ForestClosed sets and open setsSID history Attributes that are always excluded by the systemSystem attribute exclusion listAttribute exclusion listInstalling 128-Bit High Encryption SoftwareDomain ControllerAGUDLPWindows Time Server/Service How to configure the Windows time server-PDC MigrationKerberos Survival GuideServer Roles Migration DHCP MigrationWINS MigrationCA MigrationNPS MigrationDNS MigrationPost Migration Decommission the Source Domain (Example)Completing Post-Migration Tasks (Example)Enterprise ADMINS Authorize DHCP server without Enterprise Admin privilegesDomain Admins vs. Enterprise AdminsBackup All user attributes Active Directory Attributes in the ADUC GUI ToolInfrastructure Planning and Design Active Directory Domain Services Operations Guide.Download IPD DOCs.Infrastructure Planning and Design Guide Series It is complex task to managing the multi domains environment. Assume you have multiple child domains & multiple trusts as well so you have to understand very much the below operations/topics..
You create trusts in Windows Server 2008 with the New Trust Wizard. Before you use the New Trust Wizard, review the following terminology. Each highlighted term represents the exact term as it is used in the wizard:
<> This domain: The domain from which you launch the New Trust Wizard. When you start the wizard, it immediately verifies your administrative credentials in the domain for which you are the administrator. Therefore, the wizard uses the term “this domain” to represent the domain that you are currently logged on to.
<> Local domain / Local forest: The domain or forest where you start the New Trust Wizard.
<> Specified domain / Specified forest: The other domain or forest that this local domain or local forest will trust. Although the New Trust Wizard is aware of the domain context in which it is running, it does not have knowledge of the other domain that you want to create the relationship with. After you type the name of the other domain or forest in the Trust Name page, that name is used whenever the wizard refers to the specified domain or specified forest.
<> Two-way trust: A trust relationship between two domains in which both domains trust each other. For example, domain A trusts domain B, and domain B trusts domain A. All parent-child trusts are two-way trusts.
<> One-way: incoming trust: A one-way trust relationship between two domains in which the direction of the trust points toward the domain from which you start the New Trust Wizard (and which is identified in the wizard as This domain). When the direction of the trust points toward your domain, users in your domain can access resources in the specified domain. For example, if you are the domain administrator in domain A and you create a one-way, incoming trust to domain B, this provides a relationship through which users who are located in domain A can access resources in domain B. Because this relationship is one way, users in domain B cannot access resources in domain A.
<> One-way: outgoing trust: A one-way trust relationship between two domains in which the direction of the trust points toward the domain that is identified as Specified domain in the New Trust Wizard. When the direction of trust points toward the specified domain, users in the specified domain can access resources in your domain. For example, if you are the domain administrator in domain A and you create a one-way, outgoing trust to domain B, this action provides a relationship through which users who are located in domain B can access resources in domain A. Because this relationship is one way, users in domain A cannot access resources in domain B.
<> Both sides of the trust: When you create external trusts, shortcut trusts, or forest trusts, you have the option to create each side of the trust separately or both sides of the trust simultaneously. If you choose to create each side of the trust separately, you must run the New Trust Wizard twice—once for each domain. When you create trusts separately, you must supply the same trust password for each domain. As a security best practice, all trust passwords should be strong passwords.
<> Domain-wide authentication: An authentication setting that permits unrestricted access by any users in the specified domain to all available shared resources that are located in the local domain. This is the default authentication setting for external trusts.
<> Forest-wide authentication: An authentication setting that permits unrestricted access by any users in the specified forest to all available shared resources that are located in any of the domains in the local forest. This is the default authentication setting for forest trusts.
<> Selective authentication: An authentication setting that restricts access over an external trust or forest trust to only those users in a specified domain or specified forest who have been explicitly given authentication permissions to computer objects (resource computers) that reside in the local domain or the local forest. This authentication setting must be enabled manually.
<> Trust password: An option in which both domains in a trust relationship share a password, which is stored in the trusted domain object (TDO) object in Active Directory Domain Services (AD DS). When you choose this option, a strong trust password is generated automatically for you. You must use the same password when you create a trust relationship in the specified domain. If you choose to create both sides of the trust simultaneously, you run the New Trust Wizard once. Create the trust between PDC
Here DNS is covering only for creating the trust.
You can use stub zones to:
There are two lists of DNS servers involved in the loading and maintenance of a stub zone:
When a DNS server loads a stub zone, such as widgets.tailspintoys.com, it queries the master servers, which can be in different locations, for the necessary resource records of the authoritative servers for the zone widgets.tailspintoys.com. The list of master servers may contain a single server or multiple servers, and it can be changed anytime.
There are several conditions you should take into account when choosing between conditional forwarders or secondary zones with zone transfers (to resolve DNS names that your DNS Servers are not authoritative for). When you decide whether to use conditional forwarders or secondary zones with zone transfers enabled, there are several considerations you should take into account before choosing either configuration.
The benefit of using a conditional forwarder is that it is much easier to configure and troubleshoot than a zone transfer. The process of configuring a conditional forwarder is straightforward: all you need to know is the DNS domain name of the domain that houses the DNS server that you are configuring to forward requests and the IP address of the target DNS server.
However, a conditional forwarder is not an efficient way to keep a DNS server that hosts a parent zone aware of the authoritative DNS servers for a child zone. If you use a conditional forwarder, whenever the authoritative DNS servers for the child zone change, the conditional forwarder setting on the DNS server that hosts the parent zone must be configured manually with the IP address for each new authoritative DNS server for the child zone.
Using a secondary zone with zone transfers enabled is beneficial because this configuration maintains a list of all the authoritative DNS servers for the secondary copy of the zone, and the list is updated as DNS servers are added and removed from the target forest or domain. Secondary zones also host a full copy of the DNS zone.
The drawbacks to using secondary zones with zone transfers enabled are that this configuration is much more complicated to configure and maintain and you do not have the direct, point-to-point contact with a DNS server in the target forest or domain as you do with a conditional forwarder. In addition, with secondary zones you expose hosts to IP address mappings for all hosts in the zone. This can expose the domain or forest to security risks due to unauthorized access.
Query the PDC emulater of the remote domain before creating the trust.
using nslookup You can use NSLOOKUP for DNS troubleshooting. See the below example. cmd---nslookup set q=srv _ldap._tcp.dc._msdcs.trusteddomain.com _ldap._tcp.gc._msdcs.trusteddomain.com _ldap._tcp.pdc._msdcs.trusteddomain.com _ldap._tcp.dc._msdcs.trustingdomain.com _ldap._tcp.gc._msdcs.trustingdomain.com _ldap._tcp.pdc._msdcs.trustingdomain.com If above test is passed we can say DNS seems OK.
Service
Port/protocol
RPC endpoint mapper
135/tcp, 135/udp
Network basic input/output system (NetBIOS) name service
137/tcp, 137/udp
NetBIOS datagram service
138/udp
NetBIOS session service
139/tcp
RPC dynamic assignment
Win 2k/2003:1024-65535/tcp Win 2008+:49152-65535/tcp
Server message block (SMB) over IP (Microsoft-DS)
445/tcp, 445/udp
Lightweight Directory Access Protocol (LDAP)
389/tcp
LDAP ping
389/udp
LDAP over SSL
636/tcp
Global catalog LDAP
3268/tcp
Global catalog LDAP over SSL
3269/tcp
Kerberos
88/tcp, 88/udp
Domain Name Service (DNS)
53/tcp1, 53/udp
Use port query for that. http://www.microsoft.com/en-in/download/details.aspx?id=17148
How to Create Two way Transitive Trust – Windows Server 2008 R2
http://social.technet.microsoft.com/wiki/contents/articles/13906.how-to-create-two-way-transitive-trust-windows-server-2008-r2-en-us.aspx
Name suffix routing is a mechanism for managing how authentication requests are routed across Windows Server 2008 forests and Windows Server 2003 forests that are joined by forest trusts. To simplify the administration of authentication requests, when a forest trust is created, all unique name suffixes are routed by default. A unique name suffix is a name suffix within a forest, such as a user principal name (UPN) suffix, Service Principal Name (SPN) suffix, or Domain Name System (DNS) forest or domain tree name, that is not subordinate to any other name suffix. For example, the DNS forest name fabrikam.com is a unique name suffix within the fabrikam.com forest.
All names that are subordinate to unique name suffixes are routed implicitly. For example, if your forest uses fabrikam.com as a unique name suffix, authentication requests for all child domains of fabrikam.com (childDomain.fabrikam.com) will be routed because the child domains are part of the fabrikam.com name suffix. Child names are displayed in the Active Directory Domains and Trusts snap-in. If you want to exclude members of a child domain from authenticating in the specified forest, you can disable name suffix routing for that name. You can also disable routing for the forest name itself, if necessary.
For more information about name suffix routing, see Routing name suffixes across forests (http://go.microsoft.com/fwlink/?LinkId=111725).
Note
You cannot enable a name suffix that is the same as another name in the routing list. If the conflict is with a local UPN name suffix, you must remove the local UPN name suffix from the list before you can enable the routing name. If the conflict is with a name that is claimed by another trust partner, you must disable the name in the other trust before it can be enabled for this trust.
Task requirements
You can use either of the following tools to perform the procedures for this task:
<>Active Directory Domains and Trusts
<>Netdom.exe
For more information about using the Netdom command-line tool to modify name suffix routing, see Netdom Overview (http://go.microsoft.com/fwlink/?LinkId=111537).
To complete this task, you can perform the following procedures:
<>Modify Routing for a Forest Name Suffix
<> Modify Routing for a Subordinate Name Suffix
<> Exclude Name Suffixes from Routing to a Forest
For more information about how selective authentication settings work, see "Security Considerations for Trusts" in the Windows Server 2003 Technical Reference on the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=35413).
Diagram of a forest trust
By default the Windows server will reset the trust password every 30 days. Some times the change only occurs on the Windows side and trust object in DSfW does not get the update leading to a broken trust. Validating and reseting the trust is one way to fix this. Another option is to disable the server from changing the password. http://www.youtube.com/watch?v=pU9Gm5DxLCw
"Both domains in a trust relationship share a password, which is stored in the TDO object in Active Directory. As part of the account maintenance process, every thirty days, the trusting domain controller changes the password stored in the TDO. Because all two-way trusts are actually two one-way trusts going in opposite directions, the process occurs twice for two-way trusts. A trust has a trusting and a trusted side. On the trusted side, any writable domain controller can be used for the process. On the trusting side, the PDC emulator performs the password change."
DFL & FFL for trust You can create a forest trust between two Windows Server 2003 forests, between two Windows Server 2008 forests, between two Windows Server 2008 R2 forests, between a Windows Server 2003 forest and a Windows Server 2008 forest, between a Windows Server 2003 forest and a Windows Server 2008 R2 forest, or between a Windows Server 2008 forest and a Windows Server 2008 R2 forest. Forest trusts cannot be extended implicitly to a third forest.
How Active Directory Functional Levels Work http://technet.microsoft.com/en-us/library/cc739548
How To Determine Trust Relationship Configurations http://support.microsoft.com/kb/228477
Creating the Forest Root Domain http://technet.microsoft.com/en-us/library/cc781481(v=ws.10).aspx
Configuring DNS for the Forest Root Domain http://technet.microsoft.com/en-us/library/cc771849(v=ws.10).aspx
How to Create Two way Transitive Trust – Windows Server 2008 R2 (en-US) http://social.technet.microsoft.com/wiki/contents/articles/13906.how-to-create-two-way-transitive-trust-windows-server-2008-r2-en-us.aspx
Checklist: Creating a forest trust(create one way or two way) http://technet.microsoft.com/en-us/library/cc756852%28WS.10%29.aspx Accessing resources across forests http://technet.microsoft.com/en-us/library/cc772808(v=ws.10).aspx
How Domain and Forest Trusts Work: http://technet.microsoft.com/en-us/library/cc773178%28WS.10%29.aspx#w2k3tr_trust_how_knfk Additional Configuration for Functionality Across Forests (Multiple Forest Considerations in Windows 2000 and Windows Server 2003) http://technet.microsoft.com/en-us/library/cc779566(WS.10).aspx Accessing Resources across forest and achieve Single Sign ON (Part1) http://blogs.technet.com/b/mir/archive/2011/06/12/accessing-resources-across-forest-and-achieve-single-sign-on-part1.aspx
(2011-09-07) Kerberos Authentication Over An External Trust – Is It Possible? (Part 1) (2011-09-07) Kerberos Authentication Over An External Trust – Is It Possible? (Part 2) (2011-09-07) Kerberos Authentication Over An External Trust – Is It Possible? (Part 3) (2011-09-07) Kerberos Authentication Over An External Trust – Is It Possible? (Part 4) (2011-09-07) Kerberos Authentication Over An External Trust – Is It Possible? (Part 5) (2011-09-14) Kerberos Authentication Over An External Trust – Is It Possible? (Part 6)
http://www.windowsecurity.com/articles/Auditing-Windows-Active-Directory-Trust-Relationships.html
Review the following known issues before creating domain and forest trusts in Windows Server 2008:
<> You cannot delegate the creation of trusts to any user who is not a member of the Domain Admins group or the Enterprise Admins group. Even though you can grant a user the Create TDO (Trusted Domain Object) right or the Delete TDO right in the System container of a domain, the user will not be granted the right to create a trust. This issue occurs because Netlogon and the trust-creation tools (Active Directory Domains and Trusts and Netdom) are designed so that only members of the Domain Admins group and the Enterprise Admins group can create trusts. However, any user who is a member of the Incoming Forest Trust Builders group can create one-way, incoming forest trusts to your forest.
<> When you are logged on locally to a domain controller and you try to create a new trust by using Active Directory Domains and Trusts, the operation may be unsuccessful and you may receive the message “Access denied.” This issue occurs only if you are logged on locally to the domain controller as an ordinary user (that is, you are not logged on as Administrator or as a member of any administrative groups for the domain). By default, ordinary users are blocked from logging on locally to a domain controller unless Group Policy is modified to permit this.
<> When you use the Active Directory Domains and Trusts snap-in to create a trust, you may receive the message “Operation failed. Parameter incorrect.” This issue may occur if you try to establish a trust relationship when the source domain and the target domain have one or more of the following identifiers that are the same:
<> Security identifier (SID)
<> Domain Name System (DNS) name
<> NetBIOS name
To resolve this issue, do one of the following before you try to create the trust, as appropriate to your situation:
<> Rename the conflicting identifier.
<> Use a fully qualified domain name (FQDN) if there is a NetBIOS conflict.
<> The option to create a forest trust may not appear in the New Trust Wizard. This issue typically occurs when one or both of the Windows Server 2008 forests are not set to the Windows Server 2003 forest functional level or higher. For more information about forest functional levels, see Active Directory Functional Levels Technical Reference (http://go.microsoft.com/fwlink/?LinkId=111466).
4706
A new trust was created to a domain.
4707
A trust to a domain was removed.
4713
Kerberos policy was changed.
4716
Trusted domain information was modified.
4717
System security access was granted to an account.
4718
System security access was removed from an account.
4864
A namespace collision was detected.
4865
A trusted forest information entry was added.
4866
A trusted forest information entry was removed.
4867
A trusted forest information entry was modified.
http://support.microsoft.com/kb/947226
http://www.windowsecurity.com/articles/event-ids-windows-server-2008-vista-revealed.html
http://www.windowsecurity.com/articles/Auditing-Users-Groups-Windows-Security-Log.html
http://social.technet.microsoft.com/wiki/contents/articles/5310.active-directory-migration-high-level-steps-and-flowchart.aspx
Active Directory Migration Tool versions and supported environments http://technet.microsoft.com/en-us/library/active-directory-migration-tool-versions-and-supported-environments(v=ws.10).aspx
Computer Migration - Things to Consider http://www.sivarajan.com/cm.html
Workstation Profile Migration http://portal.sivarajan.com/2010/04/workstation-profile-migration.html
ADMT Guide: Migrating and Restructuring Active Directory Domains http://technet.microsoft.com/en-us/library/cc974332(v=ws.10).aspx
ADMT 3.2: Common Installation Issues http://blogs.technet.com/b/askds/archive/2010/07/09/admt-3-2-common-installation-issues.aspx
Installing ADMT in the Target Domain http://technet.microsoft.com/en-us/library/cc974370(v=ws.10).aspx
Users/Groups/Computer migration & Error troubleshotting
http://blog.thesysadmins.co.uk/category/admt http://blog.thesysadmins.co.uk/category/admt/page/2
http://technet.microsoft.com/en-us/library/cc974423%28v=ws.10%29.aspx
http://technet.microsoft.com/en-us/library/cc974425%28v=ws.10%29.aspx
http://blogs.technet.com/b/askds/archive/tags/admt/
http://technet.microsoft.com/en-us/library/cc974327(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/cc974345(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/cc974430(v=ws.10).aspx
http://technet.microsoft.com/en-us/library/cc974452(v=ws.10).aspx
Restructuring Active Directory domains within a forest involves migrating accounts and resources from the source domains to the target domains. Unlike the process for restructuring Active Directory domains between forests, when you restructure domains in a forest, the migrated objects no longer exist in the source domain.
For intraforest migration, computer accounts are treated differently than user and group accounts. To facilitate rollback, a new computer account is created in the target domain, and the source computer account remains enabled in the source domain after the migration.
In addition, migrating user accounts, resources, and groups requires special consideration when you restructure Active Directory domains within a forest because of the containment rules that apply to Active Directory groups. For these reasons, the challenge when you restructure Active Directory domains in a forest is to ensure that users have continuous access to resources during the migration process.
When you restructure Active Directory domains within a forest, you must be concerned with two types of closed sets:
<> Users and groups
<> Resources and local groups Users and groups
The first type of closed set includes the following:
<> User accounts
<> All the global groups to which the users belong
<> All the other members of the global groups
Global groups are limited to members of the domain where the global group exists. Therefore, if you migrate a user account to a new domain but you do not migrate the global groups to which the user belongs, the user is no longer a valid member of those global groups and the user cannot access resources that are based on membership in those global groups. Therefore, when you are moving accounts between domains in a forest, it is necessary to move closed sets so that users retain access to their resources.
Although built-in accounts (such as Administrators, Users, and Power Users) and well-known accounts (such as Domain Admins and Domain Users) cannot be Active Directory Migration Tool (ADMT) migration objects, migrating these groups in closed sets is not a common problem. Using them in access control lists (ACLs) or membership in domain local groups is not an effective way to assign resource permissions.
When you migrate users, ADMT makes the user a member of the domain users group in the target domain. However, it does not maintain permissions for other built-in groups (such as Server Operators and Backup Operators) or well-known groups (such as Domain Admins). If you have used built-in or well-known groups to assign resource permissions, you must reassign those permissions to a new domain local group before you begin the migration. Reassigning permissions includes performing the following steps:
1. Create a new domain local group in the source domain.
2. Create a new global group in the source domain that contains users who need access to the resource.
3. Add the new global group to the domain local group.
4. Run security translation by using a security identifier (SID) mapping file that maps the well-known group to the new domain local group (created in the first step) on all resources that assign permissions using well-known groups. For information about performing a security translation by using a SID mapping file, see Translate Security by Using a SID Mapping File, later in this guide.
In small domain environments that have few global groups, you might be able to identify closed sets of users and groups. If you can identify closed sets, you can migrate users and groups at the same time. In a large domain environment, a user can belong to a number of global groups. Therefore, it is difficult to identify and migrate only closed sets of users and groups. For this reason, it is best to migrate groups before you migrate user accounts.
For example, User 1 belongs to global groups Global A and Global B and is a member of Domain 1. If an administrator moves User 1 and Global A to Domain 2 in the same forest, these accounts no longer exist in Domain 1. They exist only in Domain 2 in the same forest. Global B group remains in Domain 1. This creates an open set, or a set that includes users and groups in more than one domain. Because global groups can only contain members from the domain where the global group exists, the membership of User 1 in Global B is no longer valid, and User 1 can no longer access resources based on membership in Global B. Therefore, it is best to migrate both global groups before you migrate User 1.
If you are migrating an open set of objects in an environment where the functional level for both the source domain and the target domain is Windows 2000 native or higher, ADMT transforms the global group into a universal group so that it can contain users from other domains and retain the group membership. When the set becomes a closed set, ADMT changes the group back to a global group. The benefit of this process is that ADMT ensures that all closed set problems are resolved. However, replication of the global catalog is increased while the groups are universal groups because membership is copied to the global catalog.
If the functional level of the source domain is Windows 2000 mixed, ADMT cannot transform the global group into a universal group because universal groups cannot exist at that functional level. Even if the target domain is in native mode, however, users in mixed mode domains would not get the SIDs of universal groups in their access tokens, if the groups are from outside the domain. Therefore, ADMT creates a copy of the global group in the target domain and adds all migrated users to the copy of that group. This group has a new SID and no SID history. This method does not preserve access to resources unless you run the ADMT Security Translation Wizard in Add mode to update permissions, which delays and complicates the migration process. For this reason, we do not recommend that you restructure domains that are operating at the Windows 2000 mixed domain functional level or the Windows Server 2003 interim domain functional level. Resources and local groups
The second type of closed set is resources and local groups. In most cases, resources have permissions assigned to computer local groups or domain local groups. Because computer local groups are migrated when you migrate the computer, these groups are a natural closed set. However, domain local groups can be used on multiple computers to assign permissions.
In this case, you can either migrate all the computers that use the domain local group at the same time that the domain local group is migrated to the target domain or you can manually change the domain local group to a universal group and then migrate the universal group. Changing the domain local group to a universal group is a manual process because ADMT does not automatically perform this task. Although this change can increase the size of your global catalog, over a limited time period, it is an effective way to migrate resources and domain local groups as a closed set.
SID history helps you to maintain user access to resources during the process of restructuring Active Directory domains. When you migrate an object to another domain, the object is assigned a new SID. Because you assign permissions to objects based on SIDs, when the SID changes, the user loses access to that resource until you can reassign permissions. When you use ADMT to migrate objects between domains in the same forest, the SID history is automatically retained. In this way, the SID from the source domain remains as an attribute of the object after the object is migrated to the target domain.
For example, an organization that is restructuring its Active Directory domains moves universal and global groups from a source domain to the target domain before moving user accounts. Because this is a migration within a forest and the functional level of the source domain is Windows 2000 native, these groups cease to exist in the source domain and exist only in the target domain. Because the SID history of both users and groups is migrated, the users continue to have access to resources in the source domain based on their membership in a group that exists in the target domain. Assigning resource access to groups
The most effective way to assign permissions to resources is to perform the following actions:
1. Assign users to global groups
2. Place global groups within domain local groups
3. Assign permissions to the domain local groups
Some attributes are always excluded from the migration by ADMT and cannot be configured to be migrated. This protects system-owned attributes. These attributes include the following:
<> Object globally unique identifier (GUID)
<> SIDs (Although SIDs can be added to the SID history of the object in the target domain.)
<> LegacyExchangeDN
The first time that you run an ADMT user migration, ADMT generates a system attribute exclusion list, which it stores in its database. The system attribute exclusion list contains two attributes by default: mail and proxyAddresses. ADMT also reads the schema in the target domain, and adds any attributes to the list that are not part of the base schema. Attributes in this list are excluded from migration operations even if the attribute is not specified in the attribute exclusion list. An administrator can change the system attribute exclusion list only by using a script. This protects attributes that are important in order for server-based applications, such as Microsoft Exchange, to work. If the target domain schema is further extended after ADMT has generated the list, administrators must manually add the new attributes to the list, unless they are certain that copying the values of these attributes from the source domain will not interfere with server-based applications.
Administrators can define a list of attributes that are excluded from each migration. This is called an attribute exclusion list. By default, when using the ADMT console, state information for attributes that are configured to be excluded is stored in the user interface (UI) and included in the exclusion list for the next migration. Scripting and command-line attributes do not have state information. Therefore, they are not stored in the UI. These attributes must be added to the attribute exclusion list for each migration operation, either by means of the attribute name or by means of an option file.
The computer on which the Active Directory Migration Tool (ADMT) is installed requires 128-bit high encryption. This encryption is standard on computers that are running Windows 2000 Server Service Pack 3 (SP3) or Service Pack 4 (SP4), Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2. If you plan to install ADMT on a computer that does not support 128-bit high encryption by default, you must install the 128-bit high encryption pack.
You can download the encryption pack from Windows 2000 High Encryption Pack (http://go.microsoft.com/fwlink/?LinkId=76037). Establishing Required Trusts for Your Migration
Before you can migrate accounts and resources from a source domain to a target domain in a different Active Directory forest, you must ensure that the appropriate trusts exist between the forests. Trust relationships between the forests that you are restructuring makes it possible for the Active Directory Migration Tool (ADMT) to migrate users and service accounts and translate local user profiles from the source domains to the target domains. In addition, depending on how trust relationships are configured, users in the source domain can access resources in the target domain. Moreover, users in the target domains can access resources in the source domain that have not yet been migrated.
To migrate users and global groups, you must establish a one-way trust between the source domain and the target domain, so that the source domain trusts the target domain.
To migrate resources or translate local profiles, you must do one of the following:
<> Create a one-way trust between the source domain and the target domain.
<> Create a two-way trust between source and target domains.
You can use this procedure to verify that a domain computer account is registered properly and that the Service Principal Names (SPNs) are advertised. This account is required for the domain controller to function as a domain controller in the domain.
Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at http://go.microsoft.com/fwlink/?LinkId=83477.
To verify a domain computer account for a new domain controller
1. Open a Command Prompt as an administrator: On the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, provide Domain Admins credentials, if required, and then click Continue.
2. At the command prompt, type the following command, and then press ENTER:
dcdiag /test:MachineAccount
3. It the test is successful, you should see the following message:
<ComputerName> passed test MachineAccount.
To receive more detailed information, including the SPNs that are found for the domain controller, use the /v option.
You can only add an user in a trusted domain security group if that group is a domain local/Builtin local so you can only able to add an account in "ADMINISTRATORS" bulitin local security group but not in "Domain admins" coz "Domain admins" is a Global security group.
There is a similarity between local group & domain local group.
See the below link. http://msmvps.com/blogs/acefekay/archive/2012/01/06/using-group-nesting-strategy-ad-best-practices-for-group-strategy.aspx
Group Type and Scope Usage in Windows http://support.microsoft.com/kb/231273
Group scope http://technet.microsoft.com/en-us/library/cc755692(v=ws.10).aspx
Changing group scope When you create a new group, by default the new group is configured as a security group with global scope, regardless of the current domain functional level. Although changing a group scope is not allowed in domains with a domain functional level of Windows 2000 mixed, the following conversions are allowed in domains with the domain functional level of Windows 2000 native or Windows Server 2003:
It is very important that your domain/forest is running with proper time & time sync should be proper with PDC/DC. Windows time service having a very important role on that. Kerberos authentication will be failed if PDC is not working properly.
http://social.technet.microsoft.com/wiki/contents/articles/4209.kerberos-survival-guide.aspx
netsh dhcp server export C:\dhcp.txt all netsh dhcp server import C:\dhcp.txt all
netsh dhcp server \\rumor export C:\dhcp.txt all
C:\>netsh dhcp server \\mst-ads01 show optionvalue >>c:\DHCPConfig.txt
C:\>netsh dhcp server \\mst-ads01 show scope dump >> c:\Dhcp_scopes.txt
Event Type: Information Event Source: DhcpServer Event Category: None Event ID: 1044 Date: 1/20/2011 Time: 1:18:18 PM User: N/A Computer: RUMOR Description: The DHCP/BINL service on the local machine, belonging to the Windows Administrative domain services.corp.contoso.com, has determined that it is authorized to start. It is servicing clients now. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: 0000: 00 00 00 00
Above event is applicable for 2003 and 2008 as well .... . http://blogs.technet.com/b/teamdhcp/archive/2009/02/18/migration-of-dhcp-server-from-windows-server-2003-to-windows-server-2008.aspx
Only Enterprise admins can authorise the DHCP servers for his own forest not even any domain admins form any child domains.
http://social.technet.microsoft.com/wiki/contents/articles/14456.authorize-dhcp-server-without-enterprise-admin-privileges.aspx
The following table is an extract from TechNet
Group
Description
Default user rights
Domain Admins
Members of this group have full control of the domain. By default, this group is a member of the Administrators group on all domain controllers, all domain workstations, and all domain member servers at the time they are joined to the domain. By default, the Administrator account is a member of this group. Because the group has full control in the domain, add users with caution.
Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force a shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects.
Enterprise Admins (only appears in the forest root domain)
Members of this group have full control of all domains in the forest. By default, this group is a member of the Administrators group on all domain controllers in the forest. By default, the Administrator account is a member of this group. Because this group has full control of the forest, add users with caution.
Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects.
Most of the IT guys misunderstands the roles of these user groups and their user rights in a domain environment and a forest environment. Now I hope you have a pretty clear picture on what members of these two groups can do.
http://technet.microsoft.com/en-us/library/cc756898(WS.10).aspx _______________________________________________________________________________________________________________
Somekey points
1.Last but not the least keep remember Inter forest migration is copy paste but Intra forest is cut paste so take the valid backup before proceding the Migration.
When we want to perform ldap queries or create object delegation in Active Directory, we must know which attribute behind in the fields. Here are attributes for Active Directory Users and Computers console fields.
File name
Size
Active Directory Certificate Services.zip
1.9 MB
Download
Active Directory Domain Services.zip
2.2 MB
DirectAccess.zip
2.0 MB
Dynamic Datacenter.zip
3.1 MB
Exchange Online - Evaluating Software-plus-Services.zip
1.6 MB
Exchange Server.zip
2.9 MB
File Services.zip
Forefront Identity Manager.zip
Forefront Unified Access Gateway.zip
1.8 MB
Internet Information Services.zip
1.5 MB
IPD - All.zip
69.9 MB
IPD Series Introduction.zip
143 KB
Malware Response.zip
MED-V.zip
Microsoft Application Virtualization 4.6.zip
3.0 MB
Print Services.zip
Remote Desktop Services.zip
2.3 MB
Selecting the Right NAP Architecture.zip
2.8 MB
Selecting the Right Virtualization Technology.zip
SharePoint Online - Evaluating Software-plus-Services.zip
SharePoint Server.zip
2.4 MB
SQL Server.zip
System Center 2012 - Operations Manager.zip
3.2 MB
System Center 2012 - Service Manager.zip
System Center 2012 - Virtual Machine Manager.zip
4.2 MB
System Center Configuration Manager 2007.zip
System Center Data Protection Manager 2007.zip
2.1 MB
System Center Operations Manager 2007.zip
System Center Service Manager 2010.zip
2.7 MB
System Center Virtual Machine Manager 2008.zip
1.3 MB
Terminal Services.zip
1.2 MB
Windows Deployment Services.zip
1.7 MB
Windows Server Virtualization.zip
Windows User State Virtualization.zip
Windows_Optimized_Desktop_Scenarios.zip
435 KB
http://technet.microsoft.com/en-us/solutionaccelerators/ee382254.aspx
This article has been highlighted in this week's "Top Contributors" TechNet Wiki Ninjas blog : blogs.technet.com/.../top-contributors-windows-trust-migration-agudlp-admt-slow-boots-and-slow-logons-sbsl-windows-server-2012.aspx
This article has been highlighted in this week's TNWiki Article Spotlight - blogs.technet.com/.../tnwiki-article-spotlight-first-of-2013.aspx
Thanks Richard
This article has been highlighted [yet again] in this week's "Top Contributors" Wiki Ninja blog : blogs.technet.com/.../top-contributors-first-of-2013-windows-trust-migration-agudlp-admt-small-basic-forums-help-active-directory-lync-server-2013-and-more.aspx
i.biswajith, I really appreciate your efforts and the contribution you are giving to TechNet WiKi... Awesome article..One shall keep this page in bookmarks..
Thanks Venkat