Remove known bad emails from tenant

Microsoft has a technology in Exchange Online known as ZAP. It will basically move known malicious emails, even after they may have initially been delivered to a mailbox. You can read more about the the technology here:

Zero-hour auto purge protection against spam and malware

ZAP however, is a ‘reactive’ security technology requiring knowledge of malicious content prior to taking action. There will therefore be cases when malicious content can get delivered to a mailbox, especially if the attack is relative new in the wild, simply because it has not yet been identified.  Hopefully, users have been trained so they can report any suspicious material that they do find, as I have detailed here:

Improved security is a shared responsibility

You can also enable an alert that notifies when someone reports an email. When that happens, you may want to check through all the other mailboxes to see whether that malicious email occurs elsewhere. If the payload is indeed malicious, you may wish to take the pro-active step of deleting that bad email from all users inboxes.

You can achieve this using two steps:

1. Create a content search to locate the suspect item in your tenant

2. Use PowerShell to delete the discovered items

Step one is to login to the Microsoft 365 tenant as an administrator and visit the Security and Compliance Center like so:

image

Select Content Search from under the Search option on the left.

Before you create a new search, you’ll need to find something unique about the item you are searching for.

image

In the case above, with this dodgy email, I’ll do a search based on the senders email but I could as easily do one on the mis-spelled subject ‘Alart’. All you need is something unique.

image

If I look in my inbox I can see this email listed as shown.

image

I create a new Content Search and use the unique criteria in the keywords as shown above.

image

Below this I can limit where the search is conducted. In this case, I will specify messages, as that is what I am looking for. You can get quite granular here if you need to. Just select Modify and specify the location you wish to search. Remember, the more places you search the longer it will take to return results.

image

Once you have crafted your search, select Save & run in the lower left. After a short while, you should see the results. In this case, I have only found the one result, which is the item in my inbox. Make sure you check the items that are returned as it is these items that will be deleted! You may need to adjust your search to get exactly the results you wish.

Next, you’ll need to fire up PowerShell and connect to the Microsoft Security and Compliance Center for you tenant. I have a script that you can use here if you have MFA:

https://github.com/directorcia/Office365/blob/master/o365-connect-mfa-sac.ps1

and if you don’t (shame on you):

https://github.com/directorcia/Office365/blob/master/o365-connect-sac.ps1

Once you have successfully connected you need to run the following line of PowerShell:

New-ComplianceSearchAction -SearchName “<Content search query name>” -Purge -PurgeType SoftDelete

for a ‘soft delete’ of the item (i.e. recoverable). Or

New-ComplianceSearchAction -SearchName “<Content search query name>” -Purge -PurgeType HardDelete

for a ‘hard delete’ (i.e. non-recoverable). You’ll also need to change <Content search query name> to match the name you gave the Content Search when you created it.

image

You should now see a prompt, as shown above, asking you to confirm your actions. Generally, you’ll select Yes to All here.

image

This will kick off the process of deleting the content you have found. Note, this process is not immediate. It may take a little while to work through all the locations.

image

When the process is complete, as shown above, that item no longer appears in mailboxes.

That’s how you run your own ZAP!

Need to Know podcast–Episode 219

We are just past Halloween and it’s time for something that seems to scare most people who administer Microsoft 365. PowerShell. However, to hold your hand while we dive deep we one of the best in business – Elliot Munro from GCITS – to guide you. Also, Brenton and I bring you all the latest news from the fire hose of Microsoft Ignite 2019, so much so that we’ll have more next time. Holey moley, there lots in the episode, so lean back, listen in an enjoy.

This episode was recorded using Microsoft Teams and produced with Camtasia 2019

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-219-elliot-munro/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

Elliot Munro

@contactbrenton

@directorcia

Introducing the new Edge and Bing

Microsoft 365 Productivity score

New Office Mobile App

Microsoft Fluid Framework

Introducing Microsoft 365 Business voice to UK and Canada

What’s new in Microsoft Teams from Ignite

Microsoft Endpoint Manager vision

The future of Yammer

Empower your people with Project Cortex

Check off your To-Do tasks in Teams

Security and Compliance announcements from Ignite

Need to Know podcast–Episode 218

I talk to industry veteran and Microsoft MVP Tony Redmond about a variety of topics including Exchange Online, Teams, PowerShell as well as his fantastic Office 365 administration eBook offering. He shares lots of great insights on a variety of Microsoft offerings. Brenton and I also talk about news and updates in the Microsoft Cloud and get you ready for what we are potentially expecting from the upcoming Microsoft Ignite conference. Listen along and get ready for the tsunami from Microsoft Ignite.

This episode was recorded using Microsoft Teams and produced with Camtasia 2019

Take a listen and let us know what you think – feedback@needtoknow.cloud

You can listen directly to this episode at:

https://ciaops.podbean.com/e/episode-218-tony-redmond/

Subscribe via iTunes at:

https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2

The podcast is also available on Stitcher at:

http://www.stitcher.com/podcast/ciaops/need-to-know-podcast?refid=stpr

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.

Resources

@12knocksinna = Tony Redmond

@contactbrenton

@directorcia

Tony’s blog

Office 365 for IT Pros eBook

Surface laptops are finally repairable

Microsoft’s cloud earnings

CIAOPS MS-101 online training course now available

New Microsoft partner CSP agreement

Microsoft acquires Mover.io

How to check user sign in history

Tamper protection in Microsoft Defender ATP

End user self service for Power Platform

What is Microsoft 365 Business [VIDEO]

Call of Duty – Modern Warfare

What you need for Windows Virtual Desktop (WVD)

banking-checklist-commerce-416322

Windows Virtual Desktop (WVD) is now generally available and I’ll be covering off how to set it up in upcoming articles. However, before you even login to your Azure tenant to start setting this up, here’s what you’ll need:

1. A Windows Virtual Desktop license for every user who want to use the service. These come with all Microsoft 365 and Windows E3 and E5 suites.

2. A paid Azure subscription. The majority of the cost of the WVD service will be your Virtual Machine hosts. The cost of these will vary on how many you want to use and how long they run for.

3. Azure Active Directory. The users who access the WVD service need to be in Azure AD. These users can be cloud only or synced from on premises using Azure AD Connect.

4. A Domain Controller (DC). At this point in time the WVD still requires a ‘traditional’ domain controller to allow the VMs to connect to for access. If you only have cloud users then the easiest option to achieve this is to add Azure AD Domain Services. If you already have an on premises Domain Controller (DC) you’ll need a Site to Site (S2S) VPN to link your on premises network to Azure. Note, that if you have an on premises DC that is using Azure AD Connect you can’t just add Azure AD Domain Services because Azure AD Connect doesn’t sync ‘traditional’ DC attributes. So, if you have an on premises DC, even if it is already using Azure AD Connect, you’ll still require a S2S VPN to Azure to allow the WVD service to connect VMs to that domain.

5. Azure AD tenant ID. Each Azure AD has a unique number which you can get from the web interface or via PowerShell. This is because it is possible to have multiple AD’s inside Azure and each can be configured and connected differently. The WVD service will need to know which specific Azure AD to connect to when provisioning.

6. Azure Subscription ID. The costs of the WVD service need to be applied against a unique subscription inside Azure. again, remember it is possible to have multiple independent subscriptions inside an Azure tenant. The WVD setup will need to know which subscription to bill for the service.

7. Azure tenant admin account. This will typically be a global administrator of your Azure environment. This will typically be the user who sets up, configures and manages WVD. They will also typically be an administrator of the domain that is connected to Azure AD.

8. Domain join account. This is an account that has the rights to join machines to the domain. The WVD service will create a number of VMs that need to be connected to the domain so that users on the domain can login to these machines in your WVD environment. You may wish to have a domain join user who is not a global administrator for security reasons but you should also be aware of the potential password requirement differences between your domain user and the Azure admin account. You may wish to use the same Azure admin account as your domain join account. If so, just beware of the password requirement policy for these.

image

As you can see above, the domain join account has to be at least 12 characters long, plus 3 of the following – 1 lower case character,  1 upper case character, 1 number, a special character. That requirement may be different from what your Azure AD or on premises AD requires. My recommendation would be to create a stand alone domain join account that meets the requirements and is only used for joining machines.

9. Azure Virtual Network (VNET). You’ll need a pre-existing VNET for the WVD machines to connect to. When you implement Azure AD Domain Services or a S2S VPN to connect an on premises DC, you’ll need a VNET. Make sure you understand the IP addressing and subnetting of your Azure VNET when you create it, as changing it later can be very painful.

10. Appropriate skill set. WVD requires a range of skills and understandings including:

– Identity management

– Azure AD

– PowerShell

– Azure IaaS including VNETs, VMs, Storage, etc

– Networking

– Azure backup, imaging, etc

Can you bumble you way through without these? Maybe, but life will be much easier if you do have these skills and really, if you are planning to work in the Microsoft Cloud environment, these should be considered mandatory.

There you have it, ten pre-requisite items to get sorted before you launch into creating a WVD for yourself. Get these sorted prior and your installation will be much smoother!

As I said, I’ll have upcoming articles on how to set this up, so stay tuned.

Microsoft 365 Automation presentation

These are the slides from my recent presentation on the automation options available in Microsoft 365.

The most important take away I believe is that we live in a world dominated by software. This fact is highlighted that:

Software is eating the world

There are plenty of reasons not to focus on software as a success path but that major reason to is simply the opportunity it provides, especially if most others believe it is all too hard.

It is important remember that software is a skill not a talent. This means it is something that can learned and improved continually over time. There is no such thing as a born developer. Some may have a higher aptitude to software development than others but that doesn’t means it isn’t something you can develop and learn.

As you ponder the worth of automation, have a look at all the simple processes you repeat continually throughout your day. Why is that? Why are these not automated? We live in a world of abundant technology. Most people carry a computer with them that is more powerful that the one that landed on the moon, yet it seems we all have less time to do the things we really enjoy. Why is that? We have allowed technology to master us, rather than using software to make it do our bidding.

The place to start with Microsoft 365 automation is on the desktop. Applications like Word, Excel, and so on contain the ability to record processes via macros and replay these quickly and easily. In fact it will actually convert these actions into code that can be further modified. Every Office application has a huge set of tools to assist with automating processes.

Although tools like SharePoint Designer have now been depreciated they are still available to use. If you are doing work with SharePoint, especially migration, it is important that you have some idea about the workflows SharePoint Designer creates and how they can be maintained.

Third party services like IFTTT and Zapier provide the ability to connect to Microsoft 365 services. One place that I use IFTTT is to save a backup of each of my blog articles directly to a OneNote file I have saved in OneDrive. I use Zapier to automate my free SharePoint email course offering.

The important consideration here is that the automation does not have to be purely focused on a technical outcome. It can be used in many places inside a business, including marketing.

The Microsoft equivalent of tools like IFTTT is known as Microsoft Flow. It allows to connect to both Microsoft 365 and third party services and map a process around these. The great thing about Flow is that it can integrated to includes on premises resources as well as be extended. More power is also available with tools like Azure Logic App and Azure Functions, which can be easily integrated into Microsoft 365.

Introduction to Microsoft Flow

Automation is also available in Microsoft Teams by utilising either the built in bots or even going far as to build your own. You will also find that Teams has a Flow bot that you can incorporated. This shows you the power of the power of the Microsoft solution via the integration of tools throughout the stack. Delivering automation for a business through a services like Teams makes a lot of sense as many of your users are already here most of the time.

The automation tool that most IT Professionals should be focusing on without doubt is PowerShell. Unfortunately, this seems to be the one that garners the most resistance and there is no doubt that getting started with PowerShell can be challenging. However, there are options like Azure Cloud Shell that make this much easier and also allow you to access PowerShell through a browser or even a mobile app.

The way forward with PowerShell is to use it’s ability to integrate and take advantage of the Microsoft Graph. This avoids the need to load multiple cumbersome service modules. If you are looking to invest your time in PowerShell with Microsoft 365 then you should be investigating how to take advantage of the Microsoft Graph using it.

As a final point to consider, I’d recommend you take a look at the following video from Daniel Pink, especially at this point (from about 29 minutes in):

https://youtu.be/CUDqN7MNsRw?t=1662

Connecting to Cloud App Security API

As I have said previously, I believe Microsoft Cloud App Security is a must have for every tenant:

A great security add on for Microsoft 365

You can also manipulate it via an API and PowerShell. Most of this manipulation is currently mainly to read not set information but that is still handy. Here’s how to set that up.

image

You’ll firstly need to go to the Microsoft Cloud App Security console and select the COG in the upper right corner of the screen. From the menu that appears, select Security Extensions as shown.

image

The option for API tokens should be selected, if not select this. Now select the + button in the top right to generate a new token.

image

Enter a name for this new token and select the Generate button.

image

Your API token should be generated as shown. Copy both the token and the URL and select the Close button. Note, you’ll need to take a copy of you token here as it won’t be available once you move forward.

image

You should now see the token listed in the Microsoft Cloud App Security portal as shown above.

This token can now be utilised to access Microsoft Cloud App Security via PowerShell. I have created a basic script for you to use here:

https://github.com/directorcia/Office365/blob/master/o365-mcas-api.ps1

that will basically return all of the data current in there.

You’ll then need enter the values from this configuration into the script prior to running it:

image

but in essence what that script does is take the token and uri and apply to the invoke-rest method to get a response. That return response contains a whole range of data from Microsoft Cloud App Security.

image

To see what you can and can’t do with the API visit the Microsoft Cloud App Security portal again and select the Question mark in the upper right this time. Select API documentation from the menu that appears.

image

In there you’ll find a range of information about the API.

As I said, most of the available command current just “get” information. Hopefully, commands that “set” information aren’t too far away.

Retrieving credentials securely with PowerShell

In a recent article I highlighted how you can securely save credential from PowerShell to a local file using the Export-Clixml command here:

Saving credentials securely with PowerShell

The idea with saving credentials securely is that you can now get to them quickly and easily. Just as easily in fact as embedding them into your PowerShell (which is a major no-no). So how do you do that?

You basically use the the import-clixml command like so:

$clientidcreds = import-clixml -path .\clientid.xml

to retrieve them. This will open the client.xml in the current directory, read in the encrypted values (username and password) and store them in the variable $clientidcreds.

Now $clientidcreds.password is a secure string, which means it can’t easily be used as a normal string in PowerShell. No problemo, now jus run the command:

$clientid = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($clientIdcreds.password))

and $clientid will have the plain text variable you initially saved and exported to the secure  XML file.

This is pretty neat eh? It allows you to securely save items such as oAuth and API keys in a secure file on you machine and then recall them quickly and easily with the above commands and use them in your PowerShell code.