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.

Saving credentials securely with PowerShell

There are times when you want to securely save and retrieve information in PowerShell. Saving things like passwords and other credentials to plain text is not a good idea at all. To avoid that, you can use the Secure string feature of PowerShell. The most common way to do this is via the command:

$Secure = Read-Host –AsSecureString

This creates a secure string. After you enter the command, any characters that you type are converted into a secure string and then saved in the $secure variable. With this command, the characters you enter are not displayed on the screen.

image

Because the $secure variable contains a secure string, PowerShell displays only the System.Security.SecureString text when you try and view it. So the information to be secured is now saved as a protected variable called $secure in PowerShell. How can this now be written securely to a file so that it can be re-used later and still remain protected, even on the disk?

You can use the command Export-Clixml because a valuable use of this on Windows computers is to export credentials and secure strings securely as XML.

Thus, a better way to capture the value you want to save securely is probably via:

$Secure = get-credential -credential ClientID

image

Which will prompt you for the information as shown above. You will note that the User name filed has already been created thanks to the –credential parameter.

This will then give you a variable with a username (here ClientID) and a secure string that is a PowerShell credential.

You can then save the information via:

$clientid | Export-CliXml -Path .\clientid.xml

image

If the Export-Clixml is used to save that variable to a file (here clientid.xml), it will save it like shown above. You will note that the Password field is encrypted. This is where the secure information is kept, which is great, since it is now encrypted on disk.

The other great thing about using Export-Clixml is that:

The Export-Clixml cmdlet encrypts credential objects by using the Windows Data Protection API. The encryption ensures that only your user account on only that computer can decrypt the contents of the credential object. The exported CLIXML file can’t be used on a different computer or by a different user.

image

Thus, if the file with the saved and encrypted information is copied and used by another login on the same machine or on a different machine, you get the above result. Basically, it can’t be decrypted.

Of course, this isn’t perfect, but it does mean that once you have saved the information using the above technique the only way it can be decrypted is via the same logon on to the same machine. This means you don’t need to have secure variables saved as plain text inside scripts or in unprotected files on disk that can be copied and work anywhere. With this technique you can ensure that information saved to a file is encrypted and cannot be used by any other user or by any other machine. Thus, if someone got hold of the file, the information couldn’t be viewed or decrypted and thus access would be denied.

Hopefully, that should allow you to develop more secure PowerShell scripting.

Bringing colour to PowerShell

image

I like to use colour in PowerShell via the –foreground and –background options to imp0rove the legibility of my scripts. However, with a range of colours to select from it became hard to work out what any combination looked like. I’d like to aim for a standard that looks good on most screens. Problem was I couldn’t really find an easy way to view all these options quickly and easily.

I therefore decided to create my own solutions here:

https://github.com/directorcia/Office365/blob/master/text-colour.ps1

that you can also use. It will basically spit out a line of text for each colour combination so you can see what it actually looks like. This makes it much easier to see which combinations of foreground and background colours work.

Hopefully, this helps others brighten their PowerShell output.