Multilingual invitations for Teams Meetings

This new feature for Teams, allows administrator to customise meeting invitations, to display the information of meeting in up to two languages ton all email platforms

In order to enable this, we can apply a new policy in their admin portal by enabling the MeetingInviteLanguages parameter in the CsTeamsMeetingPolicy at the user or group level, or for the entire organization

To enable this, we must use PowerShell, so let’s go:

#connect to Teams PowerShell

Import-Module MicrosoftTeams

Set-ExecutionPolicy -ExecutionPolicy Unrestricted


#check the current configuration

Get-CsTeamsMeetingPolicy -identity global | fl *lang*

#apply the new config

Set-CsTeamsMeetingPolicy -Identity Global -MeetingInviteLanguages "en-US,es-ES"

It may take several hours before the policy becomes active, but in the end, we will be able to find this in a new teams meeting:

Hope that helps, till nex time!


My password recommendations from the trenches

The following are recommendations and thoughts that I extracted by working with several customers, maybe you will find it obvious, but for other people could be useful. So, let’s begin:

In the identity plane, we could say that exists 2 categories:

  • Resist Common attacks
  • Contain successful attacks

I don’t want to enter of how to resist or contain attacks, because probably I covered some of these topics in other blog entries, but for me, there is another category which is: understand the human nature.

Nothing more that understand that almost every rule that we impose to the end users, result in degradation of security. Why? Because we force users to use long passwords, with special characters, and in the end, users tend to reuse passwords which makes easier to guess or crack passwords for malicious actors.

So, in the post I will resume some of my experiences as AntiPatterns and recommendations:

  • Antipattern – Requiring long passwords: excessive length passwords (more than 10 characters) can result in a behaviour predictable, users tend to choose repeating patterns (heyholetsgoheyholetsgo) that meet the character length but clearly not hard to guess. We can say that this kind of passwords are hard to guess but lead to poor behaviours to guess the password.
    • SuperPRO Tip: You can use a long password, but in this case what I recommend is something that engineers from Microsoft do. They use a very loooooooong password, they forget it, and instead of it, they use passwordless mechanisms such as Windows Hello to sign in.

My tip: Use minimum 8 length requirement but ban common passwords with Azure AD Password Protection.

  • Antipattern – Require use of multiple character sets: probably you’re not in the same line as me, but I’ve seen that this rule do more harm than good. People use patterns as substitutions such  as $ for s, @ for a, 1 for I. So keep it in mind
  • Antipattern – Password expiration: Policy expiration drive users to use very predictable password (for example, the next password can be predicted on the previous password), end users do not tend to use a new password, the tend to update the old one.

My tip for the two previous points: Azure AD Password Protection + Conditional Access based on User Identity

  • Recommendation – Ban common passwords: For me, the most important restriction is to ban the use of common password to reduce the possibility of brute force or password spray attacks

Tip: Look at my first tip 😊

  • Recommendation – Educate end Users not to use organization credentials anywhere else: Yes I know that educate users are difficult, but you have to do it, because the tend to reuse the same password across multiple sites. It is a common practice for cyber criminals to try compromised credentials across many sites.
  • Recommendation – Enforce MFA registration and enable MFA: ensure that users maintain their security information up to date, so they can respond to security challenges if needed. Doing this, I have seen that end users are more implicated concerning digital security

Enabling MFA prevents up to 99.9% of identity attacks, and if we use other controls such as user location, the better.

PRO TIP: Use Conditional access with FIDO2 security key (PassWordless Authentication with Fido 2 Keys – Albandrod’s Memory (

EndUser TIP: Consider turning on two-step verification everywhere you can

  • Recommendation – Enable risk-based Authentication: when the system detects suspicious activity, it challenges the user to ensure that they are the legitimate account owner. Personally, I think that this feature is great, but the only drawback that it is only included with AAD P2

Probably you will have different ones based on your experience but these are my recommendations. Till next time and stay safe!

Duplicated users in AzureAD

Sometimes it happens, users syncronized from OnPrem to AzureAD, are not being soft matched, and it’s necessary to do a hard match, in this post I will explain the basic steps to do it:

  1. Disable the sync for that particular object, my recommendation would be to create a OU in your AD which is not being selected to be synchronized
  2. Execute a Sync Delta in your ADConnect Start-ADSyncSyncCycle -PolicyType Delta
  3. Check that the bogus user has been deleted, and delete it from Recycle bin withRemove-MsolUser -UserPrincipalName <user> -RemoveFromRecycleBin
  4. Find the users ObjectIDldifde -d "CN=username,CN=Users,DC=domain,DC=local" -f C:\user.txt
  5. Find objectGUID:: in c:\user.txt
  6. If you don’t like the previous step, you can search for the sourceanchor in the metaverse of AADConnect,
  7. Update AzureID, setting the object ID to sync with toSet-MsolUser -UserPrincipalName <upn> -ImmutableId <objectGUID>
  8. Now, sync withStart-ADSyncSyncCycle -PolicyType Initial

With this, what we are doing id a hard match for the user, once is done, you’re ready to go

Deploying Microsoft 365 Apps

This a service that I discovered the other day, which is Office cloud policy service: lets you enforce policy settings for Microsoft 365 Apps for enterprise (what was named in the past Office 365 ProPlus) on a user’s device. It doesn’t matter if the device isn’t domain joined or otherwise managed.

The magic here flows when a user signs into Microsoft 365 Apps for enterprise on a device, then the policy settings roam to that device. Also, some other cool features is that you can enforce some policy settings for Office for the web, and anonymous users.

Some of the policies to configure are also included in GPO or in EndPoint Manager, so take into account this. But also keep in mind the following requirements:

  • At least Version 1808 of Microsoft 365 Apps for enterprise.
  • User accounts created in or synchronized to Azure Active Directory (AAD).
  • Office cloud policy service supports security groups and mail-enabled security groups created in Azure AD.
  • to create policy configurations, you need to have one of the following roles: Global Administrator, Security Administrator, or Office Apps Admin.

To enable security policy recommendations, sign in to the portal for managing Microsoft 365 Apps for enterprise, click Security, and then choose On for the Security Policy Advisor.

How Security Policy Advisor creates recommendations

When a security group has been assigned a policy configuration, Security Policy Advisor analyzes how users in that group work with Microsoft 365 Apps for enterprise. Based on this analysis and on Microsoft best practices, recommendations are created for specific security policies and insights about the impact of those policies on productivity and security.

Recommendations are usually generated within a few minutes of a policy configuration being applied to a group. On rare occasions, it may take longer. In such instances, please revisit Security Policy Advisor to check if new recommendations are available.

that’s all for know, keep playing and discover some cool jewels hided in the M365 portal

till next time!

Retention Label VS Retention Policy

Retention is a great way to drive information governance and user behaviour, it is a good practice to have implemented a retention policy in organization content in order to enable long term retention in some of the workload such as SPO, Teams, ODFB, EXO…

But when it comes to the question what feature do I need to use in each case, it is when the doubts comes, so, with the following post I expect to clarify some of those points:

Use Retention Labels when:

  • Information within the same location requires different classifications to drive lifecycle
  • Information is required to be managed as a record or a regulatory record
  • Information requires manual classification by users or auto-classification using Keywords, metadata or machine learning

Use Retention Policies when:

  • A single baseline retention period is applicable to all information with a location (ODFB, EXO etc.)
  • Joiner / Leaver scenarios are required to be automatically managed
  • No user intervention is expected or required with the baseline policy

Enabling Microsoft Whiteboard

Have you ever used Whiteboad? If not it is a useful application where users can create a canvas, to shared ideas and content, also Whiteboard can be used to collaborate with yout team wether you’re in the same place or multiple locations.

But, the main problem is to be able to store & retrieve canvas or share them with other people, you’ll need to sign in with Office 365 credentials.

In my case, I was receiving the following message “Your admin has disabled sign in for Whiteboard”

But the fix is pretty simple… Simply go to the Office 365 admin portal, navigate to Settings and then to “Services & add-ins”, where you will see the new Whiteboard option and you will see that it is set to Off, so slide it over to On and press save:

The effect is immediate, and you’ll then be able to log in straight away and start working on whiteboards together!

This is an all or nothing approach, and at this point there are no administrative controls to enable or disable this on a per-user level – so you will need to be wary of content being stored in yet another location

Licensing Details for Litigation Hold in Office 365

Legal Hold can be used as an alternative to using third-party backup solutions since all emails are retained and cannot be deleted by the user or admin, except by retention policies.

Admins can place mailboxes on litigation hold or in-place hold. When you place content locations on hold, content is held until you remove the hold from the content location or until you delete the hold.

Litigation hold in O365 originally only existed for Exchange Online mailbox data, but has been extended to SharePoint Online, Teams, OneDrive, etc.

The user you wish to place on hold must a subscription that includes at least Exchange Online (Plan 2). This includes the following online licenses:

  • Microsoft 365 E5
  • Microsoft 365 E3
  • Office 365 E5
  • Office 365 E3
Users in subscriptions that include Exchange Online (Plan 1) can also be put on hold if the user has the add-on Exchange Online Archiving . Holds only apply to mailbox data with this license.

One great advantages of hold is that the user account can be deleted after they leave the company and the data will still be preserved for eDiscovery. So you won’t be burning a license for a user who does not access their mailbox any longer.

For more information about litigation or legal hold in Office 365, read In-Place Hold and Litigation Hold in Exchange Server.

Office 365 Your Organisation Needs More Information To Keep Your Account Secure

I know that we have to take security seriously, but I faced this problem so many times. Have you recently created a new Microsoft 365 or Office 365 account and users are being forced to setup MFA within 14 days despite MFA not being configured?

we are in the same boat!

I’m constantly setting up new tenants for clients and performing migrations and while enforcing MFA is a great idea and having it enabled by default is good it does cause issues during the configuration stage of a tenant.

The issue is being caused by a new security default policies being applied to the tenant.

Here is how to temporally (take it seriosly yo!) disable the new security default policies to turn off this behaviour.

Log into your tenant and go to the Admin console and click in ‘Azure Active Directory’ from the left hand menu.

now click on ‘Azure Active Directory’ then ‘Properties’ then ‘Manage Security Defaults’.

Set ‘Enable Security Defaults’ to ‘No’.

Tick an option which most applies to you and click ‘Save’.

Now users will not be forced to configure MFA but remember weak passwords are causing us all major issues so please enable MFA for user accounts as soon as you can.

Unable to see Public Teams or join them

My customer had an issue where public teams are no longer showing in Teams application or Browser, whenever you go to “Join Team” or “Create Team”

Also, something weird is that the search box on the right hand of the screen was missing, so the screen that they were seeing, was similar to the following one:


So in order to solve that, you need to do the following:

  • Access to with at least a Teams Administrator role in the company
  • Go to Org-Wide Settings –> Team Settings
  • At the bottom of the Teams settings, there is a Search by Name section. Ensure this is turned OFF

Once this has been turned off, it takes about 30 minutes for the tenant to update with the changes. Take into account that some changes done via UI will take up to 24 hours (in some cases I faced it)

If you go back to ‘Join or create a team’ you should see the search box and the public teams. Probably you will need to clean cache in the browser and in the Teams App ( )

Hope it helps!