No one has responded to this discussion for at least a year, so this information may be out of date. If you're looking for information about this topic, please search for a more recent discussion or post a new question.

Can Exchange be set to nonauthoritative

  • 3 Followers
  • 10 Replies |
  • This post has 0 verified answers |
Answered (Not Verified) This question has suggested answer(s)

About our business:

  • We currently have over 100 DNS records and are not interested in migrating our DNS.  
  • We also have only about 10 Exchange accounts and about 10 pop 3 accounts (for websites to send mail from)
  • We have a catch all

Our current setup we have our Exchange set to nonauthoritative.  For the 10 Exchange users we forward their mail from the generic mail system to the Exchange.  Will this be possible?  We really won't be able to test or evaluate this product if we are forced to change our DNS.   


If manually configure our DNS will the product work? 


Type Priority Host Points to address TTL
MX 0 @ MYDOMAIN-com.mail.eo.outlook.com 1 Hour
CNAME - autodiscover autodiscover.outlook.com 1 Hour

Type TXT Name TXT Value TTL
TXT @ v=spf1 include:outlook.com ~all 1 Hour

Type Service Protocol Port Weight Priority Target Name TTL
SRV _sip _tls 443 1 100 sipdir.online.lync.com MYDOMAIN.com 1 Hour
SRV _sipfederationtls _tcp 5061 1 100 sipfed.online.lync.com MYDOMAIN.com 1 Hour


  • Post Points: 35
All Replies
  • I am in the same situation.  I don’t want to change DNS providers for 2 reasons.  First, I have many DNS entries at my current host (1&1) and don’t wish to recreate them all.  Second, I have some mailboxes that will use Office 365, and some that will continue to function as POP accounts served by 1and1, and I don’t want to have to buy (eventually) an Office365 mailbox for each user who is currently happy using a free POP account.  I have gotten everything to work, with one exception.

    First, here’s what works.  Let’s assume my domain is contoso.com.  So I set up my Office 365 domain as contoso.onmicrosoft.com.  I went through the process of adding my vanity domain (contoso.com) in Office 365, including adding the CNAME through 1&1, but didn’t take the last step to transfer DNS control to Office 365.  So now my vanity domain is active in Office 365, but the DNS is still being managed by 1and1.

    I created a test user at Office 365 with the email address test@contoso.com.  I also checked in the advanced user Email configuration to be sure that this user was also assigned the email address test@contoso.onmicrosoft.com, which it was.  Then, in the 1and1 admin site, I created an email forward, pointing test@contoso.com to test@contoso.onmicrosoft.com.  Now, if I send email from an unrelated account to test@contoso.com, it goes to 1and1, which forwards it to test@contoso.onmicrosoft.com, which ends up in the Office365 mailbox of test@contoso.com.  Perfect.  If I send an email from another Office365 user account to test@contoso.com, it also finds its way to the correct mailbox.  Also perfect.

    The problem arises when I want to send an email from the Office 365 mail client to a contoso user that is NOT on the Office 365 system (let’s call him Fred).  Fred@contoso.com is still a POP mailbox at 1and1.  If I send an email to fred@contoso.com from an unrelated account, it gets to Fred’s POP mailbox just fine.  But if I send an email from test@contoso.com to fred@contoso.com, the Office365 exchange server looks for a user named fred in my Office365 account, and returns a failure message when none is found.  The message is never sent to the internet, where it would end up with 1and1 (the desired result).

    It seems that I should be able to overcome this problem by letting Office365 know that it is a non-authoritative with respect to the contoso.com domain, basically forcing it to go out to the public MX record with every email, whether the user is found in the Office365 account or not.  Or at a minimum, having it go out to the public MX if no user is found internally.  But I can’t figure out how to make either of those happen.

    Is there a DNS setting I can add at Office 365 to basically trick Office 365 into going out to the public MX or straight to 1&1?  Any other ideas?

    • Not Ranked
    • Post Points: 0
  • Bump...  

    Chase Dahl?  David Martin?  David Rummelhart?  Any help greatly appreciated.  This is a big issue for us.  Thanks.

    • Not Ranked
    • Post Points: 0
  • Hello,

     

     This is a very good question as Office365 does differ from BPOS. While I look into this a bit more here is a link with a possible solution.

     

    http://help.outlook.com/en-us/beta/cc967280.aspx

     

    Thank You,

    David Brody
    Office 365 Technical Support
    • Top 500 Contributor
    • Post Points: 0
  • That is how we are setup - but I know we had to specifically request our Exchange be set to nonauthoritive before it would work.  I don't see a way to do this in Office365.  Also if we are forced to move our DNS - we may have to abandon this solution.  We are not interested in bundling our DNS with our email.  Not that clouds fail (cough AMAZON) - but if they do we want to have some options left to rescue our sites and clients.  

    • Not Ranked
    • Post Points: 0
  • Thanks for checking this out, David B.  I visited the link you included, and clicked through to "Configure a Shared Address Space with On-Premises Relay".  I think this is basically what I have set up, except for step #3 in the "Tasks in the Cloud" section:

     

    3. Configure contoso.edu as an internal relay domain

    If you don't configure the share address space @contoso.edu as an internal relay domain, e-mail sent from students in the cloud-based e-mail service to faculty and staff with @contoso.edu addresses in the on-premises messaging system won't be delivered, and NDRs will be generated.

    To configure @contoso.edu as an internal relay domain, use Windows PowerShell. To learn how to install and configure Windows PowerShell and connect to the service, see Use Windows PowerShell in Exchange Online.

    Run the following command:

    Set-AcceptedDomain <shared address space> -DomainType InternalRelay
    

    For our example, contoso.edu is the shared address space. Run the following command:

    Set-AcceptedDomain contoso.edu -DomainType InternalRelay
    
    So are you saying that I need to run these PowerShell commands on the Office 365 Exchange Server?  When I click through on the link that describes how to do that ("Use Windows PowerShell in Exchange Online"), it says that it applies to Office 365 Beta for enterprises, but is silent about the small business version.  I am hesitant to try...
    • Not Ranked
    • Post Points: 0
  • Well, I tried anyway, and didn't get too far.  I fired up PowerShell and followed the instructions here, but got the following error message in Step 4:

    PS C:\Windows\system32> $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook

    .com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

    [ps.outlook.com] Connecting to remote server failed with the following error message : Access is denied. For more infor

    mation, see the about_Remote_Troubleshooting Help topic.

       + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc

      eption

       + FullyQualifiedErrorId : PSSessionOpenFailed

     Anyone have any ideas?

     

    • Not Ranked
    • Post Points: 0
  • Hello,

     

    Please follow these steps to make sure Powershell is set up properly:

     

    Verify that Windows PowerShell can run scripts

     

    1. Click Start > All Programs > Accessories > Windows PowerShell.

    2. Do one of the following to open Windows PowerShell:

    If you're running Windows Vista, Windows 7, or Windows Server 2008 R2, right-click Windows PowerShell and select Run as administrator. If you get a user account control prompt that asks if you would like to continue, respond Continue.

     

    If you're running Windows XP or Windows Server 2003, click Windows PowerShell.

     

    3. Run the following command:

    Copy

    Get-ExecutionPolicy

     

    4. If the value returned is anything other than RemoteSigned, you need to change the value to RemoteSigned.

    Note   When you set the script execution policy to RemoteSigned, you can only run scripts that you create on your computer or scripts that are signed by a trusted source.

    Enable scripts to run in Windows PowerShell

    In Windows PowerShell session you just opened as an administrator, run the following command:

    Copy

    Set-ExecutionPolicy RemoteSigned

     

    5. Verify that WinRM allows Windows PowerShell to connect

     

    1. Click Start > All Programs > Accessories.

    2. Do one of the following to open a command prompt:

     

    If you're running Windows Vista, Windows 7, or Windows Server 2008 R2, right-click Command Prompt and select Run as administrator. If you get a user account control prompt that asks if you would like to continue, respond Continue.

    If you're running Windows XP or Windows Server 2003, click Command Prompt.

     

    3. At the command prompt, run the following commands:

    Copy

    net start winrm

    winrm get winrm/config/client/auth

    Note   If the WinRM service is already running, you don't have to start it. You can check the status of the WinRM service by running the command sc query winrm.

    4. In the results, look for the value Basic = . If the value is Basic = false, you must change the value to Basic = true.

    Note   If you started the WinRM service, and you don't need to change the Basic value, run the command net stop winrm to stop the WinRM service.

    Configure WinRM to support basic authentication

    1. At the command prompt you just opened as an administrator, run the following commands. The value between the braces { } is case-sensitive:

    Copy

    winrm set winrm/config/client/auth @{Basic="true"}

    2. In the command output, verify the value Basic = true.

    Note   If you started the WinRM service, run the command net stop winrm to stop the WinRM service.

    David Brody
    Office 365 Technical Support
    • Top 500 Contributor
    • Post Points: 0
  • Hi,

     

    Once you have powershell working I can confirm that I just set my Small Business account domain from Authoritative to ExternalRelay then to InternalRelay, which I verified by by running Get-AcceptedDomain. I do not have an environment to test this in at the moment but I look forward to hearing your results.

     

    Thank you,

    Spike

    • Top 500 Contributor
    • Male
    • Post Points: 0
  • Problem solved!  For future reference, here is what I did:

     

    1.  I confirmed that PowerShell was configured properly by following the directions here (I only needed to follow steps 4 and 5, since I am running Windows 7). 


    2.  I connected to Exchange using PowerShell, following the directions here. 


    3.  Then I started configuring my Office 365 Exchange account (note that you can find here more complete instructions than what I have listed below).  I confirmed that my vanity domain had been successfully added by running the PS command [Get-AcceptedDomain], and checking that my vanity domain was listed in the output as an Authoritative and non-default domain.  I had previously added my vanity domain using the Office 365 Admin control panel, going through all the steps except stopping before making any changes to my current DNS or MX records (other than adding the CNAME required to verify the domain).

     

    4.  I changed my vanity domain to InternalRelay by running the PS command [Set-AcceptedDomain <vanitydomainname> -DomainType InternalRelay], substituting my vanity domain (including the “.com”) for “<vanitydomainname>”. 


    5.  I confirmed that my vanity domain had been successfully changed to internal relay by running the PS command [Get-AcceptedDomain], and checking that my vanity domain was listed in the output as an InternalRelay and non-default domain. 


    6.  In order to test the setup, I created a mail account in Office 365 that had a primary email address on my vanity domain, but didn’t create a record for that user with my master DNS/email host (1&1).

     

    7.  I then sent emails from the test Office 365 account to (i) another Office 365 account on my vanity domain, (ii) a user on my vanity domain that does not have an Office 365 account, and (iii) an external email not associated with Office 365 or my vanity domain.  All three emails were successfully received, and all three sent replies that were successfully received by my test account.  There were no error messages.

     

    Thanks to all for your help, especially David B, Spike Fogarty and David FYIN.  Always heartwarming when the community can come together to solve a problem and hopefully save some headaches for someone else down the road. 

    • Not Ranked
    • Post Points: 0
  • The post above is a suggested answer

    • Not Ranked
    • Post Points: 0
    Suggested by
Page 1 of 1 (11 items)