If you have a large on premise environment, you might want to automate the assignment of Office 365 licenses by using (dynamic) security groups in Azure AD. With this simple manual you should be able to setup automatic license assignment based on a security group.
By default everyone may create a new team in Microsoft Teams. As an organisation admin you might want to control this, or release it a some point. With this manual you should be able to lock down team creation to users that are member of a Azure AD Security group.
STEP 1: First we will need to install the Preview version of the Azure Active Directory PowerShell module for Graph. Open a PowerShell window with Adminstrator privileges and run the following 2 commands:
The result of the script should give you the updated settings. On the last line you should see EnableGroupCreation. If you want to reverse this setting. Just simply change the following line to True and run the entire script:
$AllowGroupCreation = “True”
If you want another security group, rerun the script with the new group name.
Next, we just need to change the 2 value’s below, and run it. After running, you don’t get a confirmation. It might take up to 30 minutes before changes are visible in all Office 365 and/or Azure portals.
With the move to the cloud there might be a time where you would like to remove the Active Directory link (AD Connect) and go for a cloud only strategy. With a few simple steps you can disconnect the AD connect sync from Azure AD.
When you look in your Office 365 environment you will notice that the sync status has different symbols. One for cloud only, and one for Active Directory. To disable the link, open a PowerShell window and run the following steps.
STEP 1: First make sure that you disable the AD Connect sync service by disabling the service, or set it to staging mode.
STEP 2: Connect to your Microsoft Office 365 environment using the following command, and login to the desired environment:
STEP 3: Now run the following command to disable the sync, confirm your actions, you cannot undo this change!
When you create a new Office 365 tenant, all user mailboxes will have the default timezone and language. In my case, I work in the Netherlands, the preference for most companies is to set the Time zone to Central European Time (GMT +1) and the language of the users default folders to Dutch.
You can either ask the users to logon to webmail using https://outlook.office.com and fill in the first time question to set the time zone and default language. But how cool would it be to do this for all your users using PowerShell?
With the Azure AD Premium P2 license you are entitled for Azure AD Identity Protection. You will get the option in Conditional Access to assign risk level based options to your policies. Azure AD Identity Protection can detect six different types of suspicious sign-in activities with 3 different levels of risks.
With the riks levels combined with conditional access policies we can protect sensitive application and data access. With this article I am going to show you how to create risk-based conditional access policies
So let’s create a Policy and get Conditional Access applied with risk levels
When you’re migrating from one Exchange environment to another, or from on-premise to Exchange online without using the hybrid setup, the most forgotten part is the migration of the users x500 address. The reason why this is so important is because Exchange uses this to deliver local emails instead of the SMTP address that is normally associated with email. (This also goes along for calendar appointments)
So, by not migrating the x500 address it means that communications will fail when changing calendar appointments, or replying on old emails. To prevent this we will need to export the ExchangeLegacyDN from Active Directory, and import it again as a ProxyAddress in Active Directory.
Export the x500 address (ExchangeLegacyDN)
Step 1: From your source Active Directory, look up the distinguishedName, and copy the content of the value.
Multi Factor Authentication (MFA) is an added security feature from Azure which I believe that should be enabled by default for everybody in Office 365 and Azure. There for this manual how to enforce (Azure) MFA for all users using Azure Multi Factor Authentication
MFA can prevent unauthorized access in case of the following events:
Sign-ins from anonymous IP addresses
Impossible travel to atypical locations
Sign-ins from unfamiliar locations
Sign-ins from infected devices
Sign-ins from IP addresses with suspicious activities
Using Conditional access we can ensure that your users and company data is safe. Important to know is that Office 365 MFA is free of charge, and if you have Azure AD applications an Azure AD Premium license is required.
If you want to mark your locations as trusted location, you can do that if you have a static public IP. So the first steps are there to define your office locations.
In a new Exchange (Online) environment you might want to change the default calendar sharing permissions for all users. By default the sharing permissions for the entire organization are set to “Can view when I’m busy”.
Some companies have a different wish on the default calendar settings of their users. The preferred setting might be “Limited details”. This will show just the headlines and location of the calendar.
If you try to open an invite, it will notify that you do not have access.
So, what options do we have? From the Outlook app you can see that there are 5 options to choose from. (See screenshot below)
A commonly heart end-user frustration with Auto-mapped shared mailboxes is that Send emails from the shared mailbox end up in the send items of the user it self. In the past you would need to set a registry key on the client computer to get this resolved. But with Office 365, there is an easy way to change this behavior for every user.
With PowerShell this job is done in less than a minute in just 2 simple steps.
STEP 1: First connect to Exchange Online using the following commands:
I recently run into a case where I needed to update statistics of an Azure SQL Database because of poor performance and deadlocks. Preventing disruptions is key, so it is important to do something about it. With a simple script we can update the statistics easaly.
Why should I update statistics?
SQL Server statistics are essential for the query optimizer to prepare an optimized and cost-effective execution plan. These statistics provide distribution of column values to the query optimizer, and it helps SQL Server to estimate the number of rows. The query optimizer should be updated regularly. Improper statistics might mislead query optimizer to choose costly operators such as index scan over index seek and it might cause high CPU, memory and IO issues in SQL Server. We might also face blocking, deadlocks that eventually causes trouble to the underlying queries, resources.
Just execute the following query on your database and you should be good to go! Keep in mind, depending on your database this might take a while. During this script your database will get slow, but will remain online.
SET NOCOUNT ON
DECLARE updatestats CURSOR FOR
SELECT table_schema, table_name
where TABLE_TYPE = 'BASE TABLE'
DECLARE @tableSchema NVARCHAR(128)
DECLARE @tableName NVARCHAR(128)
DECLARE @Statement NVARCHAR(300)
FETCH NEXT FROM updatestats INTO @tableSchema, @tableName
WHILE (@@FETCH_STATUS = 0)
SET @Statement = 'UPDATE STATISTICS ' + '[' + @tableSchema + ']' + '.' + '[' + @tableName + ']' + ' WITH FULLSCAN'
EXEC sp_executesql @Statement
FETCH NEXT FROM updatestats INTO @tableSchema, @tableName
SET NOCOUNT OFF
Last few weeks I’ve been struggling with an very difficult Office 365 / Exchange Online case, that got escalated to multiple Microsoft departments to be fixed. I already found one part of the solution, but Microsoft found the second part. Today I would like to take you through all the steps to fix possible causes and resolutions. So the initial problem started with the following error in the Office 365 admin portal with the affected users:
Another symptom is the mailbox provisioning gets stuck, and hangs on “We are preparing a mailbox for this user”
You will only see this error with AD connect sync enabled environments. The problem occurs when the on-premise value mismatches with the Online Archive Guid. With just a few easy steps we can fix this issue.
We will need to fill multiple Active Directory user attributes to resolve this issue.
You want to move your mailboxes from Exchange on-premise to Office 365, and you want to give you users a smooth transition experience, then you will definitely need to implement the following to automatically create and configure a new Outlook profile on all Windows devices.
Within Outlook Microsoft has created ZeroConfigExchange to setup new profiles with minimal user interaction. Depending on your exact configuration Outlook will be configured fully automatically, or the user is required to fill in his email address and/or password.
With Azure Conditional access you get more control over your data, get better security and visibility! To use this feature you will need to buy and assign Azure AD Premium or EM+S E3/E5 licenses to your users.
This manual can be used to enforce the use of the Outlook app on IOS and Android devices by blocking all apps that do not support Modern Authentication like iOS mail and Google mail client.
Step 1: In the Azure Portal go to Conditional Access. On the first page that you get create a New policy
If you deployed Intune to your mobile devices, you want to enforce the use of the Outlook app on the mobile device. We want to make the end user experience as smooth as possible and preconfigure Outlook for the. How can we prepare the Outlook app with your company email settings? With just a few steps, we can get this setup!
Step 1: From the Azure Portal go to Intune –> Clients Apps –> App configuration policies and click Add
Step 2: Give the configuration policy a name and description. Select Device Enrollment type, my preferred method is to use Managed apps, because this will deploy the policy to both enrolled and unenrolled devices. Select the Outlook apps on Associated app, and go to Configuration settings.
With the transition to Azure AD, you might want to connect your AAD joined devices to the traditional file server as explained in this article: Go Azure AD Joined with on-prem DC and fileserver The next step is to map some network drives with Intune!
Step 1: The first step is to create a PowerShell script that will do the actual drive mappings. This script will be placed on a Azure Blob storage (or your internal domain) where you will be able to manage and maintain the script. This script will be run using a second script that we will deploy with Intune. For your convenience I’ve already prepared the script:
In this manual I will explain step by step how to migrate your users from their personal drive to OneDrive using bulk migration in SharePoint Migration tool. This includes preparing the users OneDrive, granting permissions, and setup SharePoint Migration tool.
Before we begin, we will need a migration station, I would recommend to use a server designed for this purpose. On the migration server make sure you install the following:
Last few weeks I’ve been busy with migrating file servers to SharePoint and OneDrive. For this I’ve used the SharePoint Migration tool from Microsoft. Download: Link With just a few easy steps you are able to migrate your data to SharePoint or OneDrive.
In this manual we will focus on SharePoint only, I will create a OneDrive Manual later on including CSV instruction to perform bulk migrations.
When moving your applications to the cloud, it makes sense to start using Azure Services to get the best service, highest availability (SLA) and worry free maintenance provided by Azure. The next step is to use Azure AD identities with Azure SQL Database.
Within a few steps you will have Azure AD user authentication setup.