Course Overview
Course Overview
Hello everyone. My name is Vlad Catrinescu, and welcome to my course, PowerShell Playbook on Office 365. I am a SharePoint consultant and Microsoft MVP from Montreal Canada. As more enterprises are moving from on-premises to Office 365 IT professionals and developers around the world need to upgrade their skills to the cloud in order to stay relevant. While Office 365 provides the Office 365 Admin Center as a user interface administration tool, not all of the advanced settings are available in there. By using PowerShell Office 365 administrators are able to really get the full control of their tenant and automate multiple tasks. In this course we are going to learn how to use PowerShell to manage your Office 365 tenant by looking at 12 real-life examples and common tasks for the Office 365 administrator. Some of the major topics that we'll cover in this course include Office 365 users and licenses, SharePoint online, Office 365 groups, Exchange online, and Microsoft teams. By the end of this course you will know how to use PowerShell to connect to all of the services in Office 365 and learn how to manage them with real-life examples. Before beginning this course you should be familiar with the basics of PowerShell for Office 365. From here you should feel comfortable diving into other PowerShell topics, such as Windows PowerShell Best Practices and Patterns, Working with CSV Data in PowerShell, and Reporting with PowerShell HTML and enhanced HTML. I hope that you will join me on this journey to learn PowerShell with the PowerShell Playbook for Office 365 course at Pluralsight.

Course Introduction
Course Introduction
Hello, and welcome to this PowerShell Playbook on Office 365. My name is Vlad Catrinescu, and I will be your instructor for this course. I am an Office Servers and Services MVP from Montreal Canada, and you can find me on Twitter @vladcatrinescu or follow my blog at absolute-sharepoint. com. In this first module we will start introducing what is a PowerShell playbook, as well as what we'll cover in this course. Let me start with what is a PowerShell playbook course? Since this might be the first course of this series that you watch, I just want to spend a few seconds, so you know what to expect. The PowerShell Playbook series focuses on how to do real-life tasks by using PowerShell. Each module is a separate task and modules do not build on top of each other like other courses usually do. There's no storyline behind a PowerShell Playbook, as you will often see with other Pluralsight courses. PowerShell Playbook also assumes prior knowledge of certain concepts, and I will share with you in just a bit a recommended course to watch before you start watching this course. Now why do you need to listen to this course? What is in it for you? As you know, PowerShell is not the only way to manage Office 365. There are multiple tools out there; the main ones being the Office 365 Admin Center, the Office 365 Admin App on your mobile device, as well as PowerShell. While you might spend a lot of your day in the Office 365 Admin Center, not all of the settings and configurations are available. There are a lot of tasks that are only available with PowerShell, not to mention, all the automation capabilities of PowerShell that allow you to automate management and boring tasks, so you don't spend all your time of the day on the boring stuff. You create and do productive stuff instead. Now let's take a look at the course outline. For those of you that watched my other courses you know that I usually try to make a cool looking course outline, but we have 15 modules in this course, so I'll have to go for a simpler looking one. First off, the Course Introduction, where we are right now, in which we cover what the course is, what are the prerequisites, as well as the recommended listening before the course. Then in the following module we'll learn how to connect to Office 365 services. We'll cover how to connect to Azure Active Directory, SharePoint Online, Exchange Online, Skype for Business, Microsoft Teams, and all of the Office 365 services. Then our first task will be how to disable Office 365 services for some or all the users in our tenant. A lot of the stuff Microsoft is releasing new tools that we don't necessarily want enabled for all of our users, so we will learn how to disable them either for only a certain department or all the users inside of the company. Our next example is how to change the display name format for all our users inside the company. A lot of the time a company gets acquired or they've started growing, they had different admins over that time, and the display name format sometimes if first name, last name, or last name comma first name. We'll look at how to do a quick partial script that will make it the same for everybody. We'll then take a look at a user offboarding script, and that's not something that you see often. Usually we talk about user onboarding, but what do we do when a user leaves? We'll take a look at how to use PowerShell to add an out of office message, to cancel recurring meetings, and so on. Next up, we'll have a few modules talking about Office 365 groups, since a lot of the management of Office 365 groups can only be done via PowerShell. We'll first learn how to create this secrete Office 365 group, and you will learn what exactly that means in that module. We'll then take a look at how to apply governance around Office 365 groups in a few modules. First of all, how do we only allow select users to create an Office 365 group? By default, Microsoft has an open-door policy where all the users can create Office 365 groups, but not all companies want that, so we will look at how to apply certain governance policies on who can create them. We'll then take a look at how to enforce naming policies and blocked words. After that we will look at how to add usage guidelines for your Office 365 groups. Next up, we'll look at how to hide certain columns in different SharePoint Online forms. What I mean by that is that in SharePoint Online whenever you want to create an item, edit an item, or view an item those are three different forms, and with PowerShell you can actually customize when some fields are shown. For example, let's say you have a field called Process. It makes no sense to have that field when a person creates a new request, creates a new item in SharePoint, but you want to make it available on the Edit form. You cannot do that out of the box, but you can do it via PowerShell, and we will learn how. Next up, we will learn how to upload custom sensitive information types to the Office 365 Compliance Center. Office 365 allows us to have custom sensitive information types, so we get a warning or we apply a certain policy when we see a patient record, for example, or a certain client ID, however, you can create them locally, but the only way to upload them is with PowerShell. We cannot do that via the user interface, and we will learn how. Next up, we will talk about Microsoft Teams, and we will learn how to apply certain settings in Microsoft teams, such as enable or disable the fun settings, as their called, stuff like gifs, animations, and things like that. We will then learn how to create reports around our SharePoint online external users, so how to view external users that haven't accepted the invitation with the same email that they have been invited with and so on, and lastly, in the course conclusion I will share with you some other courses and resources where you can learn more about PowerShell for Office 365. This course is aimed at anybody who wants to learn how to use PowerShell to manage Office 365 whether you're an Office 365 admin or developer. This course, of course, applies to Office 365 and all of its services and the prerequisites are that you are familiar with PowerShell and are familiar with Office 365. We're not going to cover the basics of either PowerShell or Office 365, so to get the most out of this course I recommend that you know how to do basic PowerShell scripts, and you know how to manage Office 365 in the user interface. Lastly, before you start I really recommend that you watch the PowerShell for Office 365 course on Pluralsight because that will give you a good foundation of what you can do with more simpler cmdlets in PowerShell, and this course will really take you to the next level and show it how to use them in more of a real-life scenario. Thank you very much for listening to this module, and let's get started with how to connect to Office 365 services.

Connecting to Office 365
Module Introduction
Hello, and welcome to this PowerShell Playbook on Office 365. My name is Vlad Catrinescu, and I will be your instructor for this course. In this module we will learn how to connect to Office 365 by using PowerShell. Since in the following modules we'll be playing with one or multiple Office 365 services in each, we don't want to learn how to connect to each service in every module, so this module will really cover how to connect to all of the Office 365 services, and will serve as the basis for all the other modules. We'll first learn how to connect to Azure Active Directory, learn how to connect to SharePoint Online using the module provided by Microsoft, as well as the Office 365 Dev PnP PowerShell Cmdlets. If you don't know what those are we will learn all about them in this module. We will also learn how to connect to Exchange Online, the Security and Compliance Center, Skype for Business Online, as well as Microsoft Teams. We will learn how to connect to each of those services by using both normal authentication, by normal I mean single factors, only username and password, and since most of your admin accounts are now Multifactor Authentication enabled we will also look at how to connect to all of those services by using Multifactor Authentication or with Multifactor Authentication accounts.

Getting the AzureAD PowerShell Module
Let's start with connecting to Azure Active Directory, which is the module we will use to manage our users and licenses. How do we get it? The Azure Active Directory module is hosted on the PowerShell Gallery. The PowerShell Gallery is the central repository for PowerShell content from Microsoft. To download modules from the PowerShell gallery you need to have PowerShellGet. You might already actually have PowerShellGet installed on your computer depending on what operating system or PowerShell version you have. PowerShellGet is included automatically if you're using Windows 10 or later, Windows Server 2016 or later, or if you have installed the Windows Management Framework 5. 0 or later, or lastly, if you have PowerShell 6. If you do not have any of those operating systems or requirements don't worry; you can download the PackageManagement MSI, which includes PowerShellGet from the link in the slides. Remember that from the Pluralsight course page you can download all of these slides, so you don't have to copy paste any links from this course. Simply download the slides and you're going to be able to directly click on them, so it's going to make it a lot easier for you to get those links or to get to them rather than pausing the course and copy pasting them. After you have the requirement, which is PowerShellGet, you simply need to run PowerShell as an administrator, and the only cmdlet you need to do is Install-Module -Name AzureAD. That is it. Because of the way that PowerShell works with the PowerShell Gallery, PowerShell will look in the PowerShell Gallery for modules with the name AzureAD. It will ask then if you want to download it. Say yes, and it will download and install it for you.

Demo - Getting the AzureAD PowerShell Module
So that is it for the theory. As you see, it's pretty straightforward, so now let's go to the lab and download and install the AzureAD module on our computer. We are now in the lab environment, so let's go download and install the AzureAD PowerShell module. First, here in Chrome I have opened PowerShell Gallery and already navigated to the page of the Azure Active Directory PowerShell module. If you look, if you want to use the full name of it, it's the Azure Active Directory PowerShell for Graph, the General Availability Release. There's actually another version of it, but we're going to learn about that just in a few minutes. So if you look, if you've never been to the PowerShell Gallery before, let me just show you around a bit. First of all, we have some information about the module. We then have the release notes of all the new app cmdlets that got added in the last release, and you can view all the list of cmdlets. If you click on them, honestly, it will not bring you to the help, but let me actually show you. It will just bring you to a search base in which other modules this cmdlet exists, so don't click on them if you're looking for support. You have the support site here on GitHub or on docs. com, which now they're kind of merged, and you can also see the documentation here for more details, and then if you have any questions you can also ask them directly on the module page, but let's go back to our original goal, and let's go install the module. As you see, Microsoft or the PowerShell Gallery already gave us the cmdlet to do it, so let me copy this here. Let me make sure I didn't copy any extra characters. I then have opened PowerShell as an administrator here, so I'll only copy paste this, click Enter, and depending on your security settings it might ask you, or we actually have it here, do you want to trust this repository, which is PowerShell Gallery, for getting modules? So I will say that, yes, I want to trust this directory, and then it usually takes less than 1 minute, usually about 30 seconds, and the module will be downloaded. If we want to do a quick test that's the topic we're going to talk about in a few seconds, like say start typing connect-Azure, press on Tab, it was able to autocomplete it for me, which is the easiest way to see that it got loaded. So that is it. As you see, it's really, really simple to get this module. Now that we have the module installed on our computer let's go back to the slides and learn how to connect to Azure Active Directory with PowerShell.

Connecting to Azure Active Directory
Now that we have the module we need to connect to Azure Active Directory. You, of course, need your username and password, as well as global admin rights in Azure Active Directory in order to be able to manage everything. For the PowerShell to connect the first thing that you need to do is run a Get-Credential cmdlet, and save the credentials in a variable called cred. Afterwards, we'll simply run the Connect-AzureAD cmdlet and specify the -Credential parameter that we just saved and that's it. Based on your credential PowerShell will know what tenant you want to connect with, so you don't need to provide a tenant name or anything like that. So, as you see, without Multifactor Authentication it's pretty simple. However, if your company is using Multifactor Authentication the procedure is just a little bit different. What you have to do is you need to simply run Connect-AzureAD. Because with Multifactor Authentication we cannot really save the credential and automatically connect. When we run the connect AzureAD cmdlet it will open a pop-up window asking you first for your username and password, and after that it will prompt you for the second authentication method. For some of you it might be a text message, a call, or the Microsoft authenticator app, but it will prompt you for that second authentication method.

Demo - Connecting to Azure Active Directory
So now that we've seen the theory, as you see, it's really straightforward, well let's go to the lab and see how it looks like in real-life when we connect to AzureAD with both simple and Multifactor Authentication. We are now in the lab environment, so let's connect to Azure Active Directory. I have opened PowerShell as an administrator, so we're going to do as we have learned in the slides. First I will do a cred = Get-Credential. I will start typing my username, which is vlad@globomantics. org, and my password. This pop-up, when you do a Get-Credential, remember that it's really a dumb pop-up as I like to call it. It doesn't do any validation at all. You can enter whatever you want. You're going to press on OK, and it's going to say, yes boss, I saved the credential, so not because this pop-up accepts it that you have the right one, but we're going to press Enter to save it, and then we're going to connect first of all without Multifactor Authentication, so I'll do Connect-AzureAD, give it my credential, my variable cred here, press on Enter, and that's it. As you see, I am connected to Azure Active Directory with Single Factor Authentication. I can then do stuff, for example, like say I'll do Get-AzureADUser to get all of my users, and as you see, I have a lot of results that come back. So as you see, this was really easy using Single Factor Authentication. Now let's take a look at Multifactor Authentication. So the first thing I'll do is I'll disconnect from AzureAD, and let's clean up this PowerShell. Now if we want to connect to AzureAD using Multifactor Authentication we can simply run the Connect-AzureAD PowerShell cmdlet, and then we'll have a pop-up, as you see here, that says Sign in into your account. So I will use another account here, which is jeff. collins@globomantics. org. I'll try to put in the right password, and if everything goes okay you will see that it will think for a bit, it will say, hey, we noticed this is a Multifactor Authentication account. Please enter the code that we have texted to your phone that finishes with 02. So let me get to my phone right now, and let me get the code. There we go. Hopefully I got it right. I'll click on Verify. Worked perfectly fine, so as you see, this is how you can connect to Azure Active Directory using Multifactor Authentication as well. Now that we've seen how to both download and connect to Azure Active Directory let's go back to the slides, talk a bit about the different versions or the different flavors of the AzureAD module, and take a look at other Office 365 services.

AzureAD Preview Module
Before continuing on to the next module I just wanted to talk a bit about the fact that there are actually two modules for Azure Active Directory. The first one, which we just played with, is the stable, production release of the PowerShell module for AzureAD. The second one called Azure AD PowerShell Module - Public Preview includes the latest features that are not yet in the production release. They get in that module sometimes quite a few months before they get in the stable version, however, they are not as well documented and might change before getting into the production release. At the time of recording this course we will actually use the preview module for one of the modules later in this course, specifically about Office 365 groups, but depending on your needs it's up to you to look if the cmdlets that you need have made it into the stable version yet, or you might have to go for the public preview one. The full module name in the PowerShell Gallery is the Azure Active Directory PowerShell for Graph - Public Preview Release or to install it you just need to know its module name, which is AzureAD Preview. To install it simply use the Install-Module cmdlet and give it a name, AzureADPreview. Make sure that you uninstall the production version of the AzureAD module if you're going to install the preview version.

Connecting to SharePoint Online
Next up, let's talk about how to connect to SharePoint Online with PowerShell. Unlike the AzureAD PowerShell module, which was on the PowerShell Gallery, the SharePoint Online module is hosted on the Microsoft Download Center, and you can either search for it using your favorite search engine or download those slides from Pluralsight and copy the link form the slides. You also need to be a SharePoint Online Administrator in order to connect, as well as know the URL of the SharePoint Online Admin Center, which is always in the form of https, organization name, dash admin. sharepoint. com. To connect after you download and install the module, in order to connect to SharePoint online you first need to get a credential, as we previously looked at, using the get-credential cmdlet, and then run the Connect-SPOService PowerShell cmdlet specifying the URL of your SharePoint Online Admin Center, which, by the way, I have this screenshot here. In our demo it will be globomanticsorg-admin. sharepoint. com, and give it the credential variable, which is cred. So that is it for Simple Factor Authentication. If you are using Multifactor Authentication this is just a little bit different. You do not get the credential like we didn't do for the AzureAD module. You simply run the Connect-SPOService PowerShell cmdlet, specify the URL of your SharePoint Online Admin Center, and then you will have a pop-up that will ask you for your username, password, and it will ask you to provide this second form of authentication.

Demo - Connecting to SharePoint Online
So now that we've seen the theory, let's go to the lab and see in a demo how to get a SharePoint Online PowerShell Module, how to connect to SharePoint Online using PowerShell with Single Factor Authentication, as well as Multifactor Authentication. We are now in the lab environment, so let's get this SharePoint Online module, and let's connect to SharePoint Online. First of all, let me open Chrome over here. I've already prepared. I've went to the Microsoft Download Center, and you can see I'm on the page of this SharePoint Online Management Shell, so you can Google it. You can Google SharePoint Online Management Shell. It'll be one of the first results, so I'll leave it in English. I will click on Download. I'll select the 64 bit version. As you see, it's only 2. 4MB, so it should be a very quick download, and after it's downloaded I'll double-click to start it. Of course, I will accept the terms and conditions, click on Install. I have the user account control that I need to accept, and in a few seconds it's done. So now let me go ahead and open up PowerShell as an administrator. You can also open the SharePoint Online Management Shell directly, but I personally prefer to always stay in the PowerShell window, so I'll do Run as Admin. I will accept the user account control, and now the first thing, as we did in the slides, the first thing that I will do is I'll do cred = Get-Credential vlad@globomantics. org. I will enter my password, and then I'll do Connect-SPOService. Since this is a PowerShell module it will get loaded automatically as soon as I type one of the cmdlets, and then I need to give it the URL. For the URL remember that we need to get the URL of the SharePoint Online Admin Center, so it's always HTTPS, organization name, in this case, globomanticsorg-admin. sharepoint. com. So you don't need the stuff after the. com. You can simply copy this, then paste it into PowerShell, and then we'll do a credential, give it the cred variable, and that is about it. If I put my password right, and we don't hear anything, it means we successfully connected, and we can also retest it with the --- let's say we're going to run a Get-SPOSite cmdlet to get all of our site collections. Awesome, so it worked. Let me clean this up and let me disconnect from SharePoint Online, so Disconnect-SPOService, and now let's connect with Multifactor Authentication. If I want to connect with Multifactor Authentication I will do Connect-SPOService, give it the URL, so I'll give it the same URL, and that is it. So I'll press on Enter. I'll have the pop-up asking me to sign in to my account. I'll use the jeff. collins@globomantics. org account, which is Multifactor Authentication enabled, give it my password, and now it will prompt me for my second authentication method. As you see, it texted me a code to my cell phone. So let me get my phone out, and let me get the code, which is 169825. Click on Verify. Hopefully I got it right, and if we don't see any errors I was able to connect, so I can do another Get-SPOSite and be able to see all of my site collections this time with logged in as Jeff, which is an account that uses Multifactor Authentication. So that is it. In this demo we looked at how to download and install this SharePoint Online Management Shell module and how to connect to SharePoint Online by using both Single Factor Authentication, as well as Multifactor Authentication. Now let's go back to the slides and learn how to connect to SharePoint Online, but this time with the SharePoint PnP PowerShell cmdlets.

Connecting to Office 365 Using the PnP PowerShell Cmdlets
We have now learned how to connect to SharePoint Online using the Microsoft provided module, but I also want to teach you how to connect to Office 365 using the Office 365 Dev PnP PowerShell Cmdlets, which first let's learn what they are. The Office 365 Dev PnP, which stands for Patterns and Practices, is an open source initiative by the SharePoint engineering group at Microsoft, which contains multiple solutions, best practices, and samples on how to do more with Office 365 and SharePoint. While a lot of it is really developer focused, one of the awesome solutions is the SharePoint and Office 365 Dev PnP PowerShell Cmdlets, which include over 250 PowerShell cmdlets that allow us to do more with SharePoint Online than the module provided by Microsoft. The SharePoint and Office 365 Dev PnP PowerShell module is hosted on the PowerShell Gallery. You'd need to have PowerShellGet, so the same exact prerequisites as the AzureAD PowerShell module. We've already seen how to get those earlier in this module, so I will not go over them again. In order to install the module from the PowerShell Gallery you simply need to do the Install-Module cmdlet and give it the name of the module, which is SharePointPnPPowerShellOnline in a word, and that's it.

Demo - Getting the PnP PowerShell Module
Now that we've seen the theory let's go to the lab and download and install this SharePoint and Office 365 Dev PnP PowerShell Module in our lab machine. We are now in the lab environment, so let's download and install the SharePoint PnP PowerShell module. I have already opened Chrome and navigated to the PowerShell Gallery, and the name of the module, the full name in the gallery, is the SharePoint Patterns and Practices PowerShell Cmdlets for SharePoint Online. We've already went through how the PowerShell Gallery works, so what I will do is I will copy the cmdlet here, which is Install-Module -Name SharePointPnPPowerShellOnline. The reason why it says online is that actually there is also a SharePoint 2013 and SharePoint 2016 version of those cmdlets if you're still managing on-prem. We're not going to talk too much about those because really this course is about Office 365, so SharePoint Online, but just wanted you to know. I will then go here and paste it. It will probably ask me again if I want to trust the PSGallery repository, to which I will say yes, and after that it will take maybe 30 seconds, and it will be done. That is it. We have now downloaded and installed this SharePoint Online Patterns and Practices PowerShell module on our computer. Now let's go back to the slides and learn how to connect to SharePoint Online using this module with both Single Factor and Multifactor Authentication.

Connecting to SharePoint Online Using the PNP Module
To connect you need to be a SharePoint Online admin in order to manage things at the tenant level like, for example, creating your site collection, access user profiles, and so on. You can also simply be a site collection admin on a specific site collection if you only need to manage that site collection, and lastly, you need the URL of the site collection you want to manage or the URL of the SharePoint Online Admin Center if you want to manage tenant level settings. To connect with Single Factor Authentication you simply get the credential using the Get-Credential cmdlet, as we've learned before, and then you use the ConnectPnPOnline cmdlet, specify the URL of the site collection you want to connect to, and give it the credentials parameter where we give the variable, cred in this case, that has our credential. If you have Multifactor Authentication instead of passing it a credential you can use the UseWebLogin parameter, which will open up a prompt, and it will ask you for a username, password, and second authentication method.

Demo - Connecting to SharePoint Online Using the PowerShell PnP Cmdlets
Now that we've seen the theory, let's go to the lab and test it out in real-life. We are now in the lab environment, so let's connect to SharePoint Online using the PnP PowerShell cmdlet. I will first open PowerShell as an administrator, and then let's first of all connect with Single Factor Authentication, so I will get my credentials, so cred = Get-Credential, enter my vlad@globomantics. org, enter my password, and then I'll use the Connect-PnPOnline PowerShell cmdlet, give it the URL, which will be, let's say we'll connect to the SharePoint Online Admin Center, so really the admin part of it, so it'll be globomanticsorg-admin. sharepoint. com, and use the Credentials parameter and give it the cred credential that I just saved, and if everything goes well we will not have any messages. If we want to verify that it worked, let's say we'll run a Get- PnPSite, and we should see information about this current site collection. Awesome. Now let me actually first Disconnect-PnPOnline just so we're disconnected, clean this up, and let's connect using Multifactor Authentication. So I will just get the cmdlet I used earlier, however, instead of credential I will give it the UseWebLogin parameter, which will open up the browser where I can basically log in. So let me give it jeff. collins@globomantics. org, give it the password, and then it should ask me for my second method of authentication, my phone should get the text here in a few seconds. There we go, so let me enter the code, 675879, fix that typo, click on Verify, and if I got the right one, let's say I don't want to stay signed in, now I'm able to connect, and I should still be able to do a Get-PnPSite to verify that I am actually connected. There we go. So in this small demo we have managed to connect to SharePoint Online using the PnP PowerShell module using both Single Factor Authentication, as well as Multifactor Authentication. Now let's go back to the slides and learn how to use PowerShell to connect to Exchange Online.

Connect to Exchange Online with Single Factor Authentication
We have now covered SharePoint, so let's move on to connecting to Exchange Online. To connect to Exchange Online you need to be an Exchange Online admin, and if you do not have Multifactor Authentication that's about it. Don't need to download anything at all. First, getting the credential is done with the get-credential cmdlet we already learned. We then need to establish the connection. For Exchange Online we actually do a remote PowerShell session, so we will run the New-PSSession cmdlet, giving it the ConfigurationName, ConnectionUri, Credential, Authentication, and specifying the AllowRedirection switch. The ConnectionUri is almost always outlook. office365. com/powershell- liveid, except in two small exceptions, about which we'll talk about in just a few seconds. We will then import the remote session into our current session using the Import-PSSession cmdlet, and then we'll be able to run cmdlets against Exchange Online. The exceptions for the ConnectionUri is if you are in an Office 365 tenant operating by 21Vianet in China you would use the ConnectionUri specified here in the slides, or if you're in Office 365 Germany, which is a special type of tenant, you would also use a different ConnectionUri, which you can also see in the slides right now.

Demo - Connect to Exchange Online
Now that we've seen the theory let's go to the lab and see how we can connect to Exchange Online by using PowerShell. We are now back in the lab environment, so let's connect to Exchange Online using PowerShell. First of all, here in this file I have copied the PowerShell code from the slides. We first get our credential, then we create a New-PSSession, give it a ConfigurationName, ConnectionUri. I'm using the, I'll call it the most common one because my tenant is in Canada. I will then give it my Credential, Authentication Basic, and AllowRedirection. So let me copy this into the PowerShell. This should only take a few seconds, and then I'll do the Import- PSSession, and give it the session variable that we have just created, and as you see, this is when PowerShell is actually going to get that PowerShell module and import it into our current session using a temporary name. As you see if you want to, for example, see the cmdlets, see stuff in the module, this is the name of the temporary module that we have downloaded. So if, for example, we want to see all the cmdlets inside I could do a Get-Command -Module and copy the full name here, and I'll see all of the different PowerShell cmdlets that I can do. Just so we can test it, let's, for example, run a GetDistribution Group, and this should show me all of the different distribution groups inside my tenant. Awesome. So we have connected to Exchange Online using Single Factor Authentication. Now let's go back to the slides and learn how to connect to Exchange Online using Multifactor Authentication.

Connecting to Exchange Online with Multi Factor Authentication
Now that we've seen how to connect with Single Factor Authentication let's learn how to connect with Multifactor Authentication. Exchange Online really has a few different steps if you have Multifactor Authentication enabled. If your account is MFA enabled the first thing you will need to do is download the module from the Exchange Online Admin Center. You need to go to the Exchange Online Admin Center in the Hybrid tab, and then on the Exchange Online, and then you need to click the Configure button under the Exchange Online PowerShell module. Something that you need to be careful about, and is something that I was really surprised when I did it the first time, you need to use Internet Explorer in order to download the module. The way that Microsoft packaged the application, if you try to do it with Chrome or other browsers it'll actually throw the error that you see on the screen right now, so make sure that you use Internet Explorer when you download the module. Going to the PowerShell side of things, in order to connect with this new module we actually use a different cmdlet than without Multifactor Authentication. We will use the Connect-EXOPSSession and give it the -UserPrincipalName. This will open a pop-up window where we can enter the rest of our authentication information. If you are connecting to Exchange Online Germany with Multifactor Authentication, again, it's a bit different. You need to not only give it the UserPrincipalName, but also the ConnectionUri parameter, which you can see in the slides, as well as the AzureADAuthorizationEndpointUri parameter, which you can also see in the slides. So if you're in Office 365 Germany it's a bit different, but all the rest of the world you would use the first example that I showed you where you just run the Connect-EXOPSSession and give it only the UserPrincipalName.

Demo - Connecting to Exchange Online Using Multi Factor Authentication
Now that we've seen the theory, let's go to the lab and see how we can connect to Exchange Online with PowerShell with Multifactor Authentication enabled. We are now back in the lab, so let's connect to Exchange Online using Multifactor Authentication. The first thing we'll have to do, as we learned earlier, is to download the Exchange Online PowerShell module from the Office 365 Admin Center. I have already used Internet Explorer, as we talked about, to avoid the error, and I'm in the Exchange Admin Center. From here I will go to the Hybrid tab, and I will go click on Configure from here to configure the Exchange Online PowerShell module. Let me click on Configure. I will say okay, let's use IE, click on OK. It should start downloading an application that we can then click Install on, and it automatically opens PowerShell for us. Let me make this just a bit smaller, and let me actually try to change the font to make sure that everybody, even on the mobile devices, you can clearly see the PowerShell that we're writing. So now let's clean this up, and let's run Connect-EXO, so for Exchange Online, PSSession, and give it the UserPrincipalName, which will be jeff. collins@globomantics. org. I will then have a pop-up. Well, it will ask me first of all for my password, so let me put my password in here, and now it should ask me for my second method of authentication, which it texted me to my phone right away. So let me go back to my phone, let me go find the new text, and let's type the code 171090, and if everything goes well, if when I click on Verify it will log me in, and I'll be able to run cmdlets against my Exchange Online environment. Awesome. So again, as you see similar to the Single Factor Authentication it has imported temporary portion module, so if I do now Get-DistributionGroup I should be able to view all of the distribution groups inside my company. So this is it. In this demo we have seen how to download the Example Online PowerShell module and how to connect to Exchange Online using Multifactor Authentication.

Connecting to the Security and Compliance Center with Single Factor Authentication
Moving on from Exchange, the next one is the Office 365 Security and Compliance Center. To connect to the Office 365 Security and Compliance Center you need to first have the required permissions in order to access it, so either be an Office 365 Global Admin or have the organizational management role inside of the compliance center. Connection is done similar to Exchange Online when you only have single factor authentication enabled. You first get the credential, then you create the New-PSSession, you pass it the ConfigurationName, ConnectionUri, which as you see, it's a bit different than the one for Exchange, we give it a Credential, the Authentication parameter, and lastly, the AllowRedirection, and finally, we import the remote session into our current session, and we're able to run cmdlets against the Office 365 Security and Compliance Center. Again, the ConnectionUri is the same for almost everybody in the world except Office 365 Germany, which has a different ConnectionUri parameter. So for this Single Factor Authentication, if you want to connect to the Office 365 Security---

Demo - Connecting to the Security and Compliance Center
---and Compliance Center. That's it for the theory. Now let's go to the lab and connect to the Compliance Center, see how it's like in real-life with Single Factor Authentication. We are now back in the lab environment, so let's connect to the Office 365 Security and Compliance Center using PowerShell. The first thing I did is I have copied all of my cmdlets here, so first of all I will get my credential. Then we will create a New-PSSession with the ConfigurationName Microsoft. Exchange, ConnectionUri https://ps. compliance. protection. outlook. com, give it a Credential, Authentication, and AllowRedirection parameters. So let me open up PowerShell as an administrator. Cred = Get-Credential. Login. We'll give it my username and password, which is vlad@globomantics. org, and my password. I will then copy this just to save some time on typing it all, and after this is done I will write the Import-PSSession cmdlet and give it the session variable that I have just created. Similar to Exchange Online, this will now go and download a temporary PowerShell module on this computer, which includes the latest PowerShell cmdlets for the Compliance and Security Center. If I want to see all the cmdlets inside I can, for example, do a Get-Command -Module, copy the module name from here, and I will be able to see all of the different cmdlets that I can do using this module, and as you can see, there's quite a few of them. So this is about it. We have now connected to the Office 365 Security and Compliance Center with PowerShell using Single Factor Authentication. Now let's go back to the slides and learn how to connect using Multifactor Authentication.

Connecting to the Security and Compliance Center with Multi Factor Authentication
Similar to the other products we have seen today, connecting to the Office 365 Security and Compliance Center with Multifactor Authentication is a bit different. First of all, you need to actually have a module, but luckily, if you followed this module, all of it so far, it's the same module as Exchange Online. So from the Office 365 Admin Center you would go to the Exchange Online Admin Center, under the Hybrid category, and you would download the Exchange Online PowerShell Module using Internet Explorer, this way you don't have that beautiful error that we talked about a few clips ago. To connect to the Compliance Center with Multifactor Authentication you need to use the Connect-IPPSSession PowerShell cmdlet, and give it the UserPrincipalName. You'll then have a pop-up where it will ask you for your password, as well as the rest of the authentication information to securely connect you with MFA enabled. If again, you have a tenant in Office 365 Germany you need to give it a bit more parameters. You'll need to give it the ConnectionUri parameter, as you can see here in this slide, as well as the AzureADAuthorizationEndpointUri parameter, for which you can also see the link in the slides.

Demo - Connecting to the Office 365 Security and Compliance Center with MFA
Now that we know the theory, let's go to the lab and connect to the Office 365 Security and Compliance Center with Multifactor Authentication enabled. We are now back in the lab environment, so let's take a look at how to connect to the Office 365 Security and Compliance Center using Multifactor Authentication. The first thing that we need to have is, of course, the same module, the Microsoft Exchange Online PowerShell module, which we have already installed when we have connected to Exchange Online with Multifactor Authentication. Since we have already covered how to install it, I'm not going to go over it again. I will simply open it from my task menu. Let's just clean this up, and now in order to connect I'll use the Connect-IPPSSession PowerShell cmdlet, and give it the UserPrincipalName parameter, which is jeff. collins@globomantics. org. I will then have a pop-up, which will first ask me for the password, and then it will ask me for my second authentication method, which in this case, you see it has texted me a code on my mobile phone, so let me get it. It's 446055. Click on Verify, and if everything goes well it will have no error messages, and it will download a temporary PowerShell module similar to Exchange Online, and I am now connected. That is it. We have now connected to the Office 365 Security and Compliance Center with PowerShell and Using Multifactor Authentication. Now let's go back in the slides and learn how to connect to Skype for Business Online using PowerShell.

Connecting to Skype For Business Online
Next up on our list of Office 365 Services is Skype for Business Online. The Skype for Business Online module can be downloaded from the Microsoft Download Center. You can either search for Skype for Business Online Windows PowerShell module using your favorite search engine, or you can download the slides and copy the link to the Download Center directly from there. In order to connect and manage Skype for Business Online you, of course, need to be a Skype for Business Online admin or higher, such as an Office 365 Global Administrator. In order to connect to Skype for Business Online without Multifactor Authentication you first need to get a credential, then run the New-CsOnlineSession, and provide a Credential, and finally, add the remote session into our current session by using the Import-PSSession cmdlet, and that is it. If you have Multifactor Authentication enabled you don't need to create the credential variable because we cannot pass it. You can simply run the New-CsOnlineSession PowerShell cmdlet and give it only the username. A pop-up will appear where you can enter your password, as well as complete the login process with your second authentication method, and finally, you still have to import the PSSession in our current session by using the Import-PSSession PowerShell cmdlet, as you can see in the slides.

Demo - Connecting to Skype For Business Online
Now that we've seen the theory let's go to the lab, install the Skype for Business Online Module, and connect to Skype for Business Online using both Single Factor Authentication and Multifactor Authentication. We are now back in the lab environment, so let's connect to Skype for Business Online. The first thing I will have to do is download the Skype for Business Online PowerShell module from the Microsoft Download Center. I have already opened the URL from the slides here, but feel free to either copy the URL from the slides or simply search for Skype for Business Online, Windows PowerShell Module in your favorite search engine, and you should find it quite easily. I will click on Download, it'll take a few seconds. Let's directly run it. Of course, we have no choice but to accept to the license terms, and it is already completed. I will click Close on this, and I will also close Internet Explorer, since I don't need it anymore, and let me run PowerShell as an administrator. The first thing I will do is get my credential, so Get-Credential, give it my vlad@globomantics. org, give it my password, and then I will do Session = a New-CSOnlineSession, and just try to give this. You will see that sometimes, like in this case, it's not able to automatically import the module. So what we have to do is we have to manually import it. Let me open up the Windows Explorer, and we'll have to navigate to see program files, common files, Skype for Business Online modules, Skype Online Connector, and here is where we have the Windows PowerShell script module file. So what I will do inside of PowerShell, I'll first clean up the error and I'll run an Import-Module cmdlet and give it the pat. Over here it will ask me if I want to start the WinRM service, to which I will say Yes, and now I can run my Session = New-CsOnlineSession, give it a -Credentials parameter, the cred that we have just saved earlier, and after this is done I will run an Import-PSSession and give it a session variable that I have just created. That is it. I'm now able to run PowerShell cmdlets against Skype for Business Online, and we have used single factor authentication. Now let me actually close this, and let's connect using Multifactor Authentication. So let me run this as an administrator again. This time, since we're using Multifactor Authentication, I will not have to create my cred variable again, so let me actually first of all import the module. I still have the pat in my clipboard. Then I will do Session = New-CsOnlineSession, and I'll give it the UserPrincipalName which is jeff. collins@globomantics. org. I will then have a pop-up asking me for the password, and then it will ask me for my second authentication method, which, in this case, is a text message, so I'll enter the 735855. Verify. It should be able to connect and not give any error messages, and I'll then run an Import-PSSession, and give it the session variable that we have just created. It will get that temporary PowerShell module again, and we're now connected to Skype for Business Online using Multifactor Authentication. This is it. We have now managed to download the Skype for Business Online module, import it into PowerShell, as well as connect to Skype for Business Online using both Single Factor and Multifactor Authentication. Now let's go back to the slides and learn how to connect to Microsoft Teams with PowerShell.

Connecting to Microsoft Teams
We've now seen almost all the Office 365 services and there's only one left, which is Microsoft Teams. Microsoft Teams is really the latest Office 365 service to get a PowerShell module, so let's learn how to get it and how to connect. The Microsoft Teams PowerShell module is hosted on the PowerShell Gallery. We've already seen the prerequisites required to get modules from the PowerShell Gallery, so we will not go over them again. To install the module we need to run the Install-Module cmdlet and give it a name of the module, which is MicrosoftTeams, and that is it. To connect to Microsoft Teams with Single Factor Authentication we need to get our credentials, save them in a variable called cred, and then run the Connect-MicrosoftTeams PowerShell cmdlet, and give it the credential. If we have Multifactor Authentication enabled we would run the Connect-MicrosoftTeams PowerShell cmdlet and give it the AccountId parameter, then a pop-up will open where we'd enter our password, and provide the other methods of authentication. So that's about it for the theory, as this is pretty straightforward.

Demo - Connecting to Microsoft Teams
So now that we know the theory let's go to the lab and learn how to get the Microsoft Teams PowerShell module, how to connect with both Single and Multifactor Authentication enabled. We are now back in the lab for the last time in this module to download and install the Microsoft Teams PowerShell module. So let me go here. I have already opened the PowerShell Gallery and navigated to the Microsoft Teams Module page, so to install it, as you see, we simply have to copy the Install-Module, -Name MicrosoftTeams cmdlet. So open PowerShell as an administrator, copy this in here. It will probably ask me if I want to trust the repository, to which I will say yes, and after it's installed we can connect Microsoft Teams. First, let's get the credential, so we use Single Factor Authentication, solve the cred = Get-Credential, vlad@globomantics. org, and then I will give it my password, and I will Connect-MicrosoftTeams and give it the Credential cred. As you see, I have a few red errors here I probably when I give it my credential remember that it doesn't do any actual validation, so let me try that again. Cred = Get-Credential vlad@globalmantics. org. Give it my password, and then let's try again. Connect-MicrosoftTeams cred. MicrosoftTeams -Credential cred. There we go, and we are finally connected with the account vlad@globomantics. org, so we can run cmdlets such as Get-Team, and it will show me all of the Microsoft Teams that I have access to inside of my tenant. I will then run a Disconnect-MicrosoftTeams, so we disconnect from it, and to connect to the Multifactor Authentication I'll do Connect-MicrosoftTeams, and give it my AccountId, which is jeff. collins@globomantics. org. I will have a pop-up, which will ask me for the password, and then it will ask me for my second method of authentication, which, in this case, is a text message, and the code is 640789. Click on Verify, and if everything went okay I am now connected to MicrosoftTeams using Multifactor Authentication. So if I do Get-Team right now Jeff is not a member of any Microsoft Teams, so none are returned, but as you see in the previous message, we have successfully connected. So that is it for this demo and almost for this module. In this demo we have learned how to download and install the Microsoft Teams PowerShell module and we have connected to Microsoft Teams using both Single Factor Authentication, as well as Multifactor Authentication. We have now seen both in theory and in the lab how to connect to all Office 365 services. Let's now go back to the slides and finish off this module.

Module Conclusion
To finish off this module let's review what we have learned. This module was kind of a base start for all of the others where we have learned to connect to all of the Office 365 services with PowerShell using both normal authentication, as well as Multifactor Authentication. We have learned how to connect to Azure Active Directory, SharePoint Online using the Microsoft provided module, SharePoint Online using the Office 365 Dev PnP PowerShell Cmdlets, Exchange Online, the Office 365 Security and Compliance Center, Skype for Business Online, as well as Microsoft Teams. This has been a pretty long module, but it was really a required one in order to get you started with all of the rest of the course. In the next modules we'll start working on real-life scenarios for Office 365 where each module will be its own scenario, so let's get started.

Disabling Office 365 Services for Some or All Users
Introduction
Hello, and welcome to this PowerShell Playbook for Office 365. My name is Vlad Catrinescu, and I will be your instructor for this course. In this module we will learn how to disable Office 365 services for some or all the users inside your tenant with PowerShell. We'll first look at why this is useful. So why is it important for you to know how to do this with PowerShell? Afterwards, we'll look at the PowerShell script to do it, and finally, we'll look at some other tips and tricks which might come in useful depending on what client or how your organization is set up. So let's start with why is this useful? Why do you need to learn this? Microsoft is adding new services and functionality to Office 365 every month and that's a good thing because it makes sure that our organization is always using the latest technologies and advancements in Office 365; however, there are some apps that we might not want enabled in our organization, and there are multiple valid reasons for that. It can sometimes be because of compliance reasons. For example, not all Office 365 services are hosted inside of all the Office 365 datacenter regions. To give you a concrete example, at the time of this recording Yammer was only hosted in the United States, so some of my Canadian customers that had regulatory requirements to keep data in Canada had to turn it off. Another very valid reason might simply be that you need more time to train users before enabling it for the enterprise or you want to enable it department by department, so you kind of have a controlled rollout. So there's multiple valid reasons why when Microsoft ships a feature you might not want it enabled right away, and by feature I mean really a dedicated service and not a feature inside of a specific service. Unfortunately, we cannot control that. I mean whenever they ship. For example, here I have a very recent one which is Microsoft Forms, and usually when they enable them they will be like, hey, starting in 2 or 3 weeks this will be enabled for everybody. If we look at the Microsoft documentation on how to disable some services we need to go into a user's profile, go into the Licenses, and go and shut down that service. I mean, it's easy to do when you only want to do it for a single user, however, when you have to do it with multiple users for a whole department or for all the company it can really get impossible to do it by the user interface unless you hire an intern and that's all they do for a few weeks. Luckily, we can automate this by using PowerShell, and that's exactly what we will learn how to do in this module.

Disabling Office 365 Services
Now that we know the why, let's take a look at the scripts on how to disable Office 365 services by using PowerShell. The game plan for this is that first we need to know what subscriptions we have in our tenant, as well as what service plans we want to disable. After we know all of this we're going to be able to create our PowerShell script and apply the configuration to the selected users. For this module we'll only use the Azure Active Directory PowerShell module, and we have covered how to get it and how to connect to AzureAD in the Connect to Office 365 module part of this course, so I will not cover it again in here. First to discover the subscriptions that we have available we can use the Get-AzureADSubscribedSku PowerShell cmdlet. As you can see in this tenant I have quite a few licenses. The first one is the EnterprisePremium, which in normal terms we would talk about E5. I have a PowerApps license, and Enterprise Pack, which would be an E3, an Enterprise Premium without conferencing, and a conferencing plan. For this module we will play with the Enterprise Premium license, which is the first one that you see. After we know the license we need to get what are the service plans ID. In order to do that we need to use the Get-AzureADSubscribedSku PowerShell cmdlet, give it the object ID that we got earlier for the subscription that we want to see the service plan for, and we'll expand the property service plans. This will show me all the different individual services in that subscription. For example, now I know that if I want to disable Microsoft Forms I would save the ServicePlanId in a file somewhere as text, and we will use it in the PowerShell later. Now onto the fun stuff. Let's start applying the change to a single user. I would first get my user and save them into a variable called User with the Get-AzureADUser PowerShell cmdlet. I will then create a New-Object of type Microsoft. Open. AzureAD. Model. AssignedLicense, and save it in a variable called Sku. I will then specify the SkuId property of that object and give it the SkuId of my E5 license that I got earlier. I will then specify the DisabledPlans property of that same object, and I will give it the Ids of the services that I want to disable, which we got earlier. In this case, I'm giving it Ids for Yammer, which is the first one, as well as the Forms plan, which is the second Id. I then need to create another object and this time it is a Microsoft. Open. AzureAD. Model. AssignedLicenses. You'll see the difference is not big between the first object we created in this one, as the second one has an s at the end. If you would have multiple licenses that you want to assign to the user, let's say an E3 license plus a PowerApps Premium that's where you would add them both. Even if we only want to assign only one license, we still need to create both objects. Inside this object I will use the AddLicenses method and I will add my Sku object that I had created earlier, and lastly, I will use the Set-AzureADUserLicense to assign the licenses to this user, so I'll just set AzureADLicense, give it the ObjectId of the user, and the Licenses object I have just created. So that is it to assign it to a single user. If we want to assign it, let's say, to a department we will still need to create our Microsoft assigned licenses modules, in this case our Sku and Licenses variables, however, I could then say, Get-AzureADUser where the department is Research, and for all of those users Set-AzureADUserLicense -AssignedLicenses and give it the variable the Licenses that I had just created. So as you see, even for a large number of users we can quickly assign them a custom license in only one cmdlet.

Demo - Disabling Office 365 Services
Now that we've seen the theory let's go to the lab and see it all in action. We are now in the lab environment, so let's take a look at how to disable Office 365 services for some users. First of all, I have opened the Chrome over here and have already navigated to the Office 365 Compliance Center, and have searched for Jeff Collins, and if we look at Jeff Collins' licenses I'll go on Jeff Collins here, then I see that Jeff has an E5 license. If I go into the details I will see that, I will make this bigger, Jeff has an E5 license and everything is turned on except Mobile Device Management for Intune, which I cannot even turn on, so really all of the services inside of the E5 are currently turned on, and let's see how we can change that using PowerShell. I will close this for now, and we close this, and let's go to the PowerShell ISE here. I have already connected to Azure Active Directory, as we have learned in the Connect to Office 365 module, so I'll not cover it again here. The first thing that I will do is I will get my user, so I'll Get jeff. collins@globomantics. org, and save that user in a variable called User. I will then create a new object of type Microsoft. Open. AzureAD. Model. AssignedLicense, and save it in a variable called Sku. So let me run this as well. Then I will save my SkuId. Just to recap, let's take a look at in real-life how we can find out the Id of our different subscriptions. I will run simply the Get-AzureADSubscribedSku cmdlet, and this will show me all of the different subscriptions that I have inside of my tenant. I can first see the ObjectId, and the SkuPartNumber, and the SkuId afterwards. The most important one, if we look at the ObjectId is always made up of two parts. You first have the GUID of your tenant, so if I look at my tenant Id right now it's fa17dd8f and so on, underscore, and the SkuId of my license. You don't see the SkuId completely on the other side, but you can see the start of it. It's c7df27 in the ObjectId and the same thing in the SkuId, and if we look at the SkuPartNumber, and this is something that you really get used to as you work with multiple tenants with multiple clients, Enterprise Premium is an E5 license, Enterprise Pack is an E3 license, Enterprise Premium with no PSTN conference is the E5 without any PSTN conferencing, and the MCOPSTN2 is only the audio conferencing. For my demo what I will use is I will use the Enterprise Premium License, so I will use the c7df here, so I will save this SkuId inside the SkuId property of the Sku object we have just created. Next up, I have to get the service plan Ids of the different service plans that I want to disable, so I will run a Get-AzureADSubscribedSku, only select the Enterprise Premium license, so I'll give it the full ObjectId, and then I will Select-Object and expand the property servicePlans. Once I run it, it will show me all of the different services inside of the subscription, so if we look at it I have the user, I have the ProvisioningStatus, which is a success, and by the way, if we look at the only one that's PendingActivation it is the Intune, which I was not able to turn on earlier, and now we can see why. So we have the ProvisioningStatus, ServicePlanId, and ServicePlanName. Let's say that, for example, I want to disable ToDo and Planner. I will copy the ServicePlanId here. Oops, let me go back. I will copy the ServicePlanId here in here under Sku. DisabledPlans, so you see I'll take the 3f and so on, all of it, paste it as the first one inside my DisabledPlans property, and then I will go down all of the way to Yammer, which is here, YAMMER_ENTERPRISE, which is the 754783 and so on, which I have already copied here into my script. So let me run this part of the script as well. I will then create the New-Object of type almost the same thing, Microsoft. Open. AzureAD. Model. AssignedLicenses with the s at the end. Whoops, of course, if I select all of it it always works a lot better. There we go. I will then do Licenses and use the AddLicenses property and give it the Sku that we have created earlier, so let me run this, and if we actually look inside, if I look into my Sku variable now you will see that I have my Sku Id here, and I also have the DisabledPlans, so I can see all of them, and if I look in the Licenses variable I can see that I only see the AddLicenses property, so if I look inside of it inside the AddLicenses property I see the same details that I saw in the Sku. To finish this off I will set AzureADUserLicense, specify the ObjectId, which is the User variable we got earlier,. ObjectId, and give it the Licenses variable we have previously seen, so let me run this as well. Now let's see how it looks like in the user interface. Now usually in PowerShell this is done within a few seconds, but in the user interface it might take up until 30 seconds for it to refresh. Usually in your day-to-day life 30 seconds is really not a lot, however, when you're recording a demo, and the screen is currently recording refreshing for 30 seconds might be a lot, so let's hope that it worked pretty fast. I will open up the Enterprise E5, and it seems that everything worked. My To-Do here is now disabled, and if I scroll down Yammer Enterprise is now disabled as well. So this is how you can apply it to one single user. As we have seen in the slides, you can easily apply it to multiple users as well. You can, for example do here, let's say, Get-AzureADUser Where Department equals Research. You see I have multiple users, and then I could do Set-AzureADUserLicense, not give it the ObjectId, and give it the AssignedLicenses as we did before, give it the same license we have just created, and it will assign it to all of the users that we got earlier. So that is it for this demo. We have successfully assigned a license with a custom set of service plans, but now let's go back in the slides and take a look at some other tips and tricks and how to make sure that we apply this properly inside our tenant.

Other Tips and Tricks
Now that we have seen how to do it, let's take a look at some other tips and tricks or things you should know and watch out for. First of all, make sure you document the licenses that your company assigns before mass applying the change because not all of your users might be using the same license. Sometimes we might have like say, F1 for the Field workers, E3s for the Office workers, and E5s for the Executives. By documenting it all and knowing what department has what license or what the logic is behind the licensing you can create the PowerShell script that will assign the right licenses to the right people because you're able to code all of that logic easily inside of PowerShell. Also a good idea would be to assign licenses via PowerShell, so when new users join the company it will make sure that they have the right license right away with the correct services enabled. To finish off this module let's review what we have learned. Microsoft is adding new stuff to Office 365 every month, and that's a good thing because it makes sure that our organization is always using the latest and greatest tools and are being as productive as they can be, however, there are some apps that we might not want enabled for many valid reasons, for example, compliance, training, and so on. If you want to disable apps via the user interface, so via the Office 365 Admin Center, you will need to do multiple clicks for every user. However, in this module we have learned how to use PowerShell in order to do it quickly for either one user or multiple users at the same time. Something that you need to be careful about is make sure that you document your licenses before applying the change at scale. This way you're able to give the right licenses to the right people. Thank you very much for listening to this module, and I hope you found it informative.

Changing Display Name Format for All Users in Your Company
Module Introduction
Hello, and welcome to this PowerShell Playbook on Office 365. My name is Vlad Catrinescu, and I will be your instructor for this course. In this module we'll learn how to change the Display Name format for some or all users inside your company. We will first look at why is this useful and why it's important for you to learn this. Afterwards, we'll look at the PowerShell script to do it, and a few other tips, so we make sure that you have everything right the first time. Let's start by learning how this is useful, and why you need to learn this. You've probably seen this in your professional experience, but organization can grow quickly, either naturally by hiring people or through acquisitions, and every IT person has a different way of creating users. Sometimes people come and go, and you might end up having half the people in the organization with names like last name comma first name and the other half with first name space last name. This not only can look weird and maybe even unprofessional to external organizations that you're collaborating with, but it can also impact the way that users use and search for things in Office 365. You're starting to type the name of someone and then all of a sudden you're like, oops, I forgot that for this department I need to type it the other way around because they're not proposing it to me, and so on, so how do we fix this? Let's take a look at the PowerShell and how we can make sure that everybody uses this same naming convention.

Implementing a Name Format for Everyone Inside the Organization
Now that we have seen what the problem is, let's learn how to implement the same Display Name policy for everybody inside the organization with PowerShell. The first thing that we have to do is find the users that need their Display Name updated or those for who we have enough information to update their Display Name, and finally, apply the Display Name change. It's important to know that information can be changed in Office 365 only for Cloud Only users since Azure AD Connect, previously known as DirSync, synchronizes information one way from on-premises to Azure Active Directory in the cloud, so if you change that information in Office 365 it will get overwritten on the next update anyway. You'll be able to apply a similar logic of what we do in this module to your on-prem Active Directory, but of course, some different cmdlets will apply. In this module we will really focus about Cloud Only users. The first thing that we will have to do is check if any of our Office 365 users do not have a first name or a last name. If they don't have those properties we cannot really create the Display Name, so this will make it easy for us to quickly identify those users. The UserType equal Member part make sure that we only select users that are internal employees to the organization and not Office 365 guests inside our tenant. It's recommended that even for service accounts you have some information in the first name and last name, even if it's some basic information. So the PowerShell cmdlet, if we look at it, will get an AzureADUser to get all of the users in our tenant, and then will only show those where the Surname, which is the lastname, equals null, and the first name or the GivenName, which is the property is null, as well as they're a Member, and we're only going to show the UserPrincipalName and their current DisplayName. This way maybe by knowing their current DisplayName we can go in and manually fill the missing information. Okay, so now let's see how we actually set the user DisplayName in PowerShell. The first thing that I will do is get all of my Azure Active Directory users where the UserType is Member, so it's a user inside my organization and not an external guest. I will then run a foreach loop, and I'll say, foreach user, if the user actually comes from on-premises I will write a message saying that this user is synced from an on-premises Active Directory. It's ignored in the current script, else if it's a Cloud Only user. I will say that a NewDisplayName is the User. GivenName base User lastname or User. Surname. I will then put a Write-Host in again. You don't have to do the Write-Host if you don't want to. In your script you can log it to a file or something similar, but in this case we just put them to the screen to make it easier to consume. Then I will Write-Host just a message to the screen, which, of course, is optional, but I'll do it in this case. I'll say the UserPrincipalName, which is like saying vlad@globomantics. org will now be named and output a NewDisplayName, which will be Vlad Catrinescu, and I'll put the ForegroundColor Green, and lastly, I will do my Set-AzureADUser, give it the ObjectId of the user, so user, which is the variable I'm currently looping on that ObjectId, the DisplayName parameter, and giving it the new DisplayName variable that we created just a bit earlier. That's it. So this is how the script looks in theory.

Demo - Implementing a Name Format for Everyone Inside the Organization
Now let's go in the lab and test it out, and see what it looks like in a real tenant and real-life environment. We are now back in the lab environment, so let's look at how to change the Display Name format for some or all of the users inside our organization. First of all, I have already prepared the Office 365 Admin Center here where you see I have some accounts that are, for example, first name, last name, so Alex West, and some of them are in the last name comma first name display format. So let's look at how to fix it using PowerShell. I have already copied the script from the slides here in the PowerShell ISE, so let's re-review it together as a reminder before we put it on to practice. I will first get all of my users where the UserType is Member, so I will not get my external user as my guest, and save them into a variable called Users. I will then look through all of the users that I got before, and check if the user is DirSyncEnabled, which means the user is synced from Azure on-premises, which means I cannot change their properties in 365, I need to change it on-premises, so in this case, if the user is DirSyncEnabled I'll simply write Host where the UserPrincipalName, so the logging name of that user is synced from an on-premises AD, and the user is ignored in the current script, and I'll put that in Yellow. In the else, so if the user is a cloud account, so it's not DirSyncEnabled the NewDisplayName is the User. GivenName, space, User. Surname, and then I'll Write-Host the UserPrincipalName, so let's say vlad@globomantics. org. Current Display name is, and the current DisplayName, and it will be changed to the new DisplayName variable that we just got, and I will show this in green, and for now, just so I do a test run before, I have commented this, which is the Set-AzureADUser, so this is when we're actually modifying those user properties, giving it the ObjectId of the current user we're currently looping on, and giving it the NewDisplayName variable that we have just created. So let's run this first with the Set-AzureADUser commented, so the script will not actually do anything right now, but we will look at some of the results of what it will do. So if we look at, for example, the first one, Alex West is synced from an on-premises Active Directory and will be ignored in the current script. However, Ben currently display name, the current display name for Ben is King, Ben, and it will be changed to Ben King. Same thing for Collin James, which right now is James comma space Collin, and it will be changed. We then have a bunch of them that are actually from on-premises AD, and a few others here that are currently Collins, Jeff will be changed Jeff Collins, and so on, and if the user is already a cloud user, like Jonathan King here, which already has the right display name format that will not change at all. So now that we've seen that it will do a good job let me actually take out the comment here, save this script, let me clean this up, and let's run it. It will probably take a few more seconds to run. That was fast. It's already done. If I now go into Admin Center, click Refresh, just so we make sure it's updated, and we look at what happened, we see that Ben King now switched from King, Ben to Ben, Collin James as well, and let me find my oops, Jeff Collins here switched from Collins comma space Jeff to Jeff Collins so our script worked. Remember that instead if you want to add some logic or something like that you can always say Where UserType equals Member and Department equals Research if you want to apply it to a certain subset or something like that. So you now have the basic script, and by using PowerShell you can also add a lot more logic to your script in order to apply it to only a certain department or only users with a certain profile property. Now that we've seen how it also works in the demo, let's go back in the slides and finish up this module.

Conclusion
To finish off this module let's review what we have learned. In this module we have quickly looked at how different display name formats in your organization can not only look unprofessional to outside users, but also cause confusion and inconsistency in different Office 365 services, and we have learned how to quickly fix it by using PowerShell for Office 365. We have looked at how to know what accounts in Office 365 are Cloud only, and which ones are synced from an on-premises Active Directory and other ones synced over from on-premises to Azure AD need to be modified on-premises instead of in the cloud. Thank you for listening to this module, and I hope you found it informative.

Offboarding Users
Module Introduction
Hello, and welcome to this PowerShell Playbook on Office 365. My name is Vlad Catrinescu, and I'll be your instructor for this course. In this module we'll learn how to create a user offboarding script for Office 365. We'll first look at why is this useful, so why is it important for you to learn this? Afterwards, we'll look at the PowerShell script to do it, and lastly, other tips and tricks that you need to consider before implementing it into your organization. Let's start by learning, how is this useful and why you need to learn PowerShell to do this. While everyone usually prefers to talk about employee onboarding, unfortunately sometimes users also leave the organization, and when they do there are many things we might need to do in order to have a smooth offboarding process. Some things you might want to do first is, for example, block the user from being able to sign in again, sign the user off from all of their devices, forward new emails to the manager, set a company-approved out of office message, cancel the upcoming meetings organized by this user, this way they're not keeping meeting room hostage, and so on, remove the user from all the distribution lists because there's hopefully other people in this distribution lists that will be able to take the charge or take care of it from now on. Now that we have Office 365 Groups you're probably going to want to check if the user is an owner of that group, and if yes assign it maybe to somebody else, and remove them from existing Office 365 groups, and other things like, for example, sending the OneDrive for business information to the manager. This way the manager can check if there's any documents that are useful to the company that we might want to keep before it gets deleted. All of those tasks, if you look at them one by one, can be quite easy to do if you only want to do it for one or two users a month. However, if you're in a big organization with multiple users that can quit every week, well, it can take quite a lot of your time to do manual offboarding every time, and of course, if there is a layoff, which I mean, none of us wants to happen, but reality is that sometimes they do happen, and you could have dozens if not hundreds of users that you need to offboard during the same date. Doing it manually can be almost impossible, but if you have a script to offboard those users, not only you'll be able to do it a lot easier, but it will also bring consistency to your offboarding process, so you know that every time that a user is offboarded the same process is followed, it respects your company standards, and so on. So I think this is really something that every organization should have a proper offboarding script, so let's take a look at how we can build ours.

Offboarding a User In Office 365
Now that we've seen why it's important, let's learn how to offboard an Office 365 user with PowerShell. Since we have quite a lot of tasks we will really need to split this in a few steps. We'll first connect to all of the required services, and since we want to do quite a lot of things we will connect to SharePoint, Exchange, Azure AD, and OfficeDevPnP PowerShell. We will then do all of the required actions, and at the end we will send a nicely formatted HTML email to the manager. First of all, let's connect. I will not spend too much time on this, since we covered all of it in the Connect to Office 365 module earlier in this course. I will connect to Exchange, SharePoint, OfficeDevPnP, and for the OfficeDevPnP module we will connect to the admin site, since we need to get some information from the user profile, and lastly, to Azure Active Directory. Now we will initialize the variables. For this demo we will use a single user, however, once you have your own script you'll be able to automate it for multiple users using CSV or XML files as an input. I will then create a variable called User in which I will run the Get-AzureADUser cmdlet to save my user object. I will then get my Mailbox from Exchange and get the user's manager and save them all in variables. This, of course, assumes that your user profiles are well filled, and everybody has a manager. If that is not the case, you should add some error handling around it to make sure that something will be returned or to put a default value if that user has no manager. Lastly, I will do a here string which is the out of office reply approved by the company in HTML format that includes some information and an email to the manager. So now let's start the PowerShell cmdlets for the offboarding. The first thing I will do is I will block the user from signing in Office 365 anymore with the Set-AzureADUser PowerShell cmdlet and specifying the AccountEnabled property to false. Since the user might already have some sessions open on home computers or cell phones what I will do is I will force a disconnect of all the open sessions, which will take effect as soon as the user tries to navigate to another page or service in Office 365. I will run the Revoke-SPOUser cmdlet and then the Revoke-AzureAdUserAllRefreshToken PowerShell cmdlet, which will really make sure to sign the user out from everything. Even if the Revoke-SPOUserSession isn't a SharePoint cmdlet it actually takes effect across multiple Office 365 services. Next up is forwarding the emails to the manager. I'll run the Set-Mailbox PowerShell cmdlet, specify the ForwardingAddress parameter, and saying to forward it to the UserPrincipalName, which is also often the email in Office 365, and in the script again, I assumed that my company is using the same information for username and email address, and if this is not the case you will need to adapt it a bit for your specific scenario. I will then specify the DeliverToMailboxAndForward and set it to False. What this does is that a copy of the emails will not be saved in the disabled user's mailbox. Everything will be forwarded to the manager, and nothing kept in the old mailbox. Lastly, I will hide the disabled user from the global address list, so we keep it clean, and we don't have users that don't work for the company anymore in the global address list. We will then set the out of office. I'll run the Set-MailboxAutoReplyConfiguration PowerShell cmdlet, specify the Mailbox. Alias, and set both the External and InternalMessage properties to the OutOfOfficeBody variable we have created previously. If you wish, you can also have different messages between internal or external users, but for this case we will only use one. Lastly, I will set the AutoReplyState to Enabled so this activates the out of office replies. Next up, we'll cancel the meetings organized by this user, and we will use the Remove-CalendarEvents PowerShell cmdlet to do it. We will specify the Mailbox. Alias in the Identity parameter, then use the CancelOrganizedMeetings switch parameter, and then confirm False, so we don't get a confirmation prompt from PowerShell. Now we have to remove the user from the distribution groups. The first thing I will do is a cmdlet that will find me all of the distribution lists in which a user is a member. I'm first doing a Get-DistributionGroup, then adding a where Get-DistributionGroupMember contains the Username of the user. I will then look through all of the DistributionGroups I have gotten earlier, and remove the user by using the Remove-DistributionGroupMember PowerShell cmdlet. Next up, I will reassign Office 365 group ownership if needed. What I will do is I will do something very similar to the DistributionGroup cmdlet, but I will use the UnifiedGroup cmdlets instead, so find me all of the UnifiedGroups where you find a LinkType Owner that matches my user's mailbox. Alias, and save all of those groups in a variable called Office365GroupOwner, and then I will create an empty array for now with all of the NewManagerGroups. We will use this array in case our user is the only owner of a group. We will add the manager inside, but we want to keep them for documentation inside of the email later, just to give some extra alerts to the manager that they have been added to that group, and they need to do an action on it. Now let's take a look at how to loop and reassign the group ownership. I will look through all of my groups where the user is an owner, so for each group inside the variable we created earlier get me all of the owners, so Get-UnifiedGroupLinks where the LinkType is Owner, and save them in a variable called Owners. I will then put if Owners equals one, so if there is only one owner add my manager as an owner of that group, and for the interest of space I didn't add the manager as a member as well, but we will have to do it in a demo later because you cannot add an owner directly. You first need to add a user as a member and then as an owner, so we will do it in the demo after, but just wanted to specify that I did not include it right now just for space purposes. I will then add the GRP, so my group, inside the NewManagerGroups array that we had created earlier, and lastly, remove my user from the owners of that group. If there are more than one owners, so right now the if statement says if there's only one owner, which would be my user, if not, remove that user from the owners of the group because if it gets into the else it basically means that there are already other owners in that group that can take care of everything, so we don't need to add our manager anymore. We'll then do the same thing for members, so instead of using LinkType Owners we'll use LinkType Members and do the exact same thing as before. Again, simply change the link types and the variables, NewMemberGroup instead of NewOwnerGroup and so on. We will then get the OneDrive for business information. To get the OneDrive for business information we need to go in the user's profile with the Get-PnPUserProfileProperty cmdlet part of the OfficeDevPnP module and we'll select the PersonalUrl property and save it in a variable called OneDriveUrl. I will then run a Set-SPOUser cmdlet on the OneDriveUrl and set my Manager as a site collection administrator. This way I am sure that they have all the necessary rights to save, move, change all the files in that site collection. Lastly, I will send the email message to the manager about the user by using the Send-MailMessage PowerShell cmdlet. Every message for every organization will be different, so I don't have it in the slides because it takes so much space, but we will analyze the HTML that we will build in the demo, and you'll also have it as part of the course downloads if you want to use that to at least get started with your own message.

Demo - Offboarding an User In Office365
Now that we've seen the theory, let's go to the lab and look at this in real-life as well as see what each cmdlet does. We will really run it one-by-one, so you can see what impact each cmdlet has. We are now in the lab environment, so let's take a look at the user offboarding script. So, first of all, here I have prepared the Office 365 Admin Center where I'm logged in as Vlad, which is the global administrator, and I have also logged in Internet Explorer as Jeff Collins, so we can see the experience from the user that we are offboarding, so we can kind of look at it and see it in real-life, and lastly, I have already prepared the big script that we have looked at in the slides, put it all into the PowerShell ISE, so we can analyze it and look at what each part of it does. As I have mentioned in the slides, I have already connected to all of my services, and we have covered how to do this in the Connect to Office 365 module part of this course, so I will not cover it again. First thing that I will do is I will save my input, which is the Username variable, and I will then initialize my variable. So User is basically the AzureADUser object, the Mailbox is the mailbox of the user we are offboarding, the Manager variable is the manager of the user we are offboarding, and the OutOfOfficeBody is a here string, and an HTML version of the out of office message. So it says, Hello, please note I am not working for Globomantics anymore. Please contact Manager. DisplayName at Manager. UserPrincipalName for any questions. Thank you. So we will declare those. Of course, this means maybe if you want to run it in production some more try and catch just to properly handle errors, but for now we assume that the profile is filled well, so we will not add that find catch. So now I will block the user from signing in, so the user account will now be disabled if I actually go into Jeff Collins, and it might take some time for it to refresh in the user interface. You see that the Sign-in status it now says Sign-in blocked, however, Jeff here can probably still go into Documents, can still view things because Jeff is already signed in, and this is where the Disconnect From Existing Sessions comes in. I will run this part of the script, and now if everything worked well, if I try to go, let's say, to Outlook here it should disconnect me. If I try to go here, like say I want to go to my OneDrive, again, if everything goes well it should disconnect me again, and if I go and try to login again, so let's say I try to enter my password, it will tell me, your account has been locked, and contact your support person. So this way we are sure that the user cannot sign in any more, and they are also locked out of any sessions they currently have open. So now that this part is done we'll forward the emails to the manager, so I'll say Set-Mailbox on the Mailbox. Alias -ForwardingAddresses Manager. UserPrincipalName. Again, we assume in this script that the email address and the UserPrincipalName are the same, however, if in your organization it's not the same make sure to add the required logic. So ForwardingAddress goes to my Manager, DeliverToMailboxAndForward False, and I will also hide it from the address list, so I will run this part. I will then set the out of office reply, which is Set- MailboxAutoReplyConfiguration on the Mailbox. Alias and ExternalMessage is the OutOfOfficeBody that we have created earlier, and InternalMessage is also the same one. Again, if in your organization you want to have them different, you can have different messages, and that will set the AutoReplyState to Enabled this way. OutOfOffice is enabled without a schedule on. While this is running we'll also cancel the meetings organized by this user, so this way if the user has any meetings that they are organizers, maybe they have reserved some recurring meetings with meeting rooms, we don't want to keep those booked, so we will cancel those. While this is running, actually, let me go here back in my User. Let me click on Refresh, and once it refreshes, once I go into the Mail Settings let's see if it has refreshed yet, and I see that no, so we'll give it a few minutes. We will look back, but once you get a bit further in the script under Mail Settings we'll see the email forwarding, the automatic replies, the show in global address list. All of those properties will change, but remember that once you do it in PowerShell, even if it worked perfectly, it might take up 2, 3, 5 minutes for it to be refreshed in the user interface. So we'll go back in our scripts for now, and we will look at the DistributionGroups. So we will get all the DistributionGroups where this user is a member, and for each distribution group that we found we'll remove the user from those distribution groups. After that, while this is running, we will look at how to reassign the Office 365 Group Ownership. We will first get all of the Office 365 groups where this member is an owner, and we will create a new array called NewManagerGroups. I will then say foreach group in the groups that were my user I will then do a foreach group where my user is an owner. If there is only one owner in that group, add my manager as a member, then as an owner because we have to have that logic with unified groups. Store this group in a variable here, so we can reuse it later as part of the HTML email we sent to managers, and remove my user that I'm offboarding from both owners and members, and if there are other owners inside, so if there's more than one owner that means there's already somebody there that can make sure the group is still working and that has the permission to do everything, so I will only remove my user as an owner, and that's the only thing that I will do. So let me run this part as well, and let me run it here. Then we do the exact same thing for members. So get all of the unified groups where the LinkType is Members, so our user is a member of that group, create a new array. If there's only one member or less add our manager as a member, and remove our user. If there are other members we will simply remove our user that we're offboarding from that group since there are already other members that can continue the collaboration on there. So while this is still running I will actually go into Admin Center. Let's see if this has refreshed, and unfortunately, I cannot know when it refreshes, so we're going to have to keep trying and trying. Let me try something else. Let me try to do a bit more of a forced refresh. Refresh the whole Admin Center. Go back to Jeff, go into Mail Settings, and see if it's there. So you can see that email forwarding is now applied. If we look in the details it's all forwarded to vlad@globomantics. org, and there is no copy kept of the email in this mailbox. The automatic replies are on. If we look at the message it says, Hello, please note I'm not working for Globomantics anymore. Please contact Vlad Catrinescu vlad@globomantics. org for any questions. So that is good as well, and show in global address list is a no. So the settings that we talked about earlier worked perfectly, and now we had to run the Remove from Office 365 Groups membership, so let me run this part of the script as well, and while this is running we're going to look at the next pieces, which is first, get the OneDrive for Business Information, which is done with the PnP PowerShell module, so Get-PnPUserProfileProperty for our account and select the PersonalUrl, and then what we will do is Set-SPOUser, so set our Manager on the OneDriveUrl. PersonalUrl, so really the URL of the OneDrive for Business, and set our manager as a SiteCollectionAdmin on that Site collection. This way we are 100% sure that they have all of the rights necessary to save files, copy files, move files, delete files, and so on. So now let me run this. Let me go here. Save the OneDrive for Business Information, set the site collection administrator, and then we will build our HTML objects. So we haven't looked at those in the slides, but this is only using the objects that we have and putting it into nice HTML. So if there are distribution groups, so if there were any distribution groups where the user was a member of, and we have previously removed that user, we will say, okay, if there is any of them, DGHTML, so a new variable is first, the user has been removed from the following distribution list. Start an unorganized list with HTML tag. DGHTML += an li, so a list object, the PrimarySmtpAddress of that distribution list. After the foreach loop is done close the unorganized list and add a br. so a line break. So let me add this here. Then we do the same thing for the Office365GroupsOwner. If there was any groups that the user got removed from we will simply add them inside a nice list in the HTML. I will then forward the members to the exact same thing. Nothing really complicated in here. It's just a lot of work to make it look pretty at the end, and then I will say for the NewManagerGroup, which is the variable that we got for all of the places where our user was the only owner, and we have added our manager. So I'll say, okay, first of all, bold Attention Required. The user was the only owner of the following groups. Please verify if there is any content in this group that is still needed. Otherwise, archive the group as per normal procedure. Start an unorganized list, add all of the group PrimarySmtpAddresses of the ones that we have added our manager to, and then close it. We will then do the exact same thing for the members, if there are any groups where our user was the only member, and we have added our manager there instead. Then we will create a Subject variable, which is User Offboarding Complete for our UserPrincipalName, and then create a here string with the body. So I'll say, hello Manager. DisplayName. This is an automated email from IT to let you know that the account User. PrincipalName has been de-activated as per standard procedure. All of the emails have been forwarded to you, and then I'm putting all of the different HTML scripts that I had before, I'm putting them all here. Remember that if they're all empty, so if the user was not, let's say, alone in a group, it will never get in this if, so the variable will be empty, so nothing will be written. So those will only show up in the final body if there is any content in them. We will say that you have also been assigned ownership of the OneDrive for Business of the account. Please navigate to the following URL, OneDrive for business PersonalUrl, and save any important information within 30 days. If you have any questions, please contact the IT department. Thank you, and finally, Send the MailMessage to the Manager. In this case, I'm doing vlad@globomantics. org, but you could do it with a shared mailbox, which is it@globomantics. org or something else. Give it a Subject, the Body, which is the ManagerEmailBody out-string, use the BodyAsHtml switch parameter, smtpserver, usessl, Credential, and port 587. You really need to specify that for it to work. So now let me run this last part of our script. It already did it, so now let me go to my mailbox here as Vlad. Go to Outlook, and let's take a look at the result. You see that, first of all, I'm getting a bunch of different emails from the groups. This is because the script added Vlad to a lot of groups, so this is why I'm getting those emails as the manager, and then right away after I get my user offboarding complete for Jeff. Collins@globomantics. org. Hello Vlad Catrinescu. This is an automated email from IT to let you know that the account Jeff. Collins@globomantics. org has been deactivated. Those are all of the distributional lists where the user has been removed from. Those are all of the groups where the user was a member and got removed from the following groups, and now we have the attention Required in bold of all of the five groups for both owners and members where our user has been removed, they are the only one, and our manager got added, and you have also been assigned ownership of technology OneDrive for business, click on it, we should have full access on it without any problems, and save any important data within 30 days. So this is it. This was quite a long demo, but I wanted to show it to you all step-by-step what each action does instead of running it all, so you can really see what each cmdlet does in detail. Now that we've seen the demo, let's go back to the slides and look at some other tips and tricks to ensure that this is properly deployed in your organization.

Other Tips and Tricks
Before finishing I just want to share some other tips and tricks with you guys. First of all, I really hope that you guys liked what you saw in the demo and you found some parts that you can apply as part of your own offboarding process, but I'm aware that it was not 100% complete for your scenario, as every organization really has different requirements and demands. Something that I see often, and this is just one of the examples that I see often is that some people say, okay, we should only forward the emails to the manager. Some other organizations they create full out --- give full access to the manager to the mailbox. I've already been in organizations where they reset the user's password and they allow the manager to log in with that user's username and password, so they have access to everything. Every organization is different, and it will depend on your requirements and everything, but I really hope that the demo that we looked at gave you a bunch of ideas on how to do most of the things with PowerShell. Also, depending on your industry, country, and so on you might have different regulatory or legal requirements, so you might need to use the litigation hold functionality if you want to keep all the employees data for, let's say, for 7 years. This way you can put their mailbox on legal hold and save it for a long time. This is, again, something that you can add as part of your offboarding script with PowerShell. Also something which we did not do in this script is, first of all, remove the user's license. Office 365 is a per user per month subscription, so you probably want to remove that license for the user that is gone and assign it to somebody else or have it ready for a new employee that's going to join soon. Something to be aware of is that after removing the license some of the data, such as email, OneDrive for Business will be deleted after 30 days, so it's really important to plan everything properly. If you need to keep that user's data for longer put it under litigation hold or make sure that you give access to the manager to the OneDrive for Business, so they can copy any important documents, and so on. Data in shared locations, such as SharePoint is never deleted, so you do not need to worry about data in SharePoint, in team sites, and so on, and you can always use the litigation hold or Inactive Mailbox feature in order to keep this data for longer. You can even use third-party tools or whatever other means you have in order to keep this data longer. I won't get into this topic today, since this topic, such as how to keep data, how to comply with regulations, how to use litigation holds can really be a course on its own, but something that if you have compliance requirements to keep data for a long time it's really something that as an Office 365 admin you need to look into, and you need to learn how to do.

Conclusion
To finish off this module let's review what we have learned. Scripting an offboarding process is really important, as it will bring consistency to your organization, as well as save you time each time a user departs the company. We have actually looked at how to do quite a few tasks inside Office 365 that are usually common to every offboarding process. We have learned how to sign-off the user from old devices, how to block them from logging in anymore, we have looked at how to forward the new emails to the manager, how to set a company approved out of office message, how to cancel all the upcoming meetings, and to remove them from the distribution lists. We have also looked at how to play with Office 365 groups and reassign Office 365 Group Ownership when needed, remove from Office 365 Group membership, unless they're the only one, and how to get the OneDrive for Business Information, and how to send it all to the manager in a nicely formatted HTML email. Lastly, I hope that this gave you quite a few ideas on things you can do in your own organization as part of your own offboarding script, but remember, there's no two organizations that are the same, and you might have to build on it, you might have to modify some of the things, and that is perfectly fine. You can download this script from the course downloadable files from the Exercise file, and customize it to fit your business needs. Thank you very much for listening to this module, and I hope you found it informative.

Creating a Secret Office 365 Group
Module Introduction
Hello, and welcome to this PowerShell Playbook for Office 365. My name is Vlad Catrinescu, and I will be your instructor for this course. In this module we'll learn how to create the secret Office 365 Group. We'll first look at why this is useful and why it's important for you to learn this. Afterwards, we will look at the PowerShell script to do it, and finally, we'll look at some other tips and tricks, which might come in useful. Let's start by learning how this is useful and why you need to learn this. Something that a lot of admins do not know or expect is that Office 365 groups, even those that are set to be private, can actually be found by anyone in the organization. Not only can people find the name, which can be a bit awkward if they find one like Reorg 2020, but by default they can also see the members of the group. Sometimes organizations need to have truly secret groups, and the only way to do that is with PowerShell for Office 365.

Demo - Default Behavior of an Office 365 Group
Before looking at how to create this secret group let's go in the lab and let's take a look at the default behavior of a private Office 365 Group created by the user interface, so you can see what I mean. We are now in the lab, so let's take a look at the default behavior of a private Office 365 Group. So I will log over here with Vlad Catrinescu, and I will go to Outlook like a normal user, and I will create an Office 365 Group. Let me go into Groups here. Let me go to the bottom, and then I will go on Create. I will create a new group, and I'll call it My Secret Group, let's say, I will not add a description, and I will make sure to select the privacy, put it to private, and make it, let's see, Top Secret in the classification. Click on Create. This group, when it will get created, it'll only have me inside, and like I said, I will add somebody else. I will add Jeff Collins as a member, and then the group will be created, and I'll be redirected to the group. If we look inside, once it loads we will see the members at the top right, and it should only have two members, Vlad and Jeff over here. I will then log in as another user, and I just want to show you before to make sure. I will go to Admin, I will go to look at my users here, Active Users, and I will look for a user called Vanessa Le, so let me search for Vanes here, Vanessa Le. This user is only a normal user and no admin access. I just wanted to show you this, so you can see that the user role I tried this with doesn't have any global admin access. It's a simple user, as any user inside of the company. So now if I go into our Internet Explorer I am logged in as Vanessa Le, and I will go to Outlook, and let's say that I want to discover new groups. So what I will do, I will go into Discover here, and you will see that actually My Secret Group is now showing up even if My Secret Group is a private group, and even if Vanessa Le is not a member of that group, and it's not an admin, the Vanessa account can see the group. So this is the default behavior that I was talking to you about. I mean, something to look at is that if your company is using Office 365 Groups for, let's say, projects it's not that critical that everybody in the organization can see that there's multiple projects going on, even if they cannot access the information, they can see that they exist, and that is fine. However, if you're working on Reorg 2020 or Reorg 2021, let's say, and everybody sees that when they go to discover that might not be as fun. That's not something that we usually want people to see. So let me go to My Secret Group, see what do we see inside. Because this group is private, I'm not a member, I actually get the message that, hey, this group is private. To view its messages request to join the group, so I don't have access to the actual conversations or files or anything, however, something that I want you to look at in the top right is that even if I cannot see the contents I can see the members of the group, and if I click onto members I'm able to see who is an owner, who is a member, who is a guest, and everything. So again, if this was a project it's not that bad that everybody can see who is a member of the group, but this is a reorg. Imagine I'm Vanessa, and I see Reorg 2021, I see that all of the other managers are a part of it except two or three of them, including myself. That tells me right away that I'm about to lose my job. So this is something that we really don't want as an organization. We don't want all of the groups to be viewable publicly or maybe some of the private groups you want to, but not all of them, and maybe we certainly don't want everybody to see who is a member of private groups. Again, even if I'm not a member of that group I can actually invite others, so I can invite other people to this secret group, even if I'm not a member of it, and if I'm about to lose my job maybe I'm going to send this to everybody in the organization. Again, not something that we might want to have as a company. So this is the default behavior of groups. Even if they're private, everybody can see that they exist, and everybody can see who is a member, owner, and guest inside that group, and that's maybe a behavior that we don't always want. So let's go back to the slides and learn how to create a secret Office 365 Group with PowerShell.

Creating a Secret Office 365 Group with PowerShell
Now that we have seen how it is by default, let's learn how to create the secret Office 365 Group with PowerShell. To create a secret group it's really a two step process. First, you need to create the Office 365 Group with PowerShell, and specify a very important property, which is the Hidden Group Membership Property. The reason why I'm saying that is really important is that this can only be done at the creation of a group. You cannot change this property after the group is created. Afterwards, the second step is to hide the group from the Global Address List or Search. So if we look at a PowerShell to do it the first thing that I will do is I will create this prototypal inheritance Group with the UnifiedGroup cmdlet, DisplayName Reorg 2020, the Alias, EmailAddresses, AccessType Private, and now we use the HiddenGroupMembershipEnabled switch parameter. After that I cannot do it in only one cmdlet, so I really have to do it in two separate cmdlets. I'll run a Set-UnifiedGroup cmdlet, specify the identity, which is 0365Group-Reorg2020, and then I will specify the HiddenFromAddressListsEnabled parameter, and say true, so I want to enable it to be hidden from the address list and search. So this is the PowerShell to do it.

Demo - Creating a Secret Office 365 Group
Now that we've seen the theory let's go to the lab and try it out, so we can see what each parameter does and how it behaves in a real-life scenario. We are now back in the lab, so let's learn how to create this secret Office 365 Group via PowerShell. So, first of all, let me open the PowerShell ISE over here where I have the PowerShell script from the slides. So, as we have learned, we will first do a New-UnifiedGroup, give it a DisplayName Reorg2021, give it an Alias, give it an email address, AccessType Private. Oops, let me go back here. AccessType Private, and also give it the HiddenGroupMembershipEnabled switch parameter. So let me run this. I am already connected to Exchange Online PowerShell. Again, we have already learned how to do this in the Connect to Office 365 module of this course, so I'll not cover it, but all of those cmdlets are in the Exchange Online PowerShell module. So this group got created. However, the only thing we did so far is specify the HiddenGroupMembershipEnabled parameter. To show you the exact difference of what it does I have actually kept Internet Explorer open with Vanessa Le from the example before. So let me actually go back to Outlook, just so we refresh everything. I'll go to Outlook, I will go to the Discover Groups. You'll see that because we only hid the membership we still see both groups, so if I go to My Secret Group, which is the one we have created previously in the first demo of this module, we can see the members at the top right. However, if I go back to Discover and I look at the Reorg-2021 group we have just created you'll see that I can still find a group, but there's nothing at the top right anymore. So I cannot invite the other people to join. I cannot view the memberships. I cannot view the classification, so really there's a lot of information about the group that I'm not seeing anymore. Now the second part that we need to do to have a truly secret group is to hide it from search. To hide it I will use this Set-UnifiedGroup, give it the Identity, which is the Alias I got before, and use the HiddenFromAddressListsEnabled parameter and set it to true. So let me run this as well, and then what I will do is I will go back to Internet Explorer and I will just close this tab just because the Discovery tab sometimes skips a cache, so I just close the tab, reopen it, go back to Discover, and now I don't see the 2021 Reorg anymore. So, as you see, we cannot find it, so we have managed to truly create a secret group in Office 365 by using PowerShell. Now that we've learned how to do it let's go back to the slides and look at some other tips and tricks on how you can best implement this inside your organization.

Other Tips and Tricks
Before finishing I just want to share some other tips and tricks with you guys. If you want to, you can use PowerShell to quickly hide all of your existing private Office 365 groups from search with a single cmdlet, however, since hidden membership can only be applied when creating a new group that is, unfortunately, impossible to do. So how can we at least hide all of the private Office 365 Groups from search. You will have to first use the Get-UnifiedGroup cmdlet to get all of the groups, and then we will do a Where clause, and say Where AccessType is Private, do a pipe, and then we will do his Set- UnifiedGroup HiddenFromAddressListsEnabled True. So this way we will get all of the private Office 365 groups and change them to be hidden from search, so that's really one of the big advantages of PowerShell. One cmdlet can do the change on all of them. So finish off this module. Let's review what we have learned. We have first looked at the default behavior of Office 365 Groups, and we have seen how everybody can find it, and everybody can view its members on all the private groups created via the user interface. We have learned how to create the secret Office 365 Groups by using the HiddenGroupMembershipEnabled, and HiddenFromAddressListEnabled PowerShell parameters. Lastly, we have looked at a quick way with PowerShell where you can change all of your existing Office 365 groups, especially the private ones to not be visible via search. Thank you very much for listening to this module, and I hope that you found it informative.

Office 365 Group Governance: Only Allowing Select Users to Create an Office 365 Group
Module Introduction
Hello, and welcome to this PowerShell Playbook on Office 365. My name is Vlad Catrinescu, and I will be your instructor for this course. In this module we will learn how to only allow select users to create an Office 365 Group inside your organization. We'll first look at why is this useful, and why it's important for you to learn this, and how to do it with PowerShell, and afterwards, we will look at the PowerShell script on how to actually implement it. So let's start with why is this useful? By default, everybody in the organization can create an Office 365 Group, and this can bring governance chaos if not controlled properly. I've been to conferences, I have been talking to a lot of people, and I've already heard on numerous occasions where organizations have more Office 365 Groups than users inside of the company. I've also seen users create multiple Office 365 groups for the exact same project or for the exact same idea, and then realize, hey, somebody else created it, and of course, afterwards they send an email to IT and say, hey, can you guys please merge those groups, which it seems like an easy thing to do, but can be quite difficult because there is no tools provided by Microsoft or even third parties to migrate stuff like teams content, Microsoft Planner content, and so on. There's also a risk, I would say, with the number of different workloads that create an Office 365 group without the user being aware. In Office 365 if you create a modern team site, a plan in Planner, a channel in Stream, or a Microsoft team inside of Teams all of those create an Office 365 Group, so if a user goes to Planner and they're like, okay, I just need to have a Planner plan for a certain task that will create an Office 365 Group in the background, so that will create a mailbox, a SharePoint site, and everything. So it can really be, I'm not saying users are doing it on purpose, but even if they do it accidentally it's really hard to implement governance after the fact when you really have to do a clean-up. Luckily, Microsoft allows us to configure our tenant to only allow certain people to create Office 365 groups. By reducing the number of people who can create groups you can train the super users in your organization to understand the Groups concept and reduce the chance of Groups chaos or you can also set up a form and force all of the users inside of the organization to go through that form that has an approval workflow in the background, and will really make sure that every group that gets created goes through the proper process. Something you need to be aware about, however, is that this feature doesn't come for free. It requires you to have an Azure Active Directory Premium license for everybody in the organization that will be part of an Office 365 Group. Also, unfortunately, at least in my opinion, is that licenses for this feature are not yet enforced by PowerShell. What I mean by that is that even if you don't have the right licenses it will allow you to configure it, and then at the end of the month Microsoft will send you a report saying, hey, your users do not have the right licenses for this feature. You're not in compliance with you licenses, so make sure to check what licenses you have before, and also remember that licensing changes a lot, especially in Office 365. So even from the time that I'm recording this course, maybe Microsoft has changed the licensing for that feature, so if it's a feature you're interested in make sure to talk to your Microsoft licensing partner who are masters and really know how Microsoft licensing works.

Only Allowing Select Users to Create an Office 365 Group
Now that we have seen what the problem is, let's learn how to only allow select users to create Office 365 Groups with PowerShell. The first thing you'll have to do is to create a new security group or an Office 365 group we will use to basically say, this is the group that is allowed to create other Office 365 groups inside the organization. You can call it something like Group Creators or Group Allowed or something like that. It's up to you. After you create the group add all of the members inside that will have the privilege to create groups. Add them inside as at least members. In order to set up this configuration we will be using the AzureAD PowerShell module. For this course we will be using the Preview module since the cmdlets to configure this are only available in the preview, however, they will make it into the production module soon, so make sure to check out what the cmdlets are available in the production in the stable release before getting the preview. They might already be there. Also, in order to configure this setting we will be playing with the Active Directory settings object inside your Azure Active Directory. You can only have one of them of the type Office 365 Group per tenant, so the first thing that we will do is we will make sure that there's none existing already, since you might already have created one or another admin might have created one, so the first thing we'll do is we will check if there's already an existing one. So what we will do is we'll run the Get-AzureADDirectorySetting PowerShell cmdlet where the displayname equals Group. Unified, so this will really filter all of them. Then we'll show the Values of this object. If there's nothing that comes out it means that there is no Active Directory Settings object existing, so we will have to create a new one. If you need to create one you'd first create a variable that I have called SettingTemplate, in this example, and get the AzureADDirectorySettingTemplate where the DisplayName is Group-Unified, and after that we'll call the CreateDirectorySetting method that will create a new directory setting based on that template. Lastly, I will run the New-AzureADDirectorySetting PowerShell cmdlet, which will create it, and then we're going to be able to configure it. After I have the setting created or I already have the existing one, I will first get my AzureADGroup, which, in this case, is called Office 365 Group Creators. This is really my security group, which will be allowed to create new Office 365 Groups. I will then get my AzureADDirectorySetting object by filtering on the ones with the displayname Group. Unified, and then I will set the property EnableGroupCreation to False. What this will do, this will stop everybody right now from creating new Office 365 groups, however, I will also set the GroupCreationAllowedGroupId parameter with the ObjectId of the group that I go earlier. What this will now say to Azure Active Directory is that nobody is allowed to create Office 365 Groups inside my tenant, except people in that security group. Lastly, to apply the changes I will run the Set-AzureADDirectorySetting, give Id of the setting, and the new object that I have. This way it will get applied and saved as part of my Azure Active Directory settings. Please note that for the setting in the UI to be fully updated it might take 24 hours for it to be perfect. Some Office 365 applications are almost instant, while some of them really can take one or two days for it to be fully configured, so make sure that if it doesn't work right away give it at least a day before contacting Office 365 support. If your PowerShell settings are fine, but it's not reflected in all of the applications in the user interface give it at least 24 hours before contacting support because under that they will basically tell you to wait it out and check back the next day.

Demo - Only Allowing Select Users to Create a Team
Now that we know the theory let's go to the lab and configure who can create Office 365 groups inside your tenant with PowerShell. We are now in the lab, so let's learn how to configure who can create an Office 365 group. Let me show, first of all, what I have prepared for you guys. If I go into the Office 365 Admin Center I have already created a security group called Office 365 Group Creators. If we look inside the owners are Vlad Catrinescu, which is myself, and the three members are Jonathan King, Vanessa Le, and Vlad Catrinescu. If we look at the other brother tabs that I have open I have an email open here with Ben@globomantics. org, so really a user that is not part of the group, not part of the people That will be allowed to create groups, and then in Internet Explorer here I'm logged in as Jonathan, which Jonathan King was in the Office 365 Creator Group, so he's one of the users that will be able to create them. This way we have both users, and we will be able to look at the experience really on both sides of people that are allowed and people that are not allowed. So now let me minimize the browsers here, and let's go to PowerShell. I have prepared a script already from the slides. First thing that I will do is I will look to see if my AzureADDirectorySetting object already exists. I am already connected to Azure Active Directory using the Azure AD Preview module like I have talked in the slides, and again, I will not cover how to connect because we have covered all of this already in the Connect To Office 365 module. So it looks like the Setting values are empty, which means we do not have an AzureADDirectorySetting. The text is actually quite small for this script, so let me make it a bit bigger for you guys. So what I have to do is I'll first have to create my AzureADDirectorySetting. What we will do, as we have learned in the slides, I will first get the AzureADDirectorySettingTemplate with the displayname Group. Unified. I will run the CreateDirectorySetting method, and then I will create a new one with the template that we have provided. Now that it is created we can actually, if you want, we can rerun the same cmdlet as we did before to see if it exists, and now we actually will have results in the Setting values, and those will be all of the ones that are by default in Office 365. Great, so let me clean this up, and now let's configure our Setting. What I will first do is I will set the Setting to EnableGroupCreation False. So this will turn off GroupCreation for everybody, but I will override it with my Office 365 Groups creator security group. So I will first need to get the actual group Id or object Id of that group. So I'll run a Get-AzureADGroup, and use the SearchString parameter where the name includes Office 365 Group Creators, and save it in a variable called Group, and then I set the Setting, GroupCreationAllowedGroupId parameter to the Group ObjectId, and lastly, I will Set-AzureADDirectorySetting. The Id is the Setting id, and the DirectorySetting is the Setting with the new values that we have just updated. So let me run this as well. If we recheck it now, if we look at the Setting Values, and now I'll just make this bigger, we see right away that the EnabledGroupCreation is set to False, and we can quickly see the GroupCreationAllowedGroupId. Now let's take a look at what it looks like in the user interface. I'll try to do it right away, but we might have to pause the recording, and come back to it in a future clip because sometimes it's right away, sometimes it takes up to 24 hours for it to work, so let's try it right away, and see if everything is updated. Jonathan here should still be able to create a group, so I'll go create the group name. I will say, I should be able to create this. I know I'm really creative, but what do you want? I'll click on Create, and I shouldn't have a problem with Jonathan. Add members let me add Vlad. Just do a test, click on Add, and as you see, there was absolutely no problem. After this is done and it shows me the confirmation that the group has been created we will actually go and try it with Ben King. Okay, the group got successfully created with Jonathan, so let me close this, and actually let me minimize this, and let's go try it with Ben now. To put all of the chances on our side what I will do is I will close this window, let me refresh this, and let me go to Outlook again. Right now we still see the Create button over here. As time goes by the Create button will actually disappear, but let me try to just click it. Almost every time, even if the Create button is still visible, group creation will still fail because the technical limitation behind still applies. So if I try now I should not be able to create this. I try to create the group. Click on Create. We will see if this works, but most of the time it will fail instantly because of that setting, even if it's not visible in the UI. While this is done here let's actually also try it. In another tool let's go to, let's say, Planner. Let's see if that one is set up. Planner is over here, and we'll try to create a group from Planner. I don't know if you saw it at the top left. Let me try to refresh, see if we can see it again. You see there is a New Plan at the top left, which appears for people that can create groups, and I'll look at the top left, try to see it again. It's there. Then it detects that this user cannot create an Office 365 group, so it cannot create a plan, and it disappears. Back to my mailbox here. You see that it shows a pretty ugly error. It was not able to create the Office 365 group. Let me discard the group creation. Let me try to go to Outlook again. Maybe this time it has finally kicked in the user interface, and you saw it again, the Create button first shows up and disappears. I'll refresh it again. Try to look under the Discover, which I have highlighted on the screen right now. The Create Button appears for just a few seconds or a few milliseconds even, and then disappears because this user is not allowed to create groups anymore. So that means everything is working. The users that should not be able to create groups do not see the new group or the Create button anymore in both email, as well as Planner, and we can also test it in other Office 365 services. We can go to Microsoft Teams, for example, over here and when I try to create a new team, even if I see, let me skip this step, instead of showing me Create a team it tells me to join a team, which right now I do not see any. However, if I try to go with, let me go here with Jonathan, let me go to Microsoft Teams, it should show me instead of join a team, it should also allow me to create a Microsoft team. You can see the difference really in the messages. One of them showed join the team while the other one really says join or create the team because of the different permissions that we have, and again, it looks like it's the first time I'm running Microsoft teams on this account, so it doesn't seem to load properly right away, but there we go. Join or create a team with Jonathan King and join a team only with Ben. So great. In this demo we have looked at how to configure Office 365 to only allow select users to create an Office 365 group. Now let's go back to the slides and finish this module.

Conclusion
To finish off this module let's review what we have learned. In this module we have looked at how by default everybody in the organization can create an Office 365 group, and how this can bring governance chaos, especially that almost whatever you create in Office 365 those days, like a stream channel, a planner plan, a modern team site in SharePoint, we'll create an Office 365 group. We have learned how to use PowerShell to view or edit Azure AD Settings objects, and we have looked at what settings to change in order to control who can create Office 365 groups in your organization. We have also looked at a quick demo of what the user experience is in Office 365 after we configure the setting, and where will people get different messages, and where the new create button will practically disappear. Thank you for listening to this module, and I hope that you found it informative.

Office 365 Group Governance: Enforcing a Naming Policy and Blocked Words
Module Introduction
Hello, and welcome to this PowerShell Playbook on Office 365. My name is Vlad Catrinescu, and I will be your instructor for this course. In this module we'll learn how to enforce a naming policy and blocked words in Office 365 groups. We will first look at why is this useful? So why is it important for you to learn how to do this, and then we will look at the PowerShell script to do it. So let's start by learning on how is this useful? By default, Office 365 users can create Office 365 groups without any words limit. They can really use anything from CEO at the company, company. com, legal, payroll or similar. Since every Office 365 group creates a mailbox that shows up in the Global Address List other users can find it and then send emails to it by mistake, and this can actually leak sensitive information or maybe private information to people who shouldn't have access to it. Luckily, with the blocked words functionality we can mitigate that by entering some words that would be blocked, so users would not be able to create groups with those words inside. If we look what it looks like in this example here I have set legal as a blocked word, so when I try to create it from Planner I get an error. Same thing if I try to create it from Microsoft Teams or from Microsoft Stream. After setting the blocked words, anywhere you try to create an Office 365 group it'll stop you from doing it. Now let's talk about naming conventions. Naming conventions have been available before for distribution list, and they are now also available for Office 365 groups. For those of you who are not aware, naming conventions allow you to create the uniform and consistent way of naming your Office 365 groups, and it allows you to quickly identify the purpose of the group when you create reports and everything. Naming policies can be dynamic, meaning that you can use the creator's User Profile to enter some information inside the name, such as the creator's department, country, region, and so on, and this will be done automatically. Let's take a look at some examples. In those example here the naming policy that I had was GRP Department of the person who creates the group, the name of the group, and the country or region. So when somebody tries to create a group for the name PowerShell Book the actual name will be GRP Sales, because that's the department, PowerShell Book, which is the user's input, United States because that is the country, and again, it works all over your Office 365 tenant, so wherever people try to create groups it will work. Something you need to be aware about, however, is that this feature doesn't come for free. It requires you to have Azure Active Directory Premium for everybody in your organization that will be part of an Office 365 group. Also, something else to know is that licenses are not enforced by PowerShell. What I mean by that is that even if you don't have the right licenses it will allow you to configure it, but Microsoft will send the global administrator of the tenant a report every month of the users who shouldn't have used those features or who did not comply with your current licensing. The good news, however, is that if you have a test tenant that does not have Azure AD Premium you can always enable it, play with it so you understand it, and then disable it at the end of the week, and nothing will happen, and you'll still have gained the experience of being able to play with it in real-life. Also, as you know, Microsoft changes licensing a lot, especially in Office 365, so maybe by the time you listen to this course those features are now part of the free offering, so make sure that you check with your Microsoft licensing partner or on the Microsoft Licensing site, so you can see what are the latest features included in the licensing that you have. Some administrative roles, however, are exempt from those policies, and will be able to create Office 365 groups that contain blocked words or not following the organizations naming policies. Those roles are the following; the global admin, Partner Tier 1 and Tier 2 support, the user admin account, and the directory writer's role. At the time of recording this module, and it might have changed when you're actually listening to it today, the following services did not fully support naming conventions and blocked words. Those services are Dynamic CRM, School Data Sync, the Classroom App, Power BI, and the Azure AD portal. For the latest updates on support make sure you check the following link. Feel free to download the slides and simply click on it, so you can reach it faster.

Enforcing a Naming Policy and Blocked Words
Now that we've seen what the problem is, let's learn how to enforce a naming policy and blocked words for Office 365 groups in your tenant. Before even starting with a PowerShell and technical side, let's take a look at all of the things you need before opening up PowerShell. You'll first have to identify the list of blocked words that you want to block from your groups. Something I will tell you right away is that Microsoft already provides an option to block the most common inappropriate words from groups, so don't focus on those. Focus instead on words that have to do with your business or privacy requirements. You also need to identify a naming policy that makes sense for your organization, so think at what metadata or business information would be useful for your users to have in the group name. A small recommendation from my personal experience would be to make sure that you consult with multiple departments before implementing it. If you only want to control everything from the IT department the solution might not be adopted or people might stop using it if it doesn't answer their needs, so make sure you try to connect with them before to see what they would like, and what they would find useful in order to increase their adoption and productivity with the tool. In order to do the scripts that we will do in this module you need to have the AzureAD PowerShell module. For this module at the time of this recording the cmdlets were only available in the AzureAD preview PowerShell module, however, those cmdlets will make it in the production module sometime soon, so make sure to check if they exist in there yet or you might need to install the preview version of the module, as we have learned in the Connect to Office 365 module part of this course. In order to change the settings we'll need to create or modify an Active Directory settings object inside your Azure Active Directory. It's really important that you only have one AzureAD settings object for groups, so make sure to check if there's already one that might have been created before creating a new one, so you don't have a conflict over settings. So let's take a look at how to see if there's already one existing. To verify if there's already an existing Azure Active Directory settings object, and to see it's values run the Get-AzureADDirectorySetting cmdlet where the displayname is Group. Unified. You can then output the values of that setting in the PowerShell window. If there is nothing to show it means that there is no Settings object for the Office 365 groups in your tenant. If you need to create one you would first create a variable that I have called SettingTemplate, in this example, and get the AzureADDirectorySettingTemplate where the DisplayName is Group. Unified. I will then call the CreateDirectorySetting method, and lastly, I'll run the new AzureADDirectorySetting PowerShell cmdlet, and give it my template information to create a blank AzureADDirectorySetting using that template. After I have the settings created or it's already there we need to configure the setting. I will first get my AzureADDirectorySetting object by filtering on the one with the displayname Group. Unified. I will then set the PrefixSuffixNamingRequirement property to my naming convention. In this case, I will set it to GRP, which is fixed text, space Department, which I'll put between square brackets, which is a token meaning that this will be dynamic depending on the person who creates it. I will then add another space in the GroupName token, which is the input that the users enter, and lastly, the CountryOrRegion token, which is the country or region of the user that will create the group. I will then set the CustomBlockedWordsList to all of the words I want to block from GroupNames, in this case, CEP, Legal, Payroll, all of them separated by a comma. I will also enable, so I'll set to True the EnableMSStandardBlockedWords property. This is a list that is not public, so we do not have an extensive list of what is inside, but this will block the most common words that you should not use in the enterprise. I will let you try out or use your imagination to find some of them, but there is no list of what they all are, and lastly, I will update my Setting by using the Set-AzureADDirectorySetting PowerShell cmdlet, giving it the Id of the Setting, and overriding it with our new parameters. In the earlier example we have used Department and Country or Region, but you can also use Company, Office, StateOrProvince, and so on in order to add information that is valuable to you inside of your groups. Extension attributes and custom attributes are not currently supported inside group names for naming conventions, but you can see the link below or the link in the slides to see if this changes in the future or if there's other attributes that you can use as part of your naming convention. Please note that for the setting and user interface to be fully updated it might take up to 24 hours, so do not stress if the PowerShell values look fine, but the UI isn't okay right away. Some Office 365 apps will be faster than others, so if you try them all you can probably get a quicker answer if it has worked or not, but patience is important here for this scenario. Give it 24 hours before opening a support ticket to make sure that it will work fine.

Demo - Enforcing a Naming Policy and Blocked Words
Now that we know the theory let's go in the lab and test everything out. We are now in the lab environment, so let's take a look at how to enforce a naming policy, as well as blocked words. In the PowerShell ISE here I have already connected to Azure Active Directory, and I have prepared the script from the slides. The first thing I will do, we will look at the values of the existing AzureADDirectorySetting. Since there is already one that exists, as you see here, I'm not going to create a new one, and the three properties that we will change in this demo, as we have learned in the slides, are the CustomBlockedWordsList, the EnableMSStandardBlockedWords, and the PrefixSuffixNamingRequirement. So let's take a look at the PowerShell to change them. First of all, the PrefixSuffixNamingRequirement. We'll set it to GRP, which will be a static on all of the groups, then Department, which will be a dynamic token depending on the user that actually creates the group. The GroupName, which will be the input provided by the user, as well as the CountryOrRegion, which again, will be dynamic depending on the user that creates the group. We will then set the CustomBlockedWordsList property to the three words, CEO, Legal, and Payroll, so those are the three words that we will block from creating, and we will also enable the MSStandardBlockedWords list, which again, there's no public list of those words, but you can try them out and use your imagination. Those are the words that you shouldn't use in the enterprise anyway. So let me run this part, and finally, let me update the setting using the Set-AzureADDirectorySetting PowerShell cmdlet, give it the id of the Setting, and override it with our current changes that we have just done, and now if we want to make sure that it got updated I can run the first two lines of my PowerShell script again, and you can see that in the current AzureADDirectorySetting the CustomBlockedWordsList is CEO, Legal, and Payroll. The MSStandardBlockedWords is set to True, and the prefix and suffix naming requirement is GRP Department, GroupName, and then CountryOrRegion. This setting takes quite some time to actually update throughout the user interface, especially the prefix and suffix naming requirement, so what we will do is we will pause this recording, and we will come back in a few hours, well in a few seconds for you listening at home, and we will look at what the end results look like in Office 365.

Demo - User Experience In Office 365
We have now seen how to do it, and I have given it a few hours to actually apply, so now let's take a look at the user experience in Office 365. I am back in the virtual machine, so let me open up Internet Explorer where I'm still logged in as Jonathan King, one of the users that is allowed to create groups in our tenant. So first I will go create the group from Outlook. So let's wait for the Create button to appear. Let me click on Create, and let's take a look if I start to create one, let's say Project One, you see that the group name that I am inputting is project one, however the full name that it actually gets with our naming policy is GRP IT, which is the department of Jonathan, Project One Canada, which is the country that Jonathan has in his profile. So, as you can see, it really works well in Outlook. If you try to use one of the words that we have blocked it simply says, the name cannot contain legal, and again, as we've mentioned previously, let me discard this. Let's, for example, go to SharePoint. It works across Office 365 Services, so I'll try to create a new team site here. Call it Communication Site. Doesn't matter. You see that the site names, which is the GRP IT Communication Site Canada. So really, this works across Office 365 Services. Now that we have seen how to both set it up and what the user experience is like let's go back to the slides and finish this module.

Module Conclusion
To finish off this module let's review what we have learned. In Office 365 users can create Office 365 groups by default with either inappropriate words, as well as words that could cause confusion and potential privacy problems. In this module we have learned how to block certain words, as well as inappropriate words from our Office 365 groups, and we have also looked at Office 365 group naming conventions. Naming conventions have been around in distribution lists for a while, and we have a very similar functionality for our Office 365 groups. The naming convention allows us to have consistency in our tenants, as well as quickly identify the owners and purpose of Office 365 groups. Thank you for listening to this module, and I hope you found it informative.

Office 365 Group Governance: Adding Classifications to Your Office 365 Groups
Module Introduction
Hello, and welcome to this PowerShell playbook on Office 365. My name is Vlad Catrinescu, and I'll be your instructor for this course. In this module, we'll learn how to add classifications to our Office 365 groups. We'll first look at why is this useful, and why it's important for you to learn how to do this. Afterwards, we'll look at a PowerShell script to do it, both in theory and in a real-life demo. So, let's start with learning how is this useful and why do you need to learn this. Classifications can help organizations in multiple ways. Some example classifications can be public, secret, and top secret. When creating or modifying a group, users will be able to select the classification from a predefined list by the administrator. Classifications do not technically change anything in the Office 365 group, however, they are shown at the top of every Office 365 group and all of its connected services, such SharePoint, Microsoft Teams, Outlook, Stream, and so on. This helps with the user awareness because when the user is inside the group they will be able to see how sensitive that data is. Another cool thing is that you can get the classification of a group via PowerShell. This allows you to have different reports, or different frequencies, or even automatically apply to a group of a certain classification. Here are some examples of how the classification selection process first in Outlook, then in Stream, and now in Microsoft Teams, almost wherever you create the group you're able to select a classification for it. Something you need to be aware about, however, is that this feature doesn't come for free. It requires you to have an Azure Active Directory Premium license for everyone in your organization that'll be part of an Office 365 group. Also, those licenses are not enforced by PowerShell, meaning that even if you don't have that license, it will allow you to configure it, however, this is the advantage that it also allows you to configure it on a test tenant even if you don't have the license, allowing you to play with it, and maybe do a proof of concept of what it would look like. In a production tenant, Microsoft will send the global admins of the tenant a report of the users who do not comply every month, so it's important that you check with your subscription or billing administrator if you're not exactly sure what Azure and Office 365 licenses your organization has. Furthermore, as you know, especially with Office 365, Microsoft changes licensing a lot, so make sure that you check with your Microsoft licensing partner on what features are available for your license, and if you're allowed to use this before deploying it to production.

Setting Classifications in Office 365 Groups
Now that we've seen what they are, let's learn how to add classifications to our Office 365 groups by using PowerShell. The first thing you will have to do is identify the classifications that are appropriate to your business. In this course, I will use some standard ones such as restricted, confidential, secret, and top-secret, but it's a free text-field so you can put red, blue, yellow, or anything that you want. It's really up to your business requirements. You can also specify what is the default option for people to choose, so if somebody clicks next, next, next, what will they get. And, lastly, you can specify a description for each classification to explain users what each level is for. In order to be able to do all of the tasks in this module, you need to have and you need to connect to the AzureAD PowerShell module. At the time of this recording, we'll use the Preview module because the cmdlets needed are not in the Production module yet, however, they will make it in the Production module in the future, so make sure you follow the module page on PowerShell gallery to see if they're there yet. And, all of those settings are done in an Azure Active Directory settings object inside your AzureAD. It's really important that we only have one settings object for Office 365 groups, so the first thing that we will do is to check if there's already one existing, because another admin, or even yourself, might have created one in the past. So, before creating it, we'll learn how to view if there's already one in there. To verify if there's already an existing AzureAD settings object, and to see its values, run the Get-AzureADDirectorySetting cmdlet where the displayname is Group. Unified, and then we'll look at the Values property of that object. If there is nothing to show, it means that there is no settings object for Office 365 groups inside your tenant. If you need to create one, you'd first create the variable that I have called SettingTemplate in this example, and get the AzureADDirectorySettingTemplate where the display name is Group. Unified. I will then call the CreateDirectorySetting method, and I'll run the new AzureADDirectorySetting partial cmdlet, give it the template information, and this will create my settings object inside my tenant. After I have the setting created, or it's already there, we need to configure the settings. First of all, we'll save our settings object in a variable called Setting, and then we'll set the ClassificationList property to a comma-separated value of our different classifications. I can also set my default classification to one of the options above, in this case, I have set it to Confidential, and then I can set the descriptions. The format is first you insert the name of the classification. As you can see in blue, the first one I have, Restricted, then I have a colon, and then the description that I have in green, and then a comma before I have the next one, which is Confidential, and so on. Those are all examples from Wikipedia, so feel free to copy them for lab purposes, but make sure that you work with your business to have more adapted descriptions for your business, or for your production use. Lastly, I will use the Set-AzureADDirectorySetting PowerShell cmdlet to update the current settings with the changes that we just did. As the setting will only apply to new groups, you can use PowerShell and the Set-Unified PowerShell cmdlet specifying the identity of the group and the Classification parameter. Remember that the Set-Unified PowerShell cmdlet is part of the Exchange Online PowerShell module, so you'd also need to be connected to that module as well. Please note that for the setting and UI to be fully updated, it might take up to 24-hours. So, do not stress if everything looks fine in PowerShell but it's not reflected in the user interface as it does take some time for everything to be visible.

Demo - Setting Classifications for Office 365 Groups
Now that we know the theory, let's go in the lab and test it out. We are now in the lab environment, so let's learn how to set classifications for Office 365 groups. First of all, I will go to the ISE where I have prepared the scripts from the slide. I am already connected to Azure Active Directory, as we have learned, so first thing I will do is I will check if my AzureADDirectorySetting already exist. If we look inside, we've already been playing with it for the last few module, so it's already there. I will not create a new one. Since I already have it in the Setting variable, we will simply change the following properties, the ClassificationList, the DefaultClassification, and the ClassificationDescriptions. The ClassificationList will be a comma-separated list of all of the different classifications that I want my users to select from. I have Restricted, Confidential, Secret, and Top Secret. Let me run this. I will then set what will my DefaultClassification be. So, if somebody doesn't actually select one, what will it be by default. I'll set it to Confidential. Let me run this. And, lastly, the descriptions. I'll say Okay. If I'll go here, I first need to have the classification name, in this case, Restricted, colon, Restricted material would cause, and so on, all of the description. When it's done, comma, and we start all over again with the next classification. So, I will run this as well. And, finally, we will apply the setting with the Set-AzureADDirectorySetting partial cmdlet, give it the ID of the Setting, and the DirectorySetting over-rided with the new changes that we have just made. I'll run this as well. Let me clean this up, and let's rerun the first two lines, which will basically show us the settings that are currently in Office 365. It seems that everything has been applied, so I have my DefaultClassification here, my ClassificationDescriptions, and my ClassificationList over here. Now, let's go to Office 365, see if it already took effect, and, if not, we will pause this for a few hours for me, only a few seconds for you, and we will take a look at what it looks like. But, let's first try right away, let me go to Outlook. If it shows up, we're actually really lucky so far. It always took a few hours, but it's now worked it. But, it doesn't hurt to try, and, as you see, it's unfortunately not there yet. What I will do now is I will stop this clip, and we will be back in just a few seconds while I wait a few hours offline and wait for it to be fully applied so I can show you the final result in Office 365.

Demo - User Experience in Office 365
Now that we have seen how to do it and I have given it a few hours to actually apply, let's go back to the lab and look at how the user experience for the setting looks like. We are now in the lab environment, so let me open up Internet Explorer logged in as Jonathan King, and let me go and create a new group starting from Outlook. I'll go into Outlook into groups, I'll start creating a new one, and, as you see here, I have my classifications now. If I go and hover over the little information box, you see I have all of the classifications. It says classification allows our organization to protect data based on our policies and standards. Then, you have the descriptions that you, or us in this case, have set for this tenant. If I select it and I say, okay, ConfidentialGroup, I will then let it at, let's see, Private, make it Top Secret, let it in English, and click Create. It will take a few seconds to create. Let's not add anybody right now. We'll then see where do we see the classification. It takes a few seconds to load the first time, but, as you see here right by the Private group, we see that it has the Top Secret classification. Now, let me go to the SharePoint Home for a few seconds. I'll go to SharePoint. Let's say I want to create a group from the SharePoint side of things. I will go on Create site, select a Team site, and then in the Site name I'll call it Project X. You'll see that, again, I have a question, how sensitive is your data. The default is Confidential because that's the default classification that we have set. I can select Restricted, Secret, Top Secret, and if I click on the information box here, it shows me all of the different descriptions that I have set for them. If I go to specific site, let me close this, let's see if this one actually already got created or not. Looks like it did, and you can see right under the site name, Top Secret, right here. If I go to Documents, I will still see Top Secret at the top-right, so wherever I am in the different services for this Office 365 group. Let me go to Planner as well, I will now be able to see how sensitive is the information in that certain Office 365 group. Now, let's see, if I go to all of the plans here, I'll take the GRP IT Confidential Group Canada, again, I see Private and Top Secret. So, now we have looked at what the user experience is like when we apply classifications in Office 365. We have looked at it both at the creation, as well as when we consume the different services inside of our groups. Now, let's go back to the slides and finish this module.

Module Conclusion
To finish off this module, let's review what we have learned. In this module, we have reviewed what classifications are and why it's important to classify content since every group might have different compliance and security requirements. While classifications do not change anything technically on the groups, the classification is visible on all of the services of that group, raising user awareness about the sensitivity of its contents. Classification can be set or queried by PowerShell allowing you to set different reports or tasks depending on the classification assigned to that group. Thank you very much for listening to this module, and I hope you found it informative.

Office 365 Group Governance: Adding Usage Guidelines for Your Office 365 Groups
Module Introduction
Hello and welcome to this partial playbook on Office 365. My name is Vlad Catrinescu and I'll be your instructor for this course. In this module, we'll learn how to add usage guidelines to your Office 365 Groups. We'll first look at why is this useful and why it's important for you to learn this. Afterwards, we'll look at the partial script to do it, and a few other tips to make sure that everything is done properly. Let's start by learning how is this useful and why you need to learn this. There are two types of guidelines that we can add to our Office 365 groups. The first one being Internal guidelines. This will tell users what they can do or cannot do with Office 365 groups, and this can provide, for example, how to frequently ask questions and so on, which can help you reduce the number of support tickets and clean up in the future if people know how to use them properly. The second type of guidelines is the Guest Guidelines, which are guidelines that are sent to external users that get invited to your Office 365 groups. You can include all of the information you need about, for example, privacy policies, confidentiality agreements, and more. In this first picture, you can see a link to the group usage guidelines at the bottom of the group creation pane in Outlook on the Web, and on the second image you can see the bottom of an email sent to an external member. As you can see, there's a mention saying that you will get access to Office 365 resources from the organization name, in this case Learn PowerShell, and a link to the usage guidelines of the organization. Something that you need to be aware about, however, is that this feature doesn't come for free. It requires you to have Azure Active Directory Premium for everybody in your organization that'll be part of an Office 365 Group. Licenses, however, are not enforced, meaning that even if you don't have the right licenses, you will still be allowed to configure it and test it and Microsoft will send a report of users who do not comply with the licensing requirement at the end of every month to the global admins of the tenant. Make sure that you check with your Microsoft licensing partner because licensing in Office 365 changes a lot, and by the time you listen to this course, maybe the licensing for this feature has changed. One of the advantages, however, that the license is not enforced, is that if you have a lab environment where you don't have an Azure AD Premium 12, you can congfigure it, play with it, understand what it does, and then simply remove the feature afterwards, and you'll not have to pay a dime.

Adding Usage Guidelines to Office 365 Groups
Now that we have seen them and what they are and why it's important to have usage guidelines, let's learn how to do them with Power Shell. The first thing you'll have to do is, well, to create them. When you create your internal usage guidelines, you can host them on an internal site, such as your SharePoint online Intranet, or a policy site. You can either use a document, a SharePoint! Wiki, or really anything. For the guest usage guidelines, they need to be hosted on a location that can be accessed anonymously because users that are external don't have access to your SharePoint site, so make sure that they have a link that they can access anonymously. Here's an example of Microsoft's usage guidelines for Microsoft customers and partners that have access to their Office 365 Groups. I know the link is a bit long, but remember you can download the slides from the course materials so you can quickly either click on it or copy and paste it in your favorite browser. For this module we'll be playing with the AzureAD PowerShell module. At the time of recording this course the command links needed for what we'll be doing are all in the Preview module; however, make sure to check the production module as well. If the command links are there, they will be making their way to the production module, for sure. In order to configure the setting, we'll either create or modify an Azure Active Directory settings object inside AzureAD. Since we can only have one settings object for 365 Groups, it's important to check if there's already an existing one before creating a new one. Either yourself, maybe a long time ago or another admin might have already created it, so make sure to double check before, so you don't have conflicting settings. To verify if there's already an existing AzureAD settings object, run the Get-AzureADDirectorySetting commandlet where the display name is Group. Unified and output the Values on the screen. If you see the Values it means there's already one there and you can change it with your usage guidelines, as we'll learn in just a few seconds, and if not, it means that there is no AzureAD settings object for 365 Groups yet, so we'll have to create a new one. If you need to create a new one, you'd first create a variable here that I created a Setting Template and get the AzureAD Directory Setting Template with the display name Group. Unified. I will then call the Create Directory Setting method, and lastly, I'll run the new AzureAd Directory Setting and give it the Directory Setting template that I got earlier. Now that my settings are either already existing or created, we need to configure the setting. I'll first get my AzureAD Directory Setting object by filtering on the ones with the display name Group Unified and I will set the usage guidelines URL property, and this is the property to the internal usage guidelines to the URL of where they are stored. Then, I will set the Guest Usage Guidelines URL to the public URL or the public website where my Guest Usage Guidelines are stored. Lastly, I'll run the set AzureAD Directory setting partial commandlet to update the current settings with the changes that we just did. Please note that for the setting NUY to be fully updated, it might take up to 24 hours, so don't stress if the partial fittings are fine, but not the UI. Some applications apply faster than others, but give it a good 24 hours before opening any tickets with Microsoft as sometimes it does take the full 24 hours for it to apply.

Demo - Adding Usage Guidelines to Office 365 Groups
Now that we know the theory, let's go to the lab and add usage guidelines to Office 365 Groups. We are now back in Power Shell, so let's take a look at how to add usage guidelines to Office 365 Groups. I have already prepared a partial script in the partial ISC. So the first thing we will do as we have learned in the slides, we will check if there's already an AzureAd Security setting there that we can modify, if not, we create a new one. In this case, you see that we already have an existing AzureAd Directory setting for Office 365 Groups, so we'll simply modify the existing one. The properties that we need to modify are for the usage guidelines URL, which are the internal guidelines for your employees that they see when they create a group, or in the Edit Group menu. So, I will set this to a Wiki page inside my sherpet online, or my Intranet where everybody has access to it. Then, I have my Guest Usage Guidelines for my external users. Those I will actually have them on a public site at globalmantics. org/guestpolicy, as those need to be accessible on the Internet, because users would see them before they actually have access to my tenant. Oops, I didn't select the whole thing so it was missing the ending quote... there we go. And finally, I will update my AzureAD Security setting, giving it the ID, and overriding it with the new setting that we have just specified. And that is it. I will now go really quickly to try to see if those have already been applied, it usually takes a few hours for everything to be applied, but let's give it a try, see if it'll already works, if not I will pause the recording and I'll be back in only a few seconds for you guys, but maybe in a few hours for me giving it time to really apply. So, let me go here into Create and it's not there yet. It will usually show up under the language right under the email over here, that's where you'd see the link to them; as you see, again, it's not instant. Even if we go to Power Shell now and we select again the first two lines which basically simply go back to AzureAD Directory and show you the link to settings, we have our Usage Guidelines URL over here, and our Guest Usage Guidelines URL over here, which are properly set up, but it will take a few hours for everything to be visible inside Office 365. So, we'll be back in, again just a few seconds, and look at the result.

Demo - Office 365 User Experience
We have now seen how to do it and I have given it a few hours to actually apply, so let's go back to the lab and look at the user experience of the Usage Guidelines in Office 365. We are now back in the virtual machine, so let me open up Chrome over here, where I'm still logged in as Jonathan King. So, I'll go into Outlook, I will go create a new group, so let me click on Create, and you see at the bottom after the name, classification, everything, I have my Group Usage Guidelines that when I click on them, it'll bring me to the Sharepoint Policy page we have set. You can see that right now it's not really populated. I just wanted to set up a simple page, but you have them here. When I go into an existing group, so I'll go into the one we have created a few modules ago, I'll go into the Properties; if I go into the Edit group, at the end, I'll also see the Group Usage Guidelines. Now for the Guest Usage Guidelines, what I have done is I have actually, in this group, invited a few external guests, so if I go into the email that I have received... Here is the email, you see that "You have joined GRP IT Confidential Group Canada". If I go at the bottom of it, you see I have a warning. Well, not a warning, a message, "You'll be accessing Office 365 Resources from globalmantics. org, please refer to the Usage Guidelines from globalmanticsorg. " Now, if I copy this link, and I will paste inside of Google, you'll see that first I have a warning that I'll be redirected to guidelines managed by Globalmantics. Org and that it's not hosted by Microsoft. So, after this is done, it will try to forward me to the website that we have set. Right now, it's taking a lot of time because that website doesn't actually exist, so it's timing out on trying to reach it, you see that there. Globalmantics. org/guestpolices cannot be reached, but that's just because it doesn't exist, I just wanted to show you the normal behavior. So, that is it for this demo. We have now seen how to set up Usage Guidelines for both internal and external users, as well as what the user experience looks like for both internal and external users. That is it for this demo, now let's go back to the slides and finish this module.

Module Conclusion
To finish off this module let's review what we have learned. In this module, we have learned why Usage Guidelines are important, and why they can help users get the most out of Office 365. There are two types of guidelines that you can set. Internal Guidelines for our internal members or employees, which can be seen by users when creating, modifying, or viewing the properties of a group; as well as Guest Guidelines, which are included in the email with an external user a guest invited to your Office 365 Groups. Remember that's really important for those Guest Guidelines to be hosted on a publicly accessible site if you want them to be able to access it. Thank you very much for listening to this module and I hope you found it informative.

Hide a Column in Different SharePoint Online Forms
Module Introduction
Hello and welcome to this PowerShell Playbook on Office 365. My name is Vlad Catrinescu and I will be your instructor for this course. In this module we will learn how to hide columns in different SharePoint Online forms. We'll first look at why is this useful. Why is it important for you to learn how to do this and then we'll look at the PowerShell script on how to do it. So, let's start with How Is This Useful? Before starting to talk about that, let's first look at what are those SharePoint forms that I'm talking about. When you use a SharePoint list, there are three default forms. First, the New Item Form which you see when you try to create a new item. You then have the Edit Item Form which you see when you try to edit an existing item. And lastly, the View Item Form is when you simply view the details of an existing item. When would we want to hide certain fields from those forms? Well, let's a look at the following scenario. Let's say you have a list in SharePoint where the HR department enters in information for the new users that will soon join the company. Because you're a PowerShell pro, you have already created a PowerShell script that runs daily on that list, looks at the users to be created, and creates them for you. In order to look at what users you have to create, you have added a Processed field on that list so that when the PowerShell completes, it turns the column from No to Yes. So that the next time the script runs it doesn't try to recreate the same user. For an IT person, this works great because we understand, I mean, we're the ones that build that script, we understand how it works, so we will not turn it to on by default. However, for an HR person that might not be technically savvy or who just joined the company and doesn't know how all of this script works in the back, that field can be confusing because they might think that a process means maybe that we have entered them into the payroll or something that they have to say if they have did or not. So, when they look at that form the Processed field doesn't really make sense. Since it's not up to them to actually touch it, it adds no business value. So, why do we want to keep the Processed field in the New Item Form when it doesn't do anything? It just shows more fields on the list. And this is where using PowerShell we're able to hide them in order to make sure that your users only see the right fields at the right time. Let's learn how to do it.

Hiding a Column in Different SharePoint Online List Forms with PowerShell
Now, that we've seen the why, let's learn how to hide a column in different SharePoint Online forms with PowerShell for Office 365. For this module, we'll be using the OfficeDev PnP PowerShell cmdlets. As that's the only module to have cmdlets to manage field-level settings in SharePoint Online. We have learned to download and install this module in the Connect To Office 365 module of this course. The first thing we will have to do is get a Title, Internal Name, or ID of our field that want to hide. Sometimes, as you can see for the Processed case which I highlighted in green, the Internal Name and the Title are the same. However, sometimes users actually change the display name of the field after the creation. If we look at the Title, Internal Name which I have highlighted in red, we can see that the Internal Name is titled, where the actual Title or display name is EmployeeID. So, make sure you check it so you know what to key on when you get that field using PowerShell. After I have the field, there are three methods that I can use and they all accept the Boolean so true or false. The three methods are SetShowInDisplayForm, SetShowInEditForm, and SetShowInNewForm. Those are pretty self explanatory. If I want to hide the field from the new form, I would do SetShowInNewForm equal false. Let's take a look at PowerShell to do it. I will first run a Get-PnPField specify the -List "CreateUsers" and then do a Where {$_. Title -eq "Processed"} this way save my field in a variable called $ProcessedField. I will then use the SetShowInNewForm method on the $ProcessedField variable and give it a false because I want to hide that field in this new form. Lastly, I will run the update method on that field in order to save it, and run the Execute-PnPQuery cmdlet to commit the save to SharePoint Online.

Demo - Hiding a Column in Different SharePoint Online Forms
Now that we know the theory, let's go to the lab and see how it works in a real life scenario. We are now in the lab environment so let's take a look at how we can hide a column in different SharePoint Online forms. First of all, let me show you the form. I have already logged into SharePoint over here, into my globalmantics. org. sharepoint. com and have navigated to a list called AddDistributionList which is list that I use as an input for some of my automated scripts. If we look at the forms, especially the New Item form, you'll see that all of my fields, the Ticket number, Username, DistributionList, and Processed field are there. But I'm only using the Processed field for my script just to see which items I will treat and which ones I will not treat. This is useless for my business users, so this is the field that I will hide from the New Form. Let me click on cancel here and now let's go look at the PowerShell. I have already prepared the PowerShell script over here, so let's take a look at it step by step. The first thing I will do is let's run only the Get-PnPField part on the AddDistributionList list, so we can look at the different fields that we have. You will see that there's actually a lot of fields in here. This is because when you get the PnPField cmdlet, it will show you all of the visible fields as well as all of the hidden ones. This is a way where you can really see all of the properties, all of the fields of that list. The one we're looking for is the Processed is actually a bit higher and let me scroll back up. We can find it over here and we have both the Title or the Internal Name that we can use as part of our Where clause after. In this case, I'm using Where {$_ Title -eq "Processed"}. Let me actually run this part and then if I go into my Processed. Oops, let me write at the good place instead. If I go into my ProcessedField, SetShow, you will see the three methods that we have talked about. SetShowInDisplayForm, SetShowInEditForm, and SetShowInNewForm. Since in this example I actually want to hide it from the New Form, I will run SetShowInNewForm($false). This way we do not show it in the new form and I will then run an update to update that field's properties. Lastly, in order to apply the changes to SharePoint Online, I'll run an Invoke-PnPQuery cmdlet, which is actually does the same thing as the Execute-PnpQuery so you can use either one of them. I just wanted to show you both examples, one of them in the slides, one of them in the demo. They both do the exact same thing. Just in case you fall on any of them in sample scripts, it's better to know that they both do exactly the same thing. So, run the Invoke-PnPQuery cmdlet. I will then close the PowerShell, go back to my SharePoint site. Let me just refresh the page and now when I go to create a new item here, you see the Processed field is not there anymore. However, if I click on cancel, if I go to edit an existing item, so I go to Edit Item Form. The Processed field is there. If I go to the View Item Form, so if I go to view an item, the Processed field is there as well. If we want just as a sample to turn it back on, I could turn this from SetShowInNewForm($false) to SetShowInNewForm($true). Let me run all of it at once. I'll just change it back so I make sure I give you guys the right file. I will refresh this. Now I will click on New Item and now it appeared again. Using the SetShowInNewForm, SetShowInEditForm, and SetShowInDisplayForm and the true or false parameters, you can easily change where fields appear, in what form they appear, in order for them to really be useful for whatever business application you are using. This is it for this demo. We have looked at how to both hide and display a field or a column depending on how you want to call it, in one of the three SharePoint Online Forms. Now, let's go back to the slides and finish this module.

Conclusion
To finish off this module, let's review what we have learned. We have learned that a SharePoint list has three different forms. The New item Form, the Edit item Form, and the View item Form. By default, all of the forms show all of the fields in that list. However, with PowerShell you can customize the experience by only showing necessary columns in the right form which will make users happier and increase user adoption because there is no use showing fields that are not relevant to them. We have learned how to use the OfficeDevPnP PowerShell module to hide or display fields in the SharePoint forms and we have used the three main methods of a PnP field or of a SharePoint field. The SetShowInDisplayForm, SetShowInEditForm, and SetShowInNewForm. Thank you very much for listening to this module and I hope you found it informative.

Uploading Custom Sensitive Information Types to the Office 365 Compliance Center
Module Introduction
Hello, and welcome to this PowerShell Playbook on Office 365. My name is Vlad Catrinescu, and I will be your instructor for this course. In this module, we will learn how to upload custom sensitive information types in Office 365. We will first look at why is this is useful, and why it is important for you to learn this. Afterwards, we will look at the partial script to do it. As well as a few other tricks. Let's get started with how is this useful. Data has grown exponentially in the past years, and your business may now store a lot of sensitive information about your employees, partners, or clients. Such as employee IDs, patient numbers, if you're in the health industry, social security numbers, credit card numbers, passport numbers, and so on. While Office 365 is really a secure location to put them in, applying different policies around retention, sharing, and usage, can further increase the security of those information types. Microsoft provides built-in data loss prevention policies for the common sensitive types, such as: Social Security numbers, Driver License, Passport numbers, and so on. But of course, Microsoft cannot precreate one for your employee IDs because each company is unique. So they allow you to create your own rules. The rules are created in an XML file, and you can specify multiple ways for Office 365 to detect the sensitive information. Such as: a regular expression pattern, keywords, Proximity information, you can even have different configuration levels based on how much information is found, what is the proximity keywords to your pattern, and so on. And you can look into documents, emails, and everything. So why is this important? Why do we have a module on this? The reason we are having the module on this topic, is because custom sensitive information types cannot be uploaded via the user interface. They can only be uploaded via PowerShell. So really, the only way to use this feature in Office 365, is if you know how to use PowerShell to upload those information types. Something that will not cover part of this module, or course, is how to create the rule package XML file since DLP in Office 365 is part of a bigger, compliance focused, topic that could really be it's own course. We'll focus really in this module on how to manage the policies using PowerShell, and if you want to learn how to create the XML rule package, I have added a bunch of Microsoft links in here. I know that the URLs are all long, and really small on the slides, but remember that the easiest way for you to get those links is to download the slides from the course page site. And you'll be able to either click on them, or copy/paste them.

Upload Custom Sensitive Information Types with PowerShell
Now that we know why it's important, let's see how to upload custom sensitive information types in Office 365 with PowerShell. What you'll need to get started is first the Office 365 Compliance Center PowerShell Module. We have already covered how to get the module, and how to connect to the Office 365 Compliance Center. and the connecting to Office 365 Module, earlier in this course, So I will not be covering this again in this module. You also need to have the organization management role in the Office 365 Compliance Center, or higher, in order to be able to do this. And lastly, you need to have the XML Rule Pack you want to upload. And if you don't have any, and you want to try it out in a test tenant, you can use this sample that we'll use in this course. I will make sure to include it in the downloadable files part of the course downloads. To upload sensitive information types, we'll use the New-DlpSensitiveInformationType rule package PowerShell cmdlet. The New-DlpSensitiveInformationTypeRulePackage partial cmdlet does not have too many parameters. We only need to pass the FileData parameter, which will be a get content of our XML file. And we need to specify the byte encoding, and that's about it. Something else that can be really useful is exporting an XML file of the current rules in your tenant. This can be useful if you want to see the rules, or even copy an existing one, and tweak it in order to build a new one. I will first create a variable called ExistingRules, and Get-DlpSensitiveInformationTypeRulePackage, in PowerShell, in order to save them in that variable. I will then run a set content partial commandlet, give it a path to a folder, give it the byte encoding, and the value will be the existing rules variable. And only the SerializedClassificationRuleCollection property Before we head into the demo, know that for SharePoint and for OneDrive for Business, the DLP engine uses the search crawler to identify sensitive information. Office 365 allows you to manually request a reindex on a site, list, or library. However, in some cases, especially as you get started, or if you have a lot of different site collections, as well as OneDrive for Business takes for every user, it might be complicated to request a reindex manually on every site collection. What you can do is contact Office 365 Support, explain to them the fact that you have uploaded multiple DLP policies and you want them to apply on your tenant as soon as possible. And you will like to have a full crawl. They will do it on the backend. This will reindex everything, and apply your policies.

Demo - Upload a Custom Sensitive Information Type
Now that we know the theory, let's go to the lab, and upload some custom sensitive information type in Office 365 with PowerShell. We are now in the demo environment, so let's learn how to upload the custom sensitive information type rule package. First of all, over here in the partial IC, I have already connected to the Office 365 Compliance Center. So what I will do is I will run the NewDlpSensitiveInformationTypeRulePackage, as we have looked in the slides, give it the full data parameter, and get the content from C:\Pluralsight\M12 employee ID rule pack XML with the byte encoding. So let me run this, it should tell me that it has been uploaded. And give me a little bit of information such as: variant name, the localized name, the publisher, and if it's encrypted or not. So from an uploading point of view, this is it. However, so far, it doesn't actually do anything inside your tenant. So, even it's a bit outside of the scope of this module, let's take a look at how to use it, and how we consider it work. Let me minimize the PowerShell, and let me go to the Office 365 Security and Compliance Center, where I'm logged in as a Global Administrator. I'll go into Data Loss Prevention, into policies, and you'll see that I will not see any existing policies. So I won't create a new one, I will just create a custom policy. Click on next, give it a name, tell it Globomantics Custom Employee ID, click on next, choose locations. Let's choose that it applies to Exchange and OneDrive and SharePoint. And then I need to select the Sensitive Information Type, and when do I want to apply it. So here you must select at least one classification type. I will click on edit, and here it tells me that the group must contain at least one Sensitive Information Type, or one label, so click on Sensitive Information Types, click on add over here, and I will search for our Employee ID. And here you can see the custom one that we just uploaded. Employee ID by Publisher Globomantics, which is our public one. So I will click on "Add", click on "Done" now, and let's change the accuracy from minimum 70, let's change it to minimum 60, just to make it easier to trigger part of our test. Click on "OK", let me click on "Next. " Review my settings, let's show the policy tips, send an incident report by email when there is one of them. And click on "Next", let's turn it on right away. And this should be it. We've already seen that upload of our Sensitive Information Type has worked because we now can see it when creating a new DLP policy. So this is really what I wanted to show you. This is where you actually use it. Now as you see we've actually skipped a lot of the settings. What I wanted to focus on is that you can view the employee ID here when we look in the policy. You can see the Custom Sensitive Information Type that we have uploaded, and it allows it to create the different type of Compliance Policies that you want to create inside of Office 365. So, this is it for this demo. In this demo we have look at how to use PowerShell to upload Custom Sensitive Information Type, and the Office 365 Compliance Center, that you can later use to create compliance and data loss prevention policies inside your Office 365 tenant. Now let's go back to the slides and finish this module.

Module Conclusion
To finish off this module, let's review what we have learned. Data has grown exponentially in the past years. And your business may now store a lot of sensitive information about your employees, partners, or clients. While Office 365 is a secure platform out of the box, it allows you to add even more security around sensitive information types. Office 365 provides built in data loss prevention policies for the common ones, such as: social security numbers, driver licenses, passport numbers, and so on. And it also allows you to create your own rules for your own custom sensitive information types, which is done in an XML file, and can only be uploaded to Office 365 with PowerShell. We have looked at how to use the New-DlpSensitiveInformationTypeRulePackage partial commandlet, in order to upload the new rule package to your Office 365 tenant, and also some of the considerations to look at for content crawling. As well as how to export our existing rules into a file. Thank you for listening to this module, and I hope you found it informative.

Disabling Giphy in All Your Microsoft Teams
Module Introduction
Hello and welcome to this PowerShell Playbook on Office 365. My name is Vlad Catrinescu and I will be your instructor for this course. In the module, we will learn how to disable giphy and even memes in your Microsoft Teams. We will first look at why this is useful and why it's important for you to learn how to do this with PowerShell. And afterwards, we will take a look at the PowerShell script in order to implement it. Let's start by learning how this is useful and why you need to learn this. The way communicate has changed and we use emojis, pictures, gifs to communicate with our friends and family in our personal lives on Facebook, Messenger, Whatsapp and other platforms that you might be using. Microsoft Teams which is one of the newest big products inside of Office 365, brings instant chat to the enterprise and instant messaging to the enterprise. And so far it seems to be a lot more modern and a lot more adapted for teams than Skype for Business. Microsoft Teams, by default, allows users to use gifs and emojis to express themselves which can be great but do you always want this enabled? So why would we want to disable it? Sometimes, some audiences or some discussions can be more serious and everybody can interpret emojis or gifs differently. If you have a really serious subject such as a layoff or something that impacts the whole company, you really want to be on the same page and make sure that everybody understands everything and somebody doesn't do a joke that can be interpreted badly by certain people of that group. And there's actually multiple court cases that you can read. I posted some of them here on the slides that the whole court case depended on the judge's interpretation of the gif or of the emoji inside a text message or inside of an email. So really, there is actually quite a few cases where people have sued and the decision was made based on the emoji used so it may seem more like a joke, but it can be really serious in some cases. In this module, we'll be talking about gifs as an example. However, you can use the same logic of scripting that you can apply to other Microsoft Team settings such as allowing users to delete or edit messages, allowing users to mention the full channel, and so on.

Disable Giphy in All Your Microsoft Teams
Now that we know the reason, let's learn how we can disable giphy in all of your Microsoft Teams with PowerShell. You'll first need to connect to Microsoft Teams for this module as we have learned in the Connect to Office 365 module, part of this course. And we will also be looking at some extra possibilities that have to do with Office 365 groups so the Exchange Online module, while not domain topic as this module. If you want to do all the samples, you will also need to connect to that. And again, we have learned how to get that module and connect in the Connect to Office 365 module. As a note, this module has been recorded with a better version of the Microsoft Teams PowerShell Module version 0. 9. 1 to be more exact. This version contains one big limitation which is that you can only manage the Microsoft Teams that you're currently a member of. So if you want to be able to manage all of the Microsoft Teams in your organization, you need to be an owner of all the Office 365 groups in your organization which I know is less than optimal, but it's a current limitation of the better module. Microsoft does plan to change that and add that functionality in the near future, but make sure to check the Microsoft Teams PowerShell Module page on the PowerShell gallery so you can see the latest releases and the latest features of this module. Now, let's take a look at the PowerShell. I'll first run a Get-Team to get all of my Microsoft Teams and save those in a variable. I will then look for all of them, do a try and catch, and I will try to set a team fun settings which is the name of the command-let. Pass it the group ID which is Team. groupID. Set AllowGiphy to false as well as AllowStickersAndMemes to false. And lastly, I will catch my error message in the the catch and display it if it fails. But you can also do some filtering if you want to apply this a bit more intelligently, let's say, with some condition and stuff like that. As you know, every Microsoft Team is a member of an Office 365 group. So if you look through all of your teams or groups, there is a way to link them, and this is done by the group ID of the Microsoft Team which matches the external directory object ID of the unified group. By knowing the link between those, they helps us to do things on Teams depending on conditions in Office 365 groups or vice versa. For example, let's take a look at how to change the giphy settings for Microsoft Teams only if the Office 365 group assigned to it are of a certain classification. I'll first get all of my Microsoft Teams as we did previously. Look through each one of them and then get the classification of the group with a Get-UnifiedGroup command-let and in the identity space defining the group ID. In this case, we do not need to specify exactly the property because the external directory object ID is a valid parameter for the identity field. So I don't need to specify which one I'm looking for, already works in the identity. I will then do an if statement and say if the classification is "Secret" or "Top Secret", change the fun settings to not allow stickers and memes, and also change the messaging settings to disable message editing and deleting by users. This is another example where once we know the logic on how to play your Microsoft Teams, we're able to change multiple settings.

Demo - Disable Giphy in All Your Microsoft Teams
So now that we know the theory, let's go to the lab and test it all out. We are now back in the lab environment, so let's take a look at how to disable the fun settings in Microsoft Teams. First of all, I have opened Teams here in the browser, and let's take a look at some of the settings that are by default. So if I look for the Private Group first, let's say, I will go to Manage Team. When I go to Settings and I look at the Fun Stuff category, you will see that giphy is enabled with a Moderate content filter, stickers and memes are enabled, allow memes to be uploaded, everything is enabled by default. And that is on all of the Microsoft Teams. Now, let's take a look at the partials for that we have in order to change this on all of them. We'll open the PowerShell I see here, where I have already prepared a script that we have looked at in the slides. I first run a Teams = Get-Team. I have already connected to Microsoft Teams using PowerShell. And I will not cover it again because we have covered it in details in the Connect to Office 365 module part of this course. The first thing I'll do is I'll do Teams = Get-Team. So I'll save all of the teams that I can manage in the Teams variable. Now we see for each team in Teams, try to set the team fun settings. The group ID is Team. GroupID, AllowGiphy to false, AllowStickersandMemes to false and AllowCustomMemes to false. And if something goes wrong, catch the error. And first of all, show me the team display name in yellow. And after that, show me the error message in yellow. So I'll run the script. It should only take a few seconds to run. Now that it's done, let's go to the Microsoft Team to see how it looks. I'll go back in the browser, go to the Private Groups, Manage Team. And if I go to the Settings, to the Fun Stuff, you'll see that everything is now disabled. And as a user, when I try to go in the General channel, I don't see the gif option anymore here. So it applied right away. That is it for playing with the fun settings and changing the fun settings for all of the groups at once. Remember that this logic can actually be applied to all of the Microsoft Teams Settings. And remember that you can also use logic that depends on your Office 365 groups as we looked in the slides in order to add more conditional or more logic to when you want to apply certain changes. Now that we've seen the demo, let's go back in the slides and finish out this module.

Module Conclusion
To finish off the module, let's review what we have learned. Today, instead of just using text, we use emojis, pictures, memes, gifs to communicate in our personal lives. And this is also coming in to our business lives as instant chat tools are making their way to the enterprise. The problem is that in some context, not everybody can understand in the same and some scenarios, some discussions or information with a certain sensitivity, it's better to remain on topic and everybody understanding the same thing. By using PowerShell, you can apply a change to multiple Microsoft Teams in a single script, by using different patterns or logic, depending on the properties of the team or of the Office 365 group associated with it. We have mostly looked at the fun settings parameters in this module, but you can change any team property based on that logic, since now you know how to reach Microsoft Teams with PowerShell, as well as how to match them with the respective Office 365 groups. Thank you very much for listening to this module. And I hope you found it informative.

Creating a Report of External SharePoint Online Users
Module Introduction
Hello and welcome to this PowerShell Playbook for Office 365. My name is Vlad Catrinescu, and I will be your instructor for this course. In this module, we will learn how to create a report of external SharePoint Online users. We'll first look at why and how is this useful and why it is important for you to learn this. We'll then look at the PowerShell script to do it, and finally we'll look at some other tips and tricks which will come in useful as you try to implement this in your organization. Let's start by learning how this is useful and why you need to learn this. One of the amazing features in SharePoint Online is how easy it is to collaborate with external users. Before, with on-premises, it was a real pain to get people access to your SharePoint sites. But now it's really super easy. Any user with member status or higher can invite other users to the site, and if you allow external users in your site, they can also invite other external users. As an administrators, your job is really to allow users to be productive, all while keeping the company secure and respecting all of the compliance and regulation laws that you are subject to. By being able to create a variety of reports to see who has access to what in your tenant, you're really able to achieve both of those tasks, meaning that you allow users to be productive all while making sure that they're being secure and keeping an eye on what they're doing to make sure that you also respect your security and compliance duties as well.

Returning More Than 50 Users with PowerShell
Now that we know the why, let's take a look at the PowerShell script to do it. The main PowerShell command that we will use is Get-SPOExternalUser, which returns the external users in your tenant. Looks simple, but of course there's some details we need to be very careful about so we know how to use it properly. One of those details is really that the Get-SPOExternalUser cmdlet can only return 50 users at a time. Some organizations that have been in Office 365 for a while or done work for a lot of external users might hit a limit for the default cmdlet if they run it without anything else, and then you would not have the full picture on your tenant. So how do we get more than 50 external users? The first thing, I will do a try and catch as well as a for loop. Inside my for loop I will use a variable called $i, and I will say, for $i=0, no max for $i, $i+=50. Where does that $i come from? After inside my for loop, I will use the Get-SPOExternalUser command, give it a page size 50 which is my maximum, and my position parameter will be $i. So what this will do it, the first time that we run the loop will be Get-SPOExternalUser page size 50, position 0. So getting the first 50 users from 0 to 50. The next time it runs, it will be from position 50 and getting the next 50 users. The next time it runs, from 100 and getting the next 50. Then I also have the error action stop. So the error action stop will make sure that no users are returned at all, it will actually exit the for loop and go into catch, where at the moment I don't really have anything. All of those users that I get with the Get-SPOExternalUser cmdlet, I'm saving them in a variable called $ExternalUsers. As you see, not really creative, but gets the job done. At the end of the script I will output all of the external users to the screen. Since this is such a base for all of the rest of our PowerShell scripts.

Demo - Returning More Than 50 External Users
Let's go to the lab right away and see how we can return more than 50 external users with PowerShell. We are now in the lab enviroment, so let's learn how to get more than 50 external users with PowerShell. So I will go here in the PowerShell ISE, where I have already prepared the scripts as well as connected to SharePoint Online. As we have learned in the connect to Office 365 module, part of this course. To review what we have learned in the slides, I first have a try and catch over here. Inside the try I have my for loop. So for the for loop, we are saying for $i=0, no max to $i, $i+=50. I will become the position parameter of our Get-SPOExternalUSer. Since we are limited to a page size of 50, position becomes the parameter we're going to play with in order to make sure we have all of them. So on the first loop starting from position 0, it will get 50 users. It will then go to position 50 and get the next 50, then 100 and get the next 50 and so on. So Get-SPOExternalUser, page size 50, position $i. For this example I'll use this site collection inside my own company tenant, which I know has more than 50 external users, and if it fails, if nothing is return, we will stop it. This way it goes into the catch statement, in which so far I have nothing, but you can add stuff if you want. And all of these external users will get stored in an $ExternalUsers variable. At the end of the script we'll do an $ExternalUsers. Count, which will show us how many users we actually got inside that site collection. So, it's already done, and that site collection has 144 external users. So as you see, once we know the recipe, getting more than 50 external users in PowerShell for SharePoint Online is quite easy. Now, let's go back to the slides and take a look at the other reports that we can create with PowerShell for SharePoint Online.

External User Reports
Now that we know how to return more than 50 users, let's look at the reports. We will first look at how to show all of the external users grouped per site collection. We will then look at all of the external users added in the last 30 days. And finally, all of the external users that accepted our invite, but with a different email than the ones we invited them with. So let's start with an external users per site collection report. I will first run the Get-SPOSite cmdlet to get all of the site collections in my tenant. I will then run a foreach to look through each site collection and declare a variable called $ExternalUsers = $null. I will then then run a for loop very similar to what we've seen before, just that in this one I will specify the site URL parameter, so we only get the external users for that specific site collection. I will then run an if statement, and say okay, if there have been any external users returned in that site collection, show me the site URL and show me the DisplayName, EMail, AcceptedAs, WhenCreated, and InvitedBy properties of those external users as a table on the screen. This will show them to us on the screen. We can also change the script really quickly to export it to CSV. First I will do the same thing as in the previous example where I will get all my site collections, look through each one of them, and do a for loop to look through 50 at a time so I make sure that I get all of my users in that specific site collection. I will the do a $ExternalUsers += Get-SPOExternalUser into site, but only select the DisplayName, EMail, AcceptedAs, and the custom property named URL with the expression being the site URL word correctly and the name URL. This way I have all of the information in the CSV file and each external users that is found also has the URL where it was found directly in the same line in the CSV file. By having all of this information in the CSV, I can then do reporting, filtering, do everything that I want. At the end of the script, I will simply export information to CSV file called ExternalUsersPerSc. csv and say that I don't want to have the type information. Now let's take a look at the second report which is a bit simpler, and it's to show us the external users added in the tenant in the last 30 days. This can come in quite useful if you want to do monthly reports of what's happening in your tenant and see who got added. This one is really similar to our first for loop that we saw when we had all of the users and really helped return more than 50. However, we add a where clause, and we say where the WhenCreated property is greater than today, add days minus 30. So, where the user has been added in the last 30 days, and then we can show that users on the screen, export them to a CSV file or really do whatever we want with them. Finally, the last report that I will show you that will come in useful is to see what users have accepted your invitation with a different email than what they were invited with. Let me tell you how this is useful. Let's say I need to collaborate with John Smith from Pluralsight, and I invite John with his work email address, which is jsmith@Pluralsight. com. If as an admin you didn't change your default tenant settings, John Smith could accept the invite but log in with his personal email address, which is johnny123@hotmail. com. This means that in the future, even if John Smith leaves Pluralsight, because he is logging in with his personal email address he could still log into our tenant because he still has access to the email address that has access to our tenant. So we definitely need to keep an eye on those accounts and make sure that the users are still working with the company when we have invited them there. To see those users, we would use the Get-SPOExternalUser cmdlet and then probably the longest PowerShell parameter that I've ever seen, which is, - ShowOnlyUsersWithAcceptingAccountNotMatchInvitedAccount $true. And for the interest of space on this slide, you'd also need to put this in a for loop to get more than 50 users. Right now if you only run what I show you on the slide you'd only get a single user, so you'd still need to put this in the for loop that we saw, and we will do that in the demo, but I wanted to keep more space to show you the parameters on the slides.

Demo - External User Reports
Talking about the lab, now that we saw the theory, let's go to the lab and look at the three reports we looked at in the slides, try them out, and see the results in real life. We are now back in the lab environment, so let's take a look at the three report we talked about in the slides. First of all, I have prepared them in the PowerShell ISE over here, so the first one we will look at is the external user per site collection. Since this one takes quite a bit to run I will just start it right away, and as it runs we will look at the script. So the first thing I do, I will get all of SharePoint Online collections with the Get-SPOSite PowerShell cmdlet, limit all, and save them in the $SiteCollections variable. I will then look for each site in my site collections, try the same look kind of that we looked at before for $i=0 no max for $i, $i+=50, and we'll use the $i for our position parameter so we can get more than 50. And what we have did is we have used the SiteURL parameter and give it the $site. url, and the site is the varibale that we are looking on. In the select, if I scroll to the end of the cmdlet here, I am selecting the users' DisplayName, Email, AcceptedAs, WhenCreated, Invitedby, and lastly I'm creating a custom expression with the name URL and the expression being $site. url. Going back to the beginning, the last thing I will do is at the end of my script I will export all of the results to a CSV file at C:\Pluralsight\M14 for module 14, ExternalUsersPerSC. csv, and NoTypeInformation. Not let's take a look at the actual CSV file, it has saved it here, let me open it and that's okay, it doesn't matter, let me show you all of the columns properly here, the WhenCreated, Invitedby, URL, and everything. So now we really have all of our information in a simple to use format. I can then use Excel features like the filter here, well let me go back here. And let's say I want to filter by everybody who has access to this site collection let's say. Or let me take one here, let me take the root site collection filter and now I can easily see everybody who has access to it, I can filter by user instead, by Invitedby, and so on. So saving this in a CSV file really gives us a lot of flexibility. Now let's take a look at the second one, I'm not going to save this. Let's go back into the ISE and the first thing I will do before I forget, I will set my external users to null, since I'm using the same variables I want to make sure that there is no overlay and it always shows the right results. For the external users in the last 30 days, we use the same kind of script as we did to get more than 50 users, so the for loop and catch. However, I will add the where WhenCreated is greater than get-date, so today, minus 30. So this really will only show us the users added in the last 30 days. So let me run this, should be really fast, and here we go. We see that this account has been added in the last 30 days. You can always play around with it and say for example, seven days instead of 30, depending really on how often you want to run this report. Now let me clean this up and let's take a look at our last report, which is invited but the user accepted the invitation with another account than the one they got invited with. So I'll start running it right away as we covered in the slides, the only PowerShell parameter that we have to give for this one is ShowOnlyUserswithAcceptingAccountNotMatchInvitedAccount $true, and this will show me users like this one, where the user got invited with the email cmvlad@hotmail. com, however, they accepted as vladcatrinescu@hotmail. com. Another example here, the user got invited with cvlad@outlook. com, however the user accepted as, v. catrinescu@apressmedia. com. So this really allows us to see users that haven't accepted it with the same account as they got invited with and this can cause security problems down the road, because even after they quit their company, if they accept it with their personal account they can still access our resources and we don't want that. So that is it for those three reports. Remember you can download the PowerShell files directly from the course downloads for this course. Now let's go back to the slides and look at some other tips and tricks for external user reporting with SharePoint Online.

Other Tips and Tricks
Before finishing, I just want to share some other tips and tricks with you guys. Something very important that I would like to share with you is at the time of recording this course there is a small bug in the Get-SPOExternalUser cmdlet which does not return some external users, especially those invited in modern sites with a pin instead of using their Microsoft account. This bug is actually logged on the GitHub of the SharePoint Online PowerShell module, Microsoft recognized it as a bug so I think it will be fixed really soon so I didn't want to spend a lot of time showing you the work around, however I will include a link of one of my blog posts in this course which also links you to the bug by Microsoft directly in their GitHub as well as shows you a work around to get around it. Make sure to check out the blog and see if that bug got resolved so you make sure that you use all of the right cmdlets to get all of the external users inside your tenant. Something else I want to share with you is that in the Set-SPOTenant cmdlet, there are quite a few parameters that allow you to customize the sharing capabilities according to your tenant. So make sure you check them out in order to achieve maximum security in your Office 365 tenant. To finish off this module, let's review what we have learned. First, SharePoint Online, part of Office 365 makes a great job at empowering users to collaborate with external partners. As an Office 365 administrator or a SharePoint Online administrator, it is your duty to make sure that users can be productive all while ensuring the security of your tenant. We have looked at how to use the Get-SPOExternalUser cmdlet and the limitation that it can only return 50 users at once, and we have learned how to loop in order to get them all. We have also looked at how to create three different reports. Users per site collection, external users added in the last 30 days, and lastly, external users that logged in with a different email address than the one we invited them with. And we have also looked at how to export the results to a CSV file in order to make it easier to send to the security department to do filtering and other cool things like that. Thank you for listening to this module and I hope you found it informative.

Course Conclusion
Course Conclusion
Hello, and welcome to this final module of this PowerShell playbook on Office 365. Before finishing up the course, let's do a final review of what we have learned. As you know, PowerShell is not the only way to manage Office 365. There are multiple tools, the main ones being the Office 365 Admin Center, we also have the Office 365 Admin App, and PowerShell. So why is it important to learn PowerShell? Well you might spend a lot of your day in the Office 365 Admin Center, not all of the settings and configurations are available there. So a lot of the tasks can only be done with PowerShell. Not to mention, the automation capabilities of PowerShell that allow you to automate management tasks and bring consistency to your operations as you've seen throughout the different modules of this course. In this course we have reviewed 12 real case scenarios and completed them with PowerShell for Office 365. We have worked across services and really connected and played with Azure Active Directory, SharePoint Online, SharePoint Online with the Dev PnP PowerShell cmdlet Exchange Online, the Office 365 Security and Compliance Center, Skype for Business Online, and Microsoft Teams. So as you see, we've really used PowerShell to work across Office 365. Something that is really important as you continue your journey with PowerShell for Office 365, and something that honestly, sometimes even I forget to do, is update your modules. Most of the modules like the SharePoint one, the Dev PnP one, are updated monthly. So, make sure to always try to keep them up to date. This way you always have the latest and greatest updates and latest features that are available via PowerShell. For the modules that come from the PowerShell gallery it's really simple to update them. You simply have to run the Update-Module PowerShell cmdlet and specify the module name and that's it. For the other modules, like the SharePoint Online, the Skype for Business Online, and so on, or the Exchange with multi-factor indication, you'll need to download the new binaries and reinstall them in order to make sure they're up to date. Some of them, for example, Exchange Online or the Compliance Center, when you only use single factor indication you download a fresh module every time you connect, so those ones you don't need to pay as much attention to. But some of them, especially the SharePoint Online one, which you need to go to the Download Center and download it, make sure you try to follow the Microsoft news so you stay up to date. Now that you're done with this course, here are some other courses on Pluralsight that you might enjoy. First of all, if you didn't watch it yet, you have the PowerShell for Office 365 course that really covers the general knowledge and principles around PowerShell for Office 365. In this course we have really focused on specific case-by-case scenarios. While that course covers really the general knowledge around it. There's also another course called Windows PowerShell Best Practices and Patterns, which is really an amazing course on PowerShell, and whatever your skill level is with PowerShell, you will learn something in there. If your goal is to automate tasks with PowerShell, you'll need to use input files, so the Working with CSV Data in PowerShell can really be an interesting course to watch as it will show you how to use CSV as an input or output for your automation scenarios. Lastly, there is a course on Reporting with PowerShell HTML and Enhanced HTML that shows you how to get information from different systems and export it to a nice HTML report so if you want to create reports about your Office 365 then that are color-coded, different displays and be able to show it nice in HTML, that's definitely a course that can be interesting for you. Before saying bye, here are some of the other places outside Pluralsight where you can improve your skills around PowerShell. First of all, you have PowerShell. org which is a community-owned and operated site around PowerShell. They have a support forum in case you run into any problems. They have a bunch of free ebooks so make sure that you check it out. If you're into reading books, there's actually a book that I have wrote on PowerShell for Office 365 that covers the general knowledge and every Office 365 service in detail with PowerShell so you can find it on Amazon or on any other bookstore. It's called the "Essential PowerShell for Office 365. " And lastly, as a third recommendation, you should check out the Hey, Scripting Guy! Blog. It's an amazing blog with lots of great content around everything PowerShell. I would also like to introduce you to a pretty new feature at Pluralsight is that you can now follow authors on Pluralsight. So if you enjoyed this course, and want to see all. com courses that I will release, be sure to follow me on Pluralsight. It will send you notification when I create new courses. So, if you enjoyed this course, make sure that you follow me on Pluralsight. And, on a last note, I just want to say huge thank you for listening to this course. I really hope that you have enjoyed listening to it and you have learned a lot. Feel free to add me on Twitter, on LinkedIn, and follow my blog at absolute-sharepoint. com where I try to share a lot of tips and tricks around SharePoint, Office 365, PowerShell, Microsoft certifications, and so on. And, if you ever see me speak at one of the conferences you are attending or speaking at, don't be a stranger, and come say hi. Thank you very much for listening to this course, and finally, if you ever see me speak at one of the conferences you are attending or speaking at, don't be a stranger and come say hi. Thank you very much again for listening to this course.