Category Archives: Exchange 2003

Steps to Troubleshoot Offline Address Book – Exchange 2010 & Exchange 2003 mixed environment

Things  To be checked before you proceed with troubleshooting  – ?

      What type of clients are used – Outlook 2003, Outlook 2007 or Outlook 2010

      Have the OAB files been replicated from Mailbox Server(OAB GenServer) to Client   Access Server.

      Does the organization contain at the least one Oab-VirtualDirectory.

      Is the OAB set for web distribution?

      Any recent changes on the environment or any updates or patches installed.

      How many users are affected and the mode of occurrence?

 

TROUBLESHOOTING

Check if Autodiscover Service is working fine in Outlook 2007 & Outlook 2010  because misconfiguration of Autodiscover could cause the OAB to fail downloading.

 

Steps to check – check the test email auto configuration on outlook client

Also another  way to check this is to see if users are able to modify OOF Assistant settings in Outlook 2007 0r 2010 .

If the problem is with Outlook 2003 then proceed with linear troubleshooting for OAB in legacy Exchange

For Outlook 2010 check if the OabVirtualDirectory is present.

To verify, open Exchange Management Shell and enter the following cmdlet. This
will return all of the OAB Virtual Directories found.

Get-OabVirtualDirectory

If the cmdlet doesn’t return any OAB virtual directories, then there is a problem
and you will need to create an OAB Virtual Directory using the
New-OabVirtualDirectory task.

Verify if there are any OABs setup for Web Distribution.

Do the following:
a. Open the Exchange Management Console.
b. Expand the Organizational Container.
c. Click on the Mailbox Container.
d. In the middle MMC pane, click on the ‘Offline Address Book’ tab.
e. If there are any Offline Address Books setup for Web distribution, they
will be identified as such under the Distribution Mechanism column as Web-Based.

The following location on the Client Access Server can be checked to see if the
Offline Address Book files have been replicated:

C:\Program Files\Microsoft\Exchange Server\Client access\OAB

This is the local cache for the Client Access server and any Offline Address Book
files that need to be updated will be updated here.

Permissions should also be checked. If any of the default permissions are locked
or are missing, the Offline Address Book files might not be replicated.

The following permissions that are installed on this directory are as follows:

Anonymous access disabled
Integrated Windows Authentication Enabled
Read Permission Enabled
Write permission disabled
Directory Browsing Disabled
Script source access disabled
Log Visits Enabled
Index this resource disabled
Execute permissions set to None

If you suspect that you are having a OAB Generation problem, turn up Diagnostic
Logging through the Exchange Management Shell.

On the Exchange 2010 mailbox server, open Exchange Management Shell and
enter the following cmdlet:

Set-EventLogLevel “MSExchangeSA\OAL Generator” -Level Expert

After you hit enter you will not see any output that indicates that the
logging level has been set.

However, you can verify the level using the following cmdlet:

Get-EventLogLevel “MSExchangeSA\OAL Generator”

Next, type Update-OfflineAddressBook -Identity “Default Offline Address
List”.
This will generate the Default Offline Address List.

Review the application event log on the mailbox server.

Another method for troubleshooting OAB failures is to use the tracing built into
ExTRA

 

  • Exchange 2010 OAB
    ================

    Analyze current configuration
    ——————————————–

    1. Use Exchange Management Console
    2. Expand Server Configuration and select Mailbox
    3. Right-click the server in the list of servers and click Properties
    4. Select the Client Settings tab
    a. Check specified Offline Address Book configuration
    b. Check Distribution methods (Web and/or public folders)

    Public folder distribution
    OAB 4.0, 3a, 2.0

    Web folder distribution
    OAB 4.0

    Public folder distribution
    ———————————-

    Use MFCMAPI to inspect the public folders housing the OAB data

    1. Public Root
    2. NON_IPM_SUBTREE
    3. OFFLINE ADDRESS BOOK
    4. DN for OAB (for example, /o=Fourthcoffee/cn=addrlists/cn=oabs/cn=Default Offline
    Address List)
    5. Double-click any of the following folders to see the messages within:

    OAB version 2
    OAB version 3a
    OAB version 4

    Web distribution
    ————————-

    1. use Exchange Management Console
    2. Expand Server Configuration
    3. Select Client Access
    4. Select the CAS server in top pane
    5. Select the “Offline Addresss Book Distribution” tab in the bottom pane
    6. Right-click the listed OAB and click Properties

    a. On the General tab look at the Polling Interval value. This is the value used
    by the File Replication Service to determine how often to replicate the OAB files
    to the distribution point.
    b. On the URLs tab look at the Internal URL and External URL values to see if
    they are appropriately configured (We should know the correct values)

    7. check the OAB generation share:

    \Program files\Microsoft\Exchange Server\ExchangeOAB

    Do you see a folder with a {guid} that matches the {guid} in the OAB URL shown
    in Outlook (Test E-mail AutoConfiguration)?

    8. Check the web distribution folder:

    \Program files\Microsoft\Exchange Server\ClientAccess\OAB\{guid}

    a. Does this {guid} match the {guid} in the share listed in step 7
    b. If not, what is the number of minutes specified for the Polling Interval? Is
    the File Replication Service running?

    c. check the Event log on the generation server

    Source: MSExchangeFDS
    Category: FileReplication

    Steps to generate a new Web distribution OAB
    ————————————————————————-

    1. In Exchange Management Console go to Organization Configuration – Mailbox
    2. Click “New Offline Address Book”
    a. Name = E2010 Web OAB
    b. OAB generation server = <E2010 mailbox server>
    c. Enable Web-based distribution
    Vdir = OAB (Default web site) CLT-E2k10
    d. Enable public folder distribution
    3. Right-click the newly created OAB and click Update
    4. Check the \program files\microsoft\exchange server\ExchangeOAB folder

    <result> you should see the {guid} subfolder just generated. This data will need to
    be replicated to the CAS server

    5. On the CAS server check \program files\microsoft\exchange
    server\clientaccess\OAB for web distribution

    <result> the files probably won’t be replicated here just yet.

6. Select Server Configuration – Mailbox

       Examine Mailbox Database properties

       Go to the Client settings tab

       Offline Address Book = <name of your new OAB> (browse if necessary)

7. Select Server Configuration – Client Access

       Select your CAS server in the top pane

       Select the “Offline Address Book Distribution” tab

       Right-click OAB (Default Web Site) and click Properties

       On the General tab check the Polling interval (set it temporarily low to
force FRS replication of the OAB files)

       On the URLs tab validate the Internal URL and external URL (for example,
the Intenal URL would just be https://cas_server/ )

8. Wait a minute or two (or whatever time you specified for the Polling
Interval)
9. On the CAS server, re-check \program files\microsoft\exchange
server\clientaccess\OAB for web distribution

<result> the files should now be in the distribution point on the CAS server

10. To force a regen of the autodiscover settings run iisreset (or just wait)

NOTE: Don’t run iisreset on a production server.

11. Start Outlook 2007 or 2010 with a cached mode profile.
12. Check the OAB URL in the Test Email AutoConfiguration dialog

<result> the URL should point to the the URL specified above plus /OAB/{guid}. For
example, https://server/OAB/d15381e6-ce14-4949-a147-2681e656744a/

Outlook 2010 OAB Analysis
======================

Troubleshooting
————————–

1. Check the Sync Issues folder

       Check the different Synchronization Log messages (with a red exclamation
point icon)

       Check for an error in the message under “Microsoft Exchange offline address
book”

2. Check the Olkdisc.log file (in the %temp% folder) for the listed OAB URL
3. Inspect the OAB URL with the Test E-mail AutoConfiguration tool

      Start Outlook

      Press CTRL, right-click the Outlook icon in the system tray and then click
Test E-mail AutoConfiguration

      Clear the two “Guessmart” checkboxes and click Test
Inspect the value for “OAB URL”

– If you using public folders for the OAB then this will say “Public
folder”

– If you are using Web distribution for the OAB this this will list the full URL to the OAB files. For example, https://server/oab/{guid}

 

 

 

 

 

 

Steps to troubleshoot on messages stuck in local delivery queue in exchange 2003

Here are the few troubleshooting steps which will be helpful during messages stuck in local delivery queue

 

Open up the queue viewer and check for last error information in the local delivery queue

 

Open  the event viewer and look for event id 2080 and check for GC and DC availability

 

Increase  the Diagnostics logging for the following keys in the registry for Dsaccess

General

Cache

Topology

Config

Ldap

 

Restart the system attendant service and check  if we could find any relevant ids

Check  with the directory access tab on ESM   and see if DC and GC are listed

 

Finally you can go ahead and hard code the exchange server to listen on a particular DC if nothing works.

 

Note:Changes in registry should be made properly and correctly else it might make the exchange server not to listen to DC’s

 

Added the following registry keys.

 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeADAccess\Profiles\Default\UserDC1

IsGC = REG_DWORD 0x0

Hostname = REG_SZ <DC Name>

 

 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeADAccess\Profiles\Default\UserGC1

IsGC = REG_DWORD 0x1

Hostname = REG_SZ <DC Name>

 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeADAccess\Instance0

ConfigDCHostName = REG_SZ <DC Name

 

 

 

 

 

Troubleshooting Inbound Mail Flow in Exchange Server 2003

Lets begin with a basic overview of inbound mail flow in exchange server 2003  

Inbound mail flow is comprised of all messages received by the SMTP virtual server and destined for a recipient on the local server running Exchange Server 2003.

The following information provides you with answers to the most frequently asked questions about inbound mail flow.

 What is the basic process for inbound mail flow?

Inbound mail flows through an Exchange Server deployment in the following manner:

  1. The sending SMTP server queries Domain Name System (DNS) to locate the mail exchanger (MX) resource record of the recipient’s SMTP mail server. This MX record resolves to a corresponding host (A) record that resolves the IP address of the recipient’s SMTP mail server.
  2. The sending SMTP server initiates a conversation on the recipient’s SMTP server (using port 25). On an Exchange Server gateway, the recipient’s SMTP server is the SMTP virtual server on the Exchange server that is configured to accept inbound mail.
  3. If the message is destined for a recipient of its SMTP mail domain, the SMTP server accepts the inbound message, as defined by recipient policies. For more information about defining recipient policies, see the following Microsoft Knowledge Base articles:
  1. When the message is accepted, the message is persisted in the \Queue folder on the Exchange server. The SMTP virtual server submits the message to the Advanced Queuing Engine, which then submits the message to the message categorizer. For more information about the Advanced Queuing Engine, see the following Microsoft Knowledge Base articles:
  1. The message categorizer validates the recipients of the message, checks for proper recipient attributes, applies limits and restrictions, flags the message for local delivery, and then returns the message to the Advanced Queuing Engine.
  2. The Advanced Queuing Engine submits the message to the Local Delivery queue.
  3. The Exchange store receives the message from the Local Delivery queue.
  4. Mail messages are delivered to the client (for example Outlook, Outlook Express, or Outlook Web Access).

 What are the minimum requirements for inbound mail flow?

The following are the minimum requirements for inbound mail flow:

  • Exchange Server must have access to the Internet on port 25. This access should not be blocked by firewalls or other network settings. Anonymous connections should be allowed.
  • The Exchange Server SMTP virtual server should be configured to use the default settings. For more information about configuring the Exchange Server SMTP virtual server, see Microsoft Knowledge Base article 266686, How to Configure a SMTP Virtual Server Part 1.
  • The public mail exchanger (MX) resource record configured on your public DNS service should be accessible to all other Internet domains. The MX record should point to the Exchange server and must be identified before messages can be sent or received.
  • Recipient policies must be configured and applied correctly. Recipient policies will stamp the SMTP virtual server and the recipient’s mailbox with the correct e-mail address.

 How can I identify the scope of a problem?

Mail flow problems are often identified as mail not being delivered to or received by the client. The causes of specific problems can vary—for example, a queue may be backing up or mail may be returned as non-deliverable. Finding the answers to the following questions can help you identify the scope of a problem in your Exchange Server organization:

  • Does this affect some or all Exchange Server users? If only some users are affected, do they share a common variable? For example, are they using the same client application or are they all sharing the same local Exchange server?
  • Does this affect one or multiple Exchange servers? If multiple Exchange servers are affected, are core Windows Server components (such as DNS) configured properly for Exchange Server?
  • Does this affect multiple users on multiple Exchange servers? Are all SMTP domains hosted by your Exchange server affected? Are all users affected?
  • When did the problem begin? Did it begin when you first noticed the problem or has it existed unnoticed for some time?
  • If you are currently experiencing a problem with a particular feature or technology of Exchange Server, has this feature or technology ever worked in your deployment? If yes, when did it stop working? When is the last time you knew it was working properly?
  • What has changed? If this worked previously and is not working now, something changed. Did you move one or more mailboxes? Create one or more new users? Did a router fail? Is a service not running? Are any queues backed up?
  • What version of Exchange Server are you running? Are any service packs or updates applied? If yes, are they applied to all of the same-version servers in your organization?
  • Are you running any third-party software, such as anti-virus software? Did you perform any customizations that use event-sinks such as custom anti-virus filtering?
  • Are Windows Server components such as DNS, Active Directory, IIS, and SMTP functioning correctly? Are the services associated with Windows Server (and required by Exchange Server) running? For information about the services required for Exchange Server, see “Appendix B: Services That Are Used by Exchange Server” in the Exchange Server 2003 Administration Guide.
  • Is the MX record on the Exchange server configured properly? For information about MX records, see Microsoft Knowledge Base article 203204, How to obtain Internet Mail Exchanger records with the Nslookup.exe Utility.
  • Are recipient policies configured properly? For information about configuring recipient policies, see “Configuring Recipient Policies” in “Chapter 7: Connecting to the Internet” of the Exchange Server 2003 Transport and Routing Guide.
  • Are users able to send messages?
  • Are users able to receive messages?

 What can I do if all users are affected by an inbound mail flow problem?

In a scenario where all users are affected by an inbound mail flow problem, consider the following:

  • Firewall   Do you have a firewall? Have there been any changes to the firewall? If you have made recent changes, load a previously-saved, good configuration. Restart the firewall or firewall services. If the Message Screener component of Internet Security and Acceleration (ISA) Server is enabled, verify that message screening is configured correctly. Is TCP port 25 open on the firewall? (Port 25 must be open for Exchange Server mail flow to work properly.) Does mail function correctly behind the firewall?
  • Internet Domains   Can Internet domains send messages to you? If all external domains are unable to send mail, verify the MX record on the Exchange server and that the IP address associated with the MX record is the IP address of the Exchange server or the firewall. If some domains cannot send mail, are you getting non-delivery reports (NDRs)? Is the SMTP connector configured properly? For more information about verifying that domains can send mail, see Microsoft Knowledge Base article 153119, Telnet to Port 25 to Test SMTP Communication.
  • Domains Hosted by Exchange Server   Are all domains affected? If yes, check the recipient policy and verify that the Exchange server is authoritative for all of the hosted domains. Is port 25 open on the firewall? Check to see if any senders are receiving NDRs. If some domains are affected, does the recipient policy indicate that the Exchange Server organization is authoritative for the affected domain? Has any recipient filtering been configured that would prevent mail from reaching the affected domain?
  • Receiving Mail   If you have been able to receive mail and are now experiencing problems, try to identify when the problem began. What changes are associated with the problem? New software? New configuration? New users? Is the problem intermittent? If yes, is there a pattern? Does the problem occur when associated with specific services, components, or third-party applications? If not, check the MX records, verify that port 25 is configured properly, and that the IP address for the Exchange server can be recognized from another machine in the network.

 What can I do if only some users are affected by an inbound mail flow problem?

In a scenario where only some users are affected by an inbound mail flow problem, consider the following:

  • Services   The following Exchange Server services must be running in order for inbound mail to function properly:
  • Microsoft Exchange System Attendant
  • Microsoft Exchange Information Store
  • Microsoft Exchange Routing Engine
  • Simple Mail Transfer Protocol (SMTP)

If any of these services are stopped, restart them. Next, check the event log to identify why the service was stopped.

  • Queues   Are messages getting stuck in queues? For more information, see the question “What queues should I monitor?” later in this article.
  • Client   Frequently, when only a few users on the same Exchange server are experiencing similar problems, client software can be the cause. If this is the case, verify that users can send mail to themselves (or to any other users on the same server) using the client software normally available to them.
  • Administrative Options   Have administrators configured any restrictions on the particular group of users? Is there a size limit on inbound messages? Is there a storage limit on a particular user’s mailbox? Can the affected users receive mail from any domain or is it specific to one domain? Use message tracking and send mail to that user and follow the path it takes through your Exchange Server organization.

 What queues should I monitor?

Messages will pass through the following queues during inbound mail flow. If problems exist with the queues, messages may not be delivered. Consider using Queue Viewer in Exchange System Manager to monitor the status and state of the following queues:

  • Messages Pending Submission   Also called the pre-submission queue. This queue contains messages accepted by the SMTP service. Messages in this queue have not yet been processed by the message categorizer. If messages are accumulating in this queue, it may indicate a performance problem on the Exchange server, or it may indicate a problem with an event sink (such as custom SMTP processing code for anti-virus screening).
  • Messages Awaiting Directory Lookup   Also called the pre-categorization queue. This queue contains messages that have passed through the pre-submission queue and are waiting to be processed by the message categorizer. Messages will accumulate in this queue when the message categorizer is unable to process messages. Reasons the message categorizer may be unable to process messages include the following:
  • The message categorizer may not be able to access the global catalog to attain recipient information.
  • The global catalog lookup may be performing slowly.
  • If this is a front-end server, the required mailbox store may be disabled on a front-end server.
  • Messages are sent by previous versions of Microsoft Outlook (such as Outlook 2000)
  • A message is sent to a user’s mailbox while the mailbox is being moved
  • The user does not yet have a mailbox and no master account security ID (SID) exists for the user
  • SMTP message routing is configured in a way that causes a message to loop (looping messages are moved to this queue)
  • The Microsoft Exchange Information Store service is unavailable or not running
  • A mailbox store is not mounted,
  • Issues exist with the IMAIL Exchange store component.
  • Local Delivery   Contains messages destined for recipient mailboxes that reside on the local Exchange 2003 server. Messages can accumulate in this queue if the Microsoft Exchange Information Store service is not accepting messages or if it has a performance problem.
  • Messages Queued for Deferred Delivery   Contains messages that are queued for later delivery. Reasons that messages will be placed in this queue include the following:
  • DSN Messages Pending Submission   Contains delivery status notifications that are waiting to be rendered by Exchange Server. For example, NDRs are delivery status notifications. Reasons that messages will accumulate in this queue include the following:
  • Failed Message Retry   Contains messages that failed queue submission. Messages can fail for several reasons, including if the message is corrupted or if system resources are low. If messages appear in this queue, review your server configuration to determine whether you have non-Microsoft programs or event sinks installed (such as virus scanners) that can interfere with message queuing. If the system is responding slowly, use Windows Task Manager to identify processes with system resources. Restarting Internet Information Services (IIS) may solve the problem temporarily and allow you more time to identify the root cause of the problem.

For more information about using Queue Viewer, see Microsoft Knowledge Base article 823489, How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003.

 

%d bloggers like this: