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 Registration Below ports should be opened in all the DCs for AD/DNS. TRUST Creating the trust There 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 trust Trust 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 EventsADMT Active 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 list Installing 128-Bit High Encryption SoftwareDomain ControllerAGUDLPWindows Time Server/Service How to configure the Windows time server-PDC MigrationKerberos Survival Guide Server Roles Migration DHCP MigrationWINS MigrationCA MigrationNPS MigrationDNS Migration Post Migration Decommission the Source Domain (Example)Completing Post-Migration Tasks (Example) Enterprise ADMINS Authorize DHCP server without Enterprise Admin privilegesDomain Admins vs. Enterprise Admins Backup All user attributes Active Directory Attributes in the ADUC GUI Tool Infrastructure 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
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.
You can use NSLOOKUP for DNS troubleshooting. See the below example.
If above test is passed we can say DNS seems OK.
RPC endpoint mapper
Network basic input/output system (NetBIOS) name service
NetBIOS datagram service
NetBIOS session service
RPC dynamic assignment
Server message block (SMB) over IP (Microsoft-DS)
Lightweight Directory Access Protocol (LDAP)
LDAP over SSL
Global catalog LDAP
Global catalog LDAP over SSL
Domain Name Service (DNS)
Use port query for that.
How to Create Two way Transitive Trust – Windows Server 2008 R2
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).
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.
You can use either of the following tools to perform the procedures for this task:
<>Active Directory Domains and Trusts
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
Routing for a Subordinate Name Suffix
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
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.
"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
How Active Directory Functional Levels Work
How To Determine Trust Relationship Configurations
Creating the Forest Root Domain
Configuring DNS for the Forest Root Domain
How to Create Two way Transitive Trust – Windows Server 2008 R2 (en-US)
Checklist: Creating a forest trust(create one way or two way)
Accessing resources across forests
How Domain and Forest Trusts Work:
Additional Configuration for Functionality Across Forests (Multiple Forest Considerations in Windows 2000 and Windows Server 2003)
Accessing Resources across forest and achieve Single Sign ON (Part1)
(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)
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).
A new trust was created to a domain.
A trust to a domain was removed.
Kerberos policy was changed.
Trusted domain information was modified.
System security access was granted to an account.
System security access was removed from an account.
A namespace collision was detected.
A trusted forest information entry was added.
A trusted forest information entry was removed.
A trusted forest information entry was modified.
Active Directory Migration Tool versions and supported environments
Computer Migration - Things to Consider
Workstation Profile Migration
ADMT Guide: Migrating and Restructuring Active Directory Domains
ADMT 3.2: Common Installation Issues
Installing ADMT in the Target Domain
Users/Groups/Computer migration & Error troubleshotting
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.)
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
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.
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
2. At the command prompt, type the following command, and then press ENTER:
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
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.
Group Type and Scope Usage in Windows
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.
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
Time: 1:18:18 PM
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.
0000: 00 00 00 00
Above event is applicable for 2003 and 2008 as well .... .
Only Enterprise admins can authorise the DHCP servers for his own forest not even any domain admins form any child domains.
The following table is an extract from TechNet
Default user rights
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.
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
Active Directory Certificate Services.zip
Active Directory Domain Services.zip
Exchange Online - Evaluating Software-plus-Services.zip
Forefront Identity Manager.zip
Forefront Unified Access Gateway.zip
Internet Information Services.zip
IPD - All.zip
IPD Series Introduction.zip
Microsoft Application Virtualization 4.6.zip
Remote Desktop Services.zip
Selecting the Right NAP Architecture.zip
Selecting the Right Virtualization Technology.zip
SharePoint Online - Evaluating Software-plus-Services.zip
System Center 2012 - Operations Manager.zip
System Center 2012 - Service Manager.zip
System Center 2012 - Virtual Machine Manager.zip
System Center Configuration Manager 2007.zip
System Center Data Protection Manager 2007.zip
System Center Operations Manager 2007.zip
System Center Service Manager 2010.zip
System Center Virtual Machine Manager 2008.zip
Windows Deployment Services.zip
Windows Server Virtualization.zip
Windows User State Virtualization.zip
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
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..