Outlook is not showing my Skype for Business presence

Today I noticed that Outlook was not showing the presence of my contacts anymore. It appeared they were all offline. However, when I checked their status in Skype for Business, they weren’t offline.



Outlook using a registry key to identity which IM Provider is integrated. That registry key is HKEY_CURRENT_USER\Software\IM Providers. You will find a value under IM Providers called DefaultIMApp. When I checked the value it had changed to Teams. Since my organization hasn’t migrated to Teams yet for their VOIP I didn’t need that value. I need the value voor Skype for Business which is Lync. So, after changing the value back and restarting outlook the “issue” was resolved.


Oh no MFA was down again

Ah it happened again, Microsoft Azure Multi Factor Authentication was down. If you google it, you will probably find the details somewhere. But in short, people were not able to use their mobile device to deliver the second layer of authentication to make their authentication more secure. Security is important, reliable services for security even more. People complained for hours how they couldn’t work anymore, how their services became inaccessible, how they couldn’t perform their normal day to day operations due to the outage.  So, shame on you Microsoft for allowing customers to be in a situation like this.

But also shame on you customers (and by extension IT service providers) for not using MFA smarter than you are currently.

Wait, what? What a nerve, blaming us for an outage of a cloud service, we pay good money for something that is supposed to have 99.9% uptime.

To be honest, I am not blaming you for the outage. I am blaming you for the fact that you couldn’t work. Too many times I see people using MFA as an on/off switch without a clear plan or design when MFA is actually needed. Mike Tyson once said, “Everyone has a plan and then they get punched in the face”. Well, consider this outage your proverbial punch in the face. If you were unable to work due to a second security layer failure you clearly have not done your due diligence about two things:

  1. What are we going to do when MFA goes offline? Granted since we are dealing with a cloud service, we have come to expect the necessary uptime of cloud services especially the Microsoft ones, but still, good service providers have a plan in case something fails. Working with cloud services is not an excuse to be lazy or to forget crucial things in service design.
  2. Do we really need ALWAYS MFA to be on? Is MFA indeed an on/off switch or do you just need to use MFA where it is really necessary?

And the reality is that MFA is not always needed. The truth is that too many people look at MFA as an on/off switch because they don’t know how to configure MFA properly or maybe are (dare I to say it) too lazy to do it in a more thought through way.

Because let’s be honest, when you work in a controlled environment like in your office, on a laptop or desktop with the necessary security measures like device enrollment in a managed device management suite, what is the added value of MFA? Security measures need to be in place to protect your end-users and devices in an unsafe environment, where the risk of being hacked or your users and devices being compromised is the highest. If you consider your own office an unsafe place, you might have potentially bigger problems than MFA. Like with the use of a super complex password and a frequent request to change passwords, unbalanced security measures can lead to end-user to actively time to go around your security measures. When that happens, your security plan (even if you have one) goes out the door.

Microsoft Azure has a service for those specific cases. It is the exact same service you have been using for your MFA, Azure Active Directory. AAD has a feature called conditional access. It allows you to define the different scenarios where you actually do MFA and where you don’t. It can help you to be selective in the usage of MFA and allow people to work ‘normally’ in a safe environment. It gives your end-users confidence that they are being taken care off and when indeed the request for MFA comes up, they also get the mental note that they are currently in an unsafe environment and should behave in a more secure way than they normally would when they are in the office.

So, back to original statement, would this have helped 100% against the MFA outage? No, but if people were working in a secure environment they wouldn’t have been impacted by the MFA since there was no need for MFA. Like I said, consider this outage your wake-up. Having a security plan is one thing, having a balanced security plan, with attention for end-user convenience and the possibility that certain services can and will go offline might be even a better approach.

Assign licenses to a group instead of user in Office 365/Azure

Ah, the joys of licensing in Office 365. Without a license, there is no just no fun in Office 365, you have no services available and without a service no option to be productive. There is a lot to be said about licensing in Office 365. You have license bundles like E3, E5, Microsoft 365 etc. that contain a bunch of services. You need to make sure you give people the right services they actually need to do their job. There are a lot of debates about whether you want to open all the services for all the users or not. Just based on these statements you can tell that assigning the right license is a very important task. To make this task a little more complex there wasn’t really a way to automate managing licenses to users except for PowerShell. Think about it, AAD Connect synchronizes your users, contacts, and groups with all their attributes from your on-premises but there was no option to manage the license assignment.

Until now.

Azure Active Directory, one of the most overlooked and underestimated services attached to Office 365, has the possibility to assign licenses to a group. Since the documentation is excellent, thank you Microsoft, I don’t think it makes sense for me to go into detail in the how. https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/licensing-groups-assign

Side Note: this functionality is only available (for now) is the Azure Portal, not in the Office 365 Portal

AutoUpdate based on membership

What is very interesting is that licenses are kept up to date when user memberships change for the group, the licenses for those users are updates as well. This methodology allows you to manage your licenses (and therefore your active services) by adding and removing users to and from groups.

Migration from direct to inherited through groups 

How do you convert from direct to group based? There are like always multiple methods but something that I like to use is this structure.

  1. Create your groups and make them available in your Azure Portal (e.g. with AADConnect when sync is needed)
  2. Setup your license assignment per group
  3. Add your users to the groups and sync if needed
  4. Check for conflicting licenses (see next paragraph) and solve them
  5. Remove the direct licensing

Conflicting licenses

Unfortunately, there are licenses that don’t like being together, these will cause licensing conflicts. Luckily when there is a licensing conflict the original license will stay in place and you have time to fix it. An overview of the license SKUs and which one will cause conflicts can be found here: https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/licensing-service-plan-reference

PowerShell for Group Licensing


Azure Active Directory activates MFA for elevated user accounts (admins)

You probably haven’t noticed anything (yet). But Microsoft has created a rule in Azure Active Directory Conditional Access called Baseline policy: Require MFA for admins (Preview). Read the Microsoft post here. I am a strong believer in security and that doesn’t change because we are currently using a cloud service like Office 365. Elevated accounts like admins should be using MFA. Microsoft supports that statement by implementing this new policy. The reason why you haven’t noticed anything yet, is because in the preview stage, Microsoft decided to opt you out unless you activate it in the policy. When it goes in to GA, it will be reversed to opting in unless you deactivate it.

Now what is going to be the impact? Easy, all types of admin will have to use MFA to get access to the Office 365 services. But what about scripts, service accounts, etc? The policy gives you the ability to opt out certain accounts, so I would create a group with all you admin users that you use for automation or service accounts.

Now, a lot of people are going to complain that this is going to effect their end-users. To those people I tell them this: Why do your end-users have admin accounts enabled? I strongly believe in a separation of duties and accounts. If there is a part of of my daily tasks that require me to have an elevated account, make sure I have an separate account that has those permissions. Elevating your permissions should be a conscious decision and if your account is always elevated it is not. The possibility of doing something wrong is too real when you don’t separate your accounts.

Make sure to investigate before it goes in GA

Security and Office 365 through Secure Score, download my eBook.

Let’s just drop it here. It is finally here. My first eBook/white paper, whatever you want to call it around Office 365 and Security. If you don’t want to read the story behind it, that is fine, I will not be offended. Download it here.

For weeks I have been trying to get this out of the door. Ever since Secure Score came out, I wondered how to make the most of your security on Office 365 and get that number as high as possible. Even though Secure Score does a really good job in trying to explaining the What and the How, it lacked a bit the Why behind it in my opinion. That is what I tried to do, I use this document on my own tenant and it did help me increasing security and getting it all under control. I hope it does the same for you.

Feedback is always welcome, positive as negative. This is a learning path for me as well.

Download it here.

[New video] Help your end-users be aware of phishing attack by customizing their login experience in Office 365 and Azure.

[New video] Help your end-users be aware of phishing attack by customizing your login experience in Office 365 and Azure. Use the company branding functionality to customize your login page. #SecurityMatters


Azure Active Directory and Conditional Access – MFA

What if you don’t want multi-factor authentication to be an on/off switch? What would you say if you could activate MFA based on criteria like Risky Sign-ins, Domain Join Status and so much more. Be smart with your MFA. Combine Conditional Access of Azure Active Directory with MFA and be amazed by the potential … 

Protect yourself again phishing attacks in Office 365 by using Company Branding

A quick tip

If you want to avoid being the victim of phishing this will help. Phishing attacks will lead you to a fake login page where they will ask for a username and password, hoping that the end-user will not see the difference between the real login page and the fake page. With Azure Active Directory you can change the login page for Office 365 so it contains your logo, a tagline, and some basic company information. Phishing attackers in most cases won’t go through the trouble to build a custom login page. If you end-user see that the login page is not your custom designed login page, they will know it a fake one. Since AAD Company branding is a part of the Office 365 license, this is available to you for free.

Company branding happens in the Azure portal. So we need to authenticate with our Office 365 credentials at https://portal.azure.com. Proceed to Azure Active Directory and you should see your Office 365 Directory and the following option Company branding.



Change your company branding to your own design. In my case, I changed the Californian Highway with my own preferred image, added a logo and change the sign in text.


When the configuration is changed when you fill in a username of your Office 365, the design will change from the default Office 365 login experience to your customized one. This will be the case for each application that uses your Azure Active Directory login page. So if you end-user are the subject of a phishing attack they should see that the login experience doesn’t change based on their username and that should help them identify that something is wrong with the page.

PowerShell Automation: Save Password in a file for further use.

When you want to use PowerShell with a service, in most cases you will need to authenticate to that service. If you are looking to automate, trivial task, you will need some kind of mechanism to load your credentials from a separate, secure location so you don’t need to be available when the script runs. Of course you can save the password in the file but that isn’t really secure.

Part 1: Retrieve password from the user and save it into a file

$username = “admin@testaadjsol.onmicrosoft.com”

$secureString = read-host “Please provide password for Office 365” | ConvertTo-SecureString -AsPlainText -Force

$secureStringText = $secureString | ConvertFrom-SecureString

Set-Content “c:\scripts\passwordtest.txt” $secureStringText


Part 2: Load from a file and connect to the service. In this case the service is Office 365.

$secureString = Get-Content “C:\scripts\passwordtest.txt” | ConvertTo-SecureString

$myCredentials = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $username, $secureString

Connect-MsolService -Credential $myCredentials

Data Loss Prevention in SharePoint Online based on metadata

When we look at Data Loss Prevention in Office 365, either in Exchange Online, or in SharePoint Online (included here is OneDrive), people will often think it is only to be used for sensitive data. And in their mind, sensitive data is personally identifiable information, financial information like credit card number or even medical information. However, sensitive data can be so much more. Let’s take SonyGate a few years ago. I bet that their definition of sensitive information goes far beyond that.

Microsoft has done a stellar job in extending their definition of sensitive information with everything they can identify for a large number of people. But what about corporate sensitive data? Legal documents, contracts? How about we start protecting those? And that is exactly what we are going to do in this post. We are going to create a DLP policy to protect contracts. In SharePoint Online there are few ways you can identify a document to be a contract. You can use content types, metadata, etc. I am a huge fan of content types so I am going to use that.

Ok, I am not going to explain how you add a content type to a document library. If you need help for that, there are tons of good videos and blog posts that will explain it in detail. So fast forward to the part where I added the content type to a document library and I upload a document.






Ok. DLP in SharePoint Online can use a search query to activate the DLP rule. Few opening remarks with this though, adding a search query to a DLP rule can’t be done by the user interface. You need to use PowerShell for this. Additionally, any changes you want to make to the DLP rules can’t be done through the user interface. Again, this needs to be done through PowerShell. Before we start however we need to make sure we have a search query we can use in the rules. To do this I am going to create a new mapping between a managed property and a crawled property in SharePoint Online Search. Go to Office 365 > Admin > SharePoint Online > Search > Manage Search Schema. I mapped ows_ContentType to RefinableString01 and added an alias ContentTypeAlias. Trigger a crawl or be patient until the crawl has picked up your document and test it out through a search in SharePoint Online.

SearchTerm: ContentTypeAlias:Contract

This search shows me all the documents with the content type contract.







Success. Now I can create my DLP policy. Like I said before since this functionality is not available through the user interface you need to feel comfortable using PowerShell and understand how a DLP policy and rule is created.

Step 1: Connect to Security and Compliance with PowerShell

$myCredentials = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.compliance.protection.outlook.com/powershell-liveid/ -Credential $myCredentials -Authentication Basic -AllowRedirection

Import-PSSession $Session

Step 2: Create a DLP Policy. This policy will only apply to SharePoint and OneDrive. If you want to include Exchange you can do that by adding -ExchangeLocation parameter. Check the documentation for more details.

New-DlpCompliancePolicy -Name Contract_policy -SharePointLocation All -OneDriveLocation All -Mode Enable

Step 3: Add a DLP rule to the policy. DLP rules are the brains of the organization so you want to stop and think what you are trying to achieve. DLP is an ideal way to educate people about data security. DLP rules allow you the present a policy tip to the end user explaining what he is trying to do might be in violation of a specific policy. DLP rules should protect data, but there might be a reason why you need to “break” the rule. People should be able to do this, but they need to provide a justification. The last configuration I want to set, I want this rule to apply to sharing with external people. I have no problem with contracts being shared internally. So when you are done, this is what you get. And of course, we use our search term and the content identification to be protected.

New-DlpComplianceRule -Name Contract_content -Policy Contract_policy -AccessScope NotInOrganization -BlockAccess $true -BlockAccessScope PerUser -ContentPropertyContainsWords “ContentTypeAlias:Contract” -Disabled $false -NotifyAllowOverride “WithJustification” -NotifyPolicyTipCustomText “This is a Contoso Contract! Treat as Confidential” -NotifyUser “Owner”

One the DLP is activated and had time to put its rules on the document, this is what the end-user will see when he tries to share a document with an external user that has the content type contract.