Your company network includes an On-Premises Windows Active Directory (AD) that has a DNS domain
named contoso.local and an email domain named contoso.com. You plan to migrate from On-Premises
Exchange to Office 365.
You configure DirSync and set all Azure Active Directory {Azure AD) usernames as
%username%@contoso.com
You need to ensure that each user is able to log on by using the email domain as the username.
Which two actions should you perform? Each correct answer presents part of the solution.
A.
Verify the email domain in Azure AD domains.
B.
Run the Set-MsolUserPnncipalName -UserPnncipalName %username%@co ntoso.onmicrosoft.com –
NewUserPrincipalName %usemame %@contoso.com Power Shell cmdlet.
C.
Edit the ProxyAddress attribute on the On-Premises Windows AD user account.
D.
Verify the Windows AD DNS domain in Azure AD domains.
E.
Update the On-Premises Windows AD user account UPN to match the email address.
Explanation:
* There are two main traffic flows originating from the server hosting the Azure Active Directory Sync tool:
The Azure Active Directory Sync tool queries a domain controller on the on-premises network for changes
to accounts and passwords.
The Azure Active Directory Sync tool sends the changes to accounts and passwords to the Azure AD
instance of your Office 365 subscription. These changes are sent through the on-premises network’s proxy
server.
* Verify that your virtual machine is joined to the domain by checking your internal DNS to make sure that
an Address (A) record was added for the virtual machine with the correct IP address from Azure. For the
Azure Active Directory Sync tool to gain access to Internet resources, you must configure the server that
runs the Azure Active Directory Sync tool to use the on-premises network’s proxy server.Deploy Office 365 Directory Synchronization in Microsoft Azure
I think it as A and B
A & E
https://support.microsoft.com/en-us/help/2523192/user-names-in-office-365,-azure,-or-intune-don-t-match-the-on-premises-upn-or-alternate-login-id
B is to change the upn for one user , the ? asks for “all” users/..
Microsoft do talk about the Proxy server a lot in their architecture for this sort of solution:
https://technet.microsoft.com/en-us/library/dn635310.aspx
From the link to easy gave, “here are three possible causes of this issue: 1 – Your company domain is not yet verified. ”
On this basis I would say it is A and C.
I would agree to “to easy”…
– A: correct because this domain shall be used by users. So it MUST be verified.
– B: incorrect, because powershell cmdlet cannot work with the %username%, I think it should use $env:username to work with environment variables.
– C: incorrect, because proxy addresses attributes affect only Exchange recipients. Has nothing to do with authentication.
– D: incorrect, because non-routable domain. You could never verify contoso.local 🙂
– E: correct, because technically the UPN is used for logon, but the user shall insert email address. This will only work if both attribute has same value. This is the recommended approach for Office 365.