INDEX

Page No Name 1. creating a trust between two AD domain 1. Differencr Between Domain and Domain Controller 2. TOMESTONE Period Check 4. Recover Deleted Object 10. Microsoft Exchange attributes and reconnect the user to the Exchange mailbox 13. To Clean MetaData

Do you have a Step-by-Step on creating a trust between two AD domains' (Windows 2000 and Windows 2003) two-way trust? The main concern here is there have to be some DNS records created before the trust steps are taken. I am more concerned with those DNS steps. For the example please use Windows 2000 domain as ABC.com and Windows 2003 as 123.AD.com. Thanks! Okay. I made the assumption that the DNS servers are the Domain Controllers. I also assumed good connectivity between the DNS severs. We will call SERVERA the Domain Controller from ABC.com and Server1 from the 123.com domain. Here are the DNS steps that you could use: 1. On Server1 log on and access DNS. 2. Right Click on the zone 123.com and click properties. 3. Got to the transfers section and configure the server to allow zone transfers to the SERVERA IP address. 4. On SERVERA log on and access DNS. 5. Right click on the zone ABC.com and click properties. 6. Go to the transfers section and configure the server to allow zone transfer to the Server1 IP Address. 7. Still on SERVERA, create a SECONDARY zone called 123.com. 8. Indicate that the Master server for the 123.com zone it Server1. 9. On Server1, create a zone called ABC.com. 10. Indicate that the Master server for the ABC.com zone is SERVERA. 11. Check that the Zones are correctly populated by accepting your changes and then double-clicking on the new zone

Difference between DC and Domain

First
domain consists of Domain controller & computers that belong to that Domain. Domain controller controls all computer in that domain. clearly, domain- group of computers (PCs) with server that controls others domain controller- Server/PC dedicated to control others

Second

The above comes out as having no idea what is being talked about. I assume it is standard Windows LAN because those terms word for word exist in that style of network.

Domain is centralized with something like Windows 2003 Server. As opposed to Workgroup
who could have been just a bunch of DOS machines networked under one name. Centralized as in you could have roamed within the machines of that same domained LAN. Which is not happening with a Workgroup.

Domain Controller is the aforementioned centralized machine which has all the accounts and
settings and manages all services. When it is down a LAN domain is down too so Microsoft introduced PDC and a backup idea called BDC anologuous to RAID.

TombStone Period Check

1. Start Run mmc ADSI EDIT 2. Configuration CN Configuration, DC-Domain CN=Services CN= Windows NT CN=Directory Services Right Click Properties. 3. Open a window View the Attribute Editor and u see the Attribute lifetime in shown.

Recover Deleted Item

1. Click Start, click Run, and then type LDP.exe.

Note: If the LDP.exe utility is not installed, install the support tools from the Windows Server 2003 installation CD, or get them from Windows 2003 SP1 Support Tools.

2. Use the Connection menu in LDP to perform the connect operations and the bind operations to a Windows Server 2003 domain controller. Specify domain administrator credentials during the bind operation.

3. Click Options > Controls.

4. In the Load Predefined list, click Return Deleted Objects. Under Control Type, click Server, and the click OK.

5. Click View > Tree. Now type the distinguished name path of the deleted objects container in the domain where the deletion occurred, and then click OK.

Note: The distinguished name path is also known as the DN path. For example, if the deletion occurred in the petri.local domain, the DN path would be the following path:
cn=deleted Objects,dc=petri,dc=local

6. In the left pane of the window, double click the Deleted Object Container. Note: As a search result of LDAP query, only 1000 objects are returned by default. For example, if more than 1000 objects exist in the Deleted Objects container, not all objects appear in this container. If your target object does not appear, use NTDSUTIL, and then set the maximum number by using maxpagesize to get the search results, as described in the following KB article: How to view and set LDAP policy in Active Directory by using Ntdsutil.exe - 315071 7. Double-click the object that you want to undelete or to reanimate. 8. Right-click the object that you want to reanimate, and then click Modify.

9. Next, change the value for the isDeleted attribute and the DN path in a single Lightweight Directory Access Protocol (LDAP) modify operation. To configure the Modify dialog, follow these steps: a. In the Edit Entry Attribute box, type isDeleted. Leave the Value box blank.

b. Click the DELETE option button, and then click Enter to make the first of two entries in the Entry List dialog.

Important: Do not click Run at this phase!!! c. In the Attribute box, type distinguishedName. In the Values box, type the new DN path of the reanimated object. For example, to reanimate the TestUser user account to the Sales OU, use the following DN path:
cn=TestUser,ou=Sales,dc=petri,dc=local

Note: If you want to reanimate a deleted object to its original container, append the value of the deleted object's lastKnownParent attribute to its CN value, and then paste the full DN path in the Values box.

d. In the Operation box, click REPLACE. Click ENTER.

e. Click to select the Synchronous check box, and the Extended check box.

f. Click RUN. Note the results pane on the right side showing you that the operation was successful.

10. After you reanimate the objects, click Options > Controls and click the Check Out button to remove (1.2.840.113556.1.4.417) from the Active Controls box list.

11. Open Active Directory Users and Computers, and reset the user account passwords, profiles, home directories and group memberships for the deleted users. You need to do this because when the object was deleted, all the attribute values except SID, ObjectGUID, LastKnownParent and SAMAccountName were stripped. 12. Enable the reanimated account in Active Directory Users and Computers.

Note: The restored object has the same primary SID as it had before the deletion, but the object must be added again to the same security groups to have the same level of access to resources. The RTM release of Windows Server 2003 does not preserve the sIDHistory attribute on reanimated user accounts, computer accounts, and security groups, however, Windows Server 2003 with Service Pack 1 does preserve the sIDHistory attribute on deleted objects. 13. If you do not reset the reanimated user account's password you will get an error saying: Windows cannot enable object TestUser because:
Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirement of the domain.

For organizations using Exchange 2003 you need to remove Microsoft Exchange attributes and reconnect the user to the Exchange mailbox. In order to do so follow these steps: 1. In Active Directory Users and Computers, right-click the restored user and select Exchange Tasks.

2. Select Remove Exchange Attributes and click Ok all the way till the end of the wizard.

3. In Exchange System Manager, navigate to the mailbox store containing the recovered user's mailbox. Refresh the Mailboxes node list, and if needed, rightclick the Mailboxes node and select Run Cleanup Agent.

Note that the deleted user's mailbox is marked with a red X.

4. Right-click the deleted mailbox, select Reconnect.

5. Type the reanimated user's name. Press Check Names, then click Ok.

6. The mailbox is now reconnected. Wait a couple of minutes or re-run the Recipient Update Service from the Exchange System Manager console.

To clean up metadata 1. At the command line, type Ntdsutil and press ENTER.
C:\WINDOWS>ntdsutil ntdsutil:

1. At the Ntdsutil: prompt, type metadata cleanup and press Enter.

ntdsutil: metadata cleanup metadata cleanup:

1. At the metadata cleanup: prompt, type connections and press Enter.

metadata cleanup: connections server connections:

1. At the server connections: prompt, type connect to server <servername>, where <servername> is the domain controller (any functional domain controller in the same domain) from which you plan to clean up the metadata of the failed domain controller. Press Enter.
server connections: connect to server server100 Binding to server100 ... Connected to server100 using credentials of locally logged on user. server connections:

Note: Windows Server 2003 Service Pack 1 eliminates the need for the above step. 1. Type quit and press Enter to return you to the metadata cleanup: prompt.
server connections: q metadata cleanup:

1. Type select operation target and press Enter.

metadata cleanup: Select operation target select operation target:

1. Type list domains and press Enter. This lists all domains in the forest with a number associated with each.
select operation target: list domains Found 1 domain(s) 0 - DC=dpetri,DC=net select operation target:

1. Type select domain <number>, where <number> is the number corresponding to the domain in which the failed server was located. Press Enter.

select operation target: Select domain 0 No current site Domain - DC=dpetri,DC=net No current server No current Naming Context select operation target:

1. Type list sites and press Enter.

select operation target: List sites Found 1 site(s) 0 - CN=Default-First-SiteName,CN=Sites,CN=Configuration,DC=dpetri,DC=net select operation target:

1. Type select site <number>, where <number> refers to the number of the site in which the domain controller was a member. Press Enter.
select operation target: Select site 0 Site - CN=Default-First-SiteName,CN=Sites,CN=Configuration,DC=dpetri,DC=net Domain - DC=dpetri,DC=net No current server No current Naming Context

select operation target: 1. Type list servers in site and press Enter. This will list all servers in that site with a corresponding number.
select operation target: List servers in site Found 2 server(s) 0 - CN=SERVER200,CN=Servers,CN=Default-First-SiteName,CN=Sites,CN=Configuration,DC=dpetri,DC=net 1 - CN=SERVER100,CN=Servers,CN=Default-First-SiteName,CN=Sites,CN=Configuration,DC=dpetri,DC=net select operation target:

1. Type select server <number> and press Enter, where <number> refers to the domain controller to be removed.
select operation target: Select server 0 Site - CN=Default-First-SiteName,CN=Sites,CN=Configuration,DC=dpetri,DC=net Domain - DC=dpetri,DC=net Server - CN=SERVER200,CN=Servers,CN=Default-First-SiteName,CN=Sites,CN=Configuration,DC=dpetri,DC=net DSA object - CN=NTDS Settings,CN=SERVER200,CN=Servers,CN=DefaultFirst-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net DNS host name - server200.dpetri.net Computer object - CN=SERVER200,OU=Domain Controllers,DC=dpetri,DC=net No current Naming Context select operation target:

1. Type quit and press Enter. The Metadata cleanup menu is displayed.
select operation target: q metadata cleanup:

1. Type remove selected server and press Enter. You will receive a warning message. Read it, and if you agree, press Yes.

metadata cleanup: Remove selected server "CN=SERVER200,CN=Servers,CN=Default-First-SiteName,CN=Sites,CN=Configuration,DC=dpetri,DC=net" removed from server "server100" metadata cleanup:

At this point, Active Directory confirms that the domain controller was removed successfully. If you receive an error that the object could not be found, Active Directory might have already removed from the domain controller. 1. Type quit, and press Enter until you return to the command prompt. To remove the failed server object from the sites 1. In Active Directory Sites and Services, expand the appropriate site. 2. Delete the server object associated with the failed domain controller.

To remove the failed server object from the domain controllers container 1. In Active Directory Users and Computers, expand the domain controllers container. 2. Delete the computer object associated with the failed domain controller.

1. Windows Server 2003 AD might display a new type of question window, asking you if you want to delete the server object without performing a DCPROMO operation (which, of course, you cannot perform, otherwise you wouldn't be reading this article, would you...) Select "This DC is permanently offline..." and click on the Delete button.

1. AD will display another confirmation window. If you're sure that you want to delete the failed object, click Yes.

To remove the failed server object from DNS 1. In the DNS snap-in, expand the zone that is related to the domain from where the server has been removed. 2. Remove the CNAME record in the _msdcs.root domain of forest zone in DNS. You should also delete the HOSTNAME and other DNS records.

1. If you have reverse lookup zones, also remove the server from these zones. Other considerations Also, consider the following:

If the removed domain controller was a global catalog server, evaluate whether application servers that pointed to the offline global catalog server must be pointed to a live global catalog server. If the removed DC was a global catalog server, evaluate whether an additional global catalog must be promoted to the address site, the domain, or the forest global catalog load. If the removed DC was a Flexible Single Master Operation (FSMO) role holder, relocate those roles to a live DC. If the removed DC was a DNS server, update the DNS client configuration on all member workstations, member servers, and other DCs that might have used this DNS server for name resolution. If it is required, modify the DHCP scope to reflect the removal of the DNS server. If the removed DC was a DNS server, update the Forwarder settings and the Delegation settings on any other DNS servers that might have pointed to the removed DC for name resolution.

One of the important features of Windows Server 2003 was that Microsoft finally achieved the ability to create a true Kerberos trust between forests, also called a "cross-forest trust." This was noticeably missing in Windows 2000 Server, which allowed only NTLM or "external" trusts that did not have transitivity. Building a cross-forest trust permits a trust to be established between the root domain of two forests, and any child domain in either forest can have access to resources in the other forest without an explicit trust, as Windows 2000 required. Recently, I was working with a client to resolve an issue regarding Microsoft Exchange Server working across a trust. In that situation, it became necessary to create a new trust. Although the client's admins were experienced, they had never built a cross-forest trust. For anyone who needs a refresher on how to build a cross-forest trust, here are the steps: Background: In our scenario, let's consider two forests, Corp.net and ABC.com. There is a child domain, NA.corp.net, in the Corp.net forest, but ABC.com is a single domain forest. Our goal will be to create a two-way trust between the Corp.net domain and the ABC.com domain. Because it's a transitive trust, the NA domain will be able to use the trust as well. Preparation is key for a cross-forest trust Before creating the trust, there are a few issues that need to be addressed. First, ensure that the system time is synchronized. Because Kerberos will be used for authenticating the trust, the time skew between the two forests must be within five minutes -- or whatever the time skew is set to. The best way to do this is to manually check the system time on the PDC of the root domain of each forest and set both to point to the same external time source. If the time isn't in sync, the trust can be built but operations across it won't work because of authentication failure -- just like with any other time sync issue. The next step is to provide DNS name resolution between the two forests. There are a number of ways to do this. In our scenario, you can configure a secondary zone for ABC.com to be hosted on the Corp.net DNS server, and a secondary zone of Corp.net on the ABC.com DNS server. The same thing could be accomplished using conditional forwarders or even simple forwarding. I prefer defining a conditional forwarder for each domain on the DNS servers in the other domains. Thus, Corp.net would be defined on ABC.com DNS servers and vice versa. After this is accomplished, make sure each domain name can be pinged from a client in the other domain. Finally, both forests must be in Windows Server 2003 forest functional mode. Set all domains to Windows Server 2003 domain functional mode, and then set the forest mode. Creating the trust in Active Directory

You can initiate the trust wizard from either domain, but do it from a DC -- preferably the PDC -- in the root domain of the forest. 1. Go to the Active Directory Domains and Trusts snap-in (domain.msc). In Active Directory Domains and Trusts snap-in, right click the Corp.net domain icon and select Properties. Click on the Trusts tab. This will initiate the New Trust Wizard. Click Next on the welcome screen. 2. In the Trust Name screen, enter the name of the other domain. In this case, we are running the wizard from Corp.net, so we enter ABC.com in this field and click Next. 3. In the Trust Type dialog, shown in Figure 1, you can select External Trust or Forest Trust. The External Trust would be an NTLM type (non-transitive) trust. Select Forest Trust to build a transitive, Kerberos type trust. Keep in mind that if the Forest Trust option is greyed out, the forest functional level has not been set.

Figure 1: You can select External Trust or Forest Trust in the Trust Type dialog. 4. In the Direction of Trust screen, shown in Figure 2, you can select a two-way trust or a one-way outgoing or one-way incoming trust, demonstrating the flexibility of establishing a trust from either domain. In this example, we will create a two-way trust.

Figure 2: In the Direction of Trust screen, you can select a two-way trust or a oneway outgoing or one-way incoming trust 5. When you select a two-way trust, you will be presented with the Sides of Trust dialog. In Figure 3, I selected the option to create both ends of the trust. Following that dialog, an authentication screen is presented to allow entry credentials in the other domain that will permit creation of the trust.

Figure 3: Sides of Trust dialog

6. Next, Figure 4 shows the Outgoing Trust Authentication Level Local Forest. Here we can select Forest Wide Authentication or Selective Authentication. This is the authentication level for the trust going from the local forest to the other (remote) forest. In simple terms, if you select Forest Wide Authentication, the Authenticated Users group in the remote domain will behave as if it were in the Authenticated Users group in the local forest. In other words, wide open. The Selective Authentication option allows administrators in the local forest to grant specific rights for users in the remote domain to local domain resources by group or user account. Forest Wide Authentication is used for a two-forest configuration for one company, while Selective Authentication would be appropriate for an extranet where you want more control of individual resources.

Figure 4: Outgoing Trust Authentication Level Local Forest 7. The ensuing screen is Outgoing Trust Authentication Level Specified Forest. The questions are the same here to allow you to select Forest Wide or Selective Authentication, from the remote forest to the local forest. 8. Next, there is a summary screen reviewing the trust choices. After that, there will be screens asking if you want to confirm the incoming trust and the outgoing trust. Select the "Yes" option to test the trust. 9. Figure 5 shows that we have created a two-way trust to the ABC.com domain.

Figure 5: A two-way trust to the ABC.com domain has been created There you have it. Although this procedure shows the creation of a two-way trust, similar steps would be used to create a one-way. Remember that the system time between the DCs in the two forests must be within the five-minute time skew and name resolution must be maintained. how to modify desktop shortcut with Group Policy? I mean create the icon from scratch by copying a shortcut from a network share So if the shortcut is called MyShortcut.lnk and is stored on \\server\share, you would have copy \\server\share\MyShortcut.lnk "C:\Documents and Settings\%username%" Note the quotes are required to escape the spaces in the target %username% will resolve to the current logged on user Tested from command prompt (and works) but not by script Q: How to create Roaming User Profiles on Windows Server 2003?
A: On your server, create a folder called Profiles and Share it as Profiles$, set share rights as follows:

Administrators Full Control Everyone Change Let's say your server name is Server1. Open Active Directory Users and Computers, open your target users container, double click on the User and click tab Profile. In the field Profile Path type the following: \\Server1\Profiles$\%username% Next time the user logs on, his/her profile folder will be automatically created. Now, if you're using Windows Server 2003, open your Group Policy for the domain or just edit the Default Domain Policy (right click on Domain Name in Active Directory Users and Computers, click Properties, click tab Group Policy and then Default Domain Policy or just edit one of your own), navigate to Computer Configuration\Administrative Templates\System\User Profiles and locate policy called Add the Administrators security group to roaming user profiles, then set it to Enabled.

Assign a home folder to a domain user Note: To specify a network path for the home folder, you must first create the network share and set permissions that permit the user access. You can do this with Shared Folders in Computer Management on the server computer. To assign a home folder to a domain user: Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers. In the console tree, click Users. In the Details pane, right-click the user account, and then click Properties. In the Properties dialog box, click Profile. Under the Home folder, type the folder information. To do this, follow these steps: To assign a home folder on a network server, click Connect, and then specify a drive letter. In the To box, type a path. This path can be any one of the following types: Network path, for example: \\server\users\tester You can substitute username for the last subfolder in the path, for example: \\server\users\username Note In these examples, server is the name of the file server housing the home folders, and users is the shared folder. Click OK. Back to the top Assign a home folder to a local user To assign a home folder to a local user:

Click Start, click Control Panel, double-click Administrative Tools, and then double-click Computer Management. In the console tree, click Users in Local Users and Groups. Click the user account. Click the Action menu, and then click Properties. Click the Profile tab, click Connect, and then specify a drive letter. In the To box, type a path. This path can be any of the following types: Network path, for example: \\server\users\tester You can substitute username for the last subfolder in the path, for example: \\server\users\username Where server is the name of the file server housing the home folders, and where users is the shared folder. Click OK. Back to the top Specify a home folder for a terminal server In Windows Server 2003, you can specify a home folder for a terminal server. Assign each user on a terminal server a unique home folder. This makes sure that you store the program information separately for each user in the multi-user environment. Note: If you specify only the home folder for Windows Server 2003, both Windows 2003 and Terminal Services use this home folder. To specify a home folder for a terminal server, use one of the following procedures. Domain user account Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers. In the console tree, expand the domain node, and then click the Users folder. Double-click the user account. Click the Terminal Services Profile tab. If the Terminal Services home folder is on the local server, click Local path, and then type the path of the profile. Note If you do not specify the location path in the Terminal Service Home folder pane, the default local home folder is located at the following path: system drive\Documents and Settings\username If the Terminal Services home folder is on a network share, click Connect, select a drive to connect, and then type the network path. Click OK. Local user account Click Start, point to Programs, point to Administrative Tools, and then click Computer Management. In the console tree, click Users in Local Users and Groups. Double-click the user account.

Click the Terminal Services Profile tab. If the Terminal Services home folder is on the local server, click Local path, and then type the path of the profile. Note If you do not specify the location path in the Terminal Service Home folder pane, the default local home folder is located at the following path: system drive\Documents and Settings\username If the Terminal Services home folder is on a network share, click Connect, select a drive to connect, and then type the network path. Click OK. Back to the top Assign a home folder to a user from the command line You can use the net user command to assign a home folder to a user from the command line. For example, at the command line, type the following command, and then press ENTER: net user tester /homedir:\\server\tester$ This command assigns the tester$ hidden shared folder on the server to the user Tester. Back to the top Assign a home folder to a user by using a logon script You can automate user account creation and home folder assignment. You can use the net user command to create local user accounts in configuration scripts. Create a logon script The following example creates a user named "tester". The user is created with a comment, password expiration settings, home folder, and profile path configured: NET USER tester /add /comment:"Example Account for User" /expires:never /homedir:\\zippy\%username%$ /profilepath:\\zippy\profile Assign a logon script to a profile To assign a logon script to a profile, follow these steps: Click Start, point to Settings, and then click Control Panel. Double-click Administrative Tools, and then double-click Computer Management. In the console tree, click Local Users and Groups, and then click Users. Click the user account, click Action, and then click Properties. Click Profile, and then type the file name of the script in the Logon script box. Note: For local accounts, the logon script path is %Systemroot %\System32\Repl\Import\Scripts. However, this folder is not created if you perform a clean installation of Windows Server 2003. If the logon script is stored in a subfolder of the domain controller, type the following login script path before the logon script name: