Requirements

In order to have successful results, you will need the following.

• Exchange Administrator Permissions -or Global Administrator Permissions
• Audit Logs Enabled. Specifically Mailbox Audit logs
• Exchange Online Management PowerShell Module

Get Recipient Permissions to See Who Has Access

Before we dive deep into the logs, I always like to narrow down my search by simply seeing who has access to send as that specific account. If there are only 1-2 users who have access, this narrows things down pretty well. If there are a dozen or more, then things might get a little tricky and we’ll need to go into logs.
 

Let’s check to see who has permissions and see if we get lucky. To find this, we’re going to use the Get-RecipientPermission cmdlet from the ExchageOnlineManagement module.

Get-RecipientPermission testmailbox -AccessRights SendAs | Where-Object {$_.Trustee -ne 'NT AUTHORITY\SELF'}

Identity     Trustee                     AccessControlType AccessRights Inherited
--------     -------                     ----------------- ------------ ---------
Test Mailbox paul@thesysadminchannel.com Allow             {SendAs}     False

In some scenarios it very well may be possible that the account itself sent the email, but for the sake of this article we’re going to assume someone sent an email with the sendas permissions. Therefore we added the where clause to not include SELF.

Find Account That Sent Emails From Shared Mailbox

In the example above, we can see that only one account has access to send as the shared mailbox so it’s pretty much a no brainer in this scenario. However, as I mentioned before, some shared mailboxes (or regular mailboxes for that matter) can have multiple people with this access right.
 

In order to find the exact user, let’s look to the logs and see what they say. Logs never lie!

$SendAs = Search-MailboxAuditLog -Identity testmailbox -Operations SendAs -ShowDetails
$Sendas | select LogonUserDisplayName, ClientProcessName, ItemSubject, OperationResult, LastAccessed


LogonUserDisplayName : Paul Contreras
ClientProcessName    :
ItemSubject          : The Force
OperationResult      : Succeeded
LastAccessed         : 9/14/2023 8:37:38 PM

Conclusion

In this case the recipient permissions pretty much gave it away as I was the only one with permissions. However, being able to search in the mailbox audit logs will show us EXACTLY which was the account that sent this email. Hopefully this was informative for you and you’re able to find out who sent emails from shared mailbox.

The post Find Account That Sent Emails From Shared Mailbox using PowerShell appeared first on the Sysadmin Channel.

Requirements

In order to set this up without failure, there are a few things needed to get you on your way to using Exchange Online certificate based authentication. Let’s cover what’s needed right now.
 

• A certificate, either self signed or one issued by PKI
• Azure Application Administrator or Global Administrator
• Privilege Role Administrator or Global Administrator
• Exchange Online Management PowerShell module

Above are the requirements to allow you to connect to Exchange Online using certificates. I manage Exchange Online using PowerShell so I added that as well. If you’re looking for instructions on how to get that installed, check out this article to install the Exchange Online Management module for PowerShell.

Create a Self-Signed Certificate

First things first, I thought it would be best to start off by creating the self-signed certificate to get the ball rolling. If possible, I would recommend using a certificate issued by a public key infrastructure (PKI). The reason for that is because we know we can trust it, it is inherently more secure, and we can also revoke the cert should the situation call for it. The problem is not every environment has a PKI setup (my lab included).
 

As mentioned, we don’t have a PKI in our environment so we’ll make due with a self signed certificate. Luckily, Azure does support self signed certs so let’s get that created within PowerShell.
With PowerShell open, enter in the following:
 

#splatting for human readability
$CertParam = @{
    'KeyAlgorithm'      = 'RSA'
    'KeyLength'         = 2048
    'KeyExportPolicy'   = 'NonExportable'
    'DnsName'           = 'server.thesysadminchannel.com'
    'FriendlyName'      = 'Exchange Online Automation App'
    'CertStoreLocation' = 'Cert:\CurrentUser\My\'
    'NotAfter'          = (Get-Date).AddYears(1)
}
 
#Creating self signed cert with parameters from above.
$Cert = New-SelfSignedCertificate @CertParam

The above parameters do not allow you to export the certificate to another machine. I should also note that this is saving the certificate under the user context. If you want to store the certificate under the local machine context, you will need to run PowerShell as an administrator anytime you to connect. Allowing it under the local machine certificate store means other administrators on the machine would also be able to connect. So just be aware.
 

Now that we have the cert created, let’s export it so we can upload it to Azure when we create our application.

#Since we captured the output to the $Cert variable in our previous step.
#We will use that to specify the cert parameter. 
#The .cer file will exported to the user's desktop.
 
Export-Certificate -Cert $Cert -FilePath $Home\Desktop\ExchangeOnlineAutomation.cer

Create an Azure App Registration and Service Principal

To get started, we need to make sure we have the proper rights to get the application created. This is where you will need an Azure AD Application administrator (or Global administrator).
 

Within Azure AD:

• Navigate to App registrations → New registration

• Name your application accordingly. I’ve named mine Exchange Online Automation
• Select Accounts in this organizational directory only (Single tenant)
• Leave the Redirect URI empty
• Click Register to create the app

With your app now created:

• Navigate to Certificates & secrets
• Click the certificates tab
• Click Upload certificate
• Click the folder icon and browse to your desktop to select the exported cert
• Click Add

Next we need to add the Exchange.ManageAsApp API permissions within the app so the application object can access the resource. To do this we need to add it through the manifest because we won’t be able to find it via the typical API permissions blade.
 

Within the app, navigate to the manifest blade and replace the requiredResourceAccess block with this code. Be sure to click save when it’s added.

"requiredResourceAccess": [
   {
      "resourceAppId": "00000002-0000-0ff1-ce00-000000000000",
      "resourceAccess": [
         {
            "id": "dc50a0fb-09a3-484d-be87-e023b12c6440",
            "type": "Role"
         }
      ]
   }
],

Once that is saved, we can verify it was added correctly by going back to API permissions. We will now see that Exchange.ManageAsApp is the only entry there.

 

However, we will notice that the app requires admin consent in order for it to be effective. Go ahead and consent to it now. Once complete, it should look like the image below.

Add Exchange Administrator Role

With our app now created and configured properly, we’ll need to grant the Exchange Administrator role to that app.
 

Within Azure AD:

• Navigate to Roles and administrators
• Search for Exchange and click on Exchange administrator

• You should be taken to the active assignments for the Exchange admin role
• Click on Add assignments

• Click no members selected link
• Search for the app name (Our is Exchange Online Automation)
• Click on the app to add it to the selection
• Click select
• Complete the prompts to add the role

We should now see our Service Principal listed as an active assignment.

Connect to Exchange Online using the Azure Application

Finally, we’re in a spot where we can put all of the pieces together and connect to Exchange Online using our Azure AD application (Service Principal). Again, since I use PowerShell to manage EXO, we’re going to connect using the Exchange Online Management module. Be sure to use the latest version.
 

Before we connect, let’s get the AppId. We’ll also need to know the tenant’s default onmicrosoft name. To get the AppId, go back to the overview page of the Application we created earlier.

 

$AppId = '9e46ef5x-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
$Certificate = Get-ChildItem Cert:\CurrentUser\My\A94FFE108DCxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
$TenantName = 'thesysadminchannel.onmicrosoft.com'

Connect-ExchangeOnline -AppId $AppId -Certificate $Certificate -Organization $TenantName -ShowBanner: $false

As you can see, we were able to successfully connect to Exchange Online and run the Get-Mailbox command against my account. As a side note, I’ve also chosen to not display the banner by using the ShowBanner: $false parameter in the command.

Conclusion

Hopefully this article on how to use Exchange Online certificate based authentication was insightful and you were able to implement it in your own organization. This is used pretty much daily to automate tasks in Exchange and it’s great that we don’t have to worry about usernames and passwords.
 

If you want more information on creating Azure apps and using Graph API, check out my in-depth article on how to Connect To Microsoft Graph API Using PowerShell.

The post Exchange Online Certificate Based Authentication appeared first on the Sysadmin Channel.

Requirements

If this is something we are considering than let’s take a look at the options we have available to us. As mentioned, the best (and most practical) way to handle this task is to do so via a transport rule. Furthermore, let’s list the requirements here.

• Exchange Administrator Role
• Exchange Online with a valid mail license

Block Users From Sending to External Recipients in Office 365

Regarding use cases, I’m sure someone somewhere can justify a good reason why we would want to block mail to an external domain like Gmail, yahoo or anyone outside of your domain. Perhaps they want to prevent someone from leaking information, whatever the reason may be, we’ll show you how to get this done.
 

First we’ll want to open a browser of your choice.

• Navigate to Exchange Admin Center
• Expand Mail Flow -> Rules
• Direct Link: https://admin.exchange.microsoft.com/#/transportrules

• Next Click on the “+” to create a new rule
• Select Create a new rule

• Name the rule Block Sending to External Domains
• Scroll down a bit and click on the more options link
• Under apply this rule if dropdown, select the recipient.. -> is external/internal -> select outside the organization
• Click Add Condition
• Under the next and statement, select the sender.. -> is a member of this group -> select a mail-enabled security group
• We have the option to choose individual users but it’s always best to use groups for easier administration
• Under do the following -> select block this message -> select delete the message without notifying anyone
• Apply exceptions as needeed

Testing The Exchange Transport Rule

Now that we have the rule in place, we should be able to test that it’s actually working. To do that, we’ll send an email to both an external domain and to someone in our tenant.
 

In this instance, we can run a simple message trace to see the status and the event type.

Conclusion

Hopefully this article was informative and we were able to show you how to block users from sending to external recipients. We showed you how to create an Exchange Transport Rule as well as confirming that the actual email was being blocked at the Exchange level.
 

If you’re looking to implement something like this, just be sure that you have the right parameters in place. If this is not configured correctly, you can imagine the mayhem you’d cause by blocking all outbound emails.
 

Finally, if you’re looking for more articles on Exchange, be sure to check out how to block legacy authentication in Office 365

The post Block Users From Sending to External Recipients in Office 365 appeared first on the Sysadmin Channel.

Requirements

As of today, there aren’t any major requirements other than having an Office 365 tenant and a mailbox in Exchange Online to be able to use this feature.
 

Plus Addresses – What is it and why should I use it

Before we get into the details of how to enable plus addressing in Office 365 Exchange Online, let’s take a minute to explain what it is and why it would be beneficial for you to use it.
 

For starters, plus addressing is a standard approach for mailboxes to provide dynamic, disposable recipient email addresses. Furthermore, it should be explicitly mentioned that this is intended for recipient addresses, not sending addresses.
 

As we’re well aware, the basic format for an SMTP email address is username@domain.com. However, when using plus addressing, the basic format would be username+additionalcharacterstomakethisunique@domain.com. When using plus addresses, you as sender can specify a any set of characters after the “+” and when enabled, Exchange will see that and route the mail to the mailbox that it corresponds to. This is assuming the underlying mailbox is active and functioning properly.
 

We’ve gone over the what, so now let’s go over the why. Why would enabling this in your tenant be beneficial to you or your users?
 

Essentially, this would be useful to many organizations because it allows you to use “burner” addresses that route to your mailbox in the backend. I’ve used it on a couple of occasions myself, mainly when testing something using a different address. However, this can also be useful for users who would like sign up for subscription services and have the ability to identify those quickly.
 

Enable Plus Addressing in the Office 365 Portal

We’ve identified what plus addresses are and how they can might be of service to you and your org. Now let’s take a look how to enable plus addressing in the Office 365 Portal.
 

Within the Exchange Admin Center:

• Navigate to Settings -> Mail Flow
• Direct Link: https://admin.exchange.microsoft.com/#/settings
• Ensure Turn off plus addressing for your organization is unchecked

Enable Plus Addressing using PowerShell

An alternative to the Exchange Admin portal is being able to enable plus addressing using Powershell. For starters, we’ll need to install Exchange Online Powershell Module and connect to it using the Connect-ExchangeOnline cmdlet.
 

Once connected, we can run a one-liner to enable this feature for your tenant.

PS C:\> Connect-ExchangeOnline -ShowBanner: $false
PS C:\>
PS C:\> Set-OrganizationConfig -DisablePlusAddressingInRecipients $false
PS C:\>

Conclusion

Hopefully this article to show you how to enable plus addressing for Office 365 and Exchange Online was helpful. Plus addressing is helpful for users who want to create dynamic, disposable recipient addresses.
 

If this was helpful, be sure to check out our other Exchange Online posts.

The post Enable Plus Addressing in Office 365 Exchange Online appeared first on the Sysadmin Channel.

There are ways to check in the GUI and ways to check in Powershell way for CLI folks like myself. We’ll go over both methods in this article.

Requirements

As far as requirements go, we’ll lay them down here so you can have success when using this immensely useful tool.

• Global Administrator -or Exchange Administrator Role
• Information to query. SenderAddress -or RecipientAddress -or MessageId -or MessageTraceId

How to use Message Trace in Exchange Admin Center (GUI)

To achieve this, open your favorite browser and navigate to Exchange Online. There are 2 commonly known portals at this time:

• Classic Portal Direct Link: https://outlook.office365.com/ecp/
• Newest Portal Direct Link: https://admin.exchange.microsoft.com/#/messagetrace

 
In this example we’ll use the new portal.

• Once you’re in the Message Trace blade, click start a trace and a side panel will popup.
• Populate the Sender and/or Recipients you would like to check
• Select how many days you would like the search to check. Anything 10 days or newer, it is immediately accessible. Searches older than 10 days will be sent via email
• Select Summary Report
• Click Search

 
Once you get the data back from the message trace, take note of the message status. In this case, it will show “The message was delivered to the recipient’s Inbox folder.” In other cases, it will show SPAM or if they have mailbox rules in place the message will show the folder that it was delivered in. Pretty neat.

How to use Message Trace in Powershell

The tool of preference for me will always be Powershell over a GUI because it lends it self to being more scalable. I’m also in the CLI most of the so it saves time from clicking into multiple windows to get to where I need.

Just like in the GUI, you’ll need basic information to run proper searches. Also, one thing to note here is that Get-MessageTrace only runs the last 48 hours by default. If you need to search emails from 2-10 days you’ll need to use the -StartDate and -EndDate parameters. Here is an example of how to run the command in Powershell.

#Get all emails sent to Gabby over the past 10 days.
Get-MessageTrace -RecipientAddress gabby@thesysadminchannel.com -StartDate 6/20/21 -EndDate 6/30/21

If you want to get additional information from the email you can pipe it to Get-MessageTraceDetail to give you more detail on what’s going on under the hood.

#Get the message trace detail sent to Gabby over the past 10 days.
Get-MessageTrace -RecipientAddress gabby@thesysadminchannel.com | Get-MessageTraceDetail

Get all the Recipients an Email was Sent to

Another use case is to determine who are all the recipients an email was sent to. This is actually going to be a 2-step process and we’ll go over those as well.

First we’ll need to get the MessageId from one of the recipients, an example is just like the one mentioned above. For the sake of testing, we’ll use another email to get the hang of everything.

#Get the message trace detail sent to Gabby over the past 10 days.
PS C:\> Get-MessageTrace -RecipientAddress gabby@thesysadminchannel.com


Message Trace ID  : ce8277a0-7ff1-4269-e598-08d93cdf3d40
Message ID        : <BYAPR05MB51915F70965A7FE777E0243BA8009@BYAPR05MB5191.namprd05.prod.outlook.com>
Received          : 7/1/2021 10:26:15 PM
Sender Address    : testmailbox@thesysadminchannel.com
Recipient Address : gabby@thesysadminchannel.com
From IP           : xxx.xxx.xxx.xxx
To IP             :
Subject           : Message Trace Example
Status            : Delivered
Size              : 18619



PS C:\> Get-MessageTrace -MessageId '<BYAPR05MB51915F70965A7FE777E0243BA8009@BYAPR05MB5191.namprd05.prod.outlook.com>' |
 select Received, RecipientAddress, Subject, Status

Received             RecipientAddress                   Subject               Status
--------             ----------------                   -------               ------
7/1/2021 10:26:15 PM pcontreras@thesysadminchannel.com  Message Trace Example Delivered
7/1/2021 10:26:15 PM testmailbox@thesysadminchannel.com Message Trace Example Delivered
7/1/2021 10:26:15 PM gabby@thesysadminchannel.com       Message Trace Example Delivered

Conclusion

Hopefully this article was useful enough to show you how to use Message Trace in Office 365 Exchange Online to give you some insight on how to confirm receipt of a message. It also allows you to see how an email was sent to by using the MessageId.

If you want to view more content be sure to check out Exchange Online. If you prefer video content, check out our Youtube Page.

The post How To Use Message Trace in Office 365 Exchange Online appeared first on the Sysadmin Channel.

What is Legacy Authentication And Why We Should Block It

I suppose before we go into detail on how to block it, we should probably address what it is. Legacy authentication is more or less self explanatory. By that I mean, it includes authentication methods that are superseded by todays modern authentication. In short, legacy authentication are authentication methods typically used by mail protocols such as IMAP, SMTP and POP3. Microsoft Office 2010 is an example client that uses legacy authentication.

 
The biggest take away here is that legacy authentication was highly active during a time where multi-factor authentication wasn’t really a thing. We’ve come a long way as far as security and auth methods go, but should still close those gaps because it can lead to open vulnerabilities in your environment.

 
To summarize, legacy authentication does not enforce multi-factor authentication (MFA) so it gives attackers a preferred attack vector to exploit. This is the biggest reason why we want to block legacy authentication. With that said, we can now get into the modern (and preferred) methods to blocking legacy authentication using conditional access policies.

How To See If Legacy Authentication Is Blocked in your Tenant

Now before you go through your testing it might be a good idea to check whether basic authentication is blocked in your tenant to begin with. Microsoft has already stated that if they don’t see any authentication requests using these older protocols, they’re going to disable it by default. In my tenant I wasn’t using so it was actually already turned off. To save you the headache, here are the steps to check if basic authentication is enabled in your tenant.

• Navigate to https://admin.microsoft.com/ to get to the Office 365 admin portal
• Next navigate to settings -> Org Settings -> Services -> Modern Authentication
• Direct Link: https://admin.microsoft.com/AdminPortal/Home#/Settings/Services/:/Settings/L1/ModernAuthentication

Use Conditional Access To Block Legacy Authentication In Office 365

Now that we understand the why, let’s get into the how portion of this article. We’re going to assume you have permissions to create conditional access policies.

• In Azure, navigate to Azure Active Directory -> Security -> Conditional Access -> Create a New Policy
• Direct Link: https://portal.azure.com/#blade/Microsoft_AAD_IAM/ConditionalAccessBlade/Policies

• We’ll name this policy, Common Policy – Block Legacy Authentication
• Under Users and groups:
• Under Include: We’ll select all users
• Under Exclude: We’ll want to exclude our exclusions group – e.g. break glass/service accounts

• Cloud apps or actions:
• Under Include: We’ll select all cloud apps
• Under Exclude: We’ll want to leave this blank

• Conditions -> Client apps:
• Select “Yes” to configure policy
• Unselect Browser and Mobile apps and desktop clients
• Leave Exchange ActiveSync clients checked
• Leave Other clients checked

• Grant:
• Select Block Access

For the final step, set the policy to Report-only so you can have some insights before enabling the policy. This will give you a heads up as to who is still using legacy authentication and at least give them some kind of notice to stop. Otherwise, if you’re brave, turn it off and apply the scream test which is also just as effective as finding out who is still using it.

Block Legacy Authentication Exchange Online

In addition to conditional access, we should also consider disabling the legacy auth methods in Exchange Online itself. There are several ways we can about it and we’ll cover those methods as well. However, here is a quick overview.

• Using an Authentication Policy
• Apply it as the default organization policy
• Apply it as a per user policy
• Disable IMAP/POP/Mapi/SMTPAuth protocols per mailbox

Create an Authentication Policy to Disable Basic Authentication

Being able to create an authentication policy would be able to help you not only identify who is using the policy, but set a standard for your setup. The command to create an auth policy is New-AuthenticationPolicy. Let’s cover two scenarios for enabling and disabling the required protocols.

#Create a Block Legacy Authentication Policy
New-AuthenticationPolicy -Name "Block Legacy Authentication"


#Create an Allow All Legacy Authentication Policy
New-AuthenticationPolicy -Name "Allow All Legacy Authentication" -AllowBasicAuthRpc -AllowBasicAuthPop -AllowBasicAuthSmtp -AllowBasicAuthMapi -AllowBasicAuthImap -AllowBasicAuthAutodiscover -AllowBasicAuthPowershell -AllowBasicAuthActiveSync -AllowBasicAuthOfflineAddressBook -AllowBasicAuthReportingWebServices -AllowBasicAuthOutlookService -AllowBasicAuthWebServices 

#Set the authentication policy as the default authentication policy for your organization
Set-OrganizationConfig -DefaultAuthenticationPolicy 'Block Legacy Authentication'

#Set the authentication policy on a per user basis
Set-User jsnow -AuthenticationPolicy 'Block Legacy Authentication'

#Have the policy take effect within the next 30 minutes.  By default it can take up to 24 hours.
Set-User -Identity jsnow -STSRefreshTokensValidFrom (Get-Date).ToUniversalTime()

Disable IMAP/POP/Mapi/SMTPAuth protocols per mailbox

Another alternative to the authentication method is to disable the protocols for each individual mailbox. This can be done using the Set-CASMailbox command for each of the mailboxes you’d want to disable.

PS C:\> Get-CASMailbox blightyear

Name       ActiveSyncEnabled OWAEnabled PopEnabled ImapEnabled MapiEnabled SmtpClientAuthenticationDisabled
----       ----------------- ---------- ---------- ----------- ----------- --------------------------------
blightyear True              True       True       True        True


PS C:\> Set-CASMailbox blightyear -ActiveSyncEnabled: $false -PopEnabled: $false -ImapEnabled: $false -MAPIEnabled: $false
PS C:\>
PS C:\> Get-CASMailbox blightyear

Name       ActiveSyncEnabled OWAEnabled PopEnabled ImapEnabled MapiEnabled SmtpClientAuthenticationDisabled
----       ----------------- ---------- ---------- ----------- ----------- --------------------------------
blightyear False             True       False      False       False

Conclusion

That’s it. Now we know how to block legacy authentication using conditional access policies in Azure Active Directory. For more posts on conditional access or Azure AD in general, be sure to check out our gallery of Azure Active Directory.

The post How To Block Legacy Authentication Office 365 appeared first on the Sysadmin Channel.

To do this we’re going to need the Exchange Administrator role because the only way to make this possible is by using an Exchange Transport Rule (ETR). As of the writing of this article, there isn’t a magical switch on the tenant level so we’ll get our hands dirty using transport rules.

Turn Off Read Receipts in Office 365 Exchange Online

If you’ve never worked with Exchange Transport Rules you can think of it as a way to customize mail flow through a set of conditions that you choose. There are many configurations that can be done with transport rules and it’s pretty versatile so it’s going to be our tool of choice.

Now that we have a basic understanding of what a transport rule is, let’s look at how to access it. More importantly, let’s dive into the settings needed to turn off read receipts in Office 365 Exchange Online. One thing to keep in mind that is we’ll need to create 2 rules for internal users and another one for external users (if that’s what your plan is).

• Open a browser and navigate to https://portal.office.com -> Exchange Admin Center
• Navigate to Mail Flow -> Rules -> Create new rule

• Put in a name like Turn Off Read Receipts – Internal Users
• Set the rule to apply if the sender is inside the organization
• Add an and condition to select the recipient inside the organization (Set to outside for external users)
• Add another condition if the message type is a read receipt
• Under Do the following: delete the message without notifying anyone
• You can generate an incident report if you would like to be notified when the rule is hit

Testing Rule to Disable Read Receipts

With the rule now created and a couple of minutes have gone by, now would be the best time to test the rule to ensure that it’s working as expected. I’ve created a test mailbox to send a read receipt for our use case.

Because we enabled the option to generate incident reports anytime anyone sends an email with a read receipt we should be notified.

 
Several seconds after sending the test email we’ve received an email from PostMaster with the incident report. Here’s what the content of that message looks like.

That’s it! This configuration was pretty simple and should be sufficient to disable read receipts in your org. If you’re interested in other posts about Exchange Transport Rules, take a look at How To Stop Reply All Email Chains.

Finally, if you want more sysadmin content feel free to take a look at our Youtube Channel for awesome video content.

The post How To Turn Off Read Receipts in Office 365 Exchange Online appeared first on the Sysadmin Channel.

A good use case for me was that I was trying to automatically forward social media email to a single Gmail account. Albeit probably not the most efficient, but for me it was exactly what I needed. Furthermore, during my testing I was wondering why I was not receiving those test emails in my Gmail account and it was only until a received a bounce back that I was able to follow the clues to a so solution.

Your Organization Does Not Allow External Forwarding O365 Fix

I absolutely don’t recommend allowing for the entire tenant, however, if we ever have the need to allow specific users (or groups) we can definitely make that happen. Let’s go over the steps how to make that happen.

• Navigate to https://protection.office.com/antispam
• Manual way is Security and Compliance -> Threat Management -> Policy -> Anti-spam Settings (This is constantly changing so link is preferred)
• We’ll Create an outbound policy so we can apply this policy to a specific user

• For the Name: Enter Allow auto forwarding
• For the Description: Enter something descriptive
• Expand the Automatic Forwarding block
• Under Allow users to automatically forward messages outside the organization, select On – Forwarding is enabled
• Expand the Applied to block and click Add a condition
• Select Sender is and select the user address in the field
• Click Save and you’re set

Image cropped – Click to display full length image

Once we save the policy we should be good to automatically forward emails to an external organization. Although, I’ll reiterate once again. This is not something that you should be enabling for the entire organization.

Here’s what the completed policy should look like if you configured it according to the examples above.

Hopefully this article was able to guide you to fix the Your organization does not allow external forwarding error for Office 365. If you want more details, here is the Microsoft documentation

On another note, if you want to get caught up on similar posts, feel free to check out our Office 365 posts. Finally, while you’re at it, don’t forget to check out our Youtube Channel for awesome sysadmin video content.

The post [Solved] Your Organization Does Not Allow External Forwarding O365 appeared first on the Sysadmin Channel.

Some new cmdlets are now prefixed with Get-EXO…

The benefit to having this module as opposed to the version 1 module we previously got from the Exchange Admin Center in portal.office.com is that we can install this across everyone’s profile. The previous module (using Connect-EXOPSSession) was profile based so if Melissa installed it on her profile, it wouldn’t carry over to mine and I would have to go through the process myself. This particularly made it difficult for admins using a shared jumpbox because every new user would need to go through the motions if they wanted the connection. Pretty lame!

Furthermore, just like its predecessor it also supports MFA so you can ensure your security remains intact.

Install Exchange Online Powershell Module From PC With Internet Connection

• From a computer with an internet connection open PowerShell (preferably as an administrator)
• Find-Module -Name ExchangeOnlineManagement
• Install-Module -Name ExchangeOnlineManagement -Scope AllUsers
• Get-Command -Module ExchangeOnlineManagement

Using the -Scope CurrentUser parameter allows Powershell to install the module without administrator access.

Offline Installation of Exchange Online Management Module

If you’re on a machine that for some reason can’t connect to the internet, or the PSRepository is blocked, that’s ok because we’ll go over the steps to install the module without internet access.

• Hop on a computer with internet access and open PowerShell (preferably as an administrator)
• Find-Module -Name ExchangeOnlineManagement
• Save-Module -Name ExchangeOnlineManagement -Path Path
• Copy the files you downloaded to the offline computer
• Move the copied files to C:\Program Files\WindowsPowerShell\Modules (requires admin rights)

At this point you have the module installed and now it’s a matter connecting to the Exchange Online service.

Connect-ExchangeOnline -UserPrincipalName upn@domain.com
Get-Mailbox username

As mentioned this was going to be a really quick note to show you how to Install Exchange Online Powershell Module so hopefully this articles explains that. If you’re looking what to do with the Powershell or Exchange Online, be sure to check out our own Powershell gallery full of useful real world scripts, tips and tricks. If that’s not something you’re in the mood for, check out the other Exchange Online articles or even our Youtube Channel for more fun in the sysadmin sun.

The post How To Install Exchange Online Powershell Module appeared first on the Sysadmin Channel.

Prerequisites

One of the prerequisites you’ll need to in order to make this happen is to install the Exchange Online module. Luckily it’s not too difficult if you follow the linked article. Another requirement is the account you’re using must have the Exchange Administrator role to be able to query Exchange Online.

So in short, here is what you’ll need.

• Exchange Online Management Module
• Exchange Administrator or Global Administrator Role

Get Mobile Device Statistics Using Powershell

Alright now that we know what we need, let’s look at how to extract that information from Exchange Online. As mentioned we will be using the Get-MobileDevice cmdlet along with the Get-MobileDeviceStatistics to get the different properties. Get-MobileDevice has a mailbox parameter so we can filter devices that are associated with a mailbox, assuming you only wanted a single user’s device. Let’s look at what that looks like in the shell.

Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName exchangeAdmin@thesysadminchannel.com

Get-MobileDevice -Mailbox pcontreras | select @{Name = 'Identity' ; Expression = {$_.Identity -replace "\\.+"}}, `
DeviceId, IsManaged, IsCompliant, DeviceOS, DeviceType, FriendlyName, `
DeviceUserAgent, FirstSyncTime, DeviceAccessState, DeviceAccessStateReason, ClientType -First 1

Identity                : Paul Contreras
DeviceId                : D1151F256364422E827C79AF3D3B2230
IsManaged               : False
IsCompliant             : False
DeviceOS                : iOS 13.7
DeviceType              : Outlook
FriendlyName            :
DeviceUserAgent         : Outlook-iOS/2.0
FirstSyncTime           : 9/12/2020 2:43:42 AM
DeviceAccessState       : Allowed
DeviceAccessStateReason : ExternallyManaged
ClientType              : Outlook

Get Mobile Device Statistics show similar results, however, I do like the fact that it has a LastSuccessSync and LastSyncAttemptTime to see exactly how long devices have been stale. If you’re really good with with regex, you can parse the text in the Identity property to give you just the name. My regex game is really weak so if you know how to do that, please post it in the comments so other viewers can use it as well.

Powershell Script To Get Device and Statistics

Since I like to use these 2 cmdlets interchangeably, I thought it would be helpful to provide a script so you can call the Get-MobileDeviceStatistics using the GUID from Get-MobileDevice output.

#Get all mobile devices in the org
$MobileDeviceList = Get-MobileDevice

#Alternatively, Get all mobile devices from a single user
$MobileDeviceList = Get-MobileDevice -Mailbox pcontreras@thesysadminchannel.com

foreach ($Device in $MobileDeviceList) {
    $Stats = Get-MobileDeviceStatistics -Identity $Device.Guid.toString()
    [PSCustomObject]@{
        Identity              = $Device.Identity -replace "\\.+"
        DeviceType            = $Device.DeviceType
        DeviceOS              = $Device.DeviceOS
        LastSuccessSync       = $Stats.LastSuccessSync
        LastSyncAttemptTime   = $Stats.LastSyncAttemptTime
        LastPolicyUpdateTime  = $Stats.LastPolicyUpdateTime
        LastPingHeartbeat     = $Stats.LastPingHeartbeat
        ClientType            = $Stats.ClientType
    }
}

Identity             : Paul Contreras
DeviceType           : Outlook
DeviceOS             : iOS 13.7
LastSuccessSync      : 9/12/2020 2:43:43 AM
LastSyncAttemptTime  : 9/12/2020 2:43:43 AM
LastPolicyUpdateTime : 9/12/2020 2:43:43 AM
LastPingHeartbeat    :
ClientType           : Outlook

Identity             : Paul Contreras
DeviceType           : iPhone
DeviceOS             : iOS 14.1 18A8395
LastSuccessSync      : 11/12/2020 2:40:02 AM
LastSyncAttemptTime  : 11/12/2020 2:40:02 AM
LastPolicyUpdateTime : 11/11/2020 6:32:40 PM
LastPingHeartbeat    : 600
ClientType           : EAS

Alright folk, hopefully this article was useful enough to provide you the information needed to get mobile device statistics using Powershell. Furthermore, I hope it was enough to determine which of those devices are stale and no longer in use. This is an excellent strategy for when you want to do some spring cleaning.

If you like to see more cloud content, be sure to check out our Office 365 Cloud Category for more useful tips and tricks. Finally, be sure to stop by our Youtube Page for those visual learners.

The post Get Mobile Device Statistics In Exchange Online Using Powershell appeared first on the Sysadmin Channel.