Exchange Vampire

Unable to run prepareAD command

2011-05-28T01:52:00.000-07:00

Topology
========
Exchange 2007 SP1 on Windows 2003 SP2

Error
=====
When we run prepareAD command
setup /prepareAD /organizationname:CSXDEV

Configuring Microsoft Exchange Server

Organization Preparation ......................... FAILED

Active Directory operation failed on test.xyz.com. This error is not retriable. Additional information: The object cannot be added because the parent is not on the list of possible superiors.

Active directory response: 00002099: NameErr: DSID-03050EB2, problem 2005 (NAMING_VIOLATION), data 0, best match of: 'CN=Address Lists Container,CN=CSX,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=xyz,DC=com'

Resolution
==========
Renamed the Exchange setup log to ExchanegSetuplogsOld

Checked the properties of the "Address -book-Container" through ADSIEdit under Schema partition and found that "Posssuperiors" attribute was .

Add "msExchConfigurationContainer" in "Posssuperiors" .

Installation of E2K7 SP1 RU8 failing Error 1603

2011-05-28T01:35:00.000-07:00

Topology
========
Exchange 2007 SP1 RU 8

Error
====
Exchange 2007 SP1 RU8 installation is failing with Error 1603
Update Rollup 8 for Exchange Server 2007 Service Pack 1 (KB968012) 8.1.375.2' could not be installed. Error code 1603. Additional information is available in the log file x:\xx.log.

Resolution
==========
Changed to ExecutionPolicy setting to RemoteSigned by running following cmdlet.

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned.

All scripts that are locally created will run. Scripts that are downloaded from remote locations, such as the Internet, that cannot be trusted, will not run. This is the default script execution mode.

Script Security : http://technet.microsoft.com/en-us/library/bb125017.aspx

Setup on Exchange Server 2007 CCR cluster fails.

2011-05-28T01:27:00.000-07:00

Topology
=========
Exchange 2007 Active/Passive CCR Cluster
EVS Name : TestEVS
Node Names : Test1, Test2

Error
=====
1. Error from setup log:

[x/x/xxxx x:xx:xx AM] [1] 0. ErrorRecord: Cluster Common Failure Exception :
Failed to bring cluster resource Network Name (TEST1) in cluster group TEST1
online. Cluster Common Failure Exception : The group or resource is not in the
correct state to perform the requested operation. (Exception from HRESULT:
0x8007139F)

2. Error from system log:

Event ID : 1119
Raw Event ID : 1119
Record Nr. : 8063
Category : Network Name Resource
Source : ClusSvc
Type : Warning
Generated : x/x/xxxx x:xx:xx PM
Written : x/x/xxxx x:xx:xx PM
Machine : TEST1
Message : The registration of DNS name nambx06.corp.adobe.com for resource
'Network Name (TEST1)' over
adapter 'Public' failed for the following reason:DNS bad key.

Event ID : 1196
Raw Event ID : 1196
Record Nr. : 8064
Category : Network Name Resource
Source : ClusSvc
Type : Error
Generated : x/x/xxxx x:xx:xx PM
Written : x/x/xxxx x:xx:xx PM
Machine : TEST1
Message : The required registration of the DNS name(s) associated with Cluster
resource
'Network Name (TEST1)' failed for the following reason:
DNS bad key.

Resolution
==========

1) Dynamic updates were disabled on DNS and had created DNS records
manually for CMS.
2) Open Cluster Administrator, right click and click properties on Network Name
resource under Exchange group.
3) Click on Parameters tab and uncheck “DNS Registration Must Succeed”.
4) Retry setup again.

CCR Cluster: Unable to mount databases

2011-05-28T01:19:00.000-07:00

Topology
=========
Exchange 2007 Active/Passive CCR Cluster
EVS Name : TestEVS
Node Names : Test1, Test2

Unable to mounte databases when Test1 was active node.
For some reason it failover and could not mount the stores and resources for the Storage Group
failed to come online. He had shut down the Test1 node.
All Resources were online on Test1 node except second Storage Group and Third Storage Group.

Event ID
=========
Event Type: Error
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 496
Date: x/x/xxxx
Time: xx:xx:xx AM
User: N/A
Computer: Test1
Description:
eseutil (3456) Database E:\Program Files\Microsoft\Exchange Server\Mailbox\Second
Storage Group\Test1 Mailbox.edb requires logfile F:\Program
Files\Microsoft\Exchange Server\Mailbox\Second Storage Group\e01000xxxxx.log
created at xx/xx/xxxx xx:xx:xx in order to recover successfully. Recovery found
the logfile created at xx/xx/xxxx xx:xx:xx .

Resolution
=============
Both(A/P) copies of Databases were in Dirty shutdown.
Required Logs were present in the respective location.
we have 2 options
To use Restore-StorageGroupCopy command "Restore-StorageGroupCopy "CMS Name\SG name"
To run a soft recover on the passive copy or on the node where the log file was created.
As we had failed in running the command Restore-StorageGroupCopy on the passive node
Ran a soft recovery on the passive node.
Soft recovery was successfull. Databases came in clean shutdown state
Failed over the resources from active to passive, all the resources came online successfully.

Rooms missing from "All Rooms" address list after Move Mailbox

2011-05-25T06:12:00.000-07:00

ISSUE:
======
Exchange 2007\Rooms missing from "All Rooms" address list after Move Mailbox

CAUSE:
======
-In the RTM build of E2k7 there is a known issue that can occur after mailboxes
designated as "Room Mailboxes" are moved between mailbox stores.
-The attribute that identifies the mailbox as a "Room Mailboxes" is changed to the
attribute that represents a "User Mailbox"
-The value for the msExchRecipientDisplayType attribute for an account with a "Room
Mailbox" should be 7
-If this issue occurs after a move mailbox the value for the
msExchRecipientDisplayType attribute is changed to 1073741824 (this is the value
that represents a "User Mailbox".

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

WORKAROUND:
============
-You can verify this issue by using ADSIEdit.msc to view the
msExchRecipientDisplayType attribute for an account with a "Room Mailbox"
-The value should be integer value 7. If you have this issue the value will be
1073741824
-You can correct this issue by using ADSIEdit to change the value for
msExchRecipientDisplayType to 7.
-You can also modify this value in bulk by using ADMODIFY.NET, or using a script.
-After modifying the attribute you may want to speed up the process of making the
rooms visible in the All Rooms Address List by right clicking on it in EMC and
selecting apply. After this, forcing AD Replication may help as well.
-This issue is resolved in SP1 for Exchange 2007.

Unable to add replica of legacy Exchange public folders to Exchange 2007 public folder store

2011-05-25T06:04:00.000-07:00

Error :
==========
"There are no Public folder stores which do not have a replica of this folder"

If we try to run the following Management shell command

Get-PublicFolder -Identity \NON_IPM_SUBTREE -Recurse | Format-List Name

We received following error

"There are multiple MAPI public tree found"

ENVIRONMENT:
=============

2 Exchange Servers
Exchange 2000 server
Exchange 2007 (CAS,HUB,MBX)

RESOLUTION:
============

We noticed that they have Two MAPI public folder tree available in the Org
One for E2K Admin Group and One for E2K7 Admin group
Checked the msExchPFTreeType of the Hierarchy Tree and both set to the value 1
We set the Exchange 2007 MAPI tree we set the value of msExchPFTreeType to Not set.
That made the public folder tree ad NON MAPI tree
Then deleted the public folder from Exchange 2007, then we created new public
folder (Public folder database was with empty data)
We made sure that it is associated with the correct Tree
After that the Exchange 2007 public folder showed in the add replica list, Then we
added the replicas successfully

2011-05-23T04:36:00.000-07:00

You can use NexTags.exe to capture requests and responses between the device, Exchange ActiveSync and Exchange.

To use NexTags:

1. Run Nextags.exe on the server that is running Exchange ActiveSync. This is usually your Front End server if you have one. If you don’t have a Front End server run the utility on your mailbox server.

2. Click on the Options tab and check “Trace output to file”, and in the "File Name" box, specify a filename. The default is c:\massync.log

3. Set "Trim Percentage" to 30%.

4. Set "Limit file size to" to 10MB.

5. To capture logs for all users use * in the "User Names" field. To
Capture the log for individual users, type the user aliases separated by a
semicolon (;).

6. Make sure that the “Do Not buffer” check box is unchecked.

7. Click "Tags", and then click on “Errors”, “Warnings”, or “User” depending on the error you are trying to troubleshoot. You can also click on “Check all”. This logs everything and could impact performance.

8. Click "Enable Tracing".

9. Click "OK".

After you complete this configuration, the Exchange server records all the logging information to the file that you specified on the "Options" tab. This log can be useful to troubleshoot synchronization failures.

When you have finished troubleshooting the issue, make sure you turn off tracing by clicking on “Disable Tracing” and clicking OK .

Enabling SSL password changes for the Web client:Prerequisites

2011-05-23T04:09:00.002-07:00

To prepare for an SSL installation, the following resources are necessary:

• Windows 2000 Active Directory Domain
• Windows 2000 Server running IIS 5.0
Step 1 – Installing the Certification Authority

The first step to installing SSL is to install and configure the Certification Authority (CA), the service which issues and maintains the server certificates. In this lab, the CA will be installed on the Windows 2000 Domain Controller. To install the CA, follow the steps below:

1. Open ‘My Computer’ > ‘Control Panel’ > ‘Add/Remove Programs’
2. Choose ‘Add/Remove Windows Components’
3. Place a check in the box next to ‘Certificate Authority’ and click ‘Yes’ when the warning appears.
4. Click ‘Next’.
5. When prompted for the CA type, choose ‘Stand-alone root CA’

Note: this will differ in actual environments depending on planning and any existing CAs.

6. Complete the ‘CA Identifying Information’ dialog with information specific to your environment and click ‘Next’. Example information, that can be used for testing is below:

7. Verify the ‘Data Storage Location’ is suitable for your server and click ‘Next’.
8. Click ‘Ok’ when warned that IIS services will be stopped and click ‘Finish’ when setup has completed copying files.

Step 2 – Generating a certificate request
The next step is to request a certificate for the web server. This is done from the server that will have MMIS v1.5 installed on it. To request a certificate, follow the steps below:

1. Click on ‘Start’, ‘Programs’, ‘Administrative Tools’ and open the ‘Internet Services Manager’ MMC snap-in.
2. Expand the server name, right-click on ‘Default Web Site’, and choose ‘Properties’.
3. Select the ‘Directory Security’ tab and click ‘Server Certificate’.
4. Click ‘Next’ to begin the wizard and choose ‘Create a new certificate’ and click ‘Next’.
5. Choose ‘Prepare the request now, but send it later’ and click ‘Next’.
6. Click ‘Next’ to accept the default values on the ‘Name and Security Settings’ dialog.
7. On the ‘Organization Information’ dialog, enter a name and organizational unit for your certificate and click ‘Next’.
8. Enter the FQDN of your server on the next dialog (for example, mmis.domain.com) and click ‘Next’.
9. Enter the country, state/province and city/locality that your server is located in and click ‘Next’ (for state/province, standards suggest you do not abbreviate but rather spell out the name, such as Washington, as opposed to WA).
10. Specify where you would like the request saved, and click ‘Next’, then ‘Next’ again and ‘Finish’ completing the request generation.

Step 3 – Submitting the certificate request

The next step is to submit the certificate request to the CA that was created in Step 1. This is also done from the server that will have MMIS v1.5 installed on it. To submit the request, follow the steps below:

1. Start Internet Explorer and enter the following URL (replace ‘CAserver’ with the name of the server the Certification Authority was installed on), http://CAserver/certsrv.
2. Choose ‘Request a certificate’ and click ‘Next’.
3. Select ‘Advanced request’ and click ‘Next’.
4. Choose the second option, ‘Submit a certificate request using a base64 encoded PKCS #10 file or a renewal request using a base64 encoded PKCS #7 file.’ and click ‘Next’.
5. Open the file that was saved in #10 in the previous step using Notepad (by default, this file is C:\certreq.txt). It will appear similar to below:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIICnjCCAkgCAQAwgY0xIzAhBgNVBAMTGm1vYmlsZS1tbWlzLm1vYmlsZWNvcnAu
Y29tMRcwFQYDVQQLEw5XaXJlbGVzcyBHcm91cDETMBEGA1UEChMKTW9iaWxlY29y
cDESMBAGA1UEBxMJQ234ahcmxvdHRlMRcwFQYDVQQIEw5Ob3J0aCBDYXJvbGluYTEL
MAkGA1UEBhMCVVMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAz+nnFAupbS2PIkcE
zu+nl1kAwxtz60eF/I+HZO/Mo6ztWrhBu4iQVmYLQYh9uE3PHGRIB+YwGII38jKp
IgmniwIDAQsfdsUzAaBgorBgEEAYI3DQIDMQwWCjUuMC4yMTk1LjIwNQYKKwYB
BAGCNwIBDjEnMCUwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMB
MIH9BgorsdfeEEAYI3DQICMYHuMIHrAgEBHloATQBpAGMAcgBvAHMAbwBmAHQAIABS
AFMAQQAgAFMAQwBoAGEAbgBuAGUAbAAgAEMAcgB5AHAAdABvAGcAcgBhAHAAaABp
AGMAIABQAHIAbwB2AGkAZABlAHIDgYkAjuYPzZPpbLgCWYnXoNeX2gS6nuI4osrW
HlQQKcS67VJclhELlnT3hBb9Blr7I0BsJ/lguZvZFTZnC1bMeNULRg17bhExTg+n
UovzPcJhMvG7G3DR17PrJ7V+egHAsQV4dQC2hOGGhOnv88JhP9Pwpso3t2tqJROa
5ZNRRSJSkw8AAAAAAAAAADANBgkqhkiG9w0BAQUFAANBAFD/X5SZwqMG8hbPGYNS
LVZvbmL8H1hbiRqYkeoYPghq2XfQre/ifA+zaMAl1rdQMVMGl9CrW/a5e02gRaUb
nko=
-----END NEW CERTIFICATE REQUEST-----

6. Select the text after the first line through to the end of the request (do not include the beginning and ending comments, then paste that text into the field labeled ‘Base64 encoded Certificate Request’ and click ‘Next’.

The request has now been submitted and is awaiting approval from the Certificate Authority. This is covered in the next section.

Step 4 – Issue the requested certificate

The next step is to issue the requested certificate. This is done on the machine that is running the Certification Authority. To issue the certificate, follow the steps below:

1. Click on ‘Start’, ‘Programs’, ‘Administrative Tools’ and open the ‘Certification Authority’ MMC snap-in.
2. Expand the name of the CA in the left window pane and select the ‘Pending Requests’ folder. The pending certificate request will appear in the right pane.
3. Right-click on the pending request, select ‘All Tasks’ followed by ‘Issue’ to issue the certificate.

The certificate has now been issued and it must be installed on the web server.

Step 5 – Installing the certificate

Now the certificate will be installed on the server that will run MMIS v1.5. To do so, from the member server running IIS 5.0, follow the steps below:

1. Start Internet Explorer and enter the following URL (replace ‘CAserver’ with the name of the server the Certification Authority was installed on), http://CAserver/certsrv.
2. Click ‘Check on a pending certificate’ and click ‘Next’.
3. Select the certificate request that was made in Step 3, and click ‘Next’.
4. Click ‘Download CA certificate’ and when prompted, save the certificate locally on the server, then close Internet Explorer.
5. Click on ‘Start’, ‘Programs’, ‘Administrative Tools’ and open the ‘Internet Services Manager’ MMC snap-in.
6. Expand the server name, right-click on ‘Default Web Site’, and choose ‘Properties’.
7. Select the ‘Directory Security’ tab and click ‘Server Certificate’ and click ‘Next’ to begin the wizard.
8. Choose ‘Process the pending request and install the certificate’ and click ‘Next’.
9. Browse to the location of the saved certificate, select it and click ‘Open’ followed by ‘Next’.
10. The certificate information will appear, click ‘Next’ to install the certificate and ‘Finish’ to complete the wizard.

That completes the certificate installation. To test, navigate to https://localhost and verify that SSL is working correctly.

Note: You may be prompted with a warning that the certificate name does not match the server name. This appears because of the way the server name was entered on the certificate request. If you entered an FQDN, the warning will not appear if you enter the URL as an FQDN as is the case when a NetBIOS name is specified in the certificate request.

Enabling SSL password changes for the Web client:

2011-05-23T04:09:00.001-07:00

1. In ISM for each front-end server, create IISADMPWD virtual directory and map it to
drive:/WINNT/System32/inetsrv/iisadmpwd

2. Ensure that IISADMPWD directory has Anonymous Access (other auth types may be selected, but Anonymous must be one of them).

3. Ensure the Metabase setting PasswordChangeFlags is set to 0. *If you change the 1 to 0, then you can only use https://; otherwise either method will work...

cd c:\inetpub\adminscripts
adsutil set w3svc/passwordchangeflags 1

0 - requires password change by SSL
1 - allows password change by non-secure ports
2 - disables password changes
3 - undocumented but disabled
4 - disables advance notification of expiration

Troubleshooting Trusts

2011-05-23T04:05:00.003-07:00

Trust between a Windows NT domain and an Active Directory domain cannot be established or it does not work as expected - http://support.microsoft.com/default.aspx?scid=kb;en-us;889030

A very complete guide to troubleshooting almost every kind of Trust issue. Don't let the title fool you, this is very applicable to external (legacy NTLM) trusts between forests as well in 2000 and 2003.

How to configure a firewall for domains and trusts - http://support.microsoft.com/default.aspx?scid=kb;en-us;179442

A very common support case here; because trusts are not always well-understood, this article gives a matrix-based listing of all port requirements for trusts.

How to establish trusts with a Windows NT-based domain in Windows 2000 - http://support.microsoft.com/default.aspx?scid=kb;en-us;308195

A brief guide to the actual step-by-step process of creating and verifying trusts between domains.

Troubleshooting trusts - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/ad02d816-aac3-4f13-b771-39ebe7e3a5ee.mspx

A guide to the most common trust-related issues and how to quickly fix them. This is great to have in your backpocket, as it's a difficult guide to find.

Domain and Forest Trusts Technical Reference - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/b6284369-73ea-4d68-a3a5-975a0fe6782d.mspx

Finally, an architectural guide to how trusts work, with explanatory diagrams. Understanding how the entire trust system operates is often very important to resolving issues with it.

Troubleshooting DNS in regards to AD

2011-05-23T04:05:00.001-07:00

Troubleshooting DNS in regards to AD

While not directly related to your case, I wanted to provide some good information on general DNS troubleshooting, especially in regards to Active Directory. These systematic steps can save time (and a possible new case) when trying to isolate what DNS issue is affecting Active Directory. Statistically speaking, roughly 75% of our cases here in DS support have a root cause in DNS issues, so understanding all the pitfalls can be very useful.

Troubleshooting Active Directory—Related DNS Problems - http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/opsguide/part1/adogd10.mspx

This article covers understanding the symptoms of DNS issues in Active Directory and how to track down their root causes step-by-step. It explains the DNS SRV record requirements, includes useful tools with syntax, and goes into likely event log messages that will point you in the right direction for repairing DNS.

Troubleshooting Domain Name System Problems - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/bca4b6fe-d6a6-45cc-a433-86948b178f2f.mspx

A more general guide to troubleshooting DNS issues, but still very applicable to AD. Sometimes the simplest answers are the best ones, naturally.

DNS Server becomes an island when a domain controller points to itself for the _msdcs.ForestDnsName domain - http://support.microsoft.com/default.aspx?scid=kb;en-us;275278

A very common issue explained; how DNS islanding occurs and how to prevent it from crippling domain controllers.

DNSLint utility - http://support.microsoft.com/default.aspx?scid=kb;en-us;321045

The simplest method of using DNSLINT is to verify DNS records for domain controllers. To do this, run:

DNSLINT /AD IP of dc you want to check /S IP of DNS server authoritative for MSDCS subzone

This will run and generate an HTML-based report of records on this DNS server for AD, confirming that CNAME records match up with A records. The easiest way to interpret the results is to scroll to the very bottom of the page and look at the summary report - any warnings or errors will be noted. All issues in the body of the report are color-coded for easy viewing as well. It also has the /QL functionality in order to check SRV records and the like.

The tool also has some useful extra features, like /C (used to test ports on email servers), /T (used to create TXT output instead of HTM), and /NO_OPEN which prevents the HTM file from being loaded. Using these commands together means that you can very simple script a batch file which can be used to easily spot check the overall health of your DNS in regards to AD - very useful.

Some good further info on the tool:

How To Use DNSLint to Troubleshoot Active Directory Replication Issues - http://support.microsoft.com/default.aspx?scid=kb;en-us;321046
Finally, a brief explanation of using DNSLint to determine why replication is failing between multiple DC's.
AD Replication Troubleshooting

While not precisely related to your case, I wanted to provide some further information on general troubleshooting of AD Replication issues in domains and forests. The steps and tools below can be used to detect and repair the most common replication issues, and may save you a support call someday. I hope you find these useful!
Troubleshooting Active Directory Replication Problems - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/4f504103-1a16-41e1-853a-c68b77bf3f7e.mspx

A good general guide to deciding how to approach replication failures and break the problem down into its component pieces. It also covers the REPADMIN tool which will be instrumental in seeing error codes that drive how the troubleshooting is done.

Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/43e6f617-fb49-4bb4-8561-53310219f997.mspx

The most common cause of replication failure is DNS lookup issues (where we are unable to resolve CNAME records to servers in order to complete the replication ring). This guides an admin through systematically tracking down replication issues caused by DNS, and what sorts of errors mean specific conditions. In Windows Server 2003 SP1 this has been mitigated to some extent, and this is covered in detail in the above article.

Fixing Replication Connectivity Problems (Event ID 1925) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/7fcaa311-bc19-479d-9a4e-179704dfe08f.mspx

A step-by-step guide to determining replication issues caused by network problems (not related to DNS). This covers simple initial tests like PING and PING -L then moves on to more advanced steps like network tracing.

Fixing Replication Topology Problems (Event ID 1311) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/062e8eaa-27e0-4c5e-bc2b-2913ecce24b8.mspx

This article covers replication issues caused by issues in the overall site topology, where there is insufficient physical connectivity to complete the replication ring. This means that replication would work fine if the DC's sites and connections were configured more optimally, and there are no other underlying connectivity issues with DNS or the network itself.

How the Active Directory Replication Model Works - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/1465d773-b763-45ec-b971-c23cdc27400e.mspx

Finally, I wanted to provide more detailed information on how replication actually works. With an understanding of the system and how it operates, it becomes much easier to see where issues are and how to approach troubleshooting them. This guide goes into great detail on USN's, consistency, change notification, scheduling, linked values, and all the other pieces that make up this complex system.

AD Replication Troubleshooting

2011-05-23T04:04:00.001-07:00

AD Replication Troubleshooting

While not precisely related to your case, I wanted to provide some further information on general troubleshooting of AD Replication issues in domains and forests. The steps and tools below can be used to detect and repair the most common replication issues, and may save you a support call someday. I hope you find these useful!
Troubleshooting Active Directory Replication Problems - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/4f504103-1a16-41e1-853a-c68b77bf3f7e.mspx

A good general guide to deciding how to approach replication failures and break the problem down into its component pieces. It also covers the REPADMIN tool which will be instrumental in seeing error codes that drive how the troubleshooting is done.

Fixing Replication DNS Lookup Problems (Event IDs 1925, 2087, 2088) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/43e6f617-fb49-4bb4-8561-53310219f997.mspx

The most common cause of replication failure is DNS lookup issues (where we are unable to resolve CNAME records to servers in order to complete the replication ring). This guides an admin through systematically tracking down replication issues caused by DNS, and what sorts of errors mean specific conditions. In Windows Server 2003 SP1 this has been mitigated to some extent, and this is covered in detail in the above article.

Fixing Replication Connectivity Problems (Event ID 1925) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/7fcaa311-bc19-479d-9a4e-179704dfe08f.mspx

A step-by-step guide to determining replication issues caused by network problems (not related to DNS). This covers simple initial tests like PING and PING -L then moves on to more advanced steps like network tracing.

Fixing Replication Topology Problems (Event ID 1311) - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/Operations/062e8eaa-27e0-4c5e-bc2b-2913ecce24b8.mspx

This article covers replication issues caused by issues in the overall site topology, where there is insufficient physical connectivity to complete the replication ring. This means that replication would work fine if the DC's sites and connections were configured more optimally, and there are no other underlying connectivity issues with DNS or the network itself.

How the Active Directory Replication Model Works - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/1465d773-b763-45ec-b971-c23cdc27400e.mspx

Finally, I wanted to provide more detailed information on how replication actually works. With an understanding of the system and how it operates, it becomes much easier to see where issues are and how to approach troubleshooting them. This guide goes into great detail on USN's, consistency, change notification, scheduling, linked values, and all the other pieces that make up this complex system.

AdminSDHolder

2011-05-23T04:03:00.002-07:00

Description and Update of the Active Directory AdminSDHolder Object - http://support.microsoft.com/default.aspx?scid=kb;en-us;232199

AdminSDHolder is specifically designed to protect members of built-in administrative groups. These accounts are deemed security-sensitive, and so the AdminSDHolder runs once per hour to make sure the ACLs for those accounts are set to system defaults. This can cause problems because of the method that the AdminSDHolder uses to determine which accounts are protected – it works on the basis of group memberships, including nested groups.

As an example, if you have a group called CorpHelpDesk, and CorpHelpDesk is a member of CorpAccountOps, which is in turn a member of the Account Operators built in group, then AdminSDHolder will apply changes to all the members of CorpHelpDesk based on the nested group membership.

Delegated permissions are not available and inheritance is automatically disabled - http://support.microsoft.com/default.aspx?scid=kb;en-us;817433

How to workaround issues with AdminSDHolder, as well as hotfixes for 2000 and 2003 to resolve permission delegation issues.

AdminSDHolder Object Affects Delegation of Control for Past Administrator Accounts - http://support.microsoft.com/default.aspx?scid=kb;en-us;306398

How to work around an issue within Windows 2000 where removal of a user from a protected group does not reset the 'allow inheritable permissions' attribute from the object, leading to help desk users not being able to manage those accounts.

Best Practices for Delegating Active Directory Administration - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/activedirectory/actdid3.mspx

An excellent article on Delegation and how to best leverage the technology for common administrative tasks. The article goes into how the technology actually works, recommendations on using it effectively, and common pitfalls that can be avoided.

How Security Principals Work - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/6375943b-1089-4ec5-9b2d-823b884ec1ec.mspx

Finally, an architectural guide to Security Principals in Windows 2000/2003. Covers the well-known SID's, the purpose of the individual built-in accounts, group types, the built-in groups, and much more.

Configuring and Troubleshooting Firewalls with DS

2011-05-23T04:03:00.001-07:00

Configuring and Troubleshooting Firewalls with DS

Based on our previous discussions, I wanted to provide you with good information on configuring and troubleshooting firewalls to work with Active Directory. Understanding and using this documentation will likely save you from issues down the road, as Firewalls require considerable tuning to work with AD and are a frequent call generator here due to configuration issues. I hope you find this useful!

How to configure a firewall for domains and trusts - http://support.microsoft.com/default.aspx?scid=kb;en-us;179442

A brief matrix of the standard port requirements for NT, 2000, and 2003 directory services. Some of these ports can be modified further with the articles below, specifically to control RPC traffic.
Active Directory Replication over Firewalls - http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/confeat/adrepfir.mspx

An extensive guide to configuration of a firewall for AD replication. Includes examples and step by step sections, as well as background information on the process. This also includes details on using IPSEC to ensure that the communication is more secure.

How to configure RPC dynamic port allocation to work with firewalls - http://support.microsoft.com/default.aspx?scid=kb;en-us;154596

Information on the registry values that can modified to allow more controlled use of RPC through a firewall. the article also gives some recommendations on the minimum number of ports to keep open to prevent possible RPC endpoint exhaustion.

How to configure RPC to use certain ports and how to help secure those ports by using IPsec - http://support.microsoft.com/default.aspx?scid=kb;en-us;908472

A more advanced version of the 154596 article, which includes more information on using IPSEC along with the RPCcfg tool. Again, it is important to use caution when restricting RPC on domain controllers, as they use far more connections than an average machine and can be crippled by overzealous firewall administration.

You experience a long delay when you log on to a domain through a NAT server - http://support.microsoft.com/default.aspx?scid=kb;en-us;843427

A short and sweet article which explains why you cannot use NAT between DC's, or clients and DC's, without crippling Kerberos. One of the core elements of Kerberos is that it (by default) packages the originating computer IP addresses in its packets, and NAT will lead to the KDC believing there is a packet spoofing attack going on.

Some firewalls may reject network traffic that originates from Windows Server 2003 Service Pack 1-based computers - http://support.microsoft.com/default.aspx?scid=kb;en-us;899148
Finally, an article on changes to RPC in Windows Server 2003 SP1 and the impact it can have if your firewall software is out of date, along with workarounds that can be put in place in the meantime.

FSMO Roles and GC Explanation

2011-05-23T04:02:00.000-07:00

What are Operations Masters? - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/6a773f69-e153-4460-9a9b-014e98110bab.mspx

Because AD operates in a Multi-Master environment, FSMO roles are used for specific components and functions that must be centralized and managed. They also (like in the case of the PDC Emulator) often have functions designed for legacy compatibility with older operating systems like NT and Win9X. This article gives a good overview of these pieces, what their dependencies are, and what they mean to you as an admin.

How Operations Masters Work - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/795229a5-8a74-4edb-a2f4-d5794d31c2a7.mspx

A complete breakdown (per role) of how each of the 5 roles (RID, PDCE, Domain Naming, Schema, and Infrastructure) operate in practical terms, and how they should be managed.

What Is the Global Catalog? - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/24311c41-d2a1-4e72-a54f-150483fa885a.mspx

An excellent explanation of GC's and what they do in a domain environment. Many systems (like Exchange) rely on this special virtual partition, and certain functional modes (starting with 2000 Native Domain) raise the need for this as well.

How the Global Catalog Works - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/440e44ab-ea05-4bd8-a68c-12cf8fb1af50.mspx

A lengthy treastise on the 'under the covers' workings of GC's, what the default settings are, how it's populated and updated, and other elements important to troubleshooting issues.

Global Catalog Tools and Settings - http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/0d34c3b9-499b-41d3-a55f-527ce61e7858.mspx

Finally, the tools that can be used to monitor and manipulate GC's (DSSITE, LDP, ADSIEDIT, and REPADMIN), plus the various registry values important to the GC system, especially for Universal Group caching in 2003.

Finding Public Folders

2011-05-20T13:57:00.000-07:00

Just as you must configure virtual directories for mailboxes, you must also configure virtual directories for each of the public folder trees that are to be accessible over HTTP through the front-end server.
When you install Exchange, a virtual directory called "public" is created under the default Exchange HTTP virtual server to allow access to the default (MAPI-accessible) public folder tree. When you create other public folder trees (for example, to host applications), you must also create virtual directories in Exchange System Manager to expose these trees over HTTP. Identical virtual directories must exist on each front-end server and on all back-end servers that host the public folder tree.
A request made to a URL in a public folder tree is handled differently when accessing the default (or MAPI-accessible) public folder tree than when accessing general-purpose public folders (also known as application Top-Level Hierarchies [TLH], or non-MAPI TLHs).
In both cases the goal for accessing public folders is twofold:
• For availability If data exists in an Exchange 2000 Server or Exchange Server 2003 public folder somewhere in the Exchange organization and is accessible over HTTP, it is available to the user.
• For consistency As long as the server is available and the user is authenticated, the same public folder server services every request from that user. For authenticated users, ensuring that they go to the same public folder server means that they see the same data every time that they access the public folder trees through the front-end server (including status of read and unread messages, which is stored on individual servers and is not replicated between public folder servers). The fact that users always reach the same back-end server is also important for server-based applications that maintain session state, such as some built with Active Server Pages (ASP).
Public Folder Referrals
In Exchange, you can configure public folder replication on a per-folder basis. The actual public folder tree hierarchy is available on all Exchange public folder servers in the organization, but the contents of each folder may not be. This information is not stored in Active Directory but is maintained as a property on each folder in the public folder store. Therefore, special handling is required when the back-end server selected by the front-end server does not contain the contents of the folder requested by the client.
The following figure illustrates how public folder referrals travel through a front-end server.

1. An HTTP client authenticates against the front-end server and requests /public/PublicFolder2.
2. The front-end server authenticates the user against Active Directory and requests the location of the user's default public folder store.
3. Active Directory indicates to the front-end server that the user's default public folder store is on Server1.
4. The front-end server sends the client request to Server1.
5. Server1 tells the front-end server that it does not have the contents of /public/PublicFolder2, but Server2 and Server3 do.
6. The front-end server performs a hashing algorithm against the list of servers with the content (in this case, Server2 and Server3). The results of the hash in this case turn out to be Server2, so the front-end server forwards the request to Server2.
Note:
A hashing algorithm applies a given number (in this case, the user's security token) and uses it to generate a position in a list so that the distribution of all possible inputs is even over the list.
7. Server2 returns the contents of /public/PublicFolder2 to the front-end server, which then sends the contents to the HTTP client.

Enabling the "Change Password" Feature

2011-05-20T13:56:00.000-07:00

If you are using Outlook Web Access, you can enable the Change Password feature in IIS to:
• Alert users when their passwords expire.
• Enable users to use the Options button in Outlook Web Access to change their passwords.
Keep in mind that if you want to use the Change Password feature, you must also use SSL between clients and the front-end server to secure the password during transmission. Additionally, you must create a virtual directory named IISAdmPwd on the front-end server and back-end servers to handle the Change Password requests.
Note:
The only time you must require SSL on a back-end server is when you want users to be able to connect to the back-end server directly. Remember, however, that front-end servers cannot use SSL when connecting to back-end servers. Therefore, if you require SSL on the back-end server, ensure that you do not require SSL on the following directories so that front-end servers can still connect to them: Exchange, Public, ExchWeb, Exadmin, and any mailbox or public folder virtual roots.
For more information about how to configure the Change Password feature, see Microsoft Knowledge Base article 327134, "XCCC: HOW TO: Use the Change Password Feature in Outlook Web Access."
For more information about how to configure SSL, see Helping to Secure Communication: Client to Front-End Server.

Logging on to Outlook Web Access

2011-05-20T13:54:00.000-07:00

Users can log on to Outlook Web Access using either implicit logon or explicit logon.
Implicit Logon
If the front-end server is configured to authenticate users, users can access their mailboxes by omitting the username from the request, and pointing their browser to their mailbox virtual directory. The usual URL is https:///exchange/. After authenticating the user, the authentication information is used to look up the mailbox associated with the user in Active Directory and the back-end server on which the mailbox is located. The URL is updated with the user name and sent to the correct back-end server. This is known as implicit logon. Implicit logon is useful only for logging on to Outlook Web Access; specialized HTTP clients generally do not use implicit logon.
Exchange 2000 Server SP3 and Exchange Server 2003
Implicit logon makes use of the SMTP domain specified on the HTTP virtual directory to identify the user. Therefore, users connecting to that virtual server must have an e-mail address in their list of SMTP proxy addresses on their object in Active Directory with the same domain.
Exchange Server 2003 SP1
Implicit logon no longer relies exclusively on the SMTP domain specified. All the user information can be gleaned from their logon. Users can use any mailbox Exchange virtual directory to access their e-mail messages.
Explicit Logon
There are a few URLs that users can use to connect to Outlook Web Access. The usual URL is https:///exchange//.Accessing Outlook Web Access using this URL is referred to as explicit logon.
Explicit logon must be used when the front-end server is not configured to authenticate users (for more information about authentication, see Authentication Mechanisms for HTTP) or when a user is attempting to access a mailbox that is not their own but to which they have access, for example, in the case of delegate users.
Exchange 2000 Server SP3 and Exchange Server 2003
When the front-end server receives an explicit logon request from a client, the user name is extracted from the URL and combined with the SMTP domain name associated with the virtual directory or virtual server to construct a fully qualified SMTP address. The front-end server looks up this address in Active Directory and determines which back-end server has the mailbox associated with the address. The front-end server then forwards the request to that back-end server, which processes the request and returns it back through the front-end server to the client.
Exchange Server 2003 SP1
The user can choose to override the SMTP domain configured on the mailbox virtual directory, by specifying the SMTP address in the URL itself. For example; https:///exchange/username@domain.com. If no SMTP domain is specified, the SMTP domain from the virtual directory will be used.
You can prevent specific users from accessing Outlook Web Access by disallowing the HTTP protocol for those users. To change a user's protocol settings, in Active Directory Users and Computers, use the Exchange Advanced tab in a user's properties.
Simplifying the Outlook Web Access URL
Users commonly request that a simpler URL be made available for accessing their mailbox. For detailed instructions on simplifying the Outlook Web Access URL, see How to Simplify the Outlook Web Access URL

Finding User Mailboxes

2011-05-20T13:53:00.000-07:00

To provide access to mailbox folders through HTTP, you must have a virtual directory on both the Exchange front-end and back-end servers that points to the mailboxes.
Note:
User mailboxes cannot be stored on the front-end server.
When you install Exchange, a virtual directory named "Exchange" is created in the default virtual server. This directory points to the default SMTP domain for the Exchange organization. When you configure additional virtual directories on the front-end server through Exchange System Manager, you can select the SMTP domain name. In Exchange 2000 Server SP3 and Exchange Server 2003, users connecting to that virtual server must have an e-mail address in their list of SMTP proxy addresses on their object in Active Directory with the same domain. In Exchange Server 2003 SP1, users can override the SMTP domain by specifying the SMTP address in the URL (for explicit logon), or just use an implicit logon. For more information see "Logging on to Outlook Web Access" later in this topic.
In the dialog box where the SMTP domain is selected, the list of domains is a list of all domains for which there are recipient policies. Therefore, you might see duplicates in the list; it is not important which one you select.
When the front-end server detects a request to a location in the mailbox store (based on the setting of the virtual server or directory), it contacts an Active Directory global catalog server in the domain using Lightweight Directory Access Protocol (LDAP) and determines which back-end server contains the user's mailbox.

Supporting HTTP Access

2011-05-20T13:52:00.000-07:00

Whether generated by a browser or a specialized client, HTTP requests from the client computer are sent to the front-end server. The front-end server uses Active Directory to determine which back-end server to proxy the request to.
After determining the appropriate back-end server, the front-end server forwards the request to the back-end server. Apart from specific header information that indicates the request was passed through a front-end server, the request is almost the same as the original request sent from the client. In particular, the HTTP host header, which matches the name of the front-end server to which the request was sent (meaning the hostname or fully qualified domain name that the user entered in the browser), remains unchanged. The front-end server contacts the back-end server using the hostname of the back-end server (for example, backend1), but in the HTTP headers of the request, the front-end server sends the host header used by the client, for example, www.adatum.com. The host header setting ensures that the appropriate back-end Exchange virtual server handles the request. For more information about configuring virtual servers on a back-end server, see Configuring a Back-End Server.
For HTTP requests, the front-end server always contacts the back-end server over TCP port 80 (the default HTTP port), regardless of whether the client contacted the front-end server through port 80 or 443 (the SSL port). This means that:
• HTTP virtual servers on the Exchange front-end server can listen only on port 80 (HTTP) or 443 (HTTPS).
Note:
No other ports other than port 80 and port 443 can be used for HTTP virtual servers on the Exchange front-end servers.
• SSL encryption is never used between the front-end and back-end servers, although the client should use it to communicate with the front-end server.
• HTTP virtual servers that differentiate themselves from other servers only by port number are not supported in a front-end and back-end topology. For example, if a back-end server has an HTTP virtual server listening on port 8080, a client can access that back-end server only if the client is pointed directly to the back-end server (for example, http://backend1:8080/data). A client connecting to the front-end server cannot access this data.
The back-end server processes the HTTP request from the front-end normally, and the response is sent unchanged through the front-end server back to the client. This whole process is not visible to the client, which just interacts with the front-end server. The client is unaware of how the request was handled internally.

Running SMTP for POP and IMAP Clients

2011-05-20T13:51:00.002-07:00

POP and IMAP protocols are used only for receiving mail; you must configure SMTP on the front-end server so that POP and IMAP clients can submit mail. You do not have to run SMTP on the Exchange front-end server. Instead, you can use another server as a dedicated SMTP gateway.
Important:
To run SMTP on the front-end server and enable it to accept inbound mail (mail for your domains), you must mount a mailbox store on the front-end server. This mailbox store must not contain any mailboxes. You must mount a mailbox store on the front-end server because any non-delivery reports (NDRs) must be routed through the mailbox store for formatting.
To configure SMTP so that POP and IMAP clients can submit mail to external domains, you must allow relaying.
By default, Exchange allows relaying only from authenticated clients. It is recommended that you keep this default. Clients such as Microsoft Outlook Express 6.0 and Microsoft® Office Outlook® 2003, and previous versions of Outlook Express and Outlook support SMTP authentication in addition to Transport Layer Security (TLS) encryption.
You should not allow relaying in either of the following ways:
• You should not allow anonymous relaying to all IP addresses; if your front-end server is connected to the Internet, doing this allows anyone on the Internet to use your server to send mail.
• You should not allow relaying from specific client IP addresses. Even if you are familiar with the subnet from which clients send mail, the Internet environment makes it difficult to determine such a specific set of IP addresses.
Note:
If you want the front-end server to act as the bridgehead server between your company and the Internet, it is recommended that the server on the Internet that accepts mail for your domains has the ability to scan incoming messages for viruses.
Note:
For more information, see the Exchange technical guide, Exchange Server 2003 Transport and Routing Guide.

IMAP Access to Public Folders

2011-05-20T13:51:00.001-07:00

When a non referral-enabled IMAP client connects to a back-end server, it can access only public folders that have a replica on the user's home server. To access public folders that have replicas on other servers, an IMAP client must be referral-enabled. A referral-enabled client issues special commands to an IMAP server to create a list of the public folders available to the client. When the client computer requests a public folder that does not have a local replica, the server responds to the client request with a referral URL that contains the name of the server that has the public folder. The referral-enabled IMAP client computer then creates a new connection to that server to retrieve the appropriate information.
In a front-end and back-end topology, however, the front-end server acts as a referral-enabled client, so IMAP clients connecting to the front-end server do not need to support referrals; the front-end server handles referrals for them. It transparently maps non referral-enabled client requests to their referral counterparts, making the entire list of public folders available to a non referral-enabled client. When the front-end server receives a referral response from the back-end server, it does not pass this response back to the client. Instead it follows the referral for the client and makes a connection to the appropriate back-end server that has the data. The back-end server then responds with the requested item, which the front-end server relays back to the client.

Authentication for POP and IMAP Clients

2011-05-20T13:50:00.001-07:00

POP and IMAP e-mail clients send user and password information in clear text. If the front-end server is accessible from the Internet, you should configure SSL so that user authentication information and data is not passed over the Internet in clear text.

Supporting POP and IMAP Clients

2011-05-20T13:49:00.000-07:00

When you use a front-end server, the names of the servers that host the mailboxes are hidden from the users. Client computers connect to one host name shared by the front-end servers. As a result, moving users between servers is transparent to the users and requires no reconfiguration of client computers.
To log on, a POP or IMAP client sends the front-end server a logon request that contains the name of the mailbox to be accessed. The front-end server authenticates the user and uses Active Directory to determine which back-end server contains the user's mailbox. The front-end server then proxies the logon request to the appropriate back-end server. The back-end server then sends the results of the logon operation back to the front-end server, which returns the results of the operation back to the client. Subsequent POP or IMAP commands are similarly handled.
Note:
SMTP must be available to allow POP and IMAP clients to submit e-mail. You can install SMTP on the front-end server or set up a separate SMTP server. E-mail submission through SMTP on the front-end server works the same as it does on any other server running Exchange. For more information about how to configure SMTP on a front-end server, see Configuring Exchange Front-End Servers.

System Attendant on Front-End Servers

2011-05-20T13:48:00.000-07:00

By default, Exchange System Attendant no longer requires RPCs when it runs on a front-end server. The components of System Attendant that use RPCs are no longer loaded on front-end servers; therefore, these components are disabled when you designate a server as a front-end server. The following list briefly describes these components:
• DSProxy
The DSProxy service refers MAPI clients (such as Microsoft® Office Outlook® 2002) to global catalog servers for global address list lookups. DSProxy also allows MAPI clients with older versions of Outlook to access Active Directory. DSProxy no longer runs on front-end servers; therefore, the front-end server can no longer determine which back-end server contains a MAPI client's mailbox. As a result, you cannot point a MAPI client to the front-end server to determine the user's back-end server and then route the request to the appropriate server.
Note:
To enable DSProxy on the front-end server for routing MAPI client requests, install Exchange 2000 Server Service Pack 3 (SP3) and create the registry key described in Microsoft Knowledge Base article 319175, "XADM: You Cannot Perform a Check Names Query Against a Front-End Exchange Computer." Note that to receive these referrals, the client must have RPC access to the front-end server. Additionally, the front-end server must have RPC access to domain controllers.
• Recipient Update Service
The Recipient Update Service updates recipients in the directory to match address lists or recipient proxy policies. The Recipient Update Service no longer runs on front-end servers, so be sure that none of your front-end servers are designated to run the Recipient Update Service. To do this, in Exchange System Manager, under Recipients, check the properties of each Recipient Update Service and ensure that no front-end servers are named in the Exchange server field.
• Offline Address Book Generation (OABGen)
OABGen creates the offline address book. Without the OABGen service, front-end servers no longer generate offline address books.
• Group Polling
System Attendant uses group polling to ensure that the local computer remains a member of the Domain Exchange Servers group. System Attendant polls the Domain Exchange Servers group and adds the local computer back to the group if it is no longer a member. Front-end servers no longer perform this function.
• Mailbox Management
The Mailbox Management service starts and stops the mailbox cleanup process according to the settings defined in Recipient Policies. Mailbox Management no longer runs on front-end servers.
• Free/Busy (madfb.dll)
The free/busy service manages user schedules. This service no longer runs on front-end servers.