none
Running code using EWS developed against Exchange Server 2013 on MS Exchange Server 2010 RRS feed

  • Question

  • Hi there,

    I designed and specified a small software product, hiring third party Microsoft developers to build it . The software, developed using .Net framework, makes extensive use of the data held on MS Exchange Server, accessing it via EWS.  I have sold the software to my first customer, but we are stuck because the customer is unable to progress beyond the login screen getting 'user not found' whatever we try in order to log in. I have hired a 'heavy hitter' in an attempt to resolve the problem (which we originally suspected was to do with SSL. However, having run  a battery of tests he has concluded: 'If the tests at the Microsoft site are now all passing [which they are], that would kind of rule out an issue with Exchange. It would then be something that the application is doing that works fine on later versions of Exchange.'

    The area under suspicion now is around MS Exchange Server versions. The software company developed the product against MS Exchange Server 2013 whereas my customer is running  MS Exchange Server 2010. I have found a statement on Microsoft Docs (see section about EWS-operations0in-exchange) that says work against Exchange versions is forward compatible: 'The versioned schemas are implemented so that clients that are designed against an older version of EWS will work with a newer version of EWS.' However, I have not been able to find  a statement confirming the reverse i.e. that clients designed to work with a newer version of EWS will be able to work with an older version. NB all software is on-premise - not Office 365.

     

    Is anyone there able to confirm the position for us please?

    Regards

    William

    Monday, December 2, 2019 3:33 PM

Answers

  • Hi Glen,

    After a long period of silence the customer has finally re-engaged (today 26th Feb 2020). We have added the Bind as you suggested plus some other diagnostics, such as more varied error messaging throughout the login and credential checking process. However, we are yet to send this version of the code to the customer, so we are no further along with our exploration of the bind at this stage. 

    Instead, the client ran the cmdlet to prove whether RoomList was present on their environment or not - one of our favoured theories. They found that it was indeed missing. Since adding it they have been seeing a healthy response when executing the cmdlet - see the file image001.png within the folder Confero_20200226 here: https://www.dropbox.com/sh/x0y5a2qmz84k3nl/AADIp-3xrXdkLYWcTxKcIBewa?dl=0

    Now, for the first time since October, we are beyond the original 'User not found' error. But we are seeing a new one - around an an Object reference this time (see ObjRefSshot20200226). We asked the customer to log in again and to share the log file which they have (see txt file 2020-02026(1)). This is back with the developers now, bit any insights or suggestions you may have would - as always - be gratefully received.

    Kind Regards


    Bill 


    WilliamIrvine5

    Wednesday, February 26, 2020 2:21 PM
  • That error means your trying to perform an Action on an object that is null at runtime. Which means its a bug in the code (eg the code got a response it didn't expect (or couldn't deal with) so the object is null etc).
    Friday, February 28, 2020 1:21 AM

All replies

  • >> 'user not found'

    This isn't an EWS error, possibly auto-discover but a very easy fix would be for you to include an option for people to specify the EWS URL rather then using Autodiscover .

    As for versions there are operations in Exchange 2013 that where introduced in 2013 (and some 2013 SP1) that won't work on 2010 . So It depends what operations your using and what your software is doing and also how the underlying code is written. However for the most part a simple application (eg Create,Read,Update,Delete) email written in EWS will work for 2007 to 2016 as long as its coded to do so. Probably the best example is the EWSEditor https://github.com/dseph/EwsEditor/releases which like most .NET apps uses the EWS Managed API, has everything you need to test the underlying operation of EWS (and Autodiscover) at any site and will work from 2007 to Office365.

    >>. 'If the tests at the Microsoft site are now all passing [which they are], that would kind of rule out an issue with Exchange. It would then be something that the application is doing that works fine on later versions of Exchange.'

     So if your problem is on Exchange 2010 why didn't they test it against that version (goes the same for the original developers if that is your target customer)? It isn't that hard to create a simple VM test environment running Exchange 2010 to test.

    Cheers
    Glen

    Monday, December 2, 2019 10:58 PM
  • Many thanks Glen,

    I'll refer your comments to the developers and ask that thy progress your suggested workaround.

    Kind Regards

    Bill


    Wednesday, December 4, 2019 11:01 AM
  • Hi Glen,

    The developers have confirmed that the URL - rather than Autodiscover - is already used.

    Following your response, they have been trying to establish a simple VM test environment running Exchange 2010 to test our application (developed against Exchange 2013). They have made a couple of attempts, but have had difficulties establishing the Exchange 2010 VM. Are you able to point them to a relevant link(s)?

    Kind regards

    Bill 

    Wednesday, December 18, 2019 10:48 AM
  • user not found is still not an EWS I would suggest you ask for a Trace of the EWS request that produces the error https://docs.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-trace-requests-responses-to-troubleshoot-ews-managed-api-applications and then post the trace here (removing any personal identifying information).

    Exchange 2010 is still available vai the MSDN/Visual Studio subscriptions 

    https://my.visualstudio.com/downloads

    Wednesday, December 18, 2019 10:31 PM
  • Thanks Glen,

    Apologies for the delay responding - which of course is to do with the time of year.

    The server administrator restarted the server and then captured the below trace (enabled by the developers using the instructions you sent):

    <Trace Tag="EwsRequest" Tid="34" Time="2020-01-07 15:33:01Z" Version="15.00.0913.015"> <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <t:RequestServerVersion Version="Exchange2010_SP1" /> </soap:Header> <soap:Body> <m:GetRoomLists /> </soap:Body> </soap:Envelope> </Trace>

    It doesn't seem to tell us much. FYI we have another trace from the IIS Server log that provides a little more info:

    2019-10-24 00:00:05.4212 DEBUG Start CheckRoomStatuses [] []
    2019-10-24 00:00:05.4212 DEBUG Finished CheckRoomStatuses [] []
    2019-10-24 00:00:21.8016 ERROR Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. Unable to connect to the remote server ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 10.9.8.114:443
       at System.Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult)
       at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
       at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
       --- End of inner exception stack trace ---
       at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
       at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult)
       at Microsoft.Exchange.WebServices.Data.EwsHttpWebRequest.Microsoft.Exchange.WebServices.Data.IEwsHttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult) in \\REDMOND\EXCHANGE\BUILD\E15\15.00.0913.015\SOURCES\sources\dev\EwsManagedApi\src\EwsManagedApi\Core\EwsHttpWebRequest.cs:line 79
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.EmitRequest(IEwsHttpWebRequest request) in \\REDMOND\EXCHANGE\BUILD\E15\15.00.0913.015\SOURCES\sources\dev\EwsManagedApi\src\EwsManagedApi\Core\Requests\ServiceRequestBase.cs:line 413
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.BuildEwsHttpWebRequest() in \\REDMOND\EXCHANGE\BUILD\E15\15.00.0913.015\SOURCES\sources\dev\EwsManagedApi\src\EwsManagedApi\Core\Requests\ServiceRequestBase.cs:line 790
       --- End of inner exception stack trace ---
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.BuildEwsHttpWebRequest() in \\REDMOND\EXCHANGE\BUILD\E15\15.00.0913.015\SOURCES\sources\dev\EwsManagedApi\src\EwsManagedApi\Core\Requests\ServiceRequestBase.cs:line 803
       at Microsoft.Exchange.WebServices.Data.ServiceRequestBase.ValidateAndEmitRequest(IEwsHttpWebRequest& request) in \\REDMOND\EXCHANGE\BUILD\E15\15.00.0913.015\SOURCES\sources\dev\EwsManagedApi\src\EwsManagedApi\Core\Requests\ServiceRequestBase.cs:line 687
       at Microsoft.Exchange.WebServices.Data.GetRoomListsRequest.Execute() in \\REDMOND\EXCHANGE\BUILD\E15\15.00.0913.015\SOURCES\sources\dev\EwsManagedApi\src\EwsManagedApi\Core\Requests\GetRoomListsRequest.cs:line 85
       at Microsoft.Exchange.WebServices.Data.ExchangeService.GetRoomLists() in \\REDMOND\EXCHANGE\BUILD\E15\15.00.0913.015\SOURCES\sources\dev\EwsManagedApi\src\EwsManagedApi\Core\ExchangeService.cs:line 2813
       at WF_ExchangeAPI.ExchangeContext.GetRoomList() in C:\Jenkins\workspace\WFH-Laptop\WF_ExchangeAPI\ExchangeContext.cs:line 49
       at BBWT.Web.MvcApplication.CheckRooms(String k, Object v, CacheItemRemovedReason r) in C:\Jenkins\workspace\WFH-Laptop\Web\BBWT.Web\Global.asax.cs:line 325 [] []
    2019-10-24 00:00:39.8201 WARN Task:24/10/2019 00:00:39 [] []
    2019-10-24 00:00:43.8606 DEBUG Aggregating records in 'Counter' table... [] []
    2019-10-24 00:00:51.7700 DEBUG Removing outdated records from table 'AggregatedCounter'... [] []
    2019-10-24 00:00:51.7700 DEBUG Removing outdated records from table 'Job'... [] []
    2019-10-24 00:00:51.7700 TRACE Removed 1 outdated record(s) from 'Job' table. [] []
    2019-10-24 00:00:52.7840 DEBUG Removing outdated records from table 'List'... [] []
    2019-10-24 00:00:52.7840 DEBUG Removing outdated records from table 'Set'... [] []
    2019-10-24 00:00:52.7840 DEBUG Removing outdated records from table 'Hash'... [] []
    2019-10-24 00:01:01.8634 ERROR Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. Unable to connect to the remote server ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 10.9.8.114:443
       at System.Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult)
       at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
       at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
       --- End of inner exception stack trace ---


    We captured a Wireshark log as well but it didn't give us any more info than the IIS Log entries provide. I have prepared a 3-page summary of all steps that we have taken in our attempts resolve this issue. If it would help, please let me know where to send it to you - my eMail address is info@wheresfree.com

    FYI - the developers, Blueberry, have been struggling to establish Exchange Server 2010 despite the instructions and help provided here: https://bit.ly/2Fpnh9T

    Happy New Year - I'm sure we'll get there!

    Kind Regards


    Bill


    WilliamIrvine5

    Tuesday, January 7, 2020 4:17 PM
  • 2019-10-24 00:00:21.8016 ERROR Microsoft.Exchange.WebServices.Data.ServiceRequestException: The request failed. Unable to connect to the remote server ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 10.9.8.114:443

    This error is very different from what you have reported before and indicates it not really an EWS error. Basically the Exchange server hasn't even processed the SOAP request that is being sent. This is the type of error you would see if you got blocked by a firewall or proxy server. I would try some simple tests like trying to access OWA from the machine where you trying to run the code. It could be they have put IP restrictions in IIS on the EWS virtual directory (which would affect Outlook so its not something you would expect to see)

    Tuesday, January 7, 2020 11:28 PM
  • Thanks Glen,

    Apologies, I should have clarified the context to that trace (dated 24th Oct) - the IIS Log error logged/quoted above was subsequently investigated and a DNS error identified. The error was resolved on the 27th November but the User Not Found issue persisted. We ran test-webservicesconnectivity at that point and it was successful.  We have also proven the customer's set-up by using UPN suffixes successfully, by running https://testconnectivity.microsoft.com/  and by confirming that OWA logs in correctly.  

    The conclusion by 2nd December was that 'If the tests at the Microsoft site are now all passing, that would kind of rule out an issue with Exchange. It would then be something that the application is doing that works fine on later versions of Exchange.' The finger of suspicion has been around running code developed and proven against Exchange Server 2013 with Exchange Server 2010. At that point we initiated this dialogue on Technet.

    Kind Regards

    Bill 


    WilliamIrvine5

    Wednesday, January 8, 2020 3:57 PM
  • You posted the Trace request if the Exchange server is responding with the "user not found error" then there would be a Trace response ?. Otherwise the errors probably being generated by the code because of issues with your exception/error processing. 

    The other thing is that on Exchange there are no RoomLists by default these need to created first eg (New-DistributionGroup -Name "Rooms List 1" –RoomList). So that request run against any Exchange server would always return an empty list unless an administration has created some room list to use. (People confuse address book views in the GAL with Room lists these are separate things). 

    Thursday, January 9, 2020 11:36 PM
  • Hi Glen,

    Thanks for responding. The 'User not known' error message is produced by our app's code at the point of login. I've created a detailed problem statement around this specific area in case it helps:

    https://www.dropbox.com/s/5esppziuh7t14ts/Logon%20Problem%20Statement%2020200117.docx?dl=0

    I am moving towards the view that the admin user accounts recognised by Confero's Exchange server and those provided by our install pack don't match. Any checks you can suggest that we might perform would be appreciated.  

    Kind Regards

    Bill


    WilliamIrvine5

    Friday, January 17, 2020 2:53 PM
  • >>Thanks for responding. The 'User not known' error message is produced by our app's code at the point of login.

    Okay so from a troubleshooting prospective this error has no relevance to finding a fix for your issue because its only useful to somebody looking at your code. The other problem is that all that does is tell you it hit a certain point in a code branch. How it got there and what generated the original error would be more useful information. Eg for instance what was the last request done against the server was it Autodiscover or a particular EWS request and what was the response to that. >>I am moving towards the view that the admin user accounts recognised by Confero's Exchange server and those provided by our install pack don't match. Any checks you can suggest that we might perform would be appreciated.

    Probably the easiest way to test that is logon to OWA with the credentials your trying to use in your code. If the usernames and different from Email address and your trying to use the email address to logon the it will always fail. Also the EWS editor https://github.com/dseph/EwsEditor/releases will allow you to test the credentials and EWS outside of anything your code is doing and if you get errors using this then these error are a lot more useful to pointing to what might be wrong.

    Sunday, January 19, 2020 11:15 PM
  • Thanks Glen,

    I suspect the customer - who after all is only on a free trial - is close to giving up on us (if they haven't already). I've not been getting responses to my more recent communications to them.

    I will however appeal to them to try one more thing. Would you mind reviewing this recent dialogue between myself and the developers, which you may find informative:

     https://www.dropbox.com/s/jxxkr979s74meqb/PTS196634_Confero_Login_error-msg_20200128.docx?dl=0

    Do you agree we should prioritise the GetList test proposed by the developers at the bottom of the thread?  

    Kind Regards

    Bill


    WilliamIrvine5

    Tuesday, January 28, 2020 8:14 AM
  • Glen,

    I should have added that we have tried the OWA connectionon a previous occasion and it works OK.

    Kind Regards

    Bill


    WilliamIrvine5

    Tuesday, January 28, 2020 8:21 AM
  • My suggestion would be (probably more for you future customers) is create a a debug mode for your application and get it to write to detailed debug information for each operation it does. You have to much guessing between the developer and support and it seems nobody is really sure what is actually happening. A detailed debug log would show you exactly what is happening.Also

    >>

    When we are trying login to Exchange, we are using GetRoomList(). If the Exchange server has not been configured properly, this function may raise an exception. 

    If that's the case maybe before you use GetRoomList do a simple Bind to the Inbox Folder to validate the EWS connection and Mailbox access (and log that to the debug file) it just one simple request. At least at that point you know the underlying EWS connection is working correctly and its just this one operation that is the problem.

    Having a good debug log and some simple validation would have saved you a lot of debug time. At the very least you should tell them to fix the error message which doesn't seem to relate to the problem.

    Tuesday, January 28, 2020 11:38 PM
  • Thanks Glen,

    I've shared your response with the developer and they have provided this log - one showing a successfully login with a valid username and another failing because they used an invalid username. The target system in both cases was our test and demo implementation, not Confero's live environment.

    https://www.dropbox.com/s/g7dfn9zj2lslu9s/Error%20messages%20-%20196634.docx?dl=0

    Does this tell us anything? or are there other diagnostics we should try?

    Kind Regards

    Bill


    WilliamIrvine5

    Monday, February 3, 2020 1:23 PM
  • Its a good start it tells you that the credentials are okay and you can connect to the Mailbox successfully. In the case of the failed logon a 401 is the standard error message that tells you the credentials are bad (either username or password) at that point it need to go back to the operator the validate. 

    Cheers
    Glen

    Monday, February 3, 2020 10:46 PM
  • Thanks Glen,

    What this latest test confirms is that Where’s Free works as expected on our test environment (Exchange server 2013). It seems the developers’ code is OK.

    A number of tests already conducted on the customer’s (Confero’s) environment all pass – notably:

    1.  https://testconnectivity.microsoft.com 

    2.  SSL Test Report for: mail.confero.co.uk gives an ‘Overall rating A’

    3. Connecting over OWA

    4. The administrator has also confirmed that Microsoft windows firewall is used without any third party products.

    The "user not found" problem therefore only arises when we try to run the code that runs fine on our test environment on Confero’s environment.

    According to our developers:

    ‘The algorithm of the login function is as follows:
    1. Try finding a user in Exchange
    2. Try finding a user in the WhF database
    3. If both items are completed, check the user credentials
    4. If only item 1 is fulfilled, add a new user to the WhF database
    But in our case even the first step, item 1, is not fulfilled.
    We can only get the "user not found" error if the user was not found in Exchange or an exception occurred while searching for it.’

    The code executes step 1 fine on our environment, but not on Confero’s (where we also know there is no issue connecting using Confero’s user credentials conf_exch@confero.co.uk. Then doesn’t it suggest that some component that step 1 relies on being present on Confero’s platform is missing from their environment?

    Question 1. GetRoomList () might be one such candidate – are there others?

    Question 2. Is there anything else we could put in our code to expose values or failure messages that would help us get to the bottom of this issue?

    Kind Regards

    Bill


    WilliamIrvine5

    Tuesday, February 4, 2020 4:55 PM
  • What does the log from https://www.dropbox.com/s/g7dfn9zj2lslu9s/Error%20messages%20-%20196634.docx?dl=0 look like when the application is run in the customer environment ?

    This is the only answer I would focus on the moment as this is just a simple bind to a user Inbox over EWS. 

    If this is successfully then proceed to try and work out Question 1 and 2 otherwise it feels like you going in circles about the higher logic in the app.

    Tuesday, February 4, 2020 11:32 PM
  • Hi Glen,

    After a long period of silence the customer has finally re-engaged (today 26th Feb 2020). We have added the Bind as you suggested plus some other diagnostics, such as more varied error messaging throughout the login and credential checking process. However, we are yet to send this version of the code to the customer, so we are no further along with our exploration of the bind at this stage. 

    Instead, the client ran the cmdlet to prove whether RoomList was present on their environment or not - one of our favoured theories. They found that it was indeed missing. Since adding it they have been seeing a healthy response when executing the cmdlet - see the file image001.png within the folder Confero_20200226 here: https://www.dropbox.com/sh/x0y5a2qmz84k3nl/AADIp-3xrXdkLYWcTxKcIBewa?dl=0

    Now, for the first time since October, we are beyond the original 'User not found' error. But we are seeing a new one - around an an Object reference this time (see ObjRefSshot20200226). We asked the customer to log in again and to share the log file which they have (see txt file 2020-02026(1)). This is back with the developers now, bit any insights or suggestions you may have would - as always - be gratefully received.

    Kind Regards


    Bill 


    WilliamIrvine5

    Wednesday, February 26, 2020 2:21 PM
  • That error means your trying to perform an Action on an object that is null at runtime. Which means its a bug in the code (eg the code got a response it didn't expect (or couldn't deal with) so the object is null etc).
    Friday, February 28, 2020 1:21 AM