AzureADConnect Configuration


  • Hi I'm hoping for some advise on these questions about this tool

    We are attempting to synchronize our AD On premise server with AD Azure and I have downloaded AzureADConnect.msi to install
    Because we already have some users already in AD Azure that were automatically created during a recent o365 migration, I wanted to run this first on a few users from a test OU to ensure we get our processes correct , plus avoiding duplicate entries in AD Azure.

    On installation of this tool using the express option you have a choice to synchronize straight away - I'm assuming this needs to be kept unchecked otherwise it synchronize straight away - which I understand you can run manually run from "%ProgramFiles%\Microsoft Azure AD Sync\UIShell\Miisclient.exe" so we can pick the OU we want to synchronize as a test- Also I understand this tool can only be run once - and I'm not sure if this means per user or once on the server otherwise once we complete the test I cannot run it again. My final question is in response to something I saw online that you can simply select next to the Azure AD sing-in configuration screen by choosing the default option "Active Directory UPN Suffix" Azure AD Domain - I don't necessarily want to include domain.local to our AD Azure as I will correct the UPN names of the test users with Miisclient or manually before running the migration tool - I do hope this makes sense any help here would be most appreciated
    Saturday, March 11, 2017 12:15 PM


All replies

  • If you have an existing tenant, then start reading this so you understand what is supposed to happen:

    If you select express, then you are correct you are not given the option to select OUs. You can either use custom, where this option is available, or as you say, configure it after installation. The steps for how to use OU filtering is documented here:

    You can run the installation wizard multiple times. There are some configuration options you can only select on first install, such as group based filtering. The things you can change on second run on the wizard are documented here:

    Since you can't verify a domain.local in Azure AD, your users will never have that as their sign-in ID. You can either use another attribute, such as email, or change the UPN to something your users can remember, such as their email. If you are using .local today, it would make sense to change the UPN on-prem to their email address. You can change it in the sync engine, but on-prem tools, such a Outlook, wouldn't know about the change and will not work in all situations. Correcting the UPN in AD would be the best option. It is further described here:

    If there is anything not clear after reading those topics, let me know and I will update the documentation accordingly.

    Saturday, March 11, 2017 4:39 PM
  • Excellent Andreas

    In regards to the last answer

    Other than changing the UPN on each user to match what's in AD Azure, both the mail and proxy address attributes in on premise AD already match i.e "".  So would I be better to change the UPN first before running AzureADConnect or can I do this after - I understand the wizard is suppo
    sed to prompt you if it detects domain.local - or have I misunderstood this ? Also attached is a screendump where I've stopped at, I'm not sure what I should do from here and which to select and then click next 

    Many thanks for your help on this

    Saturday, March 11, 2017 9:33 PM
  • Hi Andreas

    Something else I did forget to ask , when the sync has finished
    Will the user need to change their password ?

    Many thanks again

    Saturday, March 11, 2017 9:37 PM
  • What that page is saying is that the .local address you have is not in Azure AD, and it cannot be. You need to verify that you own the domain and you cannot prove that you own a .local address. The warning here is that all your users will get their UPN changed.

    You should verify the domain you use for email in Azure AD.

    You might have done that already but have not added that domain as a valid UPN suffix to your AD.

    You now have two options. If you want to use Express settings, then you need to change the UPN attribute so it is matching your emails as well, this is the recommended option. If you do not want to do this, then you need to run a custom install. Then you have the option to use the email address as the sign-in attribute.

    Your users do not have to change their passwords. Azure AD Connect will synchronize password hashes and these are usable in Azure AD as soon as the sync has completed.

    Sunday, March 12, 2017 8:26 AM
  • Excellent Andreas , yes you are correct
    The verification appears in AD Azure but not in Active Directory Domains and Trusts 

    The express service looks the easiest - 
    So just so i've understood you correctly, here's my plan 

    1. I've got 2 x test user accounts in a test GPO called o365
    2. after applying the above verification in Active Directory Domains and Trusts
    3. run the wizard -AzureADConnect - express mode
    4. Uncheck start synchronization and install
    5. Edit the UPN on these test accounts
    6. start "%ProgramFiles%\Microsoft Azure AD Sync\UIShell\Miisclient.exe
    7. Select the test OU and users and sync

      Hope this is it , most appreciated again for your time and patience helping me with this
    Sunday, March 12, 2017 10:14 AM
  • Yes, that is it.
    Sunday, March 12, 2017 10:58 AM
  • Many thanks again Andreas

    Just one small detail what is the impact of adding another entry into Active Directory Domains and Trusts. I'm assuming it's nothing but just wanted to check. our users are using domain.local to login to the network and adding will there be any issues with this ?

    Again many thanks

    Sunday, March 12, 2017 11:30 PM
  • No, there is no impact of adding another UPN suffix to AD. Obviously when you change their signID from @domain.local to, they will be impacted. But you have to make that change to every user individually so you can control when it happens and how to inform them of the change.
    Monday, March 13, 2017 7:22 AM
  • Thanks again Andreas

    Yes makes sense now , which is the reason the UPN is changed on each user account in AD to get single sign on with their o365 login

    So when synchronization is completed for the user(s) who have had their UPN changed 
    they will be using instead of user@domain.local when they logon to the local domain

    Excellent thank you so much, you explained it brilliantly :)



    Monday, March 13, 2017 8:50 AM
  • Glad I could help. Feel free to mark on of the responses as "answered" so it disappears from the list of active threads.
    Monday, March 13, 2017 12:05 PM