- Office 365 Change Belongs To Account
- Change Office 365 Subscription Owner
- Change Belongs To In Office 365
- Cannot Change Office 365 License
Office 365 was not installed on a clean machine; an older version of Microsoft Office was installed previously. There is an issue connecting to the Internet, the Microsoft Office 365 portal ( ) or the ADFS server ( sts.yourdomain.com ) in your LAN or DMZ. We use Office 365 at work so I installed it on my home laptop as one of my 5 installs (or however many I get). Anyway, since then I have signed up with my own O365 Home account.
Continuing the 'how to do this with the new Azure AD PowerShell module' series, in this article we will explore some useful cmdlets that quickly list all Groups a user is member of, or is configured as Owner/Manager.
To get the latest version of the AzureAD PowerShell module, click here. To get the documentation on installing and using the module, click here.
Getting group membership
As a reminder, here's how to quickly get a list of all groups a user is member of via the EO Remote PowerShell cmdlets:
Office 365 Change Belongs To Account
where ‘CN=user,OU=tenant.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations, DC=EURPR03A001, DC=prod, DC=outlook, DC=com' is the DistinguishedName of the user, obtainable for example via:
Now, there's also one caveat you might want to consider when using the above cmdlet. Namely, the Get-Recipient cmdlet in EO doesn't return Office 365 Groups objects (the new, 'modern' groups) unless you specifically include them. An updated version of the above cmdlet that accounts for Groups will look like this:
and will return all Distribution groups, Mail-enabled security groups and Office 365 groups the user is member of. Dynamic distribution groups are something else you might want to consider, but those aren't a subject for the current article. You can add other recipient types to the above example as needed.
If you want to return membership of Exchange Role Groups as well, use the Get-Group cmdlet:
So, after covering the Exchange side, can we also do the same with the Azure AD cmdlets? The answer is yes, thanks to the Get-AzureADUserMembership cmdlet. Here's an example:
As usual, one probably wants to avoid using ObjectIds, so here's an example that takes care of that:
The next problem you will run into is handling the output, which is also full of ObjectIds. We can use calculated properties to work around this:
where we have also excluded the Role groups from the output. If you want to keep them, change the above cmdlet to:
Overall, the number of objects returned by the Get-AzureADUserMembership cmdlet should be greater compared to the Exchange cmdlets, because of the inclusion of objects such as Security groups and User Roles.
Get list of objects the user is Owner for
Similarly to group membership, we can also use PowerShell cmdlets to quickly get a list of all objects a user is configured as Owner for (or Manager in the Exchange world). Here's how to do this with EO remote PowerShell:
To get the Owner information with the Azure AD PowerShell, one can use the Get-AzureADUserOwnedObject cmdlet. Example use of the cmdlet:
or the more useful version sans the ObjectId obscurity:
A note is due here – the Azure AD cmdlet doesn't look at the 'ManagedBy' property. If you want to include Exchange related recipients in the output, such as (dynamic) distribution groups, use the Exchange cmdlet above.
-->Introduction
If your organization has a hybrid deployment (on-premises plus Microsoft Office 365), you frequently have to relay email messages to the Internet through Office 365. That is, messages that you send from your on-premises environment (mailboxes, applications, scanners, fax machines, and so on) to Internet recipients are first routed to Office 365, and then sent out.
Figure: Email relayed from your on-premises email servers to the Internet through Office 365
For this relay to work correctly, your organization must follow these steps:
Create one or more connectors in Office 365 to authenticate email messages from your on-premises mail servers by using either the sending IP address or a certificate.
Configure your on-premises servers to relay through Office 365.
Configure your setup so that either of the following conditions is true:
Sender domain
The sender domain belongs to your organization (that is, you have registered your domain in Office365).
Note For more information, see Add User and Domain in Office 365.
Certificate-based connector configuration
Your on-premises email server is configured to use a certificate to send email to Office 365, and the Common-Name (CN) or Subject Alternate Name (SAN) in the certificate contains a domain name that you have registered in Office 365, and you have created a certificate-based connector in Office 365 that has that domain.
If neither of the conditions in step 3 is true, Office 365 can't determine whether the message that was sent from your on-premises environment belongs to your organization. Therefore, if you use hybrid deployments, you should make sure that you meet either of the step 3 conditions.
Summary
Beginning July 5, 2017, Office 365 no longer supports relaying email messages if a hybrid environment customer has not configured their environment for either of the step 3 conditions. Such messages are rejected and trigger the following error message:
550 5.7.64 Relay Access Denied ATTR36. For more details please refer to KB 3169958.
Additionally, you must meet the second condition ('certificate-based connector configuration') in step 3 in the Introduction section if your organization requires that any of the following scenarios continue to work after July 5, 2017.
Note
The original deadline for this new process was moved from February 1, 2017, to July 5, 2017, to provide sufficient time for customers to implement the changes.
Scenarios in which Office 365 does not support relaying email messages by default
Change Office 365 Subscription Owner
Your organization has to send non-delivery reports (NDRs) from the on-premises environment to a recipient on the Internet, and it has to relay the messages through Office 365. For example, somebody sends an email message to john@contoso.com, a user who used to exist in your organization's on-premises environment. This causes an NDR to be sent to the original sender.
Your organization has to send messages from the email server in your on-premises environment from domains that your organization hasn't added to Office 365. For example, your organization (contoso.com) sends email as the fabrikam.com domain, and fabrikam.com doesn't belong to your organization.
A forwarding rule is configured on your on-premises server, and messages are relayed through Office 365.
For example, contoso.com is your organization's domain. A user on your organization's on-premises server, kate@contoso.com, enables forwarding for all messages to kate@tailspintoys.com. When john@fabrikam.com sends a message to kate@contoso.com, the message is automatically forwarded to kate@tailspintoys.com.
From the point of view of Office 365, the message is sent from john@fabrikam.com to kate@tailspintoys.com. Because Kate's mail is forwarded, neither the sender domain nor the recipient domain belongs to your organization.
Figure: A forwarded message from contoso.com that's allowed to be relayed through Office 365 because the step 3 'certificate-based connector configuration' condition is met
More information
You can set up a certificate-based connector for Office 365 to relay messages to the Internet. To do this, use the following method.
Step 1: Create or change a certificate-based connector in Office 365
Change Belongs To In Office 365
To create or change a certificate-based connector, follow these steps:
Sign in to the Office 365 portal (https://portal.office.com), click Admin, and then open the Exchange admin center. For more information, see Exchange admin center in Exchange Online.
Click mail flow, click connectors, and then do one of the following:
If there are no connectors, click (Add) to create a connector.
If a connector already exists, select it, and then click (Edit).
On the Select your mail flow scenario page, select Your organization's email server in the From box, and then select Office 365 in the To box.
Note
This creates a connector that indicates that your on-premises server is the sending source for your messages.
Enter the connector name and other information, and then click Next.
On the New connector or Edit connector page, select the first option to use a Transport Layer Security (TLS) certificate to identify the sender source of your organization's messages. The domain name in the option should match the CN name or SAN in the certificate that you're using.
Note
This domain must be a domain that belongs to your organization, and you have to have added it to Office 365. For more information, see Add Domains in Office 365.
For example, Contoso.com belongs to your organization, and it's part of the CN name or SAN name in the certificate that your organization uses to communicate with Office 365. If the domain in the certificate contains multiple domains (such as mail1.contoso.com, mail2.contoso.com), we recommend that the domain in the connector UI be *.contoso.com.
Note
Existing hybrid customers who used the Hybrid Configuration Wizard to configure their connectors should check their existing connector to make sure that it uses, for example, *.contoso.com instead of mail.contoso.com or .contoso.com. This is because mail.contoso.com and .contoso.com may not be registered domains in Office 365.
Figure: Setting up the connector to use the 'contoso.com' format (for example)
Step 2: Register your domain in Office 365
To register your domain, follow the steps in the following Office article:
In the Microsoft 365 Admin Center, click Setup, and then click Domains to see the list of domains that are registered.
Step 3: Configure your on-premises environment
To configure your on-premises environment, follow these steps:
Cannot Change Office 365 License
If your organization uses Exchange Server for its on-premises server, configure the server to send messages over TLS. To do this, see Set up your email server to relay mail to the Internet via Office 365.
Note
If you've already used Hybrid Configuration Wizard, you can continue to use it. However, make sure that you use a certificate that matches the criteria that's outlined in Step 1, sub-step 5 of this section.
Install a certificate in your on-premises environment. To do this, see Step 6: Configure an SSL certificate.
References
For more information about how to address the connector setting requirement, see Important connector notice.
For more information about how to relay messages through Office 365, see the 'Setting up mail flow where some mailboxes are in Office 365 and some mailboxes are on your organization's mail servers' section of Mail flow best practices for Exchange Online and Office 365.
Still need help? Go toMicrosoft Community or the Exchange TechNet Forums.
