Trying to Disable Microsoft Teams Phone for a user who has left the organization can be puzzling, especially if you haven’t done it before. It is quite integrated with M365 and there is a process to it. You are probably doing it this way….

Back in the day when a user left your organization, it used to be quite easy. It was done this way:

• You would disable the account in AD
• Forward their email to someone else in the organization
• Perform any modifications necessary in your VOIP phone system
• Change the VM greeting to let users know the user was no longer with the company
• Reroute their calls for awhile.

You can still do that in M365 but if you disable the account first, the user disappears in Teams Admin and you can’t do any further modifications!! If done right, it is as easy as adding a number in Teams. Here are the steps to the proper process.

How To Disable Microsoft Teams Phone

Note: Make sure you do this before you disable the account in AD. When it syncs to the Cloud the users Team’s account will disappear!!!

1. Keep the users licensing active in the M365 portal.

• Start by forwarding all calls to voicemail:

• Then, establish a VM that notifies people – the user must have a default greeting set to “<user> is no longer with <Company Name> effective <Date>. Please contact <Manager> at <Teams Phone Number>.”.

• Hide the user from the GAL. You can do this in the portal but if you operate in a hybrid environment, go to the user account in AD and set the attribute MSExcHideFromAddressLists to TRUE
• Disable the account in AD or block sign-in in the portal.
• Have your IT Ticketing system remind you to remove the licensing after a certain period in O365 portal, so you don’t needless pay for a license you are not using.

The important thing to remember is NOT disable the user M365 account until after the Teams configuration is done. Wen done right, even tough the user has disappeared from teams, people will be properly notified when they call.

Happy IT’ing

Dan

You have a group of users that you want to only login into to certain devices in your organization. A good example is a general use account that you only use in one place (like a kiosk or a dedicated work area) but MFA is not feasible. You can use Conditional Access to help with this.

What is Conditional Access?

Conditional Access is a part of Azure AD that helps organizations improve security and compliance. By creating Conditional Access policies, you can tweak your authentication process.

Think about the old way of authentication: You require user to supply a username and password. Most of the time, it’s the legitimate account owner typing them in, the user can go on to access all the data, applications and other resources they’ve been granted permissions for. But consider this, an attacker has stolen or guessed a user’s credentials. Now they are accessing your network, and could have a breach on your hands

To mitigate these risks, organizations can put additional authentication in place. MFA is a good example.

The thing is, MFA is a broad approach. In the example I am about to show you what to do if the user is unable to use MFA.

You can use Azure AD Conditional to strengthen the authentication process. For example, you can create a policy to require users in a certain group to only login on devices that are recognized by the organization (At least Azure AD registered) and block all others. This will also help you pinpoint a breach a lot quicker. I will show you how in the next section.

Limit A Users Login With Conditional Access

Login to your Azure Active Directory (AD) portal and go to Conditional Access and add a new policy:

Give your Policy a name and then add users or groups that you want to include in this policy ( In my example I added a group):

Next, you can move to the next step, which is what applications you want to restrict login to. In this example, I have chosen Office 365:

This is the most important part the Conditional Access Policy:

In the Filter for Devices Section, you exclude devices from the policy by “Trust type”. If a user account from the group specified above is NOT one or more of the trust types you specify, they ARE included. I kept it simple and chose Azure AD registered. I am in a Hybrid environment and our devices are not joined to the cloud, only registered.

The last section is to block all access to the aforementioned apps:

You could save the policy and start using it right away but that would not be a good idea. Save it as “Report-Only” and then check you Azure AD sign in logs to make sure it it working. Look at the logs by going to Azure AD / Users / Sign-in Logs. You will see a list of your users sign-ins. Filter for a time period where you have the Report-Only Conditional Access Policy in place.

Pick a user account that you know in included in the policy, if you see this then the policy would not block them if it were on:

If you see the following you the device would be blocked from signing in if it were on:

Users would expect to get this screen when they try to login:

You can investigate the sign-in to make sure it is not a false positive. Let the policy run in “Report-Only” Mode for awhile until you are sure it is running as it should and then turn it on. You have found a way to limit logging in for a certain group of users where MFA is not feasible.

Happy IT’ing

Dan

Are you still using Send-MailMessage to Send Mail In PowerShell? You need to stop. The command needs SMTPAuth enabled for your organization. If you are looking for ways to security harden you M365 tenant, disabling this feature is a good way to go. But you still need to send email in PowerShell, right? I will show you in three steps.

Step One – Send Mail In PowerShell (Set up an App is Azure)

The first step involves setting up an App registration that will let you send mail. Create an App Registration in Azure Ad by going to Azure AD / Application / App Registrations and creating one:

Click register. Now that you have you App for sending mail registered, go to API Permission and give the App permissions to Send mail as any user.

Please don’t forget to click on “Grant admin consent for” on the app.

To finish our Azure App, we need to configure the Authentication Method to use as a Client Secret. Navigate to “Certificates & secrets” and select “New client secret.”

Enter a Name and Expire Date. Not this date because when it expires, your scripts that use this app will stop working and you will have to renew it.

NOTE:

When you click “Add”, the Secret is created and you have a unique chance to get the Client Secret. This is a one-time shot, so copy the Secret, before refreshing the Page or navigating to a different Section.

Now on to step two.

Step Two – Send Mail In PowerShell (Set Security Group in Exchange Online)

Once you are done creating an App, you need to set and application policy that will only let you use only the email address you specify in your organization to send mail as:

Connect to Exchange-Online and then run the following command in PowerShell:

1. Connect to Exchange Online with the ExchangeOnlineManagement PowerShell module Connect-ExchangeOnline
2. Create a mail enabled security group which contains all the accounts you want to send mails from $restrictedGroup = New-DistributionGroup -Name “Mail service accounts” -Type “Security” -Members @(“yourorgemail@company.com”)
3. Optionally hide the group from the address list Set-DistributionGroup -Identity $restrictedGroup.Identity -HiddenFromAddressListsEnabled $true
4. Create the application access policy to only allow sending the app mails for the specified distribution group
5. Run this last set of commands:

$params = @{

    AccessRight        = “RestrictAccess”

    AppId              = “1f5ffbea-f13f-4f1a-af63-258ce4344daf”

    PolicyScopeGroupId = $restrictedGroup.PrimarySmtpAddress

    Description        = “Restrict app permissions to only allow access to service account”

}

New-ApplicationAccessPolicy @params

Once this group is created you can go to into in admin.microsoft.com (Admin portal) and Navigating to Users / Teams & Groups / Mail Enabled Security Groups and making changes as necessary:

When you send mail using MS Graph, only the email address list above will be the only one able to send as.

Step Three – Send Mail In PowerShell (Use MS Graph in PowerShell)

In order to send mail in this new set up, you need to take note of three pieces of information from your app registration:

• Tenant ID – you can get it by looking here
• Client Secret (NOTE:) from above
• App (Client ID) – you need to got to the listing of your app registration and you App (Client ID will be listed here (See below)

Then, use this script to send your mail:

#Declare Parameters

$clientID = “your ID from App Registration”
$clientSecret = “your client secret from App Registration”
$tenantID = “your tenant ID”

#Run Script

$MailSender = “emailFromStep2@company.com”

#Connect to GRAPH API

$tokenBody = @{
Grant_Type = “client_credentials”
Scope = “https://graph.microsoft.com/.default”
Client_Id = $clientId
Client_Secret = $clientSecret
}
$tokenResponse = Invoke-RestMethod -Uri “https://login.microsoftonline.com/$tenantID/oauth2/v2.0/token” -Method POST -Body $tokenBody
$headers = @{
“Authorization” = “Bearer $($tokenResponse.access_token)”
“Content-type” = “application/json”
}

#Send Mail

$URLsend = “https://graph.microsoft.com/v1.0/users/$MailSender/sendMail”
$BodyJsonsend = @”
{
“message”: {
“subject”: “Hello World from Microsoft Graph API”,
“body”: {
“contentType”: “HTML”,
“content”: “This Mail is sent via Microsoft

GRAPH

API

                        "
                      },
                      "toRecipients": [
                        {
                          "emailAddress": {
                            "address": "yourToAddress@company.com"
                          }
                        }
                      ]
                    },
                    "saveToSentItems": "false"
                  }

“@

Invoke-RestMethod -Method POST -Uri $URLsend -Headers $headers -Body $BodyJsonsend

Conclusion

It seems like a lot of work but this is just to set it up. Now that you have a good base, whenever you need to send a mail for whatever reason in PowerShell all you have to do is make sure the required email sender address is in the Mail Enabled Security Group and in the variable in the script and you are good to go. A good example is notifying users that they are using external forwarding!

Happy IT’ing

Dan

Now that you have disabled O365 External Forwarding for your organization, it’s time to find out who is using it….

List Users Who Are O365 External Forwarding

You may want to give your users a heads up that you will be disabling this feature. You can easily do this by connecting to the Exchange-Online PowerShell Module and using the Get-InboxRule commandlet. This example shows you how to get this list from a bunch of users:

#Connect to Exchange

Connect-ExchangeOnline

#Delcare Variables

$CSVPathUPN = “Path_To_UserList_CSV”

$StatusPath = “Path_To_User_Rules_Output_CSV”

#Run Script

#Try import UPN CSV file

try {
$UPNUsers = import-csv $CSVPathUPN -ErrorAction stop
}
catch {
throw “Error importing CSV: $($_.Exception.Message)”
break
}

#Go Through Each User

foreach ($UPNUser in $UPNUsers) {

#Go through each Rule and see if forwarding is set up

$x = 0

$user = $UPNUser.UPNUser

$items = @(Get-InboxRule -Mailbox $user)

$count = $items.count

while($x -lt $count) {    

    $rule = $items[$x].RuleIdentity
    $ruleWithQuotes = "{0}" -f $rule
    $rulename = $items[$x].Name
    $rulenamelength = $rulename.length

    #"`r",$rulename
    #$("-" * $rulenamelength) 

    $ForwardToObj = Get-InboxRule -Mailbox $user -Identity $ruleWithQuotes | Select ForwardTo
    $Contain = $ForwardToObj.ForwardTo

    if  ($Contain -like '*SMTP*') {
        $Contain

       } else {

        $Contain = "Not an External Forward or a Forward"
       }


    $ForwardAttachObj = Get-InboxRule -Mailbox $user -Identity $ruleWithQuotes | Select ForwardAsAttachment
    $Contain1 = $ForwardAttachObj.ForwardAsAttachment

    if  ($Contain1 -like '*SMTP*') {
        $Contain1

       } else {

        $Contain1 = "Not an External Forward or a Forward"

       }

$Rules = $user + "," + $rulename + "," + $Contain + "," + $Contain1

Write-Host $Rules
Write-Output $Rules | Out-File $StatusPath  -Append

    $x++
}

}

Write-Host All Rules Exported….

Disable External Forwarding for the Organization

When you are done writing and deploying the script, you need to make sure the default Anti-Spam Outbound Rule is enabled. As a Global Admin, go to admin.microsoft.com. Then go to Security / Policies and Rules / Threat Policies / Anti-Spam Policies:

When you click on Anti-Spam Outbound Policy (Default), you will see a fly-out menu to your right. Click on “Edit Protection Settings” and make sure the Forwarding rules are set to off:

Save your settings and it is now turned off. Notify your list if users from step one and you are done. going forward, If you prefer sending an NDR to the user when they either setup a rule or try to use it you can set up a Transport Rule in Exchange admin instead.

Go to admin.exchange.com and navigate to Mail Flow / Rules. Set up a rule to block Auto-Forward to recipients outside the organization with an explanation:

This article explains it very well.

Your Users may not like it but it protects the organization from comprised email through phishing attacks and rogue employees.

Happy IT’ing

Dan

At some point you are going to deal with a M365 User Compromise. It could be a password leak of some kind. It could be through a phishing attempt or as simple as password sharing. Either way, it can be dealt with easily and quickly in 3 steps. I will show you how.

M365 User Compromise Account – Reset the password

Go to admin.microsoft.com and under Active Users search for the user of the compromised account. Click on the Username and then find:

This will help guard against any new logins with the account.

Revoke Sign In For Compromised Account

After a password reset, the next step is to sign the compromised account out of everything. While still in the user flyout, sign the user out from all sessions:

Similarly, you can do this in PowerShell. I wrote a great article about it here.

Block Unapproved Email Apps and Protocols

As a result, going forward, make sure you are not using any App or protocol you do not need. Click the Mail Tab if the User Fly out and click the Manage Email Apps Link:

From here, uncheck any email app or protocol that could be used on a compromised account. It is a good idea to do this organization wide and not just for the user:

Voila. Not only has your user compromise been dealt with quickly, you have security hardened your M365 tenant. It gives bad actors a smaller attack surface and this could only be good for your organization!

Thankfully, I have written several articles on M365 Security. I encourage you to review them. They can help you quickly react to security compromises quickly when they happen or harden your system preventing it from happening in the first place. If you use these 3 steps to deal with an M365 User Compromise you will have it fixed in no time!!

Happy IT’ing

Dan

You, for many reasons (Security being a big one), that you need to Disable External Forwarding for your M365 Users. In this article I can show how to check which users are using forwarding and then how to turn it off for the entire organization so it won’t be a concern going forward.

List Users Who Use External Forwarding

You may want to give your users a heads up that you will be disabling this feature. You can easily do this by connecting to the Exchange-Online PowerShell Module and using the Get-InboxRule commandlet. If you only have a few users to look at you can run the following script manually:

#Connect to Exchange

Connect-ExchangeOnline

#Delcare Variables

$user = “username@domain.com”

$x = 0

$items = @(Get-InboxRule -Mailbox $user)

$count = $items.count

#Main

#Show all Rules on mailbox

$items

#Go through each Rule and see if forwarding is set up

while($x -lt $count) {

$rule = $items[$x].RuleIdentity
$ruleWithQuotes = "{0}" -f $rule
$rulename = $items[$x].Name
$rulenamelength = $rulename.length

"`r",$rulename
$("-" * $rulenamelength)

Get-InboxRule -Mailbox $user -Identity $ruleWithQuotes | Select -Property ForwardTo
Get-InboxRule -Mailbox $user -Identity $ruleWithQuotes | Select -Property ForwardAsAttachment


$x++

}

If you need to run this command for many users, I would suggest wrapping it in a For-Each Loop based on a CSV of your Organizations users and Export to a CSV if you need it as a list.

Disable External Forwarding for the Organization

For this, you need to make sure the default Anti-Spam Outbound Rule is enabled. As a Global Admin, go to admin.microsoft.com. Then go to Security / Policies and Rules / Threat Policies / Anti-Spam Policies:

When you click on Anti-Spam Outbound Policy (Default), you will see a fly-out menu to your right. Click on “Edit Protection Settings” and make sure the Forwarding rules are set to off:

Save your settings and it is now turned off. Notify your list if users from step one and you are done. They may not like it but it protects the organization from comprised email through phishing attacks and rogue employees.

Happy IT’ing

Dan

Did you create a meeting either through Outlook 365 or directly in Microsoft Teams and can’t join teams meeting online? You used the Teams Meeting Button in Outlook, or you checked the “Online Meeting” Check box in Teams, but you still can’t join?

If you already tried signing in and signing out or deleting your Teams’ cache, here is a hack to get it back.

When you create a meeting in Teams directly it is supposed to automatically have the online option. The join button in the meeting should show up when it gets close to the meeting time. In fact, the only way at this point where it won’t be online is if you use a version of Outlook that doesn’t support the Microsoft Teams Meeting.

You Invite the others in the meeting, and they get the meeting info like this:

But the meeting you created in your calendar does not have the Join Button like what you see below:

If this happens to you there are two ways to Join Online.

Right Click on the Meeting

You can right click on the meeting and choose the “Join Online” option:

Still Can’t Join Teams Meeting Online? Refresh.

It is a hack, but it works.

1. Open the meeting in Teams.
2. Invite someone to the meeting.
3. Remove them from the meeting.

Now, when you right click on the meeting. The “Join Online” Option is there. This refreshed the meeting details and brought the Join Online back!

The good news is at least you can fix the meeting and do not have to call the HelpDesk!

Happy IT’ing,

Dan

So your organization has decided to do away with their phone system an go directly to Microsoft Teams Voice. Now all that is left to do is Adding a Number to a Teams User. The only prerequisite is that you have a block of DID assigned to you by your Telco.

If you don’t have many users to add telephone numbers to, you can manually enter them using some PowerShell commands. However, if you have a lot to do I can show you a way to automate them. Let’s add some numbers!!

You Only Have a Few Users To Do

This is also a good way for adding the odd number after the migration.

Connecting to the Teams Module

Connect-MicrosoftTeams

Add User Number

Set-CsPhoneNumberAssignment -Identity userid@company.com -PhoneNumber ‘+1XXXXXXX’ -PhoneNumberType DirectRouting

Grant-CsOnlineVoiceRoutingPolicy -Identity userid@company.com -PolicyName “Policy set up by you or Telco”

Set-CsOnlineVoiceMailUserSettings -Identity userid@company.com -VoicemailEnabled $true

If you make a mistake you can easily remove the number and start again:

Remove User Number

Grant-CsOnlineVoiceRoutingPolicy -Identity userid@company.com -PolicyName $null

Remove-CsPhoneNumberAssignment -Identity userid@company.com -RemoveAll

But what if you have a lot of users to to???

You Have a Many Users To Do

You can run these commands in a batch but I would recommend testing it with a small block of users before you go ahead with the whole group. You could run a batch delete and start from scratch but that sounds like a headache….

You can use a for each loop going through each user in an import CSV you created. Create a CSV file with two field names: UPName and PNumber. Populate it with your users and then create this PowerShelScript:

$CSVPath = “<Path To File Goes Here>”

Connect-MicrosoftTeams

#MAIN

#Try import CSV file

try {
$Users = import-csv $CSVPath -ErrorAction stop
}
catch {
throw “Error importing CSV: $($_.Exception.Message)”
break
}

#Add Numbers

foreach ($User in $Users) {

Set-CsPhoneNumberAssignment -Identity $User.UPName -PhoneNumber $User.PNmuber -PhoneNumberType DirectRouting

Grant-CsOnlineVoiceRoutingPolicy -Identity $User.UPName -PolicyName “PolicyNameGoesHere”
Set-CsOnlineVoiceMailUserSettings -Identity $User.UPName -VoicemailEnabled $true

}

Write-Host User Numbers Added!

This should help you get your phone numbers added quickly.

Happy IT’ing

Dan