Thursday, September 21, 2006
Need to put the email forwarding from one domain to another
1 Go to Active directory
2 Create one contact from new contact > contact
3 Select the option for create exchange email
4 In modify option > select smtp address
5 Give the new forwarding email address, click ok
6 Right-click the new created contact > property
7 Go to exchange advanced > check the option: Hide from exchange address lists
8 Now go to the user properties from where you want to forward the email to another
email address
9 Exchange general tab > delivery option > click forward to and select the new email
address (contact) & check the option deliver message to both forwarding address and
mailbox
10 Click ok.
2 Create one contact from new contact > contact
3 Select the option for create exchange email
4 In modify option > select smtp address
5 Give the new forwarding email address, click ok
6 Right-click the new created contact > property
7 Go to exchange advanced > check the option: Hide from exchange address lists
8 Now go to the user properties from where you want to forward the email to another
email address
9 Exchange general tab > delivery option > click forward to and select the new email
address (contact) & check the option deliver message to both forwarding address and
mailbox
10 Click ok.
Group policies are not applied the way you expect; "Event ID 1058" and "Event ID 1030" errors in the application log
On your Microsoft Windows XP-based computer, group policies may not be applied as you expect. When you view the application log of the event viewer, you see error data that is similar to the following:
Description: Windows cannot access the file gpt.ini for GPO
CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=lcds,DC=lab
The file must be present at the location \\lcds.lab\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}
(Access is denied) Group Policy processing aborted.
CAUSE
This issue may occur if both of the following conditions are true:
• Your Windows XP-based computer is a member of a domain.
• The Microsoft Distributed File System (DFS) client is turned off.
Note The \\Active Directory Domain Name\Sysvol share is a special share that requires the DFS client to make a connection.
Note This issue may also occur if "Everyone" has been removed from the root drive NTFS file system permissions. If "Everyone" has been removed from the root drive NTFS permissions, restore the "Everyone" group's NTFS permissions on the root folder by granting "Everyone" the special Read and Execute NTFS permissions on the root folder only.
RESOLUTION
To resolve this issue, turn on the DFS client. To do this, follow these steps.
Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
1. Click Start, and then click Run.
2. In the Open box, type regedt32, and then click OK.
3. In the Registry Editor window, locate the following registry key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mup
4. In the right details pane, double-click DisableDFS. The DFS client is turned off if the value in the Value data box is 1.The DFS client is turned on if the value in the Value data box is 0.
5. In the Edit DWORD Value dialog box that appears, type 0 in the Value data box, and then click OK.
6. On the File menu, click Exit to quit Registry Editor.
Additionally, turn on File and Printer Sharing for Microsoft Networks on the interface. To do this, follow these steps:
1. Click Start, point to Connect To, and then click Show all connections.
2. Right-click the appropriate connection, and then click Properties.
3. Click the General tab.
4. Under This connection uses the following items, verify that the check box next to File and Printer Sharing for Microsoft Networks is selected, and then click OK.
Description: Windows cannot access the file gpt.ini for GPO
CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=lcds,DC=lab
The file must be present at the location \\lcds.lab\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}
(Access is denied) Group Policy processing aborted.
CAUSE
This issue may occur if both of the following conditions are true:
• Your Windows XP-based computer is a member of a domain.
• The Microsoft Distributed File System (DFS) client is turned off.
Note The \\Active Directory Domain Name\Sysvol share is a special share that requires the DFS client to make a connection.
Note This issue may also occur if "Everyone" has been removed from the root drive NTFS file system permissions. If "Everyone" has been removed from the root drive NTFS permissions, restore the "Everyone" group's NTFS permissions on the root folder by granting "Everyone" the special Read and Execute NTFS permissions on the root folder only.
RESOLUTION
To resolve this issue, turn on the DFS client. To do this, follow these steps.
Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
1. Click Start, and then click Run.
2. In the Open box, type regedt32, and then click OK.
3. In the Registry Editor window, locate the following registry key:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mup
4. In the right details pane, double-click DisableDFS. The DFS client is turned off if the value in the Value data box is 1.The DFS client is turned on if the value in the Value data box is 0.
5. In the Edit DWORD Value dialog box that appears, type 0 in the Value data box, and then click OK.
6. On the File menu, click Exit to quit Registry Editor.
Additionally, turn on File and Printer Sharing for Microsoft Networks on the interface. To do this, follow these steps:
1. Click Start, point to Connect To, and then click Show all connections.
2. Right-click the appropriate connection, and then click Properties.
3. Click the General tab.
4. Under This connection uses the following items, verify that the check box next to File and Printer Sharing for Microsoft Networks is selected, and then click OK.
MSExchangeAL events 8026 and 8260: Cannot access Address List configuration information
CAUSE
The Recipient Update Service is configured to use a Windows domain controller that was demoted. When the Recipient Update Service tries to query the Windows domain controller for an update, it cannot contact it.
Note This event can also be logged under normal conditions, when the Kerberos ticket for the server temporarily expires. This is especially likely when only one Windows global catalog server is available. Recovery from Kerberos ticket expiration typically occurs very quickly. In this case, the event is not a cause for alarm.
RESOLUTION
If you determine that the issue was caused by the demotion of a Windows domain controller, you can resolve this issue by following these steps:
1. Open Exchange System Manager.
2. Expand the Recipients container, and then click Recipient Update Services.
3. Double-click each Recipient Update Service, and then change the Windows domain controller setting to the new Windows domain controller in the domain.
The Recipient Update Service is configured to use a Windows domain controller that was demoted. When the Recipient Update Service tries to query the Windows domain controller for an update, it cannot contact it.
Note This event can also be logged under normal conditions, when the Kerberos ticket for the server temporarily expires. This is especially likely when only one Windows global catalog server is available. Recovery from Kerberos ticket expiration typically occurs very quickly. In this case, the event is not a cause for alarm.
RESOLUTION
If you determine that the issue was caused by the demotion of a Windows domain controller, you can resolve this issue by following these steps:
1. Open Exchange System Manager.
2. Expand the Recipients container, and then click Recipient Update Services.
3. Double-click each Recipient Update Service, and then change the Windows domain controller setting to the new Windows domain controller in the domain.
Event id 2102 & 9154. Process MAD.EXE (PID=). All Domain Controller Servers in use are not responding:
Msexchange dsaccess components on the exchange server were unable to find the domain controllers suitable for the ldap queries.
This can result in halting the mail flow.
CAUSE:
This issue may occur if the Manage Auditing and Security Log right (SeSecurityPrivilege) was removed for the Exchange Enterprise Servers domain local group on some or all of the domain controllers.
When the first Exchange computer is installed in a domain, or when Exchange Setup is run with the /domainprep switch, the Exchange Enterprise Servers group is given the SeSecurityPrivilege right.
If the SeSecurityPrivilege right is later removed, Exchange computers that use domain controllers in the domain stop working, but not immediately. When Kerberos security refresh intervals expire or Exchange services are restarted on particular servers, the issues become evident.
RESOLUTION
To resolve this issue, use the Policytest.exe utility to check the status of the SeSecurityPrivilege right on all of the domain controllers in a single domain. The Policytest.exe utility is included on the Exchange 2000 installation CD-ROM.
To determine whether or not Exchange 2000 Enterprise server has the SeSecurityPrivilege right on a domain controller:
1. Log on to the domain controller as a domain administrator, and then start the Domain Controller Security Policy console. (By default, the Domain Controller Security Policy console is located on the Start menu in the Administrative Tools group.)
2. Expand Security Settings, and then expand Local Policies. Expand User Rights Assignment, and then open the properties of Manage Auditing and Security Log.
You can grant the SeSecurityPrivilege right directly to Exchange 2000 Enterprise servers, or you can run Exchange 2000 Setup again with the /domainprep switch to grant the SeSecurityPrivilege right automatically.
If you run Setup.exe with the /domainprep switch, you do not interrupt service on existing Exchange computers. Another advantage of this method is that it checks and resets other default rights and group memberships that may also have been changed.
If the Exchange Enterprise Servers group was recently granted the SeSecurityPrivilege right, that change does not take effect until the security policy is refreshed on the domain controller. The time that it takes to refresh the security policy depends on domain topology and configuration. By default, policy replication to other domain controllers occurs within five minutes, and application of the policy change within another five minutes.
Even if a particular domain does not contain any Exchange computers, Exchange computers in other domains may use that domain’s domain controllers. If you want Exchange 2000 to be able to perform global catalog lookups and make Configuration container changes when Exchange uses these domain controllers, the follow these steps for the domain:
1. From the Exchange 2000 installation CD-ROM, run the Setup program with the /domainprep switch (Setup.exe /domainprep). This configures the appropriate groups and rights for cross-domain Exchange communication.
2. In Exchange System Administrator, create a Recipient Update Service for the domain. The Recipient Update Service for each domain is responsible for populating the Exchange Enterprise Servers domain local group with Exchange Domain Servers global groups from other domains. The Recipient Update Service is also responsible for other tasks.
This can result in halting the mail flow.
CAUSE:
This issue may occur if the Manage Auditing and Security Log right (SeSecurityPrivilege) was removed for the Exchange Enterprise Servers domain local group on some or all of the domain controllers.
When the first Exchange computer is installed in a domain, or when Exchange Setup is run with the /domainprep switch, the Exchange Enterprise Servers group is given the SeSecurityPrivilege right.
If the SeSecurityPrivilege right is later removed, Exchange computers that use domain controllers in the domain stop working, but not immediately. When Kerberos security refresh intervals expire or Exchange services are restarted on particular servers, the issues become evident.
RESOLUTION
To resolve this issue, use the Policytest.exe utility to check the status of the SeSecurityPrivilege right on all of the domain controllers in a single domain. The Policytest.exe utility is included on the Exchange 2000 installation CD-ROM.
To determine whether or not Exchange 2000 Enterprise server has the SeSecurityPrivilege right on a domain controller:
1. Log on to the domain controller as a domain administrator, and then start the Domain Controller Security Policy console. (By default, the Domain Controller Security Policy console is located on the Start menu in the Administrative Tools group.)
2. Expand Security Settings, and then expand Local Policies. Expand User Rights Assignment, and then open the properties of Manage Auditing and Security Log.
You can grant the SeSecurityPrivilege right directly to Exchange 2000 Enterprise servers, or you can run Exchange 2000 Setup again with the /domainprep switch to grant the SeSecurityPrivilege right automatically.
If you run Setup.exe with the /domainprep switch, you do not interrupt service on existing Exchange computers. Another advantage of this method is that it checks and resets other default rights and group memberships that may also have been changed.
If the Exchange Enterprise Servers group was recently granted the SeSecurityPrivilege right, that change does not take effect until the security policy is refreshed on the domain controller. The time that it takes to refresh the security policy depends on domain topology and configuration. By default, policy replication to other domain controllers occurs within five minutes, and application of the policy change within another five minutes.
Even if a particular domain does not contain any Exchange computers, Exchange computers in other domains may use that domain’s domain controllers. If you want Exchange 2000 to be able to perform global catalog lookups and make Configuration container changes when Exchange uses these domain controllers, the follow these steps for the domain:
1. From the Exchange 2000 installation CD-ROM, run the Setup program with the /domainprep switch (Setup.exe /domainprep). This configures the appropriate groups and rights for cross-domain Exchange communication.
2. In Exchange System Administrator, create a Recipient Update Service for the domain. The Recipient Update Service for each domain is responsible for populating the Exchange Enterprise Servers domain local group with Exchange Domain Servers global groups from other domains. The Recipient Update Service is also responsible for other tasks.
