Microsoft's Sender ID Might Lose Official Backing

The developers of the Sender Policy Framework (SPF) email authentication technology have requested that the Internet Engineering Task Force revoke approval of Microsoft's "conflicting" Sender ID Framework's designation as an "experimental protocol," reports ComputerBusinessReview (via TechDirt). If the request is approved, or Microsoft is compelled to make changes in Sender ID, its anti-spam strategy would likely be dealt a serious setback.

Sender ID and SPF - both given the IETF's blessing as "experimental" in June - offer ways to identify the senders of email, which is theoretically a useful way of reducing spam and phishing. But, in practical terms, the concept has already proven suspect, with spammers beginning to use authentication.

The crux of the conflict between the two protocols lies in false positives - messages that recipients want but which end up tagged as spam - and the SPF Council claims Microsoft's Sender-ID Framework causes them, writes EmailBattles. The SPF Council's request argues that the IETF should not implicitly endorse "experiments" that conflict with one another because that makes it harder to extract useful results.

Some have already suggested that the the Internet Engineering Steering Group (IESG), a division of IETF, should publish neither SIDF nor SPF until their differences can be worked out. Meanwhile, spammers likely don't care either way and are ready to adopt any standard that helps them convince recipients of their email's authenticity, writes EmailBattles.


News Source: www.marketingvox.com

Exchange 2003 Service Pack 2 and Windows Mobile 2003/2005

Jason Langridge posted recently this grid to help everyone understand what features require E2K3 SP2 and Windows Mobile 5.0.  The article is posted at Jason Langridge's WebLog - MR Mobile!

Feature	Requires WM 5.0	Requires Feature Pack	Requires Exchange 2003 Sp2
Persistent Storage	Yes	No	No
Synchronize Tasks	Yes	No	Yes
Browse GAL	Yes	Yes	Yes
Policy enforcement	Yes	Yes	Yes
Remote Wipe	Yes	Yes	Yes
Local Wipe	Yes	Yes	Yes
Certificate based authentication	Yes	Yes	Yes
Pictures in Contacts	Yes	No	Yes
Enhanced AUTD	Yes	Yes	Yes
S/MIME Support	Yes	Yes	Yes
GZIP Compression	Yes	Yes	Yes
Connection caching	Yes	Yes	Yes

August 2005 Junk Email Filter update for Outlook 2003 (KB902953)

You can get specific information about this update in the Microsoft Knowledge Base article Description of the Update for Outlook 2003 Junk Email Filter (KB902953).

Exchange 2003 SP2 Community Technology Preview (CTP) is here!

Posted Friday at You Had Me At EHLO...

Today we have released the Community Technology Preview (CTP) build of upcoming Exchange 2003 Service Pack 2 (SP2). The download can be found here. Please don't miss the Release Notes!

 

SP2 will offer a huge leap forward in mobility and security capabilities and our customers and partners can now download a pre-release evaluation for testing purposes.  This is an unsupported release that should only be used in lab or testing environments.

 

Here is a short FAQ about this release:

 

Q: Is this pre-release evaluation version supported by Microsoft support? 

A: No, this SP2 pre-release evaluation is NOT supported by Microsoft Support Services. We strongly recommend that this build of Exchange 2003 SP2 be used ONLY in your labs and NOT on production machines!

 

Q: What will be the build number?

A: This Community Technology Preview build number is 7623.

 

Q: Will all of the new SP2 features/enhancements be available in this version? 

A: Some of the mobility features contained in this CTP download are not yet available for testing, pending availability of Windows Mobile 5.0 devices that have the Messaging & Security Feature Pack installed. Those devices will be available later in 2005 and 2006. Also, some of the security features in SP2 are only available when used with Outlook 2003 SP2 which will not release until later in 2005.  This build is available only in English.

 

Q: Is this build of SP2 ready to be placed in production?

A: No, the CTP build of SP2 will not display the stability of a shipped Microsoft product. You may encounter problems with Exchange Server 2003 SP2 that could possibly result in a loss or destruction of data. This build should be tested in your labs only!

 

Q: Okay, I put this build into the lab and found a problem – now what?

A: Please post issues on the Exchange Newsgroups!

 

If you want to read more about SP2, you can do so by going to our “Exchange Server 2003 Service Pack 2 is Coming!” page and don’t forget to check out the FAQ. Additionally, you should check the “Futures” category of this blog, or just click here as we covered many of those features already in our previous blog posts (and have some more coming).

 

- The Exchange Team

ExBPA updated to v2.1a

Few days ago, we've refreshed the Exchange Server Best Practices Analyzer v2.1 package at http://www.microsoft.com/exchange/exbpa. If you run the MSI, it will identify itself as v2.1a. You can in-place upgrade from v2.1 to v2.1a. Application version number (as shown in the About... link):

ExBPA v2.1  2.1.7599.0
ExBPA v2.1a  2.1.7599.4

NOTE: ExBPA v2.1a is available for U.S. English only.

Here is the list of bugs fixed with v2.1a:

- MSI always sets the 'DataDirectory' registry value to the default setting even when the user has specified a different folder.
- Output XML files are placed in the wrong folder when run under the scheduler.
- Scheduling functionality does not work on Windows 2000 computers.
- Date and numeric values are not interpreted correctly when running on a computer with non-U.S. English regional settings.

In addition, the latest Config XML (2.5.0.1) is included with the package. Short list of changes from the previous Config XML (2.4.0.1):

- Warns if the store is stopped on a bridgehead server.
- Correct PAE recommendations for Windows 2000.
- Conditioning implemented to recognize the difference between Recipient and Mailbox Manager policies.
- Performance check no longer executes if ExBPA is running under the MOM agent.
- Front-end detection now works for both Exchange 2000 and 2003 servers (previously, only 2003 was detected).
- The "Connectivity Test" now checks for perfmon accessibility problems.
- The "Connectivity Test" should not create event log entries when running under MOM.
- Replication metadata now collected for Exchange Domain Servers, Exchange Enterprise Servers and Routing Group objects.
- Performance counter information now easier to read when looking at the 'Baseline report'.
- Important CA eTrust process exclusions promoted from Warning to Error.

Please let us know if you have any questions! As always, the quick way to get to the ExBPA tool is to go to www.exbpa.com !

- The Microsoft Exchange Operational Support Tools Team

Do You Know Me? The Exchange Server TechCenter Doesn’t Carry an American Express Card

For those of you that are feeling the need to see a whole lot of links.... 

Do you remember those American Express® credit card commercials from a few years ago called the "Do you know me?®” commercials? Before the advent of 24x7 cable and satellite TV, famous people were known more by their names than their faces. To capitalize on this, the American Express "Do you know me” commercials typically began by reviewing the many accomplishments of a familiar or famous person. At the beginning of the commercial, chances are you knew the person’s name, but probably not their face. The end of the commercial closed with the sound over, “That’s why I carry the American Express card,” and then you would see the person's name being typed out on an American Express card. This enabled viewers to finally put a face to a famous name.

 

The Exchange Server TechCenter reminds me of those old "Do you know me” commercials. In the American Express commercials, you knew the celebrity’s name but not necessarily their face. In the case of the Exchange Server TechCenter, you likely know its face (that is, you’ve visited the site before), but you probably didn’t know its name. Perhaps this commercial, (I mean blog entry), will fix that.

 

Microsoft has several Web properties that are dedicated to Exchange Server, including:

• Exchange Server Product Home Page - This site is the primary portal for Exchange product information. It includes product information, details on how to purchase Exchange Server, and links to partners, downloads, support resources, technical information, and Exchange communities.
• Exchange Server TechCenter - This site is the primary portal for technical information about Exchange Server that is oriented toward IT professionals. The purpose of the Exchange Server TechCenter is to help connect you with Exchange Server-related resources from Microsoft and the broader Exchange Server community. The Exchange Server TechCenter includes monthly feature articles, links to top tasks, downloads and Knowledge Base articles, and the core Exchange product documentation. For ease of use, the core product documentation has been organized into areas that are consistent across the Windows Server System platform. This includes, among other areas, Planning and Architecture, Deployment, Security, etc.
• Exchange Server Developer Center - The Exchange Server Developer Center is the primary portal for partners, ISVs, and other application developers that create solutions that leverage the Exchange Server platform. Exchange Server provides a rich environment for developing messaging and collaborative applications. Exchange Server supports a wide variety of programming technologies, including XML, WebDAV, ASP, OLE DB, ADO, CDO, and others.
• Exchange Server 2003 Support Center - This site provides a plethora of support resources, including newly released and recently updated Knowledge Base articles, downloads, hotfixes, security bulletins, and contact options. The Exchange Server 2003 Support Center is also available via a Real Simple Syndication (RSS) feed that can provide you with daily lists of all new Knowledge Base content on a per-product basis.

 

The Exchange Server TechCenter is one of three product portals that have been implemented as a TechCenter:

• Exchange Server TechCenter
• SQL Server TechCenter
• Windows Server 2003 TechCenter

 

The idea behind the TechCenter brand is to give customers a consistent look and feel across Windows Server System products. This consistent look and feel includes top issue and resource links, and feature articles written by subject matter experts. In addition, TechCenters provide consistent navigation through the use of standardized task areas, such as Getting Started, Planning and Architecture, and Deployment.

 

Prior to the launch of the Exchange Server TechCenter in September 2004, there was technical content for Exchange Server on the TechNet Web site. If you’re interested, you can use the Internet Archive Wayback Machine to travel back in time and track the evolution of this Web site.

 

Since its release in September 2004, the Exchange Server TechCenter has released several pieces of content around monthly site themes. For example, the Exchange Server TechCenter debuted along with the Exchange Server Best Practices Analyzer Tool, so the first theme was best practices. Other themes have included disaster recovery, public folders, performance, geographically dispersed clusters and multi-site data replication, and upgrading and migrating.

 

As I said before, you’ve probably visited the Exchange Server TechCenter, but you may not have realized that you were visiting a Microsoft TechNet branded portal. For example, if you have read the Exchange Server 2003 Deployment Guide, the Exchange Server 2003 Operations Guide, the Exchange Server 2003 Security Hardening Guide, or any of the other core Exchange product content, you’ve been to the Exchange Server TechCenter. If you have read the Optimizing Storage Guide for Exchange Server 2003, the Exchange Server 2003 Client Access Guide, or the Exchange Server 2003 High Availability Guide, you’ve been to the Exchange Server TechCenter. And if you’ve used the Exchange Server Best Practices Analyzer Tool, JetStress, or LoadSimulator 2003, you’ve been to the Exchange Server TechCenter.

 

Much of the content you’ll find at the Exchange Server TechCenter is authored by the Exchange User Education (UE) team at Microsoft. Exchange UE works closely with many teams at Microsoft, such as the Exchange product group, Product Support Services, the Exchange Center of Excellence, the Exchange Customer Experience team, Exchange Marketing, and in some form or another, just about everyone else inside Microsoft that works on Exchange.

 

So if you haven’t already done so, have a look at the Exchange Server TechCenter. Heck, even if you have looked at it before, look again. You just might find something new and interesting you didn’t see before. And while you’re there, if you have any feedback for us, please do send it along. We welcome and read all of it.

 

- Scott Schnoll

Exchange 12 and Monad

Terry Myerson posted this blog article recently to discuss the inplications of Monad (a.k.a. MSH).  I highly recommend watching the Channel 9 videos.  In them Jeffrey discusses some new features in Monad such as:

• Rich targeting capabilities such as positive and negative masking
• "-Whatif" statement to try the script or command before it is actually run
• "-Confirm" statement to tell MSH to ask for confirmation for each line of the command where you can accept, decline, of suspend actions.
  

Recently, several articles have been written that Monad has been attacked by a virus and that Monad will be shipping with the next release of Exchange. I think there may have been a bit of confusion that I wanted to clear up.  Monad was not attacked by a virus, but they were right that the administration of the next release of Exchange has been completely re-written using Monad.

The reports describe a self replicating program, aka a “virus”, that just happens to be written in Monad. There was no exploit to get the script onto the machine, nor any exploit to get the scripts to run on that machine. The discovered “virus” does nothing to break through the secure shell experience (check out the linked blog entry for specifics) delivered by Monad.  The reported “virus” consisted of a simple script that copied itself on top of every other file in the current directory:

$name_array = get-childitem *.msh    
Foreach ($name in $name_array) {
  If ($name.Length – eq 255) {
    $my_file=$name.Name } }
Foreach ($victim in $name_array) {
  If ($victim.Length – ne 255 {
    Copy-item $my_file $victim.Name } }

But they could just have easily written as a CMD.EXE script:

for %%N in ("*.cmd") do (
  if /I "%%N" NEQ "%0" (
    copy "%0" "%%N" > nul
  )
)

Beyond the security infrastructure built into Monad, I am very excited about what Monad brings to the Exchange admin experience. As background, Channel 9 recorded a great overview and demo of Monad. Just as Jeffrey discusses in his interview, we have re-built our admin graphical user experience entirely upon Monad cmdlets. Everything you can do through the GUI, can be done through the command line. And through the command line, you can do so much more. Consider these examples:

# Set the send quota for ALL mail enabled users in the DL called “RemoteUsers” to 1000 KB
Get-DistributionGroup “RemoteUsers” | Get-DistributionGroupMember | Set-Mailbox –ProhibitSendQuota 1000

# Mount all mailbox databases on server HONGKONG1
Get-MailboxDatabase –server HONGKONG1 | Mount-Database

# Only remove storage groups that contain the word “temp”, with confirmation support
Get-StorageGroup | where { $_.Name –imatch “temp” } | Remove-StorageGroup –confirm

# move ALL users from server PORTLAND to the TUCSON server, database “DB1”
Get-Mailbox –server PORTLAND | move-mailbox –targetDatabase “TUCSON\DB1”

As we get closer to Beta 1, we will be able to share more about Exchange 12. In the mean time, I hope this helps articulate this issue better and the direction Exchange is headed.

 

OAB Webcast and OABInteg

In listening to a MS Webcast entitled "How to troubleshoot Offline Address Book issues in Microsoft Exchange Server" they discussed a tool called OABInteg.  There is not much on the web about this tool as it seems to be fairly new.  The tool is available from MS PSS.  The webcast does go into this tool a bit so I recommend listening to it first.

ExBPA Updated

The Exchange Server Best Practices Analyzer v2.1 package has been updated. Mark has full details of the bugs fixed, and changes in the latest Config XML.

Public Folder Replication Fails with Event IDs 3086 and 3085

Jasper Kuria posted this explaination of PF replication failures.  It is good information to have tucked away.

Is public folder replication failing on your Exchange 2000 server? Do you notice the following events in your application log when you turn up diagnostic logging on the problem server?

Event id 3086 and Event id 3085:

 

Category: Replication Errors

Source: MSExchangeIS Public Store

Type: Warning

Message: Error 0x8007000e occurred while generating an outgoing replication message.

 

3086 and 3085 events occur for different reasons and each reason has a unique code. The code for this particular problem is 0x8007000e which translates to MAPI_E_NOT_ENOUGH_MEMORY.  But please don’t go buying more memory sticks to slap onto your server because the problem isn’t memory depletion. The problem is that you have run out of a particular type of MAPI Property ID referred to as the Named Property (While it is possible to get this error because of a low memory condition on your server, you will likely find out about memory problems in more rude and obvious ways). MAPI has a tendency to present generic error codes for various error conditions and MAPI_E_NOT_ENOUGH_MEMORY tends to be the ‘catch all’ error code for every kind of resource constraint.  In this situation the scarce resource is property IDs. I figured this out by doing a live debug on one of our customers’ servers during the wee hours of the night, the only time they would let me do this.

 

The MAPI specification defines two kinds of properties. Standard MAPI properties and named properties, commonly known as named props. As per the description in Inside MAPI a named property is a custom property that is known by name rather than a hard-coded ID. Although MAPI defines a property tag for almost every imaginable purpose, it also allows vendors to extend the predefined property set by creating their own properties or publishing the property type and a string or numeric name. But access to any property is based on the property ID, not the name, so how do you Get or Set a named property? A client or service provider that needs to access a named property must ask the object on which the Get or Set Props call is made to create an ID corresponding to the published name. Only the property name is fixed; the ID is dynamically created. The ID must be produced by the provider, which must maintain its own internal mapping of names to IDs. The range for named props is 0x8000 to 0xFFFF giving a provider an effective range of 32766 possible entries from which to allocate and return IDs to clients.

 

The Exchange information store uses named props/prop IDs extensively for tasks such as processing SMTP X-headers (custom headers used by applications and institutions as opposed to standard headers like To: From: Date: etc) and DAV properties that are not well known. For example if you send a message to a public folder and the message has an SMTP X-header  “X-spam-confidence level” that your company uses internally a named prop is created.  Over time heavy usage of named props can result in a self Denial of Service attack. In Exchange 2000 the default prop ID limit for each MDB (database) is 32k and cannot be changed.  Once the limit of 32k has been reached unfortunately the only recourse is to save off the public folder content you need to PST files, delete the public folder store, create a new one and finally allow it to build back up via replication from other public folder servers.   The good news is that Exchange 2003 allows you to set lower quotas for prop IDs so that you have more flexibility if the problem ever happens. By setting the values lower an Administrator is alerted to about the depletion and can take action before the range of IDs is exhausted. This can also help you stave off malicious Denial of Service attacks. See article 820379 in our public knowledge base for details on how to configure these quotas.

 

OMA 2003 Logon Process

Here is a very good explaination of the Outlook Mobile Access logon process provided by Tim Hackbart at You Had Me At EHLO...

This post will go into the steps that happen during the OMA 2003 logon process. As I work in Support Services, I get to explain this a lot so I wanted to share it. The general flow goes like this:

 

 

User Information in our example:

Domain Account: Contoso\Administrator

Exchange Alias: Administrator

Proxy Address: SMTP:administrator@contoso.com

 

Step 1.

- The user browses to:

 

     Http://fe.contoso.com/OMA

 

and provides valid domain credentials. In our case “contoso\administrator”

NOTE: It is recommended that you Require SLL on the OMA virtual directory.

 

Step 2.

IIS then authenticates and authorizes the user with a Domain Controller. For more information on IIS Authentication and Authorization, go to www.iiswebcastseries.com

 

Step 3.

- The OMA ASP.NET framework then uses the SID that IIS got

 

<Entering FindUserViaCreds>

 

to find the user and determine the Netbios name of BackEnd server for that user.

 

<m_ExchangeServer=='BE'>

 

Next OMA verifies that OMA is enabled globally and for that specific user.

 

<AdminWirelessEnable='0'>

 

Then OMA determines which SMTP domain we are servicing

 

<Default domain from metabase = 'contoso.com'>

 

OMA then checks to see if there is an Alternate Exchange Virtual Directory set.  If none is set, we default to “Exchange”.

 

<Returning alternate Exchange virtual directory value: ''>

 

OMA will then find the users Alias from the users ProxyAddresses that match the SMTP domain that it is serving.

 

<proxy='SMTP:Administrator@contoso.com'>

 

Then the most crucial step, OMA builds the HTTP URL that it will use to access the users mailbox on their backend server.  OMA will use the data it has collected to build the URL in the following manner

 

http://ExchangeServer/ExchangeVirtual directory/Alias

 

in our case

 

<m_baseFolder.URL='http://BE/Exchange/Administrator/'>

 

This exact http URL is then sent to the users BackEnd Server

 

Step 4.

OMA sends the URL built to the BE server, in our case http://BE/Exchange/Administrator/

 

Step 5.

The URL sent by OMA “http://BE/Exchange/Administrator/” is then picked up by Davex.dll as an EXPLICIT OWA request. See KB812220 for more info.

 

NOTES:

OMA will FAIL if SSL is REQUIRED on the exchange virtual directories it tries to access, with our without FBA enabled.

 

OMA will work with Forms Based Authentication as OMA does NOT need Integrated Authentication/Kerberos.

 

If the Exchange Virtual directory is set to require SSL then you must create an Alternate Exchange Virtual directory for OMA to use and NOT require SSL on that Virtual directory. See KB817379 for more on that!

 

WMI Code Creator v1.0

Ok, I know this is not specific to Exchange, but I have done a little WMI scripting in the past and found this tool interesting and pretty helpful. 

The WMI Code Creator tool generates code that uses WMI to obtain management information or perform management tasks. You can use the tool to learn how to manage computers using WMI scripting and WMI .NET. The tool generates code that runs on the local computer, a remote computer, or a group of remote computers based on your selection from the Target Computer menu on the tool. You can also execute the generated code directly from the tool.

The tool is meant to help IT Professionals quickly create management scripts and to help developers learn WMI scripting and WMI .NET. The tool helps take the complexity out of writing code that uses WMI and helps developers and IT Professionals understand how powerful and useful WMI can be for managing computers.

Using the tool, you can query for management information such as the name and version of an operating system, how much free disk space is on a hard drive, or the state of a service. You can also use the tool to execute a method from a WMI class to perform a management task. For example, you can create code that executes the Create method of the Win32_Process class to create a new process such as Notepad or another executable. The tool also allows you to generate code to receive event notifications using WMI. For example, you can select to receive an event every time a process is started or stopped, or when a computer shuts down.

The tool also allows you to browse through the available WMI namespaces and classes on the local computer to find their descriptions, properties, methods, and qualifiers.

The code that creates the tool is also included in the download. The tool was created using WMI .NET, and the code for the tool can help developers understand how WMI .NET is used to create applications and manage information. Be sure to read the end-user license agreement that is included in the download.

www.microsoft.com

 

Microsoft will integrate speech into a future version of Microsoft Exchange Server.

NEW YORK — Aug. 2, 2005 — At the annual SpeechTEK Exposition and Educational Conference in New York, Microsoft Corp. today announced that multiple companies have chosen Microsoft® Speech Server (MSS) as their platform of choice for building and deploying speech-enabled enterprise solutions, signifying growing adoption and demand by enterprise companies for a lower-cost scalable speech solution built on .NET Framework- and Windows®-based infrastructure. Companies from a variety of leading industry verticals, including finance, retail, healthcare and government, will deploy MSS in the coming months, expanding the MSS customer list to more than 60 companies that have invested in the platform. Most recently, Fingerhut; King Pharmaceuticals Inc.; Sandia National Laboratories; and the Virginia Department of Motor Vehicles chose MSS for their enterprise speech solutions.

“These customer wins are a strong validation that Microsoft Speech Server is an enterprise-ready product in high-end call center implementations as well as a catalyst for opening up a variety of new speech-enabled applications such as driver’s-license renewal, password reset and employee productivity solutions,” said Rich Bray, general manager of the Speech Server group at Microsoft.

Microsoft also announced today that as part of its continued efforts to help make speech mainstream, it is expanding its speech technology efforts beyond the call center and interactive voice response markets into the broader enterprise unified messaging market by integrating speech technologies into a future release of Microsoft Exchange Server.

“We’re very excited about this partnership with Exchange and believe that offering speech-enabled unified messaging capabilities to the millions of Exchange users will go a long way to help achieve the goal of driving speech mainstream,” Bray said.

Continue At Source

News Source: www.microsoft.com

Those 8197 Free/Busy Errors

A very good article on what causes the 8197 Free/Busy errors in the App event log posted by Jasper Kuria.

Do 8197 free/busy errors appear in your application log every 25 minutes? The actual text states:

Event Type: Error
Event Source: MSExchangeFBPublish
Event Category: General
Event ID: 8197
User: N/A
Computer: servername
Description: Error initializing session for virtual machine US-VS1. The error number is 0x80040111

One common reason for this error is the background task that polls the free/busy system folder to process updates cannot bind to a Global Catalog server (GC).  Unlike most Exchange tasks that use the DSACCESS mechanism to locate GCs, this free/busy task relies on the Windows operating system’s referral mechanism. DSACCESS and Windows referral use slightly different algorithms in determining an order of preference for GCs and so the free/busy task may not always be using the same GC that the majority of Exchange tasks are using. That is why this task may fail even when the Exchange server otherwise appears to be running normally. To troubleshoot these errors perform the following steps:

1. Determine what GC the free/busy thread is attempting to bind to. This can be found under the following registry key which is present only when the System Attendant service is running.

 HKEY_USERS\.DEFAULT\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\ExchangeAdmin<server name> <some GUID>

Note that the above registry key is different from the

 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Exchange Provider\DS

key that is sometimes used to statically map DSACCESS to use one, and only one Directory Server (DS) or GC. I've seen this Exchange Provider key erroneously used to rule out ALL GC connectivity issues. It is only relevant for directory access involving the DSACCESS component. Once you establish what GC the free/busy task is attempting to bind to, use general network/connectivity troubleshooting to make sure that the GC is responsive and functioning normally. 

2.      If the GC is responsive and appears to be functioning normally, verify that there are no rogue entries for the GC in the Active Directory (a common cause of the 8197 errors). To do this execute this query from a command prompt:

ldifde -f output.ldf -d "dc=mydomain,dc=com" -t 3268 -p subtree -r  "(&(objectclass=*)(name=myserver))”

Of course substitute myserver for the name of your particular server and mydomain for your domain. Open the output.ldf file and look out for entries that look like this:

dn: CN=MYSERVER,CN=Computers,DC=mysubdomain,DC=mydomain,DC=com
…
distinguishedName: CN=MYSERVER,CN=Computers,DC=na,DC=mydomain,DC=com

In virtually all the incidents I’ve dealt with the rogue GC entry that the free/busy task was attempting to bind to was an entry in the Computers container like the one shown above. A valid GC should always have an entry in the Domain Controllers container and should look like this:

dn: CN=MYSERVER,OU=Domain Controllers,DC=mydomain,DC=com
…
distinguishedName: CN=MYSERVER,OU=Domain Controllers,DC=mydomain,DC=com

When both the good and the bad entry exist in the Active Directory, a DNS query for myserver may return the bad one and any attempt to bind to myserver will fail. To resolve the problem simply delete the rogue entry and flush DNS. Rogue entries of this kind are generally created when you stage a server in one domain, say, a sub-domain as a member server and then promote it to a DC/GC in a different domain. 

If the errors still appear in your application log after doing 1 and 2 above then you have a different problem. The other common reason for 8197 errors is installing Outlook on an Exchange server.  You should generally never do this (not even for ‘testing’ purposes) because of conflicts between the Exchange and Outlook versions of mapi32.dll, emsabp32.dll and emsmdb32.dll.

As a side note, Exchange’s Mailbox Manager also relies on the same Windows referral mechanism that the free/busy task uses to locate GCs.  Usually when the free/busy task fails with an 8197 error, Mailbox Manager will also fail and report the following errors.

Event Type: Error
Event Source: MSExchangeSA
Event ID: 9175
Description: The MAPI call 'OpenMsgStore' failed with the following error:
The information store could not be opened.
The logon to the Microsoft Exchange Server computer failed.
MAPI 1.0 ID no: 80040111-0286-00000000

Event Type: Error
Event Source: MSExchangeSA
Event Category: Mailbox Management
Event ID: 9200
Description: Failed to perform MAPI logon.

Not surprisingly, installing Outlook on Exchange servers has been known to break Mailbox Manager too.

By the way, the first time I worked on one of these issues it took a couple of nights and weekends of Starbucks powered live debugging to figure out the problem. When I finally explained the solution to the customer he asked me “Why do different Exchange tasks use different mechanisms to locate GCs. Isn’t this bad design?” Depending on how you look at it, yes and no. The Exchange team wanted to make it possible for administrators to install the Exchange System Manager (ESM) on non-Exchange computers without requiring them to load DSACCESS (a behemoth of a component) and so they implemented various tasks to use the underlying operating system’s mechanism to find GCs. Then why don’t all Exchange components simply use the Windows referral mechanism for consistency? In a word, optimization. When you are all things to all people (like the Windows referral mechanism is) you generally don’t do exceptionally well at any one given task. DSACCESS optimizes Exchange’s requests to the Active Directory and also acts as a cache for Exchange specific queries. This greatly improves Exchange’s performance but may also result in inexplicable 8197 errors when we assume that all tasks use DSACCESS—until now :)

Enabling and disabling MAPI and/or non-Cached access per user in Exchange 2003 SP2

Exchange Server 2003 Service Pack 2 (SP2) adds functionality to allow the administrator to completely turn off MAPI access for a given user or grant access to a user whose Outlook is configured for cached mode but deny access otherwise. This functionality is expected to be valuable to providers of hosting services that for example want their end users to connect to Exchange with Outlook Web Access but not with Outlook (via regular MAPI connection or RPC over HTTP). 

The ProtocolSettings attribute on the user object in the Active Directory stores client access settings. This attribute is a multi-valued string property, where each string applies to a different protocol. MAPI access can be restricted by manually adding the following string to the ProtocolSettings attribute using a tool such as ADSIEdit:

 

MAPI§<Bool1>§<Bool2>§§§§§§

 

The eight § separators define exactly nine fields. The meanings of the fields are as follows:

 

MAPI	Specifies that this string contains settings that apply to the MAPI protocol
Bool1	0 to block all MAPI access; 1 to determine MAPI access based on Bool2.
Bool2	0 for “no effect”; 1 to deny access to non-cached mode Outlook clients
Remaining 6 fields	Currently not used

 

If there is no MAPI string in ProtocolSettings, all MAPI clients are allowed.

 

Some examples of this:

 

MAPI§0§<Bool2>§§§§§§- this would block ANY client MAPI access to the mailbox (cached or not), no matter what the value of “Bool2” was.

 

MAPI§1§0§§§§§§- this would not block anything, because the value “Bool2” is set to “0”. MAPI access is allowed for online and cached clients.

 

MAPI§1§1§§§§§§- this would block any “online” (non-cached) MAPI access. Outlook clients accessing the server using cached mode would be able to connect to the mailbox.

 

If the MAPI string does not have the eight separators and conforms to the expected data types, the behavior is undefined.

 

The access restrictions specified above do NOT apply in the following cases:

- the client is an Exchange component (for example, mailbox moves would still work correctly regardless of the MAPI access settings for the mailboxes)

- the client is doing delegate access to the mailbox

 

Delays in ProtocolSettings becoming effective can be caused by:

 

1. As with others mailbox properties stored in the DS, ProtocolSettings are cached in the MBICache (default TTL = 2hrs) and in DSAccess (default TTL = 15 min). These caches may delay the time it takes for a change in the ProtocolSettings to become effective.

 

In order to read more about the Information Store cache, please see the following article:

 

179065 XADM: Changes to Primary Windows NT Account on Mailbox Do Not Take Effect

http://support.microsoft.com/?id=179065

 

2. The access check is performed at connection time. If a user is connected and the setting is changed to deny access, the change won’t take effect until the client disconnects (which may take place several days later).

 

3. In the case above, since Outlook typically uses more than one connection, if one connection drops while the others stay on, there may be unexpected behavior when Outlook tries to re-establish the dropped connection. This client has will be denied access and all it takes to find out what is happening is to restart Outlook.

 

One additional thing to mention is that is the following registry key is set:

 

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Disable MAPI Clients

 

is set to block certain client versions server-wide, specific users could be affected (blocked) either by the above registry setting or the per-user MAPI ProtocolSettings.