O365 Email accounts and aliases

[Bugzi]

Hello,

 

I was wondering if someone could assist please?

 

Our current email setup is rather complicated and confusing and we are looking at simplifying it.

 

Currently teaching staff have one AD account with an email address attached.

Non teaching staff have one AD account with an email address attached and two additional O365 accounts with other email addresses.

For example: [email protected], [email protected] and [email protected].

 

I don't know the exact reasons as to why this was, but SLT wanted it this way.

This is causing non stop issues with O365 and teams and SharePoint as people are confused as to what account they should be using.

 

A possible solution that we are looking at is to merge the two additional email accounts into the main AD account, but is it possible to have the second email address as the main send/receive email address?

 

For example, user logs in with "[email protected]" into O365 but sends and receives emails as "[email protected]".

 

Any tips would be greatly appreciated please.

 

Thanks

[chaplic]

Yep.

 

Your loginname ([email protected]) doesn't have to bear ANY resemblance to your SMTP address(es)

 

I'm assuming you are syncing your AD accounts to O365, so in AD look at the proxyAddresses field if I have

 

SMTP:[email protected]

smtp:[email protected]

smtp:[email protected]

 

Then primary reply address will be [email protected] (note the capital SMTP@) whilst they will recieve email addressed to any of those three addresses (assuming registered in tenant obviously)

[Bugzi]

Thank you.

Will try this.

 

When we specify a new primary SMTP address, will this also change the default email address in the global address book?

 

Ours seems to take days to always update

[chaplic]

Yes, this will change the GAL. The delay is by design and expected

[Bugzi]

Thanks.

So I'm making these changes in the "proxyAddresses" attribute.

Would I need to change the "mail" attribute too, as that is still set to the same as the login address?

[chaplic]

Thanks.

So I'm making these changes in the "proxyAddresses" attribute.

Would I need to change the "mail" attribute too, as that is still set to the same as the login address?

mail field in O365 does practically nothing. However, I would reccomend you keep it the same as the primary reply-to address.

[p858snake]

Non teaching staff have one AD account with an email address attached and two additional O365 accounts with other email addresses.

For example: [email protected], [email protected] and [email protected].

 

Do they need to be able to send from these additional email address or just receive? (eg, if they are trading under multiple college names?)

 

A possible solution that we are looking at is to merge the two additional email accounts into the main AD account, but is it possible to have the second email address as the main send/receive email address?

 

For example, user logs in with "[email protected]" into O365 but sends and receives emails as "[email protected]".

 

This is essentially what we do, Our IT is hosted by a government department that hosts a couple of different departments IT systems, and then we have had Machinery of Government name changes which have given us multiple email address.

 

login is: [email protected] (this is what we advertise to log into systems like O365, Apple DEP)

then we have: [email protected] (sending and receiving)

we also have: [email protected] (receiving)

we also have: [email protected] (receiving)

[chaplic]

Sending as an alternative address has always been a pain and done via some fudge, e.g. set the desired address as a DL then send as that DL, or a shared mailbox, or setting up a IMAP connection too

 

However MS have introduced a fix - Ive never tried it so interested to see the results

 

Office 365: Now You Can Send Email From Proxy Address (o365reports.com)

[Bugzi]

Thanks everyone.

I'm making progress here with this but running into a few oddness.

 

We've changed some of our accounts over but it seems Teams is not playing ball.

When we search for a member of staff that changed, it's showing both the correct account and the old account.

 

The old account we changed in O365 admin from our domain to an onmicrosoft.com domain but Teams is still showing the previous email address that is now an alias on the main AD account.

 

I've followed these examples on clearing the Teams cache, but none of them have worked:

Troubleshooting Microsoft Teams – Clear Teams cache on Windows 10 – Boot Networks

 

Does anyone else have any suggestions please?

[chaplic]

Wait 48 hours. Teams can be really lazy updating stuff, and it's server end not client end so nothing helps.

[Boredguy]

The Address book itself normally updates overnight, but as Chaplic said, Teams can take 48 hours (or sometimes more) to finally pick up any changes made to account details.

 

During the middle of last year when we were still teaching remotely, we updated all the students display names so it showed Surname, Forename to make it easier for staff to register them.. it still had some students with the names inverted the originally way 2 days after the rest of the Team members had updated. It will change, just takes time

[Bugzi]

Thanks everyone.

So what we have done so far is:

 

1. Rename old 365 account to export the pst file into the main AD account. (This had the other domain for the email address).

2. Add the aliases to the AD account and change the primary smtp and import the pst.

 

This has all worked, but the old 365 account is still showing up in Teams when we search for them.

The account within 365 just has our collegename.onmicrosoft.com domain, but Teams seems to still think it's previous domain.

 

I understand it can take time to sync, but it's been over a week.

Is there a trick to speed this up please?

[chaplic]

So you're searching for 'fred bloggs' and the account returned '[email protected]' is being shown, and this account is soft deleted and not visible in the AAD portal?

 

If so, agree something is funky. Once I had an issue where we re-enabled the ability for some users to send IMs but some people couldn't despite the usual waiting, reseting cache, patting belly and rubbing head etc. Raised a ticket with MS and the engineer mumbled something about updating the front end, anyhoo 24 later it was sorted.

[Bugzi]

Not quite. Sorry

 

We all have "[email protected]". Support staff have "[email protected]" and "[email protected]" and "[email protected]".

The "college2.ac.uk" and "college3.ac.uk" domain are all separate O365 cloud accounts but the "college.ac.uk" domain is a Hybrid (Local AD sync) with O365.

 

We renamed "[email protected]" and "[email protected]" accounts to "[email protected]" and "[email protected]".

We then changed the default SMTP for "[email protected]" AD account to "[email protected]" and added "[email protected]" and "[email protected]" as an alias in AD.

 

This all worked fine.

 

But, in MS Teams, we can still find the old "[email protected]" O365 cloud account when you search for "Fred Blogs".

We haven't deleted the accounts but have hidden them from the Global Address Book.

 

I hope this makes sense?

[chaplic]

Just hiding them from the GAL isn't going to achieve this. Have a look at this, I have a feeling there may be licensing implications

 

 

Use Microsoft Teams scoped directory search - Microsoft Teams | Microsoft Docs

[Boredguy]

You might need to look at creating additional Global Address Books to assign to users to limit who can see who.

 

Example, all our Students have a custom GAL assigned which only lets them see fellow students and the Teaching staff in their Address book, and not our Governors or Support staff

[Bugzi]

Thanks for the help.

Still having fun with this, lol.

 

Another issue I've come across is that when we create new accounts in AD and put "college2.ac.uk" and the primary SMTP and all the other domains as aliases works great by hand, but when we try and automate this using PowerShell I found an odd quirk.

When we use the PowerShell command "Set-RemoteMailbox" to set various settings, it applies the settings but it also resets the primary SMTP from "college2.ac.uk" back to "college.ac.uk".

 

Ref: Set-RemoteMailbox (ExchangePowerShell) | Microsoft Docs

 

I've had a look at our local exchange server, as we have a hybrid setup, and our "email address policies" are disabled / unapplied.

 

Does anyone have any pointers as to where I might find the culprit please?

[chaplic]

I live in a world where people are trying to minmise exchange on prem, even if notionally having to have an exchange server on prem for daft MS support requirements

 

So to that end, I would be modifying the AD attributes directly - proxyAddresses and MsExchangeRecipientDisplayType and so on.

[Boredguy]

That command appears to be specifically for local Exchange servers, not 365 hosted or hybrid setups, so easier update the values either manually, or use Powershell to update the ADUser proxyAddress field

 

Import-Module ActiveDirectory
$User = Get-ADUser UserA -Properties proxyAddresses
$User.proxyAddresses.Add("smtp:User@Domain")
Set-ADUser -instance $User 

[Bugzi]

Thanks both.

 

I set the AD attributes already via PowerShell and that works fine.

 

However, some settings like the in-place archive, I can't seem to do via AD attributes and Microsoft recommends "Set-RemoteMailbox" but as soon as that command is run, it does "something" and changes the email format back to "domain.ac.uk".

I'm trying to understand why it changes.

[chaplic]

Thanks both.

 

I set the AD attributes already via PowerShell and that works fine.

 

However, some settings like the in-place archive, I can't seem to do via AD attributes and Microsoft recommends "Set-RemoteMailbox" but as soon as that command is run, it does "something" and changes the email format back to "domain.ac.uk".

I'm trying to understand why it changes.

All settings, including archive mailbox are set via AD (then synced into AAD then into exchange directory). There is no magic connection between exchange and O365, in fact it doesnt even need to be in hybrid.

 

Take a look at this, Exchange Recipient Type Attribute Values in Active Directory - Cloudrun then dump the same values in your AD. Then do things like 'set-remotemailbox' and see what changes.

[Bugzi]

Thanks again for the replies, much appreciated.

 

I've checked the accounts and "msExchRecipientTypeDetails" is "2147483648", "msExchRemoteRecipientType" is "1".

The mailboxes are all in O365.

 

But strangely, on some accounts that were created earlier this month, when I run any switch with "Set-Remotemailbox" has it's email address format changed back to "domain.ac.uk".

 

What I've found is in the AD attributes, there is "msExchPoliciesIncluded" and the account that has it's email format changed has "{26491cfc-9e50-4857-861b-0cb8df22b5d7} and 5f4163c4-83a0-4752-92cf-e7f860d2b30a" as values.

The test accounts, created around the same time and same process have nothing set in "msExchPoliciesIncluded" but have "msExchPoliciesExcluded" with value "{26491cfc-9e50-4857-861b-0cb8df22b5d7}" set.

 

Not sure if those attributes are meant to do something or not.

[chaplic]

I know you said recipient policies are not in play but the guid ending 5d7 is 'disable email address generation for this mailbox'

[Bugzi]

Thanks.

Somehow/something is setting the users active with "EmailAddressPolicyEnabled" set to true.

This seems to be default on our network even though our Email Address Policies show as "not applied".

 

They used to be active, years ago though I was told.

 

So far I've set all the affecting users to disable the email address policy until the migration is complete.

I've been told that we need to turn this on again though so the fun then continues