Sign in
 
HomeOnline20132010Other VersionsLibraryForumsGalleryEHLO Blog
TechCenter >
> 
> 
[E2010SP1] [EWSMA] [C#] [Windows 2003]: Can't access Exchange Server - always getting 401 - why?

Unanswered [E2010SP1] [EWSMA] [C#] [Windows 2003]: Can't access Exchange Server - always getting 401 - why?

  • Thursday, August 16, 2012 6:42 PM
     
      Has Code
    Sign In to Vote
    0

    This is very strange:

    while connecting to Exchange Server 2010 SP1 from an ASP.NET web application I always receive a 401 error:

    The request failed. The remote server returned an error: (401) Unauthorized.

    When running EWSEditor on the same web server using the same credentials and connection settings, I receive a 403 Forbidden instead.

    This is the code I'm using:

    // Benutzer für Postfach setzen
_exchange.UseDefaultCredentials = false;
_exchange.Credentials = new WebCredentials(smtpAddress, password);
// if in test mode, trust all certificates
if (_isTestEnvironment) ServicePointManager.ServerCertificateValidationCallback = CertificateValidationCallBack;
// Exchange Server-Adresse manuell ermitteln
_exchange.Url = new Uri(_providerRootIRI);
Folder exFolder;
exFolder = (path == null) ? Folder.Bind(_exchange, WellKnownFolderName.Inbox) : GetFolderByPath(path);
    What am I doing wrong?

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

     

All Replies

  • Friday, August 17, 2012 1:00 PM
     
     
    Sign In to Vote
    0

    It might help to see the IIS log entries - there are several different types of 401 and 403 response.

    But - I see you have

    _exchange.Credentials = new WebCredentials(smtpAddress, password);

    now, I know that many peoples' smtp addresses are the same as their UPN, and this would normally work.  But it's supposed to be either a username or a UPN.  So if your UPNs are in .local (for example), then using your smtp address (which will obviously not be in .local) will not authenticate properly.  You are using the 3rd constructor here:

    http://msdn.microsoft.com/en-us/library/microsoft.exchange.webservices.data.webcredentials.webcredentials(v=exchg.80)

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Friday, August 17, 2012 5:41 PM
     
     
    Sign In to Vote
    0

    Thanks for trying to help!

    It's the standard 401 (no sub category like 401.1 involved).

    Unfortunately I don't know enough about networking to understand your hint about the WebCredentials.

    Our web server is a standalone Workgroup machine while our Exchange Server machine is residing in a domain.

    What would you suggest to use in order to connect to the Exchange server?

    There's another thing that I should mention: When we enter the credentials of one of my colleagues into EWSEditor (running at our web server machine), we can flawlessly connect. But if we enter the same credentials into our web application on the same machine, we again always get a 401 error.

    I've been debugging EWSEditor and our web application simultaneously to see if there are any differences in the ExchangeService object. But I could not find any differences in any of the properties, including the credentials' data.

    But what's odd is that EWSEditor, when running at the web server machine, is extremely slow when retrieving data for my colleague's mailbox. It takes about 30 seconds for each Exchange Server request to be displayed in EWSEditor. Does this perhaps ring a bell?

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

    • Edited by BetterToday Friday, August 17, 2012 5:44 PM
    •  
     
  • Monday, August 20, 2012 12:13 PM
     
     
    Sign In to Vote
    0

    There's always a subcategory, but it just isn't being reported in your error message.  It will be there in the iis log entries, evenif it's a zero (which is actually undefined, but is sometimes returned by lazy isapi coders).

    Since the web server is in a workgroup, it might help to construct the webcredential slightly differently, specifying a domain name:

    _exchange.Credentials = new WebCredentials(username, password, domainname);

    The domain name obviously needs to be the domain containing the exchange server, and the username is a valid mailbox user in that domain.

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Monday, August 20, 2012 12:31 PM
     
     
    Sign In to Vote
    0

    Thanks again, Lee.

    I'm afraid, I can't follow you: Why should the client IIS of the machine where I'm running my ASP.NET web application and EWSEditor do log EWS errors? It isn't even involved in an EWS call.

    Nonetheless, however, I have been looking in the IIS logs where I'm running the web application. I wasn't able to find any errors in there.

    I'm now trying to add a domain to the call. I'll keep you informed on the outcome.

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

     
  • Monday, August 20, 2012 12:43 PM
     
     
    Sign In to Vote
    0
    I'm talking about the iis log of the server handling the ews calls :-)  You will know, of course, that IIS on the CAS server handles EWS calls.  If it is returning 401 to you, then it's just saying that the Exchange server returned a 401 when the application tried to access it.  All requests go in the iis log file, success or not.  If it accepted the credentials, then they will appear in the log entry.  That means that the credentials were valid for the domain, but some other iis restriction caused the denial.  If there are no credentials logged, then that means they weren't even valid.

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Monday, August 20, 2012 1:49 PM
     
     
    Sign In to Vote
    0

    Thanks, Lee, I see now.

    Unfortunately I'm working against the production environment. The whole setup I'm facing is quite quirky: Our team doesn't have an SLA with the infrastructure team so far. So we don't get any Exchange Server support whatsoever. I have initiated to get such SLA but this will take a few months... So I currently don't get any helpful support from the infrastructure team. (I guess it's a Jersey thing ...)

    So I unfortunately currently don't get any EWS IIS log information. I'll have to poke about in the fog until it works.

    ...

    So I now have tried connecting by adding the domain information to the WebCredentials constructor. Unfortunately this didn't work. - I should add that I didn't need to add domain information to the EWSEditor connection dialog to make it work.

    As I said, I can't see any difference between how my web application connects to the Exchange Server and how EWSEditor connects to the Exchange Server. I had examined all the ExchangeService properties on both programs. Yet, EWSEditor is able to connect, whereas my web application receives a 401.

    What could possibly make a difference between a plain executable file and an IIS hosted web application in regard to establishing a connection to EWS?

    Your help is very much appreciated.

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

     
  • Monday, August 20, 2012 2:01 PM
     
     
    Sign In to Vote
    0

    Here's one more piece of information:

    When I had been testing my implementation at a domain development machine, everything worked fine for the first few days. So I know, my code is properly implemented.

    But after a couple of days someone at the infrastructure team must have re-configured something at the Exchange Server. From that day on, my implementation didn't work at any machine, neither at the development machine (using Visual Studio and WebDev web server) in the domain nor at the web server (IIS)  in the work group.

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

    • Edited by BetterToday Monday, August 20, 2012 2:03 PM
    • Edited by BetterToday Monday, August 20, 2012 2:05 PM
    •  
     
  • Monday, August 20, 2012 2:16 PM
     
     
    Sign In to Vote
    0

    That's why it would help to see the iis log entries.  The subcode helps to narrow down the cause a little, but it is never returned by IIS to any client application, which is why the error message you get from ASP.Net is so vague.  It is only telling you what little information it has to work with.

    http://support.microsoft.com/kb/907273

    Is EWS Editor definitely working for you now?  In your first post, you were getting a 403 (again about 20 different possible causes for that).  But if it's working now, then that is a cause for optimism.

    BTW, when I suggested this:

    _exchange.Credentials = new WebCredentials(username, password, domainname);

    please note that you should not enter the username in a username@domain.com form (i.e. the UPN, which is sometimes the same as the smtp address).  It should just be the username part.  Again, it would be so good to see the iis logs, since then we'd see how, or even if, the CAS server accepted the credentials.

    But anyway, most importantly, is EWS Editor working right now?

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Monday, August 20, 2012 3:05 PM
     
     
    Sign In to Vote
    0

    I now tried to leave out the "@domain.com" from the login, but still to no avail.

    I have three users here to test with:

    1. my.technical.user@domain.com
    2. other.technical.user@domain.com
    3. human.user@domain.com

    And here are the results I get from EWSEditor and our web application:

    Account Name SMTP Address Web Application EWS Editor
    mtu@domain.com my.technical.user@domain.com 401 403
    other.technical.user@domain.com other.technical.user@domain.com 401 401
    human.user@domain.com human.user@domain.com 401 working

    The 403 is thrown in EWSEditor while it's executing TestExchangeService().

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

     
  • Monday, August 20, 2012 3:16 PM
     
     
    Sign In to Vote
    0

    Here are two screenshots from the EWSEditor session using our technical user's credentals:

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

     
  • Monday, August 20, 2012 3:16 PM
     
     
    Sign In to Vote
    0

    When EWS Editor works, from the File menu, do you use 'Open Default Exchange Service', or 'New Exchange Service'.  I assume it's 'New...', since you are accessing EWS from a workgroup, and I can't imagine that 'Default...' would work at all.  But let me know if somehow it does.

    So, assuming you select 'New...' do you leave 'Use Autodiscover...' checked?

    I assume you also have to select 'Use the following credentials...' (because you are accessing from a workgroup)?  What do you put in there?  user@domain.com + password , or user + password + domain ?

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Monday, August 20, 2012 3:18 PM
     
     
    Sign In to Vote
    0

    Okay, thanks.  ignore my last post for a moment.

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Monday, August 20, 2012 3:25 PM
     
     
    Sign In to Vote
    0

    Is this the first thing it tries to do?  In your first post, it looks like the first thing it tries to do is to bind to the inbox.  Does that actually work okay, or has the code changed since then?

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Monday, August 20, 2012 4:15 PM
     
     
    Sign In to Vote
    0

    The screenshot you see came from EWSEditor.

    The code I posted above, however, was my own code I used in the web application.

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

     
  • Monday, August 20, 2012 7:16 PM
     
     
    Sign In to Vote
    0

    Oh, right.  I thought the TestExchangeService code was your own - I've never seen a screen showing code like that in EWS Editor.

    Anyway, here's something to try.  I have some generic code that sends EWS requests to a server name that you put into a textbox.  Stick the code below into a text file (using Notepad) and save it into an .htm file so that when you double-click it, it will open in a browser.  Supply a server name, and click GO.  It should ask you for some credentials, and then show the results in the bottom text box.

    <html>
    <head>
    <script language="VBScript">

    Dim objXMLHTTP, objXMLDoc

    Sub go_OnClick()
      strProtocol = document.all.protocol.value
      strServerName = document.all.server.value
      strURL = strProtocol & "://" & strServername & "/EWS/Exchange.asmx"
      Set objXMLHTTP = CreateObject("Microsoft.XMLHTTP")
      objXMLHTTP.Open "POST", strURL, True
      objXMLHTTP.setRequestHeader "Content-type:", "text/xml"
      objXMLHTTP.onReadyStateChange = getRef("checkXMLHTTPState")
      strXML = txt1.innerText
      objXMLHTTP.Send(strXML)
    End Sub

    Sub checkXMLHTTPState
      If objXMLHTTP.readyState = 4 Then
        responseStatus.innerHTML = objXMLHTTP.Status & " - " & objXMLHTTP.StatusText
        Set objXMLDoc = objXMLHTTP.ResponseXML
        txt2.innerText = objXMLHTTP.ResponseText
        Set objXMLHTTP = Nothing
        Set objXMLDoc = Nothing
      End If
    End Sub

    </script>

    </head>

    <body>
    <font face="Sans-serif" size="2">
    <b>Send an EWS XML request to your server</b><br>
    <input name="protocol" value="https" size="5">://<input name="server">
    <input type="button" name="go" value="GO">
    <span id="responseStatus"></span>
    <p>
    Paste your EWS request XML here:<br>
    <textarea id="txt1" rows="25" cols="75">
    <?xml version="1.0" encoding="utf-8"?>
    <soap:Envelope
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"
    xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
    >
    <soap:Body>
    <m:FindItem Traversal="Shallow">
    <m:ItemShape>
    <t:BaseShape>Default</t:BaseShape>
    </m:ItemShape>
    <m:IndexedPageItemView MaxEntriesReturned="10" BasePoint="Beginning" Offset="0"/>
    <m:ParentFolderIds>
    <t:DistinguishedFolderId Id="inbox">
    </t:DistinguishedFolderId>
    </m:ParentFolderIds>
    </m:FindItem>
    </soap:Body>
    </soap:Envelope>
    </textarea>
    <p>
    Your server will reply here:<br>
    <textarea id="txt2" rows="25" cols="75"></textarea>
    </body>

    </html>

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Tuesday, August 21, 2012 9:02 AM
     
     
    Sign In to Vote
    0

    Thanks, Lee, I'm gonna try out your script now...

    I've been debugging EWSEditor code to get this screen.

    Just to give you an overview, I have created a screenshot of each of the ExchangeService instances in both, my web application and EWSEditor. You can examine all the current ExchangeService values in the following two screenshots.

    I can't find any difference in both objects. Both seem to be sending the same values to Exchange Server. So I don't understand why EWSEditor succeeds while my web application code gets a 401.

    (This forum doesn't seem to be able to zoom images. You might need to save the screenshots locally to be able to examine them.)






    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

    • Edited by BetterToday Tuesday, August 21, 2012 9:04 AM
    •  
     
  • Tuesday, August 21, 2012 7:09 PM
     
     
    Sign In to Vote
    0

    I have now used your code to connect to our Exchange Server from our web server machine.

    Here's the result: It's "401 - Unauthorized":

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

    • Edited by BetterToday Tuesday, August 21, 2012 7:11 PM
    •  
     
  • Tuesday, August 21, 2012 8:58 PM
     
     
    Sign In to Vote
    0
    Did it ask you to log in when you clicked GO, or did it just come back with the 401 straight away?

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Wednesday, August 22, 2012 9:55 AM
     
     
    Sign In to Vote
    0

    It asked me for the log-in data three times before presenting me with the 401.

    This happens to all three accounts I've been trying for the last few days.

    I still don't understand why EWSEditor seems to be able to connect to EWS using my colleague's account data (account #3 in the examples above) while neither, my web application nor your script, can.

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

    • Edited by BetterToday Wednesday, August 22, 2012 9:57 AM
    • Edited by BetterToday Wednesday, August 22, 2012 12:19 PM
    •  
     
  • Wednesday, August 22, 2012 12:57 PM
     
     
    Sign In to Vote
    0

    When it asked for credentials, did you supply the domain name?  Like this DOMAIN\USERNAME ?  Since you are coming from a workstation, you will certainly need to supply the domain name somehow.  Or did you use the UPN?

    One thing it would be good to try is to see if you can access each of the three mailboxes using OWA.  You may even find that OWA is blocked for some reason.

    Do you have something like wireshark handy?  That is the only sure way I can think of to see what the difference is.

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Wednesday, August 22, 2012 1:55 PM
     
     
    Sign In to Vote
    0

    I've been using the UPN to log in.

    In addition to above three UPNs I was using the SMTP e-mail address of our technical account, too. When I did this, the log-in dialog returned with the user name field showing the smtp address being prepended by a domain. It only did this when using that SMTP address. It didn't behave like this when using the UPNs.

    I guess the domain is not necessary to provide. I conclude this from the fact that EWSEditor works for my colleague's account without providing the domain.

    EDIT: Just checked OWA. Works fine. Probably because it's using IE Windows authentication.

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

    • Edited by BetterToday Wednesday, August 22, 2012 1:59 PM
    •  
     
  • Wednesday, August 22, 2012 2:37 PM
     
     
    Sign In to Vote
    0
    As far as I know, you can't log in by providing an email address.  Unless, of course, it coincidentally happens to be the same as the UPN (which it often is, but not always).  And, of course, if you used the UPN, then you are also providing the domain.  I was just wondering if you were supplying a username in the old NT format.  This is only relevant for one of your logins - the one where the account name is mtu@domain.com and the email address is my.technical.user@domain.com.  For this account (assuming that I am correct that you can't log in with an email address), you will always need to supply 'mtu@domain.com' as the account name.  That may be the reason why you get that odd 403 response for this account in your earlier post.

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Wednesday, August 22, 2012 4:09 PM
     
     
    Sign In to Vote
    0

    Thanks for still keeping up with this issue, Lee!

    I see. You are right, I wasn't clear with which credentials I'd been using. Yes, I've been using UPNs all the time here for my testing. The e-mail address never worked, not even with EWSEditor. The table I gave above, listing the results I got from my code and from EWSEditor, shows results for when I was providing a UPN (e.g. 'mtu@domain.com').

    I was only pointing out the SMTP address in the table in case it made a difference.

    So, where are we now... It seems we still don't have a clue why EWSEditor successfully can open my colleague's mailbox while both our code doesn't?

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

     
  • Wednesday, August 22, 2012 6:59 PM
     
     
    Sign In to Vote
    0
    Correct.  Without access to the server, I think you'll have to capture some network packets, and see everything that's going on at a very low level.

    Mobile OWA For Smartphone
    www.leederbyshire.com
    email a@t leederbyshire d.0.t c.0.m

     
  • Thursday, August 30, 2012 8:06 PM
     
     
    Sign In to Vote
    0

    I would suggest verifying that you are using the latest version of EWS Editor from Codeplex and then be sure that your application is using the same version of the Exchange Managed API - this will establish a baseline.  From there use Autodiscover with EWSEditor and verify it works.  You should also be using Autodiscover with your application - unless for some reason there is an issue with Autodiscover in your Exchange environment.  If you have been using EwsEditor on a box other than where your applicaiton is urnning then try it on the same box as the application to see if there are any differences.

    Autodiscover is a series of processes which try to resolve to the URL for the CAS of a mailbox. One check would be to do an SCP lookup - this queries the in-network domain server to find the correct CAS for the mailbox.  If the machine the code is running on is not in-network, then the Autodiscover/SCP lookup will fail and the Autodiscover process will continue by trying POX autodiscover. 

    POX Autodiscover process does not have any in-network requirements as does its SCP lookup process.  POX Autodiscover uses the contents of the specified mailbox address to build a couple of different URLs and does posts to them.  The responses would be checked for redirections and a what amounts to a bread-crumb trail which points to other URLs and hopefully the eventual CAS for the mailbox server.  If one of those URLs built from the mailbox's smtp address does not eventually work to resolve to the mailbox then it uses another URL variation.  If POX fails, then SRV record lookups are attempted in trying to find the CAS URL. 

    If EWSEditor is working then look for a window which shows the resolved Autodisover information; you can also check the EwsEditor logs to see what the resolved URL it uses is.  Please note that you would likley never want to implement all the logic for Autodiscover yourself as its pretty complex and using the Exchange Managed API is much easier.  EwsEditor handles things like a redirection callback which is done for Office 365 Exchange servers and also handles certificates.  Be sure to also look at the code tied to EwsEditor's Options menu settings.

    In large Exchange environments the CAS URL can and does change from time to time.  Because of this your code should do autodiscover and cache the results.   If the URL becomes non-valid then do autodiscover again. Its also best practice to redo autodiscover ever 24 hours.

    For Office 365 Exchange servers you should look at these links:

        http://msdn.microsoft.com/en-US/exchange/gg490662

        http://msdn.microsoft.com/en-us/library/exchange/gg194011(v=exchg.140).aspx

    Also go over the articles tied to this link:

        http://msdn.microsoft.com/en-us/library/exchange/dd633647(v=exchg.80)

    You can also use Microsoft's online tester to verify credentails and URLs:

        https://www.testexchangeconnectivity.com/

    Dan

     
  • Friday, August 31, 2012 7:50 AM
     
     
    Sign In to Vote
    0

    Wow, this is quite a bunch of valuable suggestions. Let me reply to them briefly as far as I can give information about our configuration.

    But first: We're just having our company's Exchange Server expert here. This is what we get so far:

    • We're now connecting directly to one of our company's Exchange Servers, skipping the load balancer. This has been the reason because none of the accounts worked.
    • Still, our technical user keeps refusing to work. It still get's a 401 while now all other users work.
    • Watching the IIS log at the Exchange Server, it always logs a "403.0" while we always receive a "401" at our client. This is the most remarkable and confusing statement I can give at this time. Any suggestions?
    • Is the user to have some special AD groups required in order to be able to access EWS? Which Exchange server groups does the account have to be a member of?

    I would suggest verifying that you are using the latest version of EWS Editor from Codeplex and then be sure that your application is using the same version of the Exchange Managed API - this will establish a baseline.

    Did this.

      From there use Autodiscover with EWSEditor and verify it works.  You should also be using Autodiscover with your application - unless for some reason there is an issue with Autodiscover in your Exchange environment.  If you have been using EwsEditor on a box other than where your applicaiton is urnning then try it on the same box as the application to see if there are any differences.

    Did this. We address ou Exchange Server directly. Same for EWSEditor. The thing in question is not the URL but what EWSEditor does after getting refused by the Exchange Server at the first time, I guess.

    Autodiscover is a series of processes which try to resolve to the URL for the CAS of a mailbox. One check would be to do an SCP lookup - this queries the in-network domain server to find the correct CAS for the mailbox.  If the machine the code is running on is not in-network, then the Autodiscover/SCP lookup will fail and the Autodiscover process will continue by trying POX autodiscover. 

    POX Autodiscover process does not have any in-network requirements as does its SCP lookup process.  POX Autodiscover uses the contents of the specified mailbox address to build a couple of different URLs and does posts to them.  The responses would be checked for redirections and a what amounts to a bread-crumb trail which points to other URLs and hopefully the eventual CAS for the mailbox server.  If one of those URLs built from the mailbox's smtp address does not eventually work to resolve to the mailbox then it uses another URL variation.  If POX fails, then SRV record lookups are attempted in trying to find the CAS URL. 

    I wonder whether I (i.e. my EWS code and EWSEditor) do actively deal with these kind of details in code.

    I'll forward your suggestions to our Exchange Server expert who's currently with us in the room now.

    Any further suggestions, particularly on user configuration (Windows AD and ExS), are very much appreciated.

    Regards,
    Axel

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

    • Edited by BetterToday Friday, August 31, 2012 7:51 AM
    • Edited by BetterToday Friday, August 31, 2012 7:53 AM
    • Edited by BetterToday Friday, August 31, 2012 7:53 AM
    •  
     
  • Tuesday, September 04, 2012 11:38 PM
    Moderator
     
     
    Sign In to Vote
    0

    Hello BetterToday,

    Are you able to provide us with a summary of the results of EWS trace logging? This should tell us where the issue occurs in the auth negotiation.  

    Can you use a tool like Fiddler an capture your network traffic? Can you verify that the exchangecookie is being sent? This is required for server affinity across a network load balancer. Also, can you summarize what the network trace is doing? Can you compare the successful connection to the 401? There is something funky in the auth negotiation.

    With regards,

    Michael | Microsoft Exchange SDK

    The Exchange Development Forum Guide has useful information for using the Exchange Development Forum.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

     
  • Wednesday, September 05, 2012 9:11 AM
     
     
    Sign In to Vote
    0

    Hi Michael,

    thanks for replying.

    After our Exchange Server expert has visited us, this is the result now:

    • We still can't use the load balancer, while EWSEditor can.
      I wonder what I'm doing wrong. Would you mind explaining to me what's necessary to have this cookie set?
    • I can't use Fiddler. When I tried a few days before I couldn't see anything special. I did have HTTPS traffic logging activated. I couldn't see authentication traffic, though. I couldn't see any authentication traffic in the EWS logs, either.
    • I have set the certificate check callback to always return true, because our Exchange Servers return the load balancer's certificate.
    • The main problem was that our ExS expert had granted our user account full access rights in ExS. After he had removed them, everything worked fine. Huh??

    Well, actually we have a solution now. I have rewritten my code to arbitrarily access any of our 18 ExSs, thereby bypassing the load balancer.

    Yet I wonder what the problem may be that's keeping us from using the load balancers.

    Vote here for a Microsoft Connect feedback channel on Windows - and win a better Windows!
    Vote here for a consistent keyboard shortcut support in Visual Studio and other Microsoft products!

     
  • Wednesday, September 05, 2012 5:52 PM
    Moderator
     
     
    Sign In to Vote
    0

    Hello BetterToday,

    While your solution works, that is not optimal. There is a high probability that since your application is targeting arbitrary client access servers, that the solution is causing additional RPCs and HTTP proxing amongst your CAS so that the requests are routed to the correct CAS that services the mailbox. Depending on scale, this could cause issues.

    Perhaps the load balancer is not properly configured? The exchangecookie is handled by the EWS Managed API. What version of EWS MA are you using? If you are using an earlier version, then the cookie might not be handled by EWS MA. The exchangecookie is used by load balancers to direct the request at the CAS that handles requests for the corresponding mailbox.

    You should be able to see the headers by turning on tracing with the EWS Managed API? Did you turn on all option?

    With regards,

    Michael | Microsoft Exchange SDK

    The Exchange Development Forum Guide has useful information for using the Exchange Development Forum.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.