none
Exchange 2010 Sp2 Federation - "Unable to get status for domain aaa.com, this domain hasn't been reserved" RRS feed

Answers

  • After working with the MS tech we finally have it working. It was primarily DNS & certs causing the issue. 

    Breakdown of the troubleshooting steps:

    ==========

    At first, we ran Get-FederationInformation, and found the autodiscover was not working, then we fixed this by: Adding the necessary DNS record so autodiscover URLs would be resolved to internal IP addresses


    Renew the certificate and make sure the certificate contains autodiscover records, and trusted by federation peers.

    1. Re-issue and install the HUBSERVER-A “Exchange” SSL certs to include 2 additional SANS :
      http://technet.microsoft.com/en-us/library/dd351057(v=exchg.141).aspx
      autodiscover.domainA.net.au 
      autodiscover.domainB.net.au
    2. Bind all the DOMAIN A/B domains to the cert
    3. Install the certificate and bind the following services to it: IMAP, POP, SMTP, IIS, Federated Sharing
    4. Export the root certificate and import it on the CAS servers in the DOMAIN C domain

    After fixing the autodiscover issue, users were still unable to check the free/busy information for remote contact, and we got the error below on CAS server:

    Log Name:      Application

    Source:        MSExchange Availability

    Date:          15/08/2013 4:23:19 PM

    Event ID:      4001

    Task Category: Availability Service

    Level:         Error

    Keywords:      Classic

    User:          N/A

    Computer:      ORGBHUB-01.Domain B.net.au

    Description:

    Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: <>SMTP:Test@domainA.net.au

    failed. Exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException:

    Autodiscover failed for e-mail address <>SMTP:Test@domainA.net.au with exception

    System.Net.WebException: The request failed with HTTP status 404: Not Found.

       at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse

    response, Stream responseStream, Boolean asyncCall)

       at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

       at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult

    asyncResult)

       at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult

    asyncResult)

       at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3

    ()

       at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException

    (ExecuteAndHandleExceptionDelegate operation). ---> System.Net.WebException: The request failed with HTTP status

    404: Not Found.

       at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse

    response, Stream responseStream, Boolean asyncCall)

       at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

       at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult

    asyncResult)

       at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult

    asyncResult)

       at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3

    ()

       at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException

    (ExecuteAndHandleExceptionDelegate operation)

       --- End of inner exception stack trace ---

    . Name of the server where exception originated: ORGBHUB1. This event may occur when Availability Service

    cannot discover an Availability Service in the remote forest.

    Then we captured the ETL trace, the availability service will use Autodiscover to detect the service URL for target forest since the TargetSharingEpr is not set, however, the autodiscover failed with error 404, and the autodiscover URL is incorrect. The incorrect URL should be retrieved from organization relationship, similar as below:

    [PS] C:\Windows\system32>Get-OrganizationRelationship |fl

    RunspaceId           
    : 10f04bfd-b948-4ad9-8843-bc461132b88c

    DomainNames           : {domainB.net.au, domainA.net.au}

    FreeBusyAccessEnabled : True

    FreeBusyAccessLevel   : AvailabilityOnly

    FreeBusyAccessScope   :

    MailboxMoveEnabled    : False

    DeliveryReportEnabled : False

    MailTipsAccessEnabled : False

    MailTipsAccessLevel   : None

    MailTipsAccessScope   :

    TargetApplicationUri  : FYDIBOHF25SPDLT.domainA.net.au

    TargetSharingEpr      :

    TargetOwaURL          :

    TargetAutodiscoverEpr : https://autodiscover.domainA.net.au/

    OrganizationContact   :

    Enabled               : True

    ArchiveAccessEnabled  : False

    AdminDisplayName      :

    ExchangeVersion       : 0.10 (14.0.100.0)

    Name                  : ORG A Federation

    DistinguishedName     : CN=ORG A Federation,CN=Federation,CN=Archdiocese of Brisbane,CN=Microsoft Exchange,CN=Servi

                            ces,CN=Configuration,DC=Domain B,DC=net,DC=au

    Identity              : ORG A Federation

    Guid                  : 37b28c70-943d-4cea-a5cd-ec0247bdf89e

    ObjectCategory        : Domain B.net.au/Configuration/Schema/ms-Exch-Fed-Sharing-Relationship

    ObjectClass           : {top, msExchFedSharingRelationship}

    WhenChanged           : 6/05/2013 9:33:31 AM

    WhenCreated           : 2/05/2013 12:35:38 PM

    WhenChangedUTC        : 5/05/2013 11:33:31 PM

    WhenCreatedUTC        : 2/05/2013 2:35:38 AM

    OrganizationId        :

    OriginatingServer     : dc3.Domain B.net.au

    IsValid               : True

    As per http://support.microsoft.com/kb/2555008, The TargetApplicationUri and TargetAutodiscoverEpr values should match the equivalent values from the Get-FederationInformation cmdlet. If the values don't match, run the following command to correct the difference:

    Set-OrganizationRelationship -Identity <Name> -TargetApplicationUri <TargetApplicationUri> -TargetAutodiscoverEpr <TargetAutodiscoverEpr

    In our case, we should use the following settings:

    RunspaceId            : 6b9c8a0f-1469-4905-89a7-9ab373ad3e69

    TargetApplicationUri  : FYDIBOHF25SPDLT.Domain B.net.au

    DomainNames           : {ORG A.net.au, Domain B.net.au}

    TargetAutodiscoverEpr : https://autodiscover.Domain B.net.au/autodiscover/autodiscover.svc/WSSecurity

    TokenIssuerUris       : {urn:federation:MicrosoftOnline}

    IsValid               : True

    RunspaceId            : 6b9c8a0f-1469-4905-89a7-9ab373ad3e69

    TargetApplicationUri  : FYDIBOHF25SPDLT.Domain B.net.au

    DomainNames           : {ORG A.net.au, Domain B.net.au}

    TargetAutodiscoverEpr : https://autodiscover.ORG A.net.au/autodiscover/autodiscover.svc/WSSecurity

    TokenIssuerUris       : {urn:federation:MicrosoftOnline}

    IsValid               : True

    We corrected the TargetAutodiscoverEpr for Organization Relationship but got another new error:

    Process 4536: ProxyWebRequest FederatedCrossForest from S-1-5-21-1960408961-796845957-1417001333-25890 to https://oa.ORG A.net.au/ews/exchange.asmx/WSSecurity failed. Caller SIDs: WSSecurity. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Net.WebException: The request was aborted: The request was canceled.

    The above error was caused by incorrect IP address returned for https://oa.ORG A.net.au/ews/exchange.asmx/WSSecurity, we tried to add the host records on ORGBHUB1/02 to let them resolve oa.ORG A.net.au to x.x.x.x, after that, verified that free/busy was working between two organizations.

    Final change add the necessary DNS record so ORGBHUB1/02 will resolve oa.ORG A.net.au to the correct IP address

    And now it's all working :)

    • Marked as answer by Simone_Bennett Wednesday, August 21, 2013 12:11 AM
    Wednesday, August 21, 2013 12:11 AM

All replies

  • Hey, did you ever find a solution for this? 

    We are running into the same problem. 

    Wednesday, July 31, 2013 3:59 PM
  • Hi Cory,

    I'm working on it now with MS but so far they think its DNS not resolving the autodiscover name in the other domains correctly.

    Wednesday, July 31, 2013 11:41 PM
  • I really appreciate you replying to me.... I am in the same situation, everything passes testing, I get valid tokens using the trust but I get the same error and cant see availability information.

    Can you let me know what sort of answer they come back with for your issue?

    Thursday, August 1, 2013 4:22 PM
  • Hey,

    Is your problem solved yet?

    I'm facing the same problem with a customer that I'm trying to federate with Office 365 in order to migrate their Exch2010 SP3 and Exch2003 SP2. And I'm working with MS Support to resolve it.

    First, something to clarify is that when you federate your Exchange Organization, you federate with the Microsoft Federation Gateway as a trust broker between your organization and other organizations, beit Exchange Online or any other Exchange Organization that you want to federate with. Please read more here: http://technet.microsoft.com/en-us/library/dd335047(v=exchg.150).aspx

    Now, has the domain in question ever been federated before with other Exchange Organizations (Exchange Online, Hotmail/Outlook.com).

    Try to run the Cmdlet with the verbose parameter (Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo -Verbose) and look for the response from domains.live.com. for me it returns:

    "<detail><ErrorCode>2004</ErrorCode><ErrorEnum>DomainNotReserved</ErrorEnum><Retryable>False</Retryable><ErrorDescriptio
    n>The domain has not been reserved.</ErrorDescription></detail>"

     I have a doubt that the customer had at some point in the past hosted this domain with one of Microsoft's Online Services and the hosting provider has not removed it properly.

    Please let me know if it's similar in your case.

    I hope this info helps someone.


    Regards, Mohammad Khan

    Tuesday, August 20, 2013 8:50 PM
  • After working with the MS tech we finally have it working. It was primarily DNS & certs causing the issue. 

    Breakdown of the troubleshooting steps:

    ==========

    At first, we ran Get-FederationInformation, and found the autodiscover was not working, then we fixed this by: Adding the necessary DNS record so autodiscover URLs would be resolved to internal IP addresses


    Renew the certificate and make sure the certificate contains autodiscover records, and trusted by federation peers.

    1. Re-issue and install the HUBSERVER-A “Exchange” SSL certs to include 2 additional SANS :
      http://technet.microsoft.com/en-us/library/dd351057(v=exchg.141).aspx
      autodiscover.domainA.net.au 
      autodiscover.domainB.net.au
    2. Bind all the DOMAIN A/B domains to the cert
    3. Install the certificate and bind the following services to it: IMAP, POP, SMTP, IIS, Federated Sharing
    4. Export the root certificate and import it on the CAS servers in the DOMAIN C domain

    After fixing the autodiscover issue, users were still unable to check the free/busy information for remote contact, and we got the error below on CAS server:

    Log Name:      Application

    Source:        MSExchange Availability

    Date:          15/08/2013 4:23:19 PM

    Event ID:      4001

    Task Category: Availability Service

    Level:         Error

    Keywords:      Classic

    User:          N/A

    Computer:      ORGBHUB-01.Domain B.net.au

    Description:

    Process Microsoft.Exchange.InfoWorker.Common.Delayed`1[System.String]: <>SMTP:Test@domainA.net.au

    failed. Exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.AutoDiscoverFailedException:

    Autodiscover failed for e-mail address <>SMTP:Test@domainA.net.au with exception

    System.Net.WebException: The request failed with HTTP status 404: Not Found.

       at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse

    response, Stream responseStream, Boolean asyncCall)

       at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

       at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult

    asyncResult)

       at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult

    asyncResult)

       at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3

    ()

       at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException

    (ExecuteAndHandleExceptionDelegate operation). ---> System.Net.WebException: The request failed with HTTP status

    404: Not Found.

       at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse

    response, Stream responseStream, Boolean asyncCall)

       at System.Web.Services.Protocols.SoapHttpClientProtocol.EndInvoke(IAsyncResult asyncResult)

       at Microsoft.Exchange.SoapWebClient.AutoDiscover.DefaultBinding_Autodiscover.EndGetUserSettings(IAsyncResult

    asyncResult)

       at Microsoft.Exchange.InfoWorker.Common.Availability.UserSoapAutoDiscoverRequest.EndGetSettings(IAsyncResult

    asyncResult)

       at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.<>c__DisplayClass4.<EndInvoke>b__3

    ()

       at Microsoft.Exchange.InfoWorker.Common.Availability.SoapAutoDiscoverRequest.ExecuteAndHandleException

    (ExecuteAndHandleExceptionDelegate operation)

       --- End of inner exception stack trace ---

    . Name of the server where exception originated: ORGBHUB1. This event may occur when Availability Service

    cannot discover an Availability Service in the remote forest.

    Then we captured the ETL trace, the availability service will use Autodiscover to detect the service URL for target forest since the TargetSharingEpr is not set, however, the autodiscover failed with error 404, and the autodiscover URL is incorrect. The incorrect URL should be retrieved from organization relationship, similar as below:

    [PS] C:\Windows\system32>Get-OrganizationRelationship |fl

    RunspaceId           
    : 10f04bfd-b948-4ad9-8843-bc461132b88c

    DomainNames           : {domainB.net.au, domainA.net.au}

    FreeBusyAccessEnabled : True

    FreeBusyAccessLevel   : AvailabilityOnly

    FreeBusyAccessScope   :

    MailboxMoveEnabled    : False

    DeliveryReportEnabled : False

    MailTipsAccessEnabled : False

    MailTipsAccessLevel   : None

    MailTipsAccessScope   :

    TargetApplicationUri  : FYDIBOHF25SPDLT.domainA.net.au

    TargetSharingEpr      :

    TargetOwaURL          :

    TargetAutodiscoverEpr : https://autodiscover.domainA.net.au/

    OrganizationContact   :

    Enabled               : True

    ArchiveAccessEnabled  : False

    AdminDisplayName      :

    ExchangeVersion       : 0.10 (14.0.100.0)

    Name                  : ORG A Federation

    DistinguishedName     : CN=ORG A Federation,CN=Federation,CN=Archdiocese of Brisbane,CN=Microsoft Exchange,CN=Servi

                            ces,CN=Configuration,DC=Domain B,DC=net,DC=au

    Identity              : ORG A Federation

    Guid                  : 37b28c70-943d-4cea-a5cd-ec0247bdf89e

    ObjectCategory        : Domain B.net.au/Configuration/Schema/ms-Exch-Fed-Sharing-Relationship

    ObjectClass           : {top, msExchFedSharingRelationship}

    WhenChanged           : 6/05/2013 9:33:31 AM

    WhenCreated           : 2/05/2013 12:35:38 PM

    WhenChangedUTC        : 5/05/2013 11:33:31 PM

    WhenCreatedUTC        : 2/05/2013 2:35:38 AM

    OrganizationId        :

    OriginatingServer     : dc3.Domain B.net.au

    IsValid               : True

    As per http://support.microsoft.com/kb/2555008, The TargetApplicationUri and TargetAutodiscoverEpr values should match the equivalent values from the Get-FederationInformation cmdlet. If the values don't match, run the following command to correct the difference:

    Set-OrganizationRelationship -Identity <Name> -TargetApplicationUri <TargetApplicationUri> -TargetAutodiscoverEpr <TargetAutodiscoverEpr

    In our case, we should use the following settings:

    RunspaceId            : 6b9c8a0f-1469-4905-89a7-9ab373ad3e69

    TargetApplicationUri  : FYDIBOHF25SPDLT.Domain B.net.au

    DomainNames           : {ORG A.net.au, Domain B.net.au}

    TargetAutodiscoverEpr : https://autodiscover.Domain B.net.au/autodiscover/autodiscover.svc/WSSecurity

    TokenIssuerUris       : {urn:federation:MicrosoftOnline}

    IsValid               : True

    RunspaceId            : 6b9c8a0f-1469-4905-89a7-9ab373ad3e69

    TargetApplicationUri  : FYDIBOHF25SPDLT.Domain B.net.au

    DomainNames           : {ORG A.net.au, Domain B.net.au}

    TargetAutodiscoverEpr : https://autodiscover.ORG A.net.au/autodiscover/autodiscover.svc/WSSecurity

    TokenIssuerUris       : {urn:federation:MicrosoftOnline}

    IsValid               : True

    We corrected the TargetAutodiscoverEpr for Organization Relationship but got another new error:

    Process 4536: ProxyWebRequest FederatedCrossForest from S-1-5-21-1960408961-796845957-1417001333-25890 to https://oa.ORG A.net.au/ews/exchange.asmx/WSSecurity failed. Caller SIDs: WSSecurity. The exception returned is Microsoft.Exchange.InfoWorker.Common.Availability.ProxyWebRequestProcessingException: System.Net.WebException: The request was aborted: The request was canceled.

    The above error was caused by incorrect IP address returned for https://oa.ORG A.net.au/ews/exchange.asmx/WSSecurity, we tried to add the host records on ORGBHUB1/02 to let them resolve oa.ORG A.net.au to x.x.x.x, after that, verified that free/busy was working between two organizations.

    Final change add the necessary DNS record so ORGBHUB1/02 will resolve oa.ORG A.net.au to the correct IP address

    And now it's all working :)

    • Marked as answer by Simone_Bennett Wednesday, August 21, 2013 12:11 AM
    Wednesday, August 21, 2013 12:11 AM