EWS Error Accessing Public Folders – Exchange 2010 With Replicated Exchange 2003 Public Folders

exchange-serverexchangewebservices

We currently have the following setup:

Single Exchange 2003 Server – Also Running the Exchange 2010 Public Folder Database
Single Exchange 2010 Server – Also Running the Exchange 2010 Public Folder Database & Client Access role (e.g. with EWS, OWA, etc..)

We have public folders held on 2010 and public folders held on 2003. We are replicating the public folders both ways between servers (configured through the public folder management console).

We have a test account with a mailbox on Exchange 2010 that has the highest level of privileges (domain admin and also “organization management” within Exchange). This user is called “grey”. The user has been granted explicitly full ownership of all public folders in both the 2010 public folder database and the 2003 public folder database. We can confirm that we can access and use the public folders perfectly OK through OWA and also Outlook.

The problem we are having is accessing the public folders through Exchange. We can confirm that accessing normal folders within the mailbox itself is not an issue and is working fine.

When running the following simple code snippet to loop through the public folders we are hitting an error:

    public static void PublicFolderTest()
    {
        // Connect to Exchange Web Services 
        ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010);
        service.Url = new Uri("https://gblonxch11/EWS/Exchange.asmx");
        service.Credentials = new WebCredentials("grey@home.local", "Welcome1");
        System.Net.ServicePointManager.ServerCertificateValidationCallback = ((sender, certificate, chain, sslPolicyErrors) => true);

        FolderView folderView = new FolderView(int.MaxValue);

        FindFoldersResults findResults = service.FindFolders(WellKnownFolderName.PublicFoldersRoot, folderView);

        if (findResults.Folders.Count > 0)
        {
            Console.WriteLine("Looping Through Public Folders");
        }

    }

This code snippet is failing with the FindFolders call with the following error stack:

Microsoft.Exchange.WebServices.Data.ServiceResponseException was unhandled
Message=The mailbox that was requested doesn't support the specified RequestServerVersion.
Source=Microsoft.Exchange.WebServices
StackTrace:
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ProcessWebException(WebException webException)
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.InternalExecute()
       at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
       at Microsoft.Exchange.WebServices.Data.ExchangeService.InternalFindFolders(IEnumerable`1 parentFolderIds, SearchFilter searchFilter, FolderView view, ServiceErrorHandling errorHandlingMode)
       at Microsoft.Exchange.WebServices.Data.ExchangeService.FindFolders(FolderId parentFolderId, FolderView view)
       at Microsoft.Exchange.WebServices.Data.ExchangeService.FindFolders(WellKnownFolderName parentFolderName, FolderView view)
       at testspace.Program.PublicFolderTest() in F:\Source Code\TestApp\TestApp\Program.cs:line 40
       at testspace.Program.Main(String[] args) in F:\Source Code\TestApp\TestApp\Program.cs:line 26
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: 

We have also turned on “Failed Request Tracing” in IIS for the EWS application. The internal stack trace is attached as file “UsingExchangeVersion2010.zip”. The error stack is inconclusive – but there are errors relating to authentication issues internally in the stack.

We also tried setting the ExchangeVersion used by the EWS managed API to be Exchange2007_SP1:

    public static void PublicFolderTest()
    {
        // Connect to Exchange Web Services 
        ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2007_SP1);
        service.Url = new Uri("https://gblonxch11/EWS/Exchange.asmx");
        service.Credentials = new WebCredentials("grey@home.local", "Welcome1");
        System.Net.ServicePointManager.ServerCertificateValidationCallback = ((sender, certificate, chain, sslPolicyErrors) => true);

        FolderView folderView = new FolderView(int.MaxValue);

        FindFoldersResults findResults = service.FindFolders(WellKnownFolderName.PublicFoldersRoot, folderView);

        if (findResults.Folders.Count > 0)
        {
            Console.WriteLine("Looping Through Public Folders");
        }

    }

This results in an error but a slightly different error:

Microsoft.Exchange.WebServices.Data.ServiceResponseException was unhandled
Message=An internal server error occurred. The operation failed.
Source=Microsoft.Exchange.WebServices
StackTrace:
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ProcessWebException(WebException webException)
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.InternalExecute()
       at Microsoft.Exchange.WebServices.Data.MultiResponseServiceRequest`1.Execute()
       at Microsoft.Exchange.WebServices.Data.ExchangeService.InternalFindFolders(IEnumerable`1 parentFolderIds, SearchFilter searchFilter, FolderView view, ServiceErrorHandling errorHandlingMode)
       at Microsoft.Exchange.WebServices.Data.ExchangeService.FindFolders(FolderId parentFolderId, FolderView view)
       at Microsoft.Exchange.WebServices.Data.ExchangeService.FindFolders(WellKnownFolderName parentFolderName, FolderView view)
       at testspace.Program.PublicFolderTest() in F:\Source Code\TestApp\TestApp\Program.cs:line 40
       at testspace.Program.Main(String[] args) in F:\Source Code\TestApp\TestApp\Program.cs:line 26
       at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.nExecuteAssembly(RuntimeAssembly assembly, String[] args)
       at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
       at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
       at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Threading.ThreadHelper.ThreadStart()
  InnerException: 

The stack trace internally within IIS for the EWS is attached as file “UsingExchangeVersion2007.zip”. Again the internal stack trace is inconclusive – but again appears to be related to authentication issues.

Can anyone advise whether this has been seen before and perhaps what the root cause might be?

Best Answer

I can see several problems here:

  1. First of all, you cannot a have super-user account in Exchange 2007 and 2010 to access mailboxes. If a user is a member of any Exchange administrative groups, he will be explicitly denied to access mailboxes via the EWS API. He can be a Domain Admin or Local Admin though. So check the account you use in EWS isn't.

  2. In mixed environments like yours - 2003 & (2007 or 2010) having a CAS server on 2010 doesn't mean you can access 2003 mailboxes from EWS. The only way to do that is to migrate the mailbox from 2003 storage to 2007 storage. This is probably the reason you get the first exception, as well as the second one.

  3. I'm not really sure how Public Folders are working internally in Exchange, never worked with them, but I can suggest this is just a special kind of a mailbox. In this case your user has to have the impersonation permission. Granting full-access from exchange console won't help - it was enough only in 2007. Here is a link how to turn on impersonation in 2010: http://msdn.microsoft.com/en-us/library/bb204095.aspx

Welcome to Exchange world.

Related Topic