Bulk updating UPN suffix to prep for DirSync with O365

Technology Microsoft
1

I’ve got tons of @domain.local UPN suffixes in AD and want to change them to a valid FQDN, but only for one domain at a time so I can make sure AD is configured properly for them first.

Here’s my bulky script to avoid updating certain OU’s and users that I don’t want to mess with (UNTESTED!!!):

Import-Module ActiveDirectory
Get-Mailbox -ResultSize Unlimited | 
Where-Object `
{($_.UserPrincipalName -like "*@domain.local" `
-and $_.PrimarySmtpAddress -like "*@domainname.org" `
-and $_.DistinguishedName -notlike "*ou=DomainAdmins,*" `
-and $_.DistinguipowersshedName -notlike "*ou=LocalAdminAccounts,*" `
-and $_.DistinguishedName -notlike "*ou=SQL,*" `
-and $_.UserPrincipalName -notlike "Discovery*")} | 
ForEach-Object {
  $newUpn = $_.UserPrincipalName.Replace("domain.local","domainname.org")
  $_ | Set-ADUser -server "DC1" -UserPrincipalName $newUpn
}

This is run from an exchange powershell prompt running as admin.

I have a feeling I could do the same thing without get-mailbox and instead use Get-ADUser on my local machine that simply has RSAT…

It may even be better to simply create an OU that will sync with O365 and move everyone there (or maybe move accounts I don’t want to sync out of the default “Users” CN).

My fear of changing OUs around is there are many obscure tools that must be set to a specific OU to work, and moving a user to a different OU may change functionality that I won’t remember until later…

What do you guys do for updating UPNs to prep for O365 DirSync?

2

You’re over-thinking this a bit.

First you do need to run this from Something with RSAT tools

Second you want to create some test accounts and put them in an OU - in the script we’ll call that OU Domain Users.

Next you want to focus on just that OU - we’ll use the Search Base for that.

Lastly we want to run the -whatif switch to make sure we’re only doing what we think we are.

So take a look at this script and see if it makes any sense to you:

start-transcript

Import-Module ActiveDirectory

#Replace with the old suffix
$oldSuffix = ‘Domain.local’

#Replace with the new suffix
$newSuffix = ‘Domain.com’

#Replace with the OU you want to change suffixes for
$ou = “OU=Domain Users,DC=Domain,DC=local”

Get-ADUser -ResultSize Unlimited -SearchBase $ou -filter * | ForEach-Object {
$newUpn = $.UserPrincipalName.Replace($oldSuffix,$newSuffix)
$ | Set-ADUser -UserPrincipalName $newUpn -Whatif
}

3

I often get paranoid around AD and wind up making these things more complicated than they need to be for fear of making unwanted changes.

I can definitely set up a test OU, but I’ll have to do more research to make sure I’m not breaking anything else by moving the staff to that OU once we’re ready to make the changes en masse.

When I list all of our Primary SMTP addresses I see we have 44 different domains being used. While I am not a fan of this, it is the way things are done. Should I do anything different for those people, or just tell everyone to log in with username@ourmainsuffix.org ?

Most of those domains only have 1 or 2 mailboxes and are accessed by other users and not logged into directly.

4

If you have 44 different Primary Email addresses what does your SSL certificate look like for Exchange?

5

Well ed… you start by requesting a *.* certificate from every Cert authority and wait for one to accidentally issue it…

2 Likes
6

I only have an SSL cert for our primary domain. It hasn’t prevented anyone from sending or receiving mail so far.

7

So here’s the thing - you can kind of get around this in Exchange when you’re dealing with Aliases. But if you’re going to Hybrid Exchange and use these different domains you’re going to have a really big issue as you must have an SSL certificate for every accepted domain you’re configuring it for in Office 365. In your case you would need a SAN cert with about 50 domain names so that you can include the Autodiscover record.

8

Do I need a SAN cert for email domains that are not primary SMTP addresses, but simply aliases?

9

So this is a crazy topic and deserves more than just a thread but the answer goes like this:
You need a SAN cert that includes ANY email address that is in the users Proxy Email addresses Attributes - this is regardless if it is Primary or Secondary.
ALSO
You need an Autodiscover name in the SAN Cert for any email address that IS primary.

So let’s say you have a domain called Domain.local and you have a few other domains like:

  • Domain.com
  • Domain2.com
  • AnotherDomain.com

Now let’s just say that I look at ProxyAddresses attributes for a couple of users

User1:

  • SMTP:User1@Domain.com
  • smtp:JP@Domain2.com
  • smtp:User.1@Anotherdomain.com
  • smtp:user1@domain.local

User2:

  • smtp:User2@Domain.com
  • smtp:JM@Domain2.com
  • SMTP:User.2@Anotherdomain.com
  • smtp:user2@domain.local

In this case we have users who have a primary SMTP address in 2 Different DNS Domains. Assuming there are no users who have primary SMTP address in the Domain2.com we do NOT need an Autodiscover

Because of this we would need to have a SAN cert with these subject names (assuming the name of the Hybrid mail server is mail.Domain.com)

Mail.Domain.com
Autodiscover.Domain.com
Mail.Domain2.com
Mail.AnotherDomain.com
Autodiscover.AnotherDomain.com

You can see that all 3 domains are listed in the SAN cert.
Also you can see that Autodiscover records are listed for each of the domains where there are Primary SMTP addresses.
Lastly something that should stick out is that the SAN cert does NOT cover the Domain.local. Although it was possible to get a SAN cert with a .local in it at one time that practice has been eliminated. Therefore if you have user who has an email address listed of a .local in their ProxyAddresses Attribute the address Must be removed or the user cannot be migrated to Office 365.

Chris in your case where you have so many different Primary SMTP Domains it may be cost prohibitive for you to get a SAN cert to cover the domains you have just so you can migrate the users to the cloud. In such a case you may really want to look into a cutover migration.

10

Don’t neglect the Proxy Address property on the local AD accounts. When your local accounts sync up, if the “proxyAddressess” property is empty, it will likely result in login names you don’t want in the Office 365 console. Prior to syncing your accounts to O365, you should ensure that the property is set to something that Office 365 will like, and that your users are familiar with (like their email address or username).

One way of doing this to everyone at once, in PS is:

Import-Module ActiveDirectory
$users = Get-ADUser -Filter *
foreach ($user in $users)
{
    $email = $user.samaccountname + '@domain.org'
    $newemail = "SMTP:"+$email
    Set-ADUser $user -Add @{proxyAddresses = ($newemail)}
}

Obviously, you can filter by OU here as well. change ‘domain.org’ to your public sign-in domain.

This is needed if you want to use .local or something else (internal.domain.com) as your suffix internally. This is commonly implemented as a way of avoiding split DNS. As it stands, the accounts would sync with a sign-in of “username@internal.domain.org” instead of “username@doamin.org”

Users.PNG636×923 58.5 KB

11

So I’ve decided to just make an OU to sync and have them all be updated with the basic script above (filtering out only that OU) as everyone recommended.

It worked well and everyone in the OU passes ldfix just fine.

Here’s my thoughts now:

  1. Can I use this OU for DirSYNC and sync with O365 now, so all my staff can use O365 with their domain credentials even though we haven’t enabled Exchange yet (I have enabled OneDrive, S4B, Teams, etc)?
  2. If we do that, can I easily associate these accounts with users already in O365 that are using cloud passwords (easily can be manual, we don’t have that many staff)?
  3. If we do that, and a month later decide to do a cutover -or- hybrid Exchange migration, would we run into any issues?

I’d like to take this step by step and at least begin using what we are already using in the best possible way.

12

  1. I believe so, but have never tested. I don’t see why not, though.

  2. When we chose to sync our directory, I wondered the same thing. Turns out that as long as the UPN is the same in O365 as the one you’re syncing up, O365 automatically pairs the accounts into one that is then said to be “Synced.” You can test and observe this (as I did) by creating a “test” account in O365, and then creating a second account in local directory with the same UPN. That same kind of testing would confirm question one as well.

    synced.PNG1919×787 280 KB

  3. I don’t so, especially for a cutover. I can’t speak for a hybrid deployment though, I know they have some weird requirements.