Zoho Banner September 2011

Archive for March, 2011

I’ve been running dual boot Windows 7 and Windows Server 2008 R2 on my laptop for a little while now.  I use Windows 2008 R2 for running Hyper-V guests for testing and demo purposes.  For some time I’d been running Microsoft Security Essentials on the Windows 7 partition, but without any Anti-Malware software on the 2008 R2 partition – something that made me a little uncomfortable.  Recently, I found Comodo Antivirus.  It’s free and seems to run quite happily on my Windows Server 2008 R2 partition. 

Be aware that it does throw up the occasional advertisement bubble from its location in the notification area of the Windows task bar. This doesn’t really bother me – it seems a small price to pay for peace of mind.



I came across a problem the other day when using version 6.5.8211.0 of Microsoft Exchange MAPI and CDO 1.2.1 on a server running Good Mobile Messaging.  The Good software accesses user mailboxes via the MAPI CDO client.  At first the mailbox access was failing horribly with the following errors:

2011-03-11 13:24:33 12:00  ERROR:-2147219707
2011-03-11 13:24:33 12:00  MSG:Code:IDispatch error #1285 Source:Collaboration Data Objects Description:The attempt to log on to the Microsoft Exchange Server computer has failed. [Microsoft Exchange Server Information Store - [MAPI_E_FAILONEPROVIDER(8004011D)]]

The MAPI_E_FAILONEPROVIDER error appears to be fairly generic and I couldn’t find anything on the Microsoft Knowledge Base that matched my scenario.

In the end the problem turned out to be a by-product of my Exchange 2010 SP1 environment not having any Public Folders.  Apparently the MAPI CDO client will by default look for Public Folders when accessing the mailbox and will throw the error if it can’t find any. 

The fix is to add a registry key to the server running MAPI CDO that sets a flag (CONNECT_IGNORE_NO_PF) that instructs the client to ignore the absence of Public Folders.

  1. On the computer running Microsoft Exchange MAPI and CDO 1.2.1, click Start > Run.
  2. In the Open field, type regedit.
  3. Click OK.
  4. Perform one of the following actions:
    • If you are running a 32-bit version of Windows, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Messaging Subsystem\CDO.
    • If you are running a 64-bit version of Windows, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows Messaging Subsystem.

  5. If the CDO registry key does not exist, create a registry key that you name CDO.
  6. In the CDO registry key, if the DWORD value does not exist, create a DWORD value that you name Ignore No PF.
  7. Change the DWORD value to 1.
  8. Click OK.

Source: Technet

Interestingly, the only references I could find to the “Ignore No PF” key were some MSDN and Technet blogs and the support documentation for Blackberry Enterprise Server.  There is currently nothing available in the Microsoft on-line documentation, including the Knowledge Base (at least nothing I could find). Given that Public Folders are being “de-emphasised” within Exchange I would have thought this workaround would be given much more prominence.