none
[E2003] [WebDAV] [C#] Login timeout 440 when setting property RRS feed

  • Question

  • In short: we're running into 440 Login Timeout error when using the PROPPATCH propertyupdate method on an Exhange 2003 machine through WebDAV to set (custom or Exchange) properties that aren't full Outlook messages or appointments.

    An example of this request looks like:

     

    <?xml version="1.0" encoding="utf-8"?>
    <D:propertyupdate xmlns:D="DAV:" xmlns:ns0="test2">
      <D:set>
        <D:prop>
          <ns0:test>value1</ns0:test>
        </D:prop>
      </D:set>
    </D:propertyupdate>
    

    The strange thing is that this happens at one of our customers and the same requests do work on our test / production machine and at other customers. The logged in user has full control rights and we can do any other request, like getting mailbox, searching mailbox, adding appointments, update appointments, deleting items, etc. Yet, setting a simple property is unauthorized (440 login timeout because of FBA).

    Also, we are doing the special FBA login, which does work for other requests. The header that is sent to create the appointment (which does work and on which we want to set the property) is also exactly the same as the header for setting the property (including cookie for FBA etc).

    To clarify: we're using an external api to do the Exchange / Webdav communications. We've sniffed the requests / responses with Fiddler and because they seem valid and because it does work at other environments, we're at a loss and it doesn't seem to be something in the api.

    It ought to be some kind of Exchange or IIS side setting, but we don't see where it could be. The user should have sufficient permissions (full control, no deny).

    Does anybody have any idea where to look or which settings to check? Is there anything special about setting custom properties versus adding a full appointment which uses the same PROPPATCH method?

    Thanks a lot in advance!

    Additional details:

    - Exchange version 2003 SP2
    - IIS 6
    - The user is adding the appointment to his / her own mailbox and trying to set the property to his / her own created appointment.
    - Server uses SSL

    Thursday, September 8, 2011 12:26 PM

Answers

  • Thanks for your reply.

    I've read a bit about property exhaustion now and according to this link (http://anewmessagehasarrived.blogspot.com/2008/10/named-properties-bloat.html), when creating a new custom property successfully, the following log should also appear in the event log:

      EventID: 9873
      Source: MSExchangeIS
      A named property has been created for the database "/o=Home/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MB2/cn=Microsoft Private MDB".
       ID: 0x8519
       Named property GUID: 00020386-0000-0000-c000-000000000046
       Named property name/ID: x-myownheader
       The following user is attempting to create the named property: "N/A"
       Protocol: MAPI
       Client type: Transport
       Client version: 2049.0.33059.1

     

    Yet, this doesn't appear in either of our Exchange 2003 local environments when adding a new property that wasn't used before. Does this mean that logging these types of messages must be enabled explicitly? Or is that event just for Exchange 2007 and the event where it fails (the one you linked) should appear in Exchange 2003 Event log by default?

    Also, when you say event log, I assume you mean the Exchange machine's local Application log in the Event viewer.

    Besides setting a custom property like above by the way, we're also setting an existing property (cached guid property for meeting requests, like http://www.infinitec.de/post/2007/07/02/Creating-meeting-requests-with-WebDAV-and-Outlook-in-Cached-mode.aspx) and also, that property cannot be set (exact same unauthorized error).

    So it's not just custom properties, but also setting existing properties with PROPPATCH, which seems to rule out the named property exhaustion issue, I think?


    Edit (ANSWER): Forgot about this thread, so a very late edit as to not bump this thread. Anyway, eventually the security settings at our client concerning setting properties were not set correctly after all...
    • Edited by jcc_colin Friday, November 11, 2011 9:35 AM Adding answer, not wanting to bump this thread
    • Marked as answer by jcc_colin Friday, November 11, 2011 9:35 AM
    Wednesday, September 14, 2011 9:05 AM

All replies

  • Sorry to bump this topic shamelessly, but we haven't found a solution yet and I'm sure someone must have some suggestions?

    A little more detail then.

    This works (adding appointment):

    PROPPATCH /exchange/testuser/Agenda/test%20appointment%20in%20mailbox%20testuser-6345150120968046651703713542.eml HTTP/1.1

    <?xml version="1.0" encoding="utf-8"?>
    <D:propertyupdate xmlns:D="DAV:" xmlns:ns0="http://schemas.microsoft.com/exchange/" xmlns:ns1="http://schemas.microsoft.com/mapi/" xmlns:ns2="http://schemas.microsoft.com/mapi/proptag/" xmlns:ns3="urn:schemas:calendar:" xmlns:ns4="http://schemas.microsoft.com/mapi/id/{00062002-0000-0000-C000-000000000046}/">
      <D:set>
        <D:prop>
          <ns0:outlookmessageclass>IPM.Appointment</ns0:outlookmessageclass>
            <ns1:subject>test appointment in mailbox testuser</ns1:subject>
            <ns2:x1000001e>Test body</ns2:x1000001e>
            <ns3:dtend>2011-09-13T10:00:00.000Z</ns3:dtend>
            <ns3:dtstart>2011-09-13T09:00:00.000Z</ns3:dtstart>
            <h11:0x8217 xmlns:h11="http://schemas.microsoft.com/mapi/id/{00062002-0000-0000-C000-000000000046}/" xmlns:b="urn:uuid:C2F41010-65B3-11d1-A29F-00AA00C14882/" b:dt="int">0</h11:0x8217>
            <mapi:0x8223 xmlns:mapi="http://schemas.microsoft.com/mapi/id/{00062002-0000-0000-C000-000000000046}/" xmlns:dt="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/"  dt:dt="boolean">0</mapi:0x8223>
        </D:prop>
      </D:set>
    </D:propertyupdate>
    

    This does not work (setting property on that same appointment):

    PROPPATCH /exchange/testuser/Agenda/test%20appointment%20in%20mailbox%20testuser-6345150120968046651703713542.eml HTTP/1.1

    <?xml version="1.0" encoding="utf-8"?>
    <D:propertyupdate xmlns:D="DAV:" xmlns:ns0="testNs">
      <D:set>
        <D:prop>
         <ns0:testName>testValue</ns0:testName>
        </D:prop>
      </D:set>
    </D:propertyupdate>
    

    Same user, same mailbox, same method, same FBA cookies, different content. Modifying the same appointment works, setting a custom property does not. (Unauthorized)

    Which (security) settings in Exchange 2003 (or in IIS) could possibly block setting a custom property like this when a user has full control? Where does this error originate? Exchange or IIS? Could anything else interfere?

    The user has full control over all mailboxes. Or are there any known issues about security settings not sticking or anything else we could try?

    Any response would be appreciated. Thanks again. :)

    • Edited by jcc_colin Tuesday, September 13, 2011 7:34 AM
    Tuesday, September 13, 2011 7:32 AM
  • Have you checked the event logs on the Exchange server your trying to run this against. One possible cause of this could be named property exhaustion http://blogs.technet.com/b/exchange/archive/2010/07/29/3410545.aspx this should show up in the logs if this is the cause.

    Cheers
    Glen

    Wednesday, September 14, 2011 3:10 AM
  • Thanks for your reply.

    I've read a bit about property exhaustion now and according to this link (http://anewmessagehasarrived.blogspot.com/2008/10/named-properties-bloat.html), when creating a new custom property successfully, the following log should also appear in the event log:

      EventID: 9873
      Source: MSExchangeIS
      A named property has been created for the database "/o=Home/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MB2/cn=Microsoft Private MDB".
       ID: 0x8519
       Named property GUID: 00020386-0000-0000-c000-000000000046
       Named property name/ID: x-myownheader
       The following user is attempting to create the named property: "N/A"
       Protocol: MAPI
       Client type: Transport
       Client version: 2049.0.33059.1

     

    Yet, this doesn't appear in either of our Exchange 2003 local environments when adding a new property that wasn't used before. Does this mean that logging these types of messages must be enabled explicitly? Or is that event just for Exchange 2007 and the event where it fails (the one you linked) should appear in Exchange 2003 Event log by default?

    Also, when you say event log, I assume you mean the Exchange machine's local Application log in the Event viewer.

    Besides setting a custom property like above by the way, we're also setting an existing property (cached guid property for meeting requests, like http://www.infinitec.de/post/2007/07/02/Creating-meeting-requests-with-WebDAV-and-Outlook-in-Cached-mode.aspx) and also, that property cannot be set (exact same unauthorized error).

    So it's not just custom properties, but also setting existing properties with PROPPATCH, which seems to rule out the named property exhaustion issue, I think?


    Edit (ANSWER): Forgot about this thread, so a very late edit as to not bump this thread. Anyway, eventually the security settings at our client concerning setting properties were not set correctly after all...
    • Edited by jcc_colin Friday, November 11, 2011 9:35 AM Adding answer, not wanting to bump this thread
    • Marked as answer by jcc_colin Friday, November 11, 2011 9:35 AM
    Wednesday, September 14, 2011 9:05 AM