1

I need to stand up a test domain to try and fix accounts that have been synced into AAD. I have had zero experience with Azure AD or O365, so I'm not sure how to proceed.

A previous admin setup our company's O365 account and setup AD Connect, apparently without ever reading up or testing. AD here has been a mess.

I am the 4th person to inherit this mess. All the previous admins had their idea of the proper AD structure and best practices for groups and group policy. I've spent the better part of a year putting out fires and replaced a couple DCs and cleaned up ghosts of DCs past. We have not had any replication issues in 6 months, so I feel confident in moving forward with trying to get O365 working.

====================== The problem(s): Accounts that are synced have user@company.local names and do not allow us to log into O365. The only working accounts have been created in the cloud using their email addresses.

My plan: Setup a new DC (Hyper-V) Allow it to replicate. Shutdown DC and clean up AD so there are no ghosts left. Bring the DC up in an isolated network. Setup a trial O365 account. Sync AD to trial account. Try to fix the problems we have in our production domain.

======================

Here is where I have questions.

I need to allow this test domain to have access to the internet and O365.

Will I be able to setup a trial O365 account and setup AD connect to sync just like the production domain?

Will I be able to setup a hybrid Exchange environment to test moving mailboxes to the cloud in a trial?

The IDfix tool says I need to fix ProxyAddresses. Do I set it to our users SamAccountNames or email addresses.

I'm probably missing a lot here. Please let me know what I've missed and where I need to be looking.

Thanks for your help! dot19408

2

This is general guidance. You probably need someone who has Office 365 migration experience to look at your situation in order to give you specific guidance.

Don't lump these problems together. Fixing AD and migrating to Office 365 are separate and distinct issues and neither should have any impact on the other. Follow the IDFix recommendations for fixing your proxy addresses.

The problem(s): Accounts that are synced have user@company.local names and do not allow us to log into O365. The only working accounts have been created in the cloud using their email addresses.

  1. company.local isn't a verified domain in Office 365 and can't be added as a verified domain in Office 365. Only "routable" domains can be verified in Office 365. You need to create an alternate UPN Suffix in AD to match your verified domain in Office 365 (the public domain that you are using in Office 365 - The one that you already have in place for the cloud users).

  2. You need to configure the on premises AD user accounts to use this UPN suffx.

  3. Once you install Azure AD Connect your on premises users will be merged with the existing Office 365 users.

  • Thanks joeqwerty, The UPN was already in place when I got here. All users have that UPN set. – LT.Son Jan 8 at 19:24
  • Is the "routable" domain verified in Office 365? Is Azure Ad Connect installed yet? – joeqwerty Jan 8 at 22:52
  • If the on premises UPN was changed AFTER the users were synced to Office 365, Azure AD Connect will not change the UPN of the Office 365 object. If that's your case then you'll need to read this article on how to resolve this - support.microsoft.com/en-us/help/2669550/… – joeqwerty Jan 9 at 2:01
  • Yes the routable (company.com) domain is verified in Office 365. – LT.Son Jan 9 at 15:32
0

Correct your users UPN in local AD by adding missing suffixes to AD via 'Domains and Trusts'.

Next force a full sync from Azure AD Connect (AADC) by opening Powershell on the AADC server and typing 'Start-ADSyncSyncCycle -PolicyType Initial'.

This should fix a lot of issues you mentioned. If you want to troubleshoot further, login to portal.azure.com with your O365 admin account and go to Azure AD - AD Connect and open the Health Overview, IDFIX is also a good tool to fix problems (meant to use before the first sync to prevent this kind of issues).

Hope this helped!

0

I think that you didn’t need to setup a new DC. You just need to change the UPN to match the domain you verified in Office 365. You could refer to the following article: Office 365 – Why Your UPN Should Match Your Primary SMTP Address https://blogs.perficient.com/2015/07/07/office-365-why-your-upn-should-match-your-primary-smtp-address/

“I need to allow this test domain to have access to the internet and O365.” The domain you add to Office 365 must be your own, it cannot be test domain.

You could create an OU for test accounts in local AD and select only sync this OU in AAD connect.

Whether to deploy hybrid depends on your requirement. Pros & Cons of a Full Hybrid Office 365 Exchange Deployment http://www.coyotecrk.com/pros-cons-full-hybrid-office-365-exchange-deployment/

in addition, you could use Microsoft Exchange Server Deployment Assistant to do configuration: https://technet.microsoft.com/en-us/office/dn756393.aspx

  • Management is requiring that we fully test and document results in a test environment. I agree that we can test these changes with a few accounts, but I have my orders... – LT.Son Jan 9 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.