Rename Domain with Exchange 2007/2010 not feasible! an alternative solutions

Recently my company registered a new domain name and wanted to me to investigate best possible way to rename domain internally, change websites (hosted on IIS) publicly accessible CNAME to new domain name and change email address for entire organization. Fun hahh!! Google search appears that domain rename possible in win2k3 AD and exchange 2003 SP1.  However, according to Microsoft TechNet I can not rename Windows 2008 native domain with Exchange 2007 . what happen to those who are in the following situation:

• Rename Business registration
• Merger and/or Acquisition between companies
• Change of ownership

If your management decide to have new user account@newdomain, email addresses@newdomain and websites with new domain name. Now you will not have a choice but  find out a solution regardless of who says what. In this article (Ref: Plan A), I will investigate and share with you what happen if you rename domain on a test environment similar to my organisation i.e. Microsoft Active Directory 2008 and Exchange 2007/2010. Those who are in my situation, I will explain (Ref: Plan B) how I can accomplish same objectives with alternative deployment that means without messing around AD domain and Exchange 2007/2010.  I know plan A is going to fail but worthwhile to produce documents to management and go for plan B. So that business runs smoothly. when time perfect and fund is available then rebuild Microsoft messaging systems for entire organization.

Do NOT perform these steps in a production environment. Domain rename is NOT supported when Exchange 2007/2010 installed in a member server.

Rename Domain on a Testbed

Objectives:

• Rename Domain
• Migrate IIS to new domain
• Fix GPO and Exchange (only applicable for Exchange 2003)

Assumptions:

Steps involve:

• Set up your control station for the domain rename operation.
• Freeze the Forest Configuration
• Back up all the domain controllers in your forest.
• Generate the current forest description.
• Specify the new forest description.
• Generate domain rename instructions
• Push domain rename instructions to all domain controllers, and verify DNS readiness.
• Verify the readiness of the domain controllers.
• Execute the domain rename instructions
• Update the Exchange configuration, and restart the Exchange servers (Only applicable for Exchange 2003 SP1)
• Unfreeze the forest configuration
• Re-establish external trusts
• Fix Group Policy objects (GPOs) and links.

Precaution: Use the following link for Active Directory Backup and Restore in Windows Server 2008  or keep your resume handy

To verify the forest functionality to Windows Server 2008

1. Open Active Directory Domains and Trusts.
2. In the scope pane, right-click Active Directory Domains and Trusts and then click Raise Forest Functional Level.
3. In the Select an available forest functional level box, click Windows Server 2008, and then click Raise.
4. Click OK to raise the forest functionality, and then click OK again.

To analyze and prepare DNS zones for domain rename

1. Compile a list of DNS zones that need to be created.
2. Use the DNS MMC snap-in to create the required DNS zones compiled in step 1.
3. Configure DNS zones according to “Add a forward lookup zone” in Windows Server 2008.
4. Configure dynamic DNS update according to “Allow dynamic updates” in Windows Server 2008.

To generate the current forest description file

In windows server 2008, rendom and GPFix utility are available in %Windir%system32 folder. If you change your directory into c:Windowssystem32 and run rendom /list then domainlist.xml will be placed in same directory.

1. On the control station, open a command prompt and change to the X:DomainRename directory.
2. At the command prompt, type rendom /list the following command and press ENTER:
3. Save a copy of the current forest description file (domainlist.xml) generated in step 2 as domainlist-save.xml for future reference by using the following copy command: copy domainlist.xml domainlist-save.xml

To edit the domainlist.xml file

1. Using a simple text editor such as Notepad.exe, open the current forest description file domainlist.xml generated in “STEP 3: Generate the Current Forest Description” earlier in this document.
2. Edit the forest description file, replacing the current DNS and/or NetBIOS names of the domains and application directory partitions to be renamed with the planned new DNS and/or NetBIOS names.

To review the new forest description in domainlist.xml

At the command prompt, type the following and then press ENTER: rendom /showforest

To generate the domain rename instructions and upload them to the domain naming master

1. On the control station, open a command prompt.
2. From within the X:DomainRename directory, execute the following command: rendom /upload
3. Verify that the domain rename tool created the state file dclist.xml in the directory X:DomainRename and that the state file contains an entry for every domain controller in your forest

To discover the DNS host name of the domain naming master

1. On the control station, open a command prompt.
2. At the command prompt, type the following and then press ENTER: Dsquery server –hasfsmo name

To force synchronization of changes made to the domain naming master

The following procedure forces the Active Directory changes initiated at the Domain Naming master DC in STEP 4 to replicate to all DCs in the forest.

1. On the control station, open a command prompt.
2. At the command prompt, type the following and then press ENTER: repadmin /syncall /d /e /P /q DomainNamingMaster

where DomainNamingMaster is the DNS host name of the domain controller that is the current domain naming master for the forest.

To verify the readiness of domain controllers in the forest

1. On the control station, open a command prompt and change to the X:DomainRename directory

2. At the command prompt, type the following command and then press ENTER: rendom /prepare

3. Once the command has finished execution, examine the state file domainlist.xml to determine whether all domain controllers have achieved the

To execute the domain rename instructions on all domain controllers

1. On the control station, open a command prompt.
2. At the command prompt, type the following and then press ENTER: rendom /execute
3. When the command has finished execution, examine the state file domainlist.xml to determine whether all domain controllers have reached either the Done state or the Error state.
4. If the domainlist.xml file shows any DCs as remaining in the Prepared state, repeat step 2 in this procedure as many times as needed until the stopping criterion is met.

To force Rendom /execute to re-issue the RPC to a DC in the Error state

1. In the domainlist.xml file, locate the <Retry></Retry> field in the domain controller entry for the DC that you believe should be retried.
2. Edit the domainlist.xml file such that the field reads <Retry>yes</Retry> for that entry.
3. The next execution of the rendom /execute command will re-issue the execute-specific RPC to that DC.

To fix up DFS topology in every renamed domain

On the control station, open a command prompt. For each Dfs root, if any of the topology components as described above needs to be fixed, type the following command (the entire command must be typed on a single line, although it is shown on multiple lines for clarity) and press ENTER:

dfsutil /RenameFtRoot /Root:DfsRootPath /OldDomain:OldName /NewDomain:NewName /Verbose

-Where-

DfsRootPath is the DFS root to operate on, e.g., \microsoftguru.com.aupublic.

OldName is the exact old name to be replaced in the topology for the Dfs root.

NewName is the exact new name to replace the old name in the topology.

To fix up Group Policy in every renamed domain

1. On the control station, open a command prompt and change to the X:DomainRename directory.
2. At the command prompt, type the following command (the entire command must be typed on a single line, although it is shown on multiple lines for clarity) and press ENTER:

gpfixup /olddns:OldDomainDnsName /newdns:NewDomainDNSName /oldnb:OldDomainNetBIOSName

/newnb:NewDomainNetBIOSName /dc:DcDnsName 2>&1 >gpfixup.log

-Where-

OldDomainDnsName is the old DNS name of the renamed domain.

NewDomainDnsName is the new DNS name of the renamed domain.

OldDomainNetBIOSName is the old NetBIOS name of the renamed domain.

NewDomainNetBIOSName is the new NetBIOS name of the renamed domain.

DcDnsName is the DNS host name of a domain controller in the renamed domain, preferably the PDC emulator, that successfully completed the rename operation with a final Done state in the dclist.xml state file in “STEP 8: Execute Domain Rename Instructions” earlier in this document.

For example,

gpfixup /olddns:wolverine.com.au /newdns:microsoftguru.com.au /oldnb:wolverine /newnb:microsoftguru /dc:dc.wolverine.com.au 2>&1 >gpfixup1.log

To force replication of the Group Policy fix-up changes made at the DC named in DcDNSName in above step of this procedure to the rest of the DCs in the renamed domain, type the following and then press ENTER: repadmin /syncall /d /e /P /q DcDnsName NewDomainDN

-Where-

DcDnsName is the DNS host name of the DC that was targeted by the gpfixup command.

NewDomainDN is the distinguished name (DN) corresponding to the new DNS name of the renamed domain.

Repeat steps  in this procedure for every renamed domain. You can enter the commands in sequence for each renamed domain.

For Example, repadmin /syncall /d /e /P /q dc.microsoftguru.com.au dc=microsoftguru,dc=com, dc=au 

To update the DNS name of the CA machine

1. On the CA machine, open registry editor and locate the entry CAServerName under HKLMSystemCurrentControlSetCertSvcConfigurationYourCAName.
2. Change the value in CAServerName to correspond to the new DNS host name.

To update the Web enrolment file

To enable proper Web enrollment for the user, you must also update the file that is used by the ASP pages used for Web enrollment. The following change must be made on all CA machines in your domain.

1. On the CA machine, search for the certdat.inc file (if you have used default installation settings, it should be located in the %windir%system32certsrv directory).

2. Open the file, which appears as follows:

<%’ CODEPAGE=65001 ‘UTF-8%>

<%’ certdat.inc – (CERT)srv web – global (DAT)a

‘ Copyright (C) Microsoft Corporation, 1998 – 1999 %>

<% ‘ default values for the certificate request

sDefaultCompany=””

sDefaultOrgUnit=””

sDefaultLocality=””

sDefaultState=””

sDefaultCountry=””

‘ global state

sServerType=”Enterprise” ‘vs StandAlone

sServerConfig=”OLDDNSNAMEYourCAName”

sServerDisplayName=”YourCAName”

nPendingTimeoutDays=10

‘ control versions

sXEnrollVersion=”5,131,2510,0″

sScrdEnrlVersion=”5,131,2474,0″

%>

3. Change the SServerConfig entry to have the NewDNSName of the CA machine.

To perform attribute clean up after domain rename

1. On the control station, open a command prompt.
2. At the command prompt, from within the X:DomainRename directory, execute the following command: rendom /clean

Command-line usage to run XDR-fixup.exe

XDR-fixup.exe /s:start_domainlist.xml /e:end_domainlist.xml [/user:username /pwd:password | *] [/trace:tracefile] /changes:changescript.ldf /restore:restorescript.ldf [/?]

Note This command is one line. It has been wrapped for readability.

Command-line usage to verify XDR-fixup.exe

Use the following command line to verify the changes that are made by XDR-fixup.exe:

XDR-fixup /verify:restorescript.ldf /changes:verifycorrections.ldf

To unfreeze the forest configuration

From within the X:DomainRename directory, execute the following command: rendom /end

To force remove domain member if fails to join new domain using following command. Then re-join domain manually.

netdom remove <machine-name> /Domain:<old-domain> /Force”

To use Control Panel to check for primary DNS suffix update configuration for a computer

The following procedures explain two ways to view the setting for a member computer that determines whether the primary DNS suffix changes when the name of the membership domain changes.

1. On a member computer, in Control Panel, double-click System.

2. Click the Computer Name tab and then click Change.

3. Click More and then verify whether Change primary domain suffix when domain membership changes is selected.

4. Click OK until all dialog boxes are closed.

To use the registry to check for primary DNS suffix update configuration for a computer

1. On the Start menu, click Run.

2. In the Open box, type regedit and then click OK.

3. Navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters.

4. Verify whether the value of REG_RWORD SyncDomainWithMembership is 0x1. This value indicates that the primary DNS suffix changes when the domain membership changes.

To determine whether Group Policy specifies the primary DNS suffix for a computer

1. On a member computer, perform one of the following steps:
2. At a command prompt, type gpresult. In the output, under Applied Group Policy objects, check to see whether Primary DNS Suffix is listed.

Open the Resultant Set of Policy Wizard, as follows:

In Active Directory Users and Computers, right-click the computer object, click All Tasks, and then click Resultant Set of Policy (Logging).

Open a command prompt and then type: ipconfig /all

Check the Primary DNS Suffix in the output. If it does not match the primary DNS suffix that is specified in the System Control Panel for the computer (see “To use Control Panel to check for primary DNS suffix update configuration for a computer” earlier in this document), then the Primary DNS Suffix Group Policy is applied.

u In the registry, check for the presence of the entry Primary DNS Suffix under HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftSystemDNSclient. If a value is present, then the Primary DNS Suffix Group Policy is applied to the computer.

To install Support Tools

1. On the Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition operating system CD, double-click the Support folder.

2. In the Support folder, double-click the Tool folder and then run suptools.msi.

To use ADSI Edit to add DNS suffixes to msDS‑AllowedDNSSuffixes

The attribute msDS‑AllowedDNSSuffixes is an attribute of the domain object. Therefore, you must set DNS suffixes for each domain whose name is going to change.

1. On the Start menu, point to Programs, Windows Server 2003 Support Tools, Tools, and then click ADSI Edit.

2. Double-click the domain directory partition for the domain you want to modify.

3. Right-click the domain container object, and then click Properties.

4. On the Attribute Editor tab, in the Attributes box, double-click the attribute msDS‑AllowedDNSSuffixes.

5. In the Multi-valued String Editor dialog box, in the Value to add box, type a DNS suffix and then click Add.

6. When you have added all the DNS suffixes for the domain, click OK.

7. Click OK to closed the Properties dialog box for that domain.

8. In the scope pane, right-click ADSI Edit and click Connect to.

9. Under Computer, click Select or type a domain or server.

10. Type the name of the next domain for which you want to set the primary DNS suffix, and then click OK.

11. Repeat steps 2 through 7 for that domain.

12. Repeat steps 8 through 10 to select each subsequent domain and repeat steps 2 through 7 to set the primary DNS suffix for each subsequent domain that is being renamed.

                 

To apply the Group Policy setting Primary DNS Suffix to groups of member computers

1. In Active Directory Users and Computers, right-click the domain or organizational unit that contains the group of computers to which you are applying Group Policy.

-Or-

In Active Directory Sites and Services, right-click the site object that contains the computers to which you are applying Group Policy.

2. Click the Group Policy tab.

3. In the Group Policy object Links box, click the Group Policy object that you want to contain the Primary DNS Suffix setting.

-Or-

To create a new Group Policy object, click New and then type a name for the object.

4. With the Group Policy object selected, click Edit.

5. Under Computer Configuration, click to expand Administrative Templates, Network, and then click DNS Client.

6. In the results pane, double-click Primary DNS Suffix.

7. Click Enabled, and then in the Enter a primary DNS suffix box, type the DNS suffix for the domain whose member computers are in the group you selected in Step 1.

8. Click OK.

9. Close the Group Policy dialog box, and then close the properties page for the selected object.

To configure the redirecting alias DNS entry

1. In the DNS MMC snap-in, expand the DNS server node to expose the old DNS zone.

2. Right-click the old DNS zone.

3. Click New Alias (CNAME ).

4. In the Alias name box, type the original fully qualified domain name (FQDN) of the HTTP Server..

5. In the Fully qualified domain name for target host box, type the new FQDN of the HTTP Server, and then click OK.

At this point you can test the redirection by pinging the FQDN of the old HTTP server. The ping should be remapped to the new FQDN of the HTTP server.

Issues involving domain rename:

• XDR-Fixup tool does not work on Exchange 2010 
• Exchange SMTP stops functioning
• Exchange organization initialization fails

Simple alternative solutions without renaming domain

Microsoft does not support domain rename if Exchange 2007 installed in member server. So what could be work around if you have to have new user account, corresponding emails account and web sites with new domain name without renaming domain.

• Prepare a control workstation station and log on as a domain admin, schema admin and enterprise admin
• Create a new range of IP in your infrastructure
• Prepare an windows server 2008 and promote as your new primary domain with new domain name
• Create External trust between two domains
• Ask your ISP Add new Host (A) and MX record with new domain

            

• Point this new MX record to existing SMTP server
• Add new domain into trusted domain list

• Add new email policy for new domain

• Change default email address to new email addresses through email property of mailbox using Exchange management console

• Migrate IIS web sites to new web server
• Redirect CNAME record to new websites for customers and stakeholder
• Add 301 redirect using Google webmaster if necessary 

Relevant Articles:

Microsoft Exchange System Attendant service does not start

completely remove Exchange 2000 or Exchange 2003 from Active Directory

How to remove Exchange Server 2003 from your computer

How to remove the first Exchange Server 2003 computer from the administrative group

Removing and Modifying Exchange 2007

Step-by-Step Guide to Implementing Domain Rename

Windows Server 2003 Active Directory Domain Rename Tools

Exchange Server Domain Rename Fixup

Microsoft KB842116

Microsoft Exchange Server Domain Rename Fixup (XDR-Fixup)

Windows 2003 domain rename tools

 

How to create an external trust between two separate domains/forests

A trust is a relationship established between two different domains that enables users in one domain to be authenticated by a domain controller in the other domain. There are different type of trust in Microsoft Active Directory domain such as External, Realm, Forest and shortcut. External trust is necessary when users of two different domains of two different business units wants to utilize resources such as printers and file server of trusted domains. This article can be applied in Windows Server 2003, Windows Server 2008/R2, Windows Server 2012/R2 and Windows Server 2016 domain using same principle written below.

Authentication Consideration

Authentication Setting	Inter-forest Trust Type	Description
Domain-wide Authentication	External	Permits unrestricted access by any users. Default authentication setting for external trusts.
Forest-wide Authentication	Forest	Permits unrestricted access by any users. Default authentication setting for forest trusts.
Selective Authentication	External and Forest	Restricts access over an external. Authentication setting must be manually enabled.

Administrative Privilege

To create trust you have to be a member of Domain Admins & Enterprise Admin in both Domains.

Transitive trusts

• Shortcut trust. A transitive trust between domains in the same domain tree or forest that is used to shorten the trust path in a large and complex domain tree or forest.
• Forest trust. A transitive trust between one forest root domain and another forest root domain.
• Realm trust. A transitive trust between an Active Directory domain and a Kerberos V5 realm.

Non-transitive trusts

• External trust. A non-transitive trust created between a Windows Server 2003 domain and Windows 2000 or Windows Server 2003 domain in another forest.
• Realm trust. A non-transitive trust between an Active Directory domain and a Kerberos V5 realm.

You have to fulfill few requirements before you can activate external trust. For example: Both domain controller must ping each other by IP address. If both domain controllers are placed in different subnet then proper routing is required. If there is a firewall between domain controllers then proper firewall rules should be in place allowing LDAP, DNS and resources port to be accessible from both sites. Forest and domain functional level must be Windows Server 2003 or later version.

Example:

DC1.DomainA.com  IP address: 192.168.100.2

DC1.DomainB.com  IP address: 192.168.200.2

Step1: Port requirement

If you are using MPLS/IP VPN/VPN make sure inbound and outbound routing are in correct order. If you have firewall between organisation make sure Active Directory ports are open in both sides. Further info on port requirement visit  Active Directory and Active Directory Domain Services Port Requirements

Step2: Add DNS Record in TCP/IP Properties of Domain Controllers

Open TCP/IP Properties of DC1.DomainA.com and add IP address of DC1.DomainB.com in the secondary DNS record.

Open TCP/IP Properties of DC1.DomainB.com and add IP address of DC1.DomainA.com in the secondary DNS record.

Step3: Ping DomainA from DomainB and vice versa

Log on to each domain and ping each other by IP address. Resolve IP without any delay or timed out ping.

Step4: Test AD DS Ports

Telnet to port 389, 636 & 53 from both sides of domain to test whether you can access Active Directory & DNS

Step5: Health Check

Run a quick AD health check in both sides using this Link

Step6: Create PTR Record in both organisation

Add Reverse Lookup Zone of 192.168.200.2 into DC1.DomainA.com. To do this, Right Click on Reverse Lookup Zone>New Zone>Click Next>Primary Zone>Click Next>IPV4 reverse Lookup Zone>Type 192.168.200>Click Next>Finish.

Repeat the step to add 192.168.100.2 PTR into DC1.DomainB.com. To do this, Right Click on Reverse Lookup Zone>New Zone>Click Next>Primary Zone>Click Next>IPV4 reverse Lookup Zone>Type 192.168.100>Click Next>Finish.

Step7: Create Forward Lookup Zones in both organisation

In some DNS environment where DNS have constrained access (situation specific only), you may have to create Forward Lookup Zone for DomainA.com into DomainB.com and Forward Lookup Zone for DomainB.com into DomainA.com. But there is no harm creating a forward lookup zone in both sides as both forests are going to trust each other once trust is activated.

To do this, log on to DomainA.com >Open DNS Manager>Expand Forward Lookup Zone> Right click on Forward Lookup Zones>New Zones>primary Zones>Type FQDN of forest e.g. DomainB.com. >Select Default or select “To all domain controllers in this forest”> Type Zone Name DomainB.com>Allow Secure Dynamic Update>Follow the Wizard.

To do this, log on to DomainB.com >Open DNS Manager>Expand Forward Lookup Zone> Right click on Forward Lookup Zones>New Zones>primary Zones>Type FQDN of forest e.g. DomainA.com. >Select Default or select “To all domain controllers in this forest”> Type Zone Name DomainA.com>Allow Secure Dynamic Update>Follow the Wizard.

Step8: Create Host (A) record in both organisation

Create Host (A) record of Domain Controller of DomainA.com into Domain Controller of DomainB.com. Create Host (A) record of Domain Controller of DomainB.com into Domain Controller of DomainA.com. To do this Log on to DC1.DomainA.com>Right click on Forward Look Up Zone you created in step 7 which is DomainB.com>Click New Host (A)>Leave the Name Blank> Type IP Address of DC1.DomainB.com & Select Associated PTR Record> Click Add Host.

Repeat the Steps in DomainB.com. To do this log on to DC1.DomainB.com>Right click on Forward Look Up Zone you created in step7 which is DomainA.com>Click New Host (A)>Leave the Name Blank> Type IP Address of DC1.DomainA.com & Select Associated PTR Record> Click Add Host.

Step9: Add Name Server (NS) in both organisation

You must add Name Server of DC1.DomainA.com into the Name Servers Property of DC1.DomainB.com. Repeat the step to add Name Server of DC1.DomainB.com into the Name Servers Property of DC1.DomainA.com.

To do this log on to DC1.DomainA.com>Open DNS Manager>Right click on Forward Look Up Zone of DomainB.com>Click Properties>Click Name Servers Tab>Click Add>Type the IP Address of DC1.DomainB.com.

Repeat the Steps in DomainB.com. To do this log on to DC1.DomainB.com>Open DNS Manager>Right click on Forward Look Up Zone of DomainA.com>Click Properties>Click Name Servers Tab>Click Add>Type the IP address of DC1.DomainA.com.

Step10: Test DNS Record

Ping FQDN of DomainA.com from DomainB.com

Ping FQDN of DomainB.com from DomainA.com

Ping DC1.DomainA.com from DC1.DomainB.com

Ping DC1.DomainB.com from DC1.DomainA.com

Step11: Create External Trust

Example: One way trust allows users from DC1.DomainB.com (outgoing) get access into DC1.DomainA.com (incoming) but DC1.DomainA.com doesn’t get access to DC1.DomainB.com).

Note : if you want both sides get access to both sides then change that configure to two way trusts and set incoming and outgoing in both sides.

Creating incoming trust in DC1.DomainA.com

1. Open Active Directory Domains and Trusts.

2. In the console tree, right-click the domain for which you want to establish a trust, and then click Properties.

3. On the Trusts tab, click New Trust, and then click Next.

4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of the external domain, and then click Next.

5. On the Trust Type page, click External trust, and then click Next.

6. On the Direction of Trust page, click One-way: incoming, and then click Next.

7. On the Sides of Trust page, click This domain only, and then click Next.

8. On the Trust Password page, type the trust password twice, and then click Next.

With the administrator of the other domain, agree on a secure channel password to be used in establishing the trust.

9. On the Trust Selections Complete page, review the results, and then click Next.

10. On the Trust Creation Complete page, review the results, and then click Next.

11. On the Confirm Incoming Trust page, do one of the following

• If you do not want to confirm this trust, click No, do not confirm the incoming trust
• If you want to confirm this trust, click Yes, confirm the incoming trust, and then supply the appropriate administrative credentials from the specified domain.

12. On the Completing the New Trust Wizard page, click Finish.

 Creating outgoing trust in DC1.DomainB.com
1. Open Active Directory Domains and Trusts.

2. In the console tree, right-click the domain for which you want to establish a trust, and then click Properties.

3. On the Trusts tab, click New Trust, and then click Next.

4. On the Trust Name page, type the Domain Name System (DNS) name (or NetBIOS name) of the external domain, and then click Next.

5. On the Trust Type page, click External trust, and then click Next.

6. On the Direction of Trust page, click One-way: outgoing, and then click Next.

7. On the Sides of Trust page, click This domain only, and then click Next.

8. On the Outgoing Trust Authentication Level page, do one of the following, and then click Next:

• Click Domain-wide authentication.
• Click Selective authentication.

9. On the Trust Password page, type the trust password twice, and then click Next.

10. On the Trust Selections Complete page, review the results, and then click Next.

11. On the Trust Creation Complete page, review the results, and then click Next.

12. On the Confirm Outgoing Trust page, do one of the following:

• If you do not want to confirm this trust, click No, do not confirm the outgoing trust. Note that if you do not confirm the trust at this stage, the secure channel will not be established until the first time that the trust is used by users.
• If you want to confirm this trust, click Yes, confirm the outgoing trust, and then supply the appropriate administrative credentials from the specified domain.

13. On the Completing the New Trust Wizard page, click Finish.

 Step12: Test a Trust Relation

1. Virtualize two Windows clients
2. Join them to DomainA and DomainB
3. Create two test folders in DomainA and DomainB
4. Share and assign permission to users of DomainA and DomainB for both folders.
5. Log on to a Windows client in DomainA using credential of DomainB>Access folder of DomainA
6. Log on to a Windows client in DomainB using credential of DomainA>Access folder of DomainB

How to create an external trust between two seperate domains/forests

This gallery contains 8 photos.

A trust is a relationship established between two different domains that enables users in one domain to be authenticated by a domain controller in the other domain. There are different type of trust in Microsoft Active Directory domain such as … Continue reading →