Microsoft has included the official release of Exchange Mail Public Folders within the AAD Connect tool. This option enables support for Public Folder by synchronizing a specific set of attributes for Mail-Enabled Public Folders so they represented in Azure AD. This synchronization is required for including the public folders addresses in Directory-Based Edge Blocking.
This new feature from Microsoft doesn’t create actual public folder objects in Exchange Online directory, there is additional sychronization steps via PowerShell that is required if you are using Exchange Online.
You should ensure that “Microsoft.Exchange.System Objects” OU is also selected in OU Filtering, (it is selected by default)
Save the files to the local computer on which you’ll be running PowerShell. For example, C:\PFScripts.
Step 2: Configure directory synchronization
Directory synchronization service doesnt sync all mail-enabled public folders the scripts outlined in step 1 will synchronize these objects across on-premises and Office 365. Any special permissions will need to be recreated as these are currently unsupported by Microsoft. Synchronized mail-enabled public folder will appear as mail contact objects for mail flow purposes. These contacts will not be viewable via Exchange Admin Centre and can only be viewed using Get-MailPublicFolder
Permissions
In order to recreate the SendAs permissions in the cloud, you will need to use the Add-RecipientPermission cmdlet.
On the Exchange Server, run the following PowerShell command to synchronize mail-enabled publics
It is always recommended to use the -Whatif parameter to simulate the action before making environmental changes. Step 3: Configure Exchange Online users to access Exchange Server on-premises public folders
Step 3: Configure Exchange Online users to access Exchange Server on-premises public folders
The final step in this procedure if to configure your Exchange Online organsation to allow access to the Exchange Server Public Folder, this is completed by running the following command in Exchange Online.
It may take up to 3 hours before the Active Directory synchronization has completed. Once completed, Log on to Outlook for a user who is in Exchange Online and perform the following public folder tests;
View the hierarchy. Check permissions Create and delete public folders. Post content to and delete content from a public folder.
What is DBEB? It is a solution that allows an organization to reject message for invalid recipient at the service network perimeter. DBEB enables your Office 365 Global Administrator to add mailed-enabled recipients to Office 365 and block all messages sent to email address that aren’t present in Office 365.
Valid messages are then subject to the rest of the service filtering layers which are;
Antimalware Antispam Mail Flow Rules (otherwise knows as Transport Rules)
Invalid messages are blocked before filtering even occurs, and a non-delivery report (also known as an NDR or bounce message) is returned to the sender. The NDR looks like this:
In hybrid environments, in order for DBEB to work, email for the domain must be routed to Office 365 first (the MX record for the domain must point to Office 365).
Configuring DBEB
First of all, you need to verify that your accepted domain EXO is an Internal Relay, this is done by going to Exchange Admin Console –> Mail Flow –> Accepted domains.
If, your domain type is Authoritative you will need to click the edit button and set to internal relay
Adding your users to Office 365
Directory synchronization: Add valid users to Office 365 by synchronizing from your on-premises Active Directory environment to Azure Active Directory in the cloud. For more information about how to set up directory synchronization, see “Use directory synchronization to manage recipients” in Manage Mail Users in EOP.
In the EAC, go back to Mail flow > Accepted domains.
Select the domain and click Edit. Set the domain type to Authoritative. Choose Save to save your changes, and confirm that you want to enable DBEB.
Until all of your valid recipients have been added to Exchange
Online and replicated through the system, you should leave the accepted
domain configured as Internal relay. Once the domain type has been changed to Authoritative,
DBEB is designed to allow any SMTP address that has been added to the
service (except for mail-enabled public folders). There might be
infrequent instances where recipient addresses that do not exist in your
Office 365 organization are allowed to relay through the service.
While running the Exchange Hybrod Configuration Wizard I ran in the following issue;
HCW8078 – Migration Endpoint could not be created Microsoft.Exchange.Migration.MigrationServerConnectionFailedException The connection to the server ‘http://mail.domain.com’ could not be complete
This issue is a known issue to Microsoft and the resolution is the good old “Have you tried turning it off and on?”
The resolution was to Disable MRSProxyEnabled, this can be easily completed for all servers using;
This script will need to repeat this process for all your servers where MRSProxy is being used. Invoke-Command -ComputerName Server1 -ScriptBlock {iisreset /restart}
Once you have completed the below steps you will be able to successful rerun the Hybrid Configuration Wizard without any errors
Another great feature now become available in Microsoft Teams Preview – Information Barrier. This enables organization to prevent communicate between Teams within their own Office 365 tenant. The information barrier groups cannot be applied across tenants and using bots to add users is not supported in version 1. Information barrier policies also prevent lookups and discovery. This means that if you attempt to communicate with someone you should not be communicating with, you will not find that user in the people picker.
You might want to use information barriers in situations like these:
A team must be prevented from communicating or sharing data with a specific other team.
A team must not communicate or share data with anyone outside of the team.
In order to manage the Information Barrier policy you will need to use the Security and Compliance Centre (SCC) PowerShell cmdlets
The information barrier features is in private preview. When these features are generally available, they’ll be included in the following subscriptions;
Microsoft 365 E5
Office 365 E5
Office 365 Advanced Compliance
Microsoft 365 E5 Compliance
Microsoft Teams is firmly becoming the powerhouse that was sold at its initial launch and I can only this product becoming adopted a lot more by organisations
Its been a long road but Microsoft Teams PowerShell module version 1.0.0 is now available in GA. Microsoft has been working very hard in creating this module and have removed/introduction features into this release. So lets have a look at what we now can and cannot do with Microsoft Teams
So what’s removed?
So Microsoft have removed the following cmdlets
Get-TeamFunSettings
Get-TeamGuestSettings
Get-TeamMemberSettings
Get-TeamMessagingSettings
Set-TeamFunSettings
Set-TeamGuestSettings
Set-TeamMemberSettings
Set-TeamMessagingSettings
But do not fear, as the same functionality of these cmdlets have been integrated into Get-Team and Set-Team.
So what’s new?
Connect-MicrosoftTeams allows you to specify a Teams Government Environment (-TeamsEnvironmentName) that your organization is homed in.
Get-Team allows you to specify new filter and selection criteria to identify specific teams based off of new criteria, including the Visibility or Archived state of the teams.
So its time to start playing with the Teams module and seeing what interesting scripts can be generated.
Please Note: It is recommended to uninstall any previous version you may have installed. So check out this previous blog post i created
One of the gotchas you may encounter when migrating mailboxes to Exchange Online is none registered Accepted Domains in Exchange Online. For example you may encounter the below error;
ERROR: Migration Permanent Exception: You can’t use the domain because it’s not an accepted domain for your organization –> You can’t use the domain because it’s not an accepted domain for your organization.
This maybe due to an email alias on a particular mailbox or all your organisation mailboxes due to an Email Address Policy. When migration to Exchange Online on you need to register all your accepted domains and remove any that may cause you the above issue.
In my case, I had domain.com registered with EXO but not extension.domain.com, as the alias was a legacy address you could be removed from the mailbox either using the Exchange Management Console or my favourite utility PowerShell.
Please ensure that Azure Active Directory has synchronize this change to your mailbox
So in recent months, I have been working a number of large organisation that have issues with special characters that are affecting their migration to the Microsoft Cloud. Yes, I IDFix does an excellent job of correcting a lot of the issues. However, in recent time I have been rolled into customer sites to troubleshoot and report on special characters contained in Distribution Lists and Shared Mailboxes which cannot be migrated to Exchange Online.
What special characters are supported in Office 365?
So first of all, what is and is not supported. The below table gives an excellent break down what the character can be supported in UserNames, Password and Email Addresses.
Allowed In
Character
Name
Character
User Name
Password
Email Address
Accent
`
No
Yes
No
Ampersand
&
No
Yes
No
Angle Brackets
< >
No
Yes
No
Apostrophe
’
No
Yes
Yes***
Asterisk
*
No
Yes
No
At Symbol
@
No
Yes
No
Backslash
\
No
Yes
No
Braces
[ ]
No
Yes
No
Brackets
{ }
No
Yes
No
Circumflex
^
No
Yes
No
Colon
:
No
Yes
No
Comma
,
No
Yes
No
Dollar Sign
$
No
Yes
No
Equal Sign
=
No
Yes
No
Exclamation Point
!
No
Yes
No
Hyphen
–
Yes*
Yes
Yes*
Number Sign
#
No
Yes
No
Parentheses
( )
No
Yes
No
Percent Symbol
%
No
Yes
No
Period
.
Yes*
Yes
Yes*
Pipe
|
No
Yes
No
Plus Sign
+
No
Yes
No
Question Mark
?
No
Yes
No
Quotation Mark
“
No
Yes
No
Semicolon
:
No
Yes
No
Forward Slash
/
No
Yes
No
Tilde
~
No
Yes
No
Underscore
_
Yes**
Yes
Yes**
Uppercase Letters (A-Z)
A-Z
Yes
Yes
Yes
Lowercase Letters (a-z)
a-z
Yes
Yes
Yes
Numerals (0-9)
0-9
Yes
Yes
Yes
In order to test for the special characters above I have created the following script
}
else
{
#Write-Host "Special Character",$char," not detected in " $object.UserPrincipalName
}
}
catch
{
Write-Host "Great News!! we was unable to detect",$char,"in samaccountnames for all Distribution List" -ForegroundColor Green
}
}
}
Data Loss Prevention has now been included into Microsoft but being a Skype for Business consultant have you ever configured DLP? Probably not.
So this post will look how it is configured from Start to Finish so let’s start with the standard prerequisites;
Office 365 Global Administrator Account
Launch Microsoft 365 Admin Center –> Select Security from under Admin Center
Admin Center
Click “More resources” and Open for Office 365 Security and Compliance Center
Click Data Loss Prevention –> Click Policy –> Click Create a policy
Data Loss Prevention
For the purpose of this post I will be creating a policy for covering UK National Insurance Numbers / Passport Numbers. DLP has a list of generic policies or you can configure a custom policy
Select –> Privacy –> Select UK Personally Identifiable Information (PII) Data –> Click Next
Polices
Click Next
Create Policy
At this stage you can select if you want to configure this policy for Exchange email, Microsoft Teams chat and channel messages, OneDrive and SharePoint Documents or specify a subset of services.
Select your required option –> Select Next
Microsoft Teams or All
Example of specifying a subset of services, at this stage you can also Include/Excludes Groups, Accounts and Sites.
Select options
Select Find content that contains
For this post, I am looking for PII data that is being shared outside my organisation.
Select Next
Configure Policy
Using the default options here but you can configure option to send incident report to a Distribution List or individuals. Select Next
Configure Policy
Select “I’d like to test it out first” or Yes, turn it on right away. This is depending if your organisation is ready for the big switch on. The tenant being used in this post is a test tenant will small amount of users.
Press Next
Configure policy
Review your configured settings –> Select Create
Review
Testing – DLP for Micorsoft Teams
So like with all things Microsoft, we have to wait for replication to take place before we can really start testing DLP. Please dont expect your change to work straight away as its needs to work its way through the big Microsoft cloud.
Email Notification that NINO Number has been shared using Microsoft TeamsWarning Message to the User that sent the NINO Number Email Notification that NINO Number detected in Exchange
So its safe to say DLP is now working within my tenant.
When working with customer environments it is very possible a 3rd party appliance maybe involved and for the purpose of this post I will be directly looking at Mimecast to see how its configured to work with Office 365.
Prerequsities
An Office 365 administrator logon with permission to create a send connector.
Your internal domains must already be registered with us.
A Mimecast administrator logon with at view permission to the Gateway | Accepted Email menu item.
Mimecast recommend that if you are switching MX records, this task must be completed 3 days before changing the MX record to point at Mimecast. The reason for this allows Mimecast to build your Auto Allow list, based on recipients your users send messages to.
This has a positive impact on inbound email delivery speed, because many senders will already be known and consequently not be subject to our greylisting security feature.
Updating the SPF Record for your Domain(s)
You must have an SPF record for the domain(s) registered with Office 365. When implementing Mimecast with Office 365, this record must be updated in the DNS zone for the relevant domain to include the following:
Replace with or add: v=spf1 include:_netblocks.mimecast.com ~all
Important Note: If your outbound email is temporarily coexisting with Mimecast, you can leave the v=spf1 include:spf.protection.outlook.com –all SPF record. However, it must be removed once all your outbound email is routed through Mimecast.
Configuring Outbound Routing
Important Note: Mimecast has known issue with browsers that are not Internet Explorer and its recommend this process is completed using Internet Explorer only. All other browsers tested have issues.
Recommendation: Disable or remove any other Outbound Send Connectors. Failure to do this means your outbound email still uses these and isn’t routed through us.
Any send connectors used for other purposes (e.g archiving) may still be enabled. If in doubt, consult Mimecast Support.Any send connectors used for other purposes (login archiving) may login be enabled. If in doubt, consult Mimecast Support.
Adding the Office 365 Tenant Domain as an Internal Domain
Your Office 365 tenant domain must be added to the list of internal domains available in the Mimecast Administration Console. See the Configuring Internal Domain / Subdomains page for full details. This enables us to recognize certain auto response messages, where the sender address is not a normal internal domain. This is typically in the format @domain.onmicrosoft.com. Contact the Mimecast Support team if you have queries regarding this step.
Once this step is complete, Office 365 must be added to your authorized outbounds as an umbrella account. View the Maintaining Authorized Outbound Addresses page for more information.
To verify that Office 365 is successfully routing email outbound via us:
Log on to the Offic 365 Administration Console.
Select Admin | Exchange
Exchange Admin Centre
Select Mail Flow | Connectors Create a Connector
Mail Flow | Connectors
Select Office 365 – From Field Select Partner organization – To Field
Mail Flow Scenari
Enter Name for Connector Enter Description for Connector – Optional Ensure “Turn it on” is ticked
Select “Only when email messages are sent to these domains” Press the ( + )
Type the value * which will allow all outbound email to Mimecast
Press Next
Select “Route email through these smart hosts” Press the ( + )
Now, depending on your location you will need to use the Smart Host address from the table
Region
Office 365 Account Hostnames
America
us-smtp-o365-outbound-1.mimecast.com
America
us-smtp-o365-outbound-2.mimecast.com
Australia
au-smtp-o365-outbound-1.mimecast.com
Australia
au-smtp-o365-outbound-2.mimecast.com
Europe (Excluding Germany)
eu-smtp-o365-outbound-1.mimecast.com
Europe (Excluding Germany)
eu-smtp-o365-outbound-2.mimecast.com
Germany
de-smtp-o365-outbound-1.mimecast.com
Germany
de-smtp-o365-outbound-2.mimecast.com
Offshore
je-smtp-o365-outbound-1.mimecast-offshore.com
Offshore
je-smtp-o365-outbound-2.mimecast-offshore.com
South Africa
za-smtp-o365-outbound-1.mimecast.co.za
South Africa
za-smtp-o365-outbound-2.mimecast.co.zaM
As shown below
Smart Host for Mimecast
Press Next
Select “Always use Transport Layer Security (TLS) to secure this connection (recommended)” Select “Issued by a trusted certificate authority (CA)
Before pressing next please ensure that you confirm all your configured settings Press Next
Press the ( + ) this will allow you to validate the connector
Enter an external email to send the test email
Click Validate
If everything is ok and configured correctly you should see a success message
Press save !!! and your all done
Success!!!
Recommendation: Disable or remove any other Outbound Send Connectors, if this is not completed it may cause email to fail as it won’t be routed through Mimecast
But if doing the above seems a bit boring, there’s always PowerShell 🙂
Add your Office 365 domain as an internal domain in Mimecast
The Office 365 domain(s) must be added to the list of internal domain available in the Mimecast Administration console, if this action is missed. Mimecast are unable to recognise auto response message where the send address maybe @domain.onmicrosoft.com. Mimecast have a section about this on their website, please follow the link below. Configuring Internal Domain / Subdomains
Verify your configuration
To verify that Office 365 is successfully routing email outbound via us:
Log on to the Administration Console.
Click on the Administrationtoolbar button.
Select the Message Center | Accepted Messages menu item.
You should see messages from your organization’s internal users to external recipients. If you don’t see messages shortly after they’re sent, this indicates a configuration problem on your Office 365 send connector. Double check your configuration. Use the Office 365 Message Trace Tool in the Mail Flow | Message Trace menu of the Exchange Admin Center to help identify the issue.
Important Note: Once this step is complete, Office 365 must be added to your authorized outbounds as an umbrella account. View the Maintaining Authorized Outbound Addresses page for more information.
