There’s not much information on this error around so I figured I’d blog about it in the hope it might help someone in the future who may come across the same error and one possible answer that may help.

 

Scenario:

A customer raised a service request to Microsoft who reported some issues using the Findfolders method from exchange web services. Quite simply this method does just that, FindFolders..against an exchange store.

In this customers case what was odd about this problem is that they had recently migrated from an exchange 2003 to exchange 2010 and their exchange code, using the 1.1 Managed API they were using to bring back this data just didn’t work.

The folders had been replicated using Public Folder Manager and the core issue it was to do with accessing public folders that have been replicated from 2003 to 2010 and accessing these public folders using EWS via the 2010 server.

 

The customer had public folders held on 2010 and public folders held on 2003. They were replicating these public folders both ways between servers (configured through the public folder management console). They were using a test account with a mailbox on Exchange 2010 that had the highest level of privileges (domain admin and also “organization management” within Exchange), with the account having been granted explicitly full ownership of all public folders in both the 2010 public folder database and the 2003 public folder database. Accessing the public folders worked fine through Exchange and normal folders within the mailbox itself was not an issue.


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

public static void PublicFolderTest()
{
// Connect to Exchange Web Services
ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2010);
service.Url = new Uri("https://##servername##/EWS/Exchange.asmx");
service.Credentials = new WebCredentials(“#useraccount#”, "##password##");
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:

The errors were relating to authentication issues internally in the stack. We also tried setting the ExchangeVersion used by the EWS managed API to be Exchange2007_SP1 e.g.

// Connect to Exchange Web Services
ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2007_SP1);


This resulted in an 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:


Again the internal stack trace is inconclusive – but appeareds to be related to authentication issues. The customer raised the issue in various forums before contacting Microsoft and we spent some time trying to figure out what was happening.

 

Troubleshooting process:

EXBPA is always a good tool to determine if the server is in a healthy state

Checked event logs to determine any error event ids that may help in identifying the problem

Wireshark network trace used to determine the underlying error message and what was occurring at the time of failure from the callback to the exchange store.

Extra – Powerful Inbuilt tracing mechanisms that exchange uses

EWS Editor to reproduce the problem outside the customers code environment.

 

The problem was down to a config issue - the customer was using both his exchange servers and It looked like it gets returned when it tries to proxy to a server of the wrong version, they had two servers, both with a PF store - one is 2003  one is 2010

We disovered that the 2010 DB was pointing to a 2003 store so we repointed it to the 2010 PF store and connection using EWSEditor started working and so did the tests with the code.