You can block an user from logging on to Office 365 by setting the BlockCredential attribute to $true.
Set-MsolUser -UserPrincipalName myuser@mcsmemail.de -BlockCredential $true
But the MSOL user attribute is reverted to $false, when ADD Connect synchonization cycle runs.
This happens, because the local Active Directory attribute accountEnabled is used to controll the BlockCredential attribute in Azure AD.
If your IT operation requires the ability to have enabled users in your local Active Directory infrastructure and you need to prevent logon to cloud services you need to prevent the accountEnabled attribute from being synchronized to Azure AD. This might not necessarily be a general requirement during normal operations, but might be useful while doing a Proof-of-Concept.
Just exclude the attribute from the Azure Active Directory connector in the Synchronization Service Manager.
The following script disables all users excluding
# Userfilter $UserExceptions = ("Sync_SYNC01_add98768492f@mcsmemail.onmicrosoft.com","SPO-SRV-ACCOUNT@mcsmemail.de","SynchedAdmin@mcsmemail.de") # Fetch synchronized users $DomainAccounts = Get-MsolUser -EnabledFilter EnabledOnly -MaxResults 5000 | Where-Object -Property LastDirSyncTime -ne $null # Select synchronized users not following the pattern ADM*@mcsmemail.de (admin accounts in this case) $DomainAccountsWithoutAdmins = $DomainAccounts | Where-Object -Property UserPrincipalName -notlike "ADM*@mcsmemail.de" # Exclude accounts listed in $UserExceptions $DomainAccountsWithoutAdminsFiltered = $DomainAccountsWithoutAdmins | Where-Object -Property UserPrincipalName -NotIn $UserExceptions # Now block cloud logon for all filtered users ForEach ($User2Block in $DomainAccountsWithoutAdminsFiltered) { Write-Host ('Disabling User: {0}.UserPrincipalName)' -f $User2Block) Set-MsolUser -UserPrincipalName $User2Block.UserPrincipalName -BlockCredential $true }
Enjoy Office 365.
Using this script you can test the domain availability in Office 365 and Azure AD. As there are different closed Office 365 and Azure AD regions you need to test per dedicated closed Office 365 region.
Regions currently implemented:
The script queries the login uri for the selected Office 365 region.
The response contains metadata about the domain queried. If the domain already exists in the specified region the metadata contains information if the domain is verified and/or federated.
Load function into your current PowerShell session:
. .\Test-DomainAvailability.ps1
# EXAMPLE # Test domain availability in the default region - Office 365 Global Test-DomainAvailability -DomainName example.com # EXAMPLE # Test domain availability in Office 365 China Test-DomainAvailability -DomainName example.com -LookupRegion China
Original source: https://blogs.technet.microsoft.com/tip_of_the_day/2017/02/16/cloud-tip-of-the-day-use-powershell-to-check-domain-availability-for-office-365-and-azure/
Troubleshooting Outlook connectivity issues with Office 365 is tricky. Administrators can use two valuable tools provided by Microsoft to identify and even fix client related connectivity issues.
Start with the Outlook account problems test page in the Office 365 portal. You need to log on as the Office 365 user having issues.
The site tests for the following:
If no issues are identified after you've logged on to Office 365, move to the next step.
The Microsoft Support and Recovery Assistant (SARA) for Office 365 is click to run tool that is installed and executed locally.
These two tools fix most of the Outlook connectivity issues you are facing as an Office 365 administrator.
Enjoy Office 365
When you use the Office 365 Portal to move an on-premise mailbox to Office 365 (aka Office 365 Onboarding) you can either move
There is no option to move only the primary mailbox, if the mailbox already uses a cloud based archive mailbox.
The required option -PrimaryOnly can only be applied when using Remote PowerShell to Exchange Online.
The following lines describe how to move the primary mailbox that does have an enabled cloud archive to Office 365:
# UPN of user to migrate to Exchange Online $User = "UserToMigrate@mcsmemail.de" # FQDN of configured migration endpoint $RemoteHost = "MigrationEndpoint.mcsmemail.de" # EOL target delivery domain aka tenant domain $TargetDelivery = "tenant.onmicrosoft.com" # Onpremise credentials to access the source mailbox $OnPremCred = Get-Credential # New onboarding move request New-MoveRequest -Identity $User -Remote -RemoteHostName $RemoteHost -RemoteCredential $OnPremCred -TargetDeliveryDomain $TargetDelivery -SuspendWhenReadyToComplete:$false -PrimaryOnly
Your scripts can go from here.
Enjoy.
You need assistance with your Exchange Server setup? You have questions about your Exchange Server infrastructure and going hybrid? You are interested in what Exchange Server 2016 has to offer for your environment?
Contact me at thomas@mcsmemail.de Follow at https://twitter.com/stensitzki
During DEV/IT Connection the new release of Office 365 for Exchange Professionals has been published.
Personally I recommend this book to every Exchange professional who wants to implement Exchange Hybrid setups or needs to migrate to Office 365. If you want to be successful, read this book and use it as a reference.
The information provided reflects the experience of the authors who contribute to the Exchange community regularly. This has been written without any Office 365 marketing stuff in mind. (As one of the authrors is Tony Redmond).
The chapters provide an overview of the various technologies as well as detailed informations for the day to day work of an Exchange administrator. Notes from the field help to understand the complex (or not so complex at all) requirements of Exchange hybrid configurations.
Due to the nature of "The Service", an Exchange administrators needs to keep up with the changes deployed constantly. This book covers the most recent changes and evolvement to "The Service" like Groups or Delve.
I will kep it short:
Buy It. Read It. Enjoy It.
Not joking...
Buy the Book
Michael Hall of MCS has published on excellent Excel tool to simplify the migration of on-premise Exchange mailboxes to Office 365.
The script does support not special characters in display names as it is intended to work with ASCII files.
The textfile type used by Excel VBA code has been changed from 437 to 65001.
When you want to use the attached Excel file you are required to create an UTF-8 export when collecting mailbox data. The required PowerShell code is as follows:
$mbx=Get-Mailbox -resultsize unlimited; $mbx | foreach-object {$UPN = $_.UserPrincipalName; $EmailAddress = $_.PrimarySmtpAddress;$OU = $_.OrganizationalUnit; $Type = $_.RecipientTypeDetails; $_ | Get-MailboxStatistics | select @{Name="UPN";expression={$UPN}},@{Name="EmailAddress";expression={$EmailAddress}},@{Name="Type";expression={$Type}},@{Name="OU";expression={$OU}},DisplayName,@{Name="TotalItemSize(MB)";expression={$_.TotalItemSize.Value.ToMB()}},LastLogonTime}|Export-csv .\Mailboxes_Output.csv -notype -Encoding UTF8
Then just follow the instructions provided in Michaels blog post.
Unsure, if you should migrate to Office 365? You want to know more about security of cloud applications and services? Your Exchange Server infrastructure requires an upgrade? Contact me via email: thomas@mcsmemail.de
This blog post focusses on an issue where your Exchange Online users are not able to send emails to other Exchange Online recipients outside of your organization when using a 3rd Party Centralized Email Flow Setup. The term 3rd Party Centralized Email Flow Setup describes a solution where you not follow the preferred hybrid architecture proposed by the Exchange product group, but use a 3rd party software as a centralized email gateway.
You have followed the recommendation to secure the Exchange Online inbound connector for your on-premises email servers by using a certificate name or the remote IP address of your on-premises email gateway.
The on-premises email security gateway utilizes a self-signed certificate to secure TLS connections. The gateway is configured to use two different send connector setups:
In this case Exchange Online Protection (EOP) will not be able to differentiate between tenant internal inbound mail flow and mail flow targeted to other tenants. Therefore, email messages sent from your Exchange Online users to recipients located in other Exchange Online tenants will be discarded.
Interestingly enough, this will happen silently. Your gateway solution will log a successful delivery to Exchange Online Protection. The tenant administrator of the recipient domain will not find an any information in the Exchange Online message tracking logs.
The following diagram illustrates the setup.
The solution for this problem is pretty simple. Just use dedicated certificates for each connector targetting Exchange Online.
Change the Internet Connector to fully trusted 3rd party certificate. In this case you are not required to modify the existing Exchange Online inbound connector setup.
The new connector configurations are:
The following diagram illustrates the new setup:
Enjoy!