Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

Exchange 2003 OMA browse functionality does not use Directory Service Access


View products that this article applies to.

Introduction

In Microsoft Exchange Server 2003, the browse functionality of Outlook Mobile Access (OMA) is written in code that is managed by Microsoft .NET Framework. Therefore, OMA browse functionality does not use the Exchange 2003 Directory Service Access (DsAccess) to locate Windows domain controllers or global catalog servers.

Because the OMA browse functionality does not use DsAccess, the steps that you typically use for troubleshooting are not valid. This article describes how to troubleshoot the OMA browse functionality.

↑ Back to the top


More information

OMA browse functionality uses the standard DirectoryEntry class and the standardDirectorySearcher class to search the Active Directory for the corresponding user objects. You can use the DsGetDcName function to get the name of the domain controller.

OMA uses the following functions to locate Windows domain controllers and global catalog servers:
  • The DsGetDcName function is sent to the Netlogon service on the remote computer that is specified by the ComputerName parameter. If the ComputerName parameter is set to NULL, the function is processed on the local computer. The DsGetDcName function does not verify that the domain controller name that is returned is the name of an actual domain controller or global catalog. If mutual authentication is required, the caller must perform the authentication.
  • The DsGetDcName function does not require any particular access to the specified domain. By default, this function does not make sure that the returned domain controller is currently available. Instead, the caller should try to use the returned domain controller. If the domain controller is not available, the caller should call the DsGetDcName function again, and then specify the DS_FORCE_REDISCOVERY flag.
  • With the DSClient for Windows 95 and for Windows 98, the DsGetDcName function is exported from the Logonsrv.dll file. However, there is no corresponding library file. This differs from Windows 2000. In Windows 2000, the DsGetDcName function is exported by the Netapi32.dll file, and the library file is Netapi32.lib.
  • OMA code calls the DsGetDcName function with the following parameter values to convert the flat domain name that the user enters during authentication to a DNS-style domain name:
    • ComputerName=NULL so that the local Exchange server processes the request
    • DomainName=Domain Name as typed by the user during authentication.
    • DomainGUID=NULL so that no additional domain is queried beyond that specified by Domain Name
    • SiteName=NULL so that a domain controller from the site that is closest to the ComputerName site is returned
    • Flags:
      • DS_IS_FLAT_NAME: This flag specifies that the DomainName parameter is a flat name.
      • DS_RETURN_DNS_NAME: This flag specifies that that the names that are returned should be DNS-style names.
  • If the DsGetDcName function returns the ERROR_NO_SUCH_DOMAIN error, the domain is assumed to be a Windows NT 4.0 domain, and the DsGetDcName function continues to use the flat name. If the DsGetDcName function return an error other than the ERROR_NO_SUCH_DOMAIN error, it returns the HTTP 401 (Unauthorized) error.

↑ Back to the top


References

For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:
314861� How domain controllers are located in Windows XP

247811� How domain controllers are located in Windows

↑ Back to the top


Keywords: KB832238, kbhowto, kbinfo

↑ Back to the top

Article Info
Article ID : 832238
Revision : 4
Created on : 10/25/2007
Published on : 10/25/2007
Exists online : False
Views : 276