none
Can I use ADSync to copy 365 users to 2016 server

    Question

  • The company I with has moved to 365.
    The existing servers are such a mess I've decided to abandon them and create a new internal .local domain.

    Is it possible to populate the new servers/domain by using ADSync to copy current 365 user accounts to a new server?

    Monday, February 27, 2017 6:54 PM

Answers

  • Hi

     Refer to this; https://blogs.technet.microsoft.com/herbchung/2015/04/14/how-to-exportimport-the-identity-from-azure-ad-to-local-ad/


    This posting is provided AS IS with no warranties or guarantees,and confers no rights. Best regards Burak Uğur

    • Marked as answer by Dale Murray Thursday, March 2, 2017 2:07 PM
    Monday, February 27, 2017 8:55 PM

All replies

  • Hi

     Refer to this; https://blogs.technet.microsoft.com/herbchung/2015/04/14/how-to-exportimport-the-identity-from-azure-ad-to-local-ad/


    This posting is provided AS IS with no warranties or guarantees,and confers no rights. Best regards Burak Uğur

    • Marked as answer by Dale Murray Thursday, March 2, 2017 2:07 PM
    Monday, February 27, 2017 8:55 PM
  • Hi,

    The company I with has moved to 365.
    The existing servers are such a mess I've decided to abandon them and create a new internal .local domain.

    Is it possible to populate the new servers/domain by using ADSync to copy current 365 user accounts to a new server?

    >>>If you want to demote the domain, and create a new internal domain. You cannot sync original account with the new internal domain.

    If you want to demote the old domain and create a new domain, then sync on-premise AD with Azure AD again, here is an article below may be helpful to you.

    Step-By-Step: Syncing An On Premise AD with Azure Active Directory

    https://blogs.technet.microsoft.com/canitpro/2014/05/13/step-by-step-syncing-an-on-premise-ad-with-azure-active-directory/

    Connect Active Directory with Azure Active Directory

    https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect

    Best Regards,

    Jay


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, February 28, 2017 5:48 AM
    Moderator
  • Thanks for the replies.

    I am abandoning because the previous "consultant" has created/changed the domains no less than twice, possibly three times. (Note, I did not include the word demoted)

    In fact, currently, there are two active domains with no trust.

    Better yet, one of the domains cannot find its replication partner.
    Where did that partner go?
    It is the DC of a new domain that person created.

    The only place that is not a total mess is the 365 environment. Thus, I am creating a new internal domain and would like to replicate the 365 environment to it. I will eventually migrate all the user machines to the domain and life will be grand.
    Tuesday, February 28, 2017 1:55 PM
  • Seems to that's the correct method,first you should sync users from azure to on-promise.(configure a local domain contoller),then will set the new domain and configure trust between these domains.Finaly migrate users,computers,groups,etc.You can migrate ad resources with ADMT.

    ADMT; https://technet.microsoft.com/en-us/library/cc974332(v=ws.10).aspx


    This posting is provided AS IS with no warranties or guarantees,and confers no rights. Best regards Burak Uğur

    Tuesday, February 28, 2017 3:50 PM
  • Hi Dale,

    As there are few inputs already on this topic, I would like to recommend do no use .local domain name whatever your requirement is. This is not supported officially and will get you into issues at later stage.

    Avoid test domain names such as .local, .example.com or .internal.

    Best approach will be to use subdomain of your registered 365 tenant. Such as corp.financialO.com for FinancialO.com.

    Hope this helps.


    Regards, Jim MSCS - MCP Disclaimer: This posting is provided AS IS with no warranties or guarantees , and confers no rights. When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer

    Tuesday, February 28, 2017 10:37 PM
  • This worked for importing all my users.

    Thursday, March 2, 2017 2:09 PM
  • I am totally at a loss in regard to why using .local is bad.

    Let me give you a bit of background on my situation; I'm using fictitious domains.

    Years ago the company setup their first server and domain; rock.local
    Some years later something screwed things up royally and setup new servers and a new domain; rockhill.local

    They never decommissioned the rock.local domain. In fact, they took one of the DC's from rock.local and used it on rockhill.local without demoting it. Now there are two screwed up domains.

    Years pass, more bad ideas and failures, now there are two distinct domains with people access things on both but no trust relationship. User accounts are created all over the place, old ones never deleted, and two exchange servers that dont know about each other, etc.

    BTW, the actual .com for the company is rockhillpass.com <-- fake name used as example

    That is the mess I inherited.

    My solution was:
    A. Move out to 365 and create a clean slate there.
    B. Clean up the servers of old data.
    C. Create a new domain named rhp.local
     - copy user accounts from o365 to the new rhp.local servers
     - create synchronization between o365 and rhp.local allowing for SSO.

    Right now I am at the synchronization part of this story.

    My users sign in to o365 as username@rockhillpass.com and in my testing the users login accounts on the domain would be username@rhp.com

    Are you suggesting it would be best to use rockhillpass.com instead of rhp.local for the domain?

    Thursday, March 2, 2017 6:47 PM
  • Hi Dale

    .Local does not have an identity in outside world. No DNS records and is not present in Root hint domains list.

    The UPN of the user should be domain.com not .local. .local wont sync with O365 because it does not know what .Local is

    If you are syncing your AD objects from Local AD to O365 > Then you need to add domain.com as upn suffix > So synced users UPN wil be xyz@domain.com > Which then be used by users to sign in to O365 accounts


    MCSA Office 365 | MCSA Exchange server 2010 | Red Hat Certified Engineer | https://www.linkedin.com/in/abrar-kaberi-46a483102/



    • Edited by Akabe Thursday, March 2, 2017 6:57 PM
    • Proposed as answer by Akabe Friday, March 3, 2017 4:02 PM
    Thursday, March 2, 2017 6:53 PM
  • Since I have not gone live with this and currently have two DC's, an app server and SQL servers - both of which are not populated with data - I may be best to just spin up two more DC, join the SQL and App servers to the new domain and deleted the old DC's.

    Seem reasonable?
    Thursday, March 2, 2017 7:27 PM
  • Cant comment on SQL and app servers but if you are planning to start fresh then your approach is right.

    I hope UPN question on .local was helpful


    MCSA Office 365 | MCSA Exchange server 2010 | Red Hat Certified Engineer | https://www.linkedin.com/in/abrar-kaberi-46a483102/


    • Edited by Akabe Friday, March 3, 2017 4:02 PM
    Friday, March 3, 2017 2:53 PM
  • Thats correct Dale and .local will cause you more headaches and grief during the migration so please spin up new DC and domain.com or whatever is appropriate for you.

    Hope this helps.


    Regards, Jim MSCS - MCP Disclaimer: This posting is provided AS IS with no warranties or guarantees , and confers no rights. When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer

    Friday, March 3, 2017 4:01 PM