Welcome to the session. Is this the last session of the day, four o'clock? All right. We're almost there. What do you guys think of the conference so far? Is it good?

I'll tell you what. I've spoken at a lot of conferences. I've attended a lot of conferences. I'll tell you the food today at lunch. If you don't go to a lot of conferences, I'm gonna tell you right now, it doesn't get any better than that. It absolutely does not. If you thought that was like, yeah, guess what?

It's all downhill from there. It was awesome. Well, we are going to talk about one thing that we love and one thing that we hate. Well, I love both things, but you're probably here because you hate SharePoint or have to deal with SharePoint. And we're here because it's some PowerShell.

I love both. PowerShell is just fun. I can do a lot of cool things with it. And the same thing with SharePoint. I've been with SharePoint ever since 2001, actually. Even before Monad came around, but I want to talk a little bit about it, but about me, a little bit about myself. My name is Rick Taylor.

I work for a company called Zack Consulting out of Draper, Utah. I live in Phoenix. I worked at Microsoft a couple of times. One time on the SharePoint engineering team and second time I worked for operations consulting or OpsCon.

That's all my contact information. I guess we'll be able to get all the slides and everything after the conference. I've written a few books. I keep saying I'll never do it again, and then I end up like on another project and writing another book. So that's me. And we're going to talk about a few things.

SharePoint and how did this all happen? So this cool word called DevOps, kind of the name of the conference, means a different thing to everybody. And even as much as we keep saying that, well, this is what it means,

somebody's going to have a different one, and whatever. So I am going to speak about DevOps briefly from the perspective of someone like me who is a SharePoint admin. I am NOT a developer. As close as I get to developing is using PowerShell. That's it.

Okay, I've opened up Visual Studio. I look at it, and if I can't get in and out and make whatever I want to in the next 15 minutes, I close it up, and I'll go get a real developer to go do some stuff. Other than that PowerShell, I'm in the ISE all day long. Why? Because SharePoint is a pain in the behind

to deal with. Okay, it is a monstrous application. How many of you are SharePoint developers? SharePoint admins? No? Some of you just got stuck with SharePoint? Oh.

Okay, well, so that's a good thing. Okay, so in the beginning, talking about DevOps and SharePoint, SharePoint was made for a lot of things. Industries, specifically, probably law and health and

legal and legal health and government. But it does so much more than that, but its infrastructure cost is like super super high. PowerShell really can help us decrease that cost. And what I mean is it administering. Okay, I

got into SharePoint before PowerShell existed, and then when PowerShell came along for other products, we were kind of like getting envy because Exchange had it from the very beginning. They had it in 2007, and we're like, wow, hey, PowerShell is cool. When do we get it? And then like they would give us like two or three commandlets.

And then in the next version, 2010, we got maybe a hundred commandlets. And then 2000, well, we got more than that. In 2013, we had about 500. 500 to 700 commandlets, and that was on-prem.

When SharePoint Online came out, now we're almost back down to zero. Well, you know, maybe about a hundred commandlets, but that's okay, and I'll explain a little bit about that. But what about this DevOps thing? What does that got to do with it? Well, we use PowerShell as DevOps engineers to help move this process along of making SharePoint less painful.

The reason is SharePoint is really one of the only products that Microsoft makes where the developer, hardcore developer, and the hardcore admin actually interact all the time. The only one. Why? Because SharePoint requires a lot of customization, custom applications requires

developers that have a lot of background in C-Sharp and all kinds of other programming methodologies, React and all that other kind of stuff. But then there's still that admin component, and so you've got ops and you've got dev

working all the time together. And what you get is, in on-prem situations, you've got these huge infrastructures. You've got, because it's a three-tiered application, right? You've got web front ends, and you've got application servers, and then you've got the SQL backend. And you're constantly doing things with all of these servers, you know, web applications, site collections, users,

user profiles, search. All of these things that require an admin, right? That's where PowerShell comes in. But then when the devs are developing and they get that stuff, they want to get it into production,

right? Where do they do that? Where does all that dev really happen? Everyone says, well, it shouldn't happen in production, but it does. And that's where we get the butting of the heads, and that's where DevOps can help. It's like, look, we're gonna set up these environments, and we're gonna make sure that when dev really does their dev, it goes through the

process that it should go through, so that we can actually turn these out. Because when SharePoint gets all jacked up, it's a pain in the behind to get it back on track. Okay, it's a pain. So, I've worked, oh, about 20 years or so in the IT field, and we always wanted to be sysadmins.

But then there were all these DBAs, there were testers, there were all of these different things that were going on. Well, when the cloud came around, it caused a little bit of pain. Why? Because now, I lost a little bit of control. I did not get to touch the server, and a lot of people liked that, right? I want to go in there.

I worked for a company, Nestle, the chocolate company. I worked in the Phoenix data center. We had, maybe about a thousand servers in that data center.

One Active Directory domain. 1,100 domain controllers all over the world. Three OUs. America, Europe, well America, which was North and South America, Europe, and Asia. Asia, Africa, Oceania, actually. Three OUs.

And if you had one domain, remember, if you made a change on one domain controller, it replicated throughout the whole thing. When we deployed SharePoint in there, we were scared to death. Because as soon as we were going to make it, if a mistake happened, right, we've got a problem.

Global. So it took a long time for us to really understand how we were going to work with this, and DevOps back in those days, all right, was just starting up, and we're like, well, how are we going to do this? How are we going to do that? Well, PowerShell really helped us, and then now going to the cloud,

now I don't get to touch these servers, hmm. The pain. How do I get these developers to get their applications deployed and still make sure that my production environment is safe? Okay, the problem is that we worked in this vacuum. Okay, the sysadmin said, you know what, I'm going to worry about the users, I'm going to worry about the permissions,

I'm going to worry about the site collections, and when these guys wanted to deploy something, it happened in the background. I woke up one day and I was like, whoop, we got these applications. Oh, guess what, that site collection looks different. Oh, guess what, we've got three or four more. It was just a mess.

It was a mess. And so what we needed to do was figure out, how were we going to work together? Groups that were isolated from each other usually didn't have any interaction. So luckily, I had a great manager that said, you know what, we're going to work together.

We're going to design this environment so that, and he designed these environments, architected this environment, so that the devs and the ops, right, the sysadmins, actually had to work together in order to make this to work. Okay, so what did that mean? That mean that I had to get on

the, you know, on a phone call, maybe with the dev, or sit in that dev's cube to help this dev deploy their code. That was cool. That was, it was a lot of, you know, it was a lot of fun actually. So,

this is kind of like the paradigm. So, at the very top you see the continuous integration. So I've got all this, this product backlog, right? I've got all this stuff that the devs want to deploy. Right? And I get this backlog, and then this is where ops comes in and says, hey, you know what? You've got all these packages. I will deploy them for you.

I'll deploy them. Once I've done this, then you go back and you test it. If you say that it's good, then I will deploy to the next environment, and you'll go back and you'll test it again. If there's errors or whatever, you fix the code, and then we start the process over again.

Okay, and then once we finally get something that's working, we say, okay, there we go. It's now into production. Meanwhile, dev is probably working on the next iteration of some new code, and we do that same process over and over and over again. The cool thing about that is, ops

really uses the same process to deploy that code that the devs did over and over again. And whenever you start repeating processes over and over again, what does that smell like? PowerShell. PowerShell helps me because these are repetitive tasks, right? Over and over and over again.

I'll just run these things over and over again. I'll just use PowerShell. Boom. Boom. Now I can automate this. Cool. So now if I can get that dev to automate their process to get it to me in my automated process, and have it automatically kick off, guess what? We have just now given everyone a lot more bandwidth

because I don't have to worry about it. Okay, what does that kind of look like? Well, first you have to map it out because you really can't automate something that you don't understand the process. So understanding the process is key. This is an example of a process. Whoa, sorry about that.

This is an example of a process that I'm currently working with the client. Okay, and we use ServiceNow. So basically what happens is, let's say that a user wants to spin up an environment in which to do some development. Cool. They put a ticket in ServiceNow.

There's a button. Create environment. A page comes up and it says, hey, who are you? Who's your manager? What do the machines look like? Are they running Linux? Are they running Windows? And it asks all that information.

How beefy do the machines have to be? How much memory? How much hard drive space? All of that. Do you need SQL? Is this one tier, two tier, three tier? Ask all the questions. Once the user fills all that out, they say go. And the process runs in the background. They get a little page that comes up and says, congratulations,

you're now the mother or the father of a brand-new environment. Cool. What's going on in the background? In the background, it kicks off a whole bunch of PowerShell scripts that we ran or that we created. Now this, okay, mind you, is for on-prem because it's creating these

virtual machines that people can touch, so to speak. Okay, so it runs it, I don't even know how many, one, two, three, four, five, at least six or seven

discrete PowerShell scripts that have their own modules and functions that are going on. I mean, it's awesome. We've got our own Git repository of where all these things come from and there's probably 50, 60 different scripts in there depending upon what needs to happen, but it's awesome. This is

DevOps in production right here, right? The the front end of that is done by Dev. Dev writes the code that accepts the entries from the user and sends it to us. We do the back end. We created those

PowerShell scripts that do those things that the Dev wants to happen. Okay, so for the cloud, it works very similarly in that we have to use PowerShell, but since we don't have access actual to the actual hardware,

right, and we're doing it in the cloud, things change. SharePoint Online Management Shell is different than the SharePoint Management Shell for on-prem. So this part of the presentation, what I'm going to do is I'm going to show you

some of the differences and what some of the gotchas are when we deal with SharePoint Online. How many of you are dealing with SharePoint right now? On-prem or in the cloud? Both. Online? Both? Both? Okay, so for those of you that are dealing with both,

you'll see a lot of the differences. Those of you that are only online, then I guess it won't matter, but let's go through that. So SharePoint Online Management Shell. It is a Windows PowerShell module. You install it on your machine and basically what this does is not to be confused with the Azure AD module or the

Microsoft Online or the old 365 module. Those are two separate modules that you also have to install, as a matter of fact, if you're going to be dealing with this. Why? Because with SharePoint Online, the SharePoint Online Management Shell, it can't create users.

It will only assign users to sites. Okay, those users have to be created using the old 365 or Azure AD module. Okay, how is it different? Well, SharePoint Online will only manage users and groups in SharePoint Online.

It won't do it for Exchange. It won't do it for anything else. As a matter of fact, you can't, let's say that I've got a user and they're assigned to a site. They've given them permissions to a SharePoint site and the user leaves the company. Okay, so you delete that user from Azure, right? They're gone. Boom. Guess what? That user is

still assigned to the site. If you go there and you look at the site, that username still shows up there. It is almost like if I were to have a user in Active Directory and assigned them to a share on a local machine, if I delete that user in Active Directory,

what happens to that local machine? If you were to go in there and look at it, at the folder that they have access to, you'll see a SID. There will still be a reference to that user that you deleted. So you actually have to delete that user. The same kind of a thing

happens with SharePoint Online. I can remove the user from the site, but that does not remove them from Azure or vice versa. If I remove them from Azure, that user has to be removed from the site because they're still there, and I'll show you that here in a bit. Okay, when should you use

SharePoint Online admin or the SharePoint Online PowerShell? Because you can do both. Okay, I can create a user in portal.office.com. Right, I can just click, click, click, click, click, click, click, create the user, or I can use PowerShell and then do it

that way. Now, my answer is, hey, when you want to do this quickly and really utilize DevOps, use PowerShell. In order to do this, there are some requirements. Okay, you got to go get the bits from Microsoft in order to use SharePoint Online Management Shell.

Okay, it is different than the on-prem. On-prem, the SharePoint management is used from the SharePoint server. You actually have to remote into the SharePoint server in order to use SharePoint with the SharePoint on-prem. With SharePoint Online, since there is no actual machine that you're touching,

you download the binaries to your local machine, and that installs them. If you kind of think of the the SharePoint management shell on on-prem loads the PS snap-ins

so that you're able to the SharePoint DLL so that you can run certain commandlets. And, but you have to remember that you can you can run any PowerShell IDE, right, and do that. You just have to remember to add the snap-in if you don't run it from the SharePoint management icon. In the SharePoint Online, it's different. In that particular case, when you install those binaries,

it's like permanently putting those snap-ins in there. The only difference is you have to make sure that you're connected to the SharePoint Online service. The other caveat, you must be a global admin. Okay, not just, there's there's no more farm admin.

Okay, with on-prem, you had a farm admin. You don't have that with SharePoint Online. With SharePoint Online, you've got site admins, and you've got a tenant, global admins. In order to use this, you must be a global admin. So, some of the differences between

on-prem and online from a IT pro or an admin perspective. Okay, with on-prem, a lot of these actions that I dealt with, I no longer have to do. Right? Logs, managed timer jobs, deploy solutions and features. I don't do that anymore in SharePoint Online.

Which, or yeah, I don't do them anymore with SharePoint Online. I do still create and delete sites. I can restore deleted sites. I can, you know, groups and users add and remove them, and I can manage permissions and so forth.

All right, time for the demo.

Ah, yes. Um, you want to take a picture of that or whatever. The demo files that I'm using, you can download those from my OneDrive. Because, I'll tell you what, searching for those online, you'll find them, but wouldn't it just be nice if you just had them right there.

And they're unzipped, so you don't have to use them all. All right. All right. So here, you see that I've got a few of these tabs of all these scripts,

and that way I don't have to go and search for them. Now, I'm going to run through a few of these to show you some of the things that you need to watch out for. So, I'm going to go to my portal. So right here, this is the admin center for my portal. Okay, here are all my users.

Okay, and if I wanted to create a user, I would click here, add a user. And it'll ask me to fill in all of these things, right? Everybody understands that? Office 365. But you know what? I don't want to have to go into it. What if I've got a whole bunch of users that I got to do? I don't want to have to go through all that, right? It's always better to use PowerShell. Cool.

In SharePoint Online, I'm going to show you this here in the admin center. When I go here,

you will see a list of the site collections that I have created. Okay, so here's a list of all the site collections that I've created. If I want to see all of the users that belong to this, because I'll tell you, that seems to be like one of the most asked questions. Who's a member of that site? Who's an admin on that site?

Why can't I get access to this site? Usually permissions, that sort of a thing. In order for me to come here and get that information, right? Let's just say project three. I have to click on the site, and then I have to wait for this, and it says, oh, here's the site. Here's the administrator. Cool. Then I have to click in the site.

It has to get rendered, and then I have to go up to site settings, click on site settings, go over here to people and groups, and then people in groups would tell me if any of my users show up, they would all show up here.

So I've just clicked four places to find out who's a member of this site. That is craziness. Okay, what if I want to find out all of the members? Because you don't have to be, right? Just because I'm in Office 365 doesn't mean that I'm assigned to a site. What if I want to find out who's assigned to a site and what their permissions are? All at once.

That's where PowerShell comes in. All right, so now I'm going to create some users. So this is the demo. I'm going to create some users. Call them test user. Test user one, two, three, four, five, six, seven, eight, ten. I'm going to assign random users

to random sites. And some of them are going to be site collection admin, some of them won't be, and we'll change all of that. And then I will show you where this split-brain Jekyll hide thing comes in, where I'll delete a user, and you'll see how he stays, and then I'll show you how to remove it. All right, so that's the demo.

Bless you. Close. All right, here we go. So the first thing that we have to do is we have to connect to the online services. Now, this is a pain in the butt to me. It's not that much of a pain, but I think it's stupid. In that, in order for me to create a user,

I don't create, I don't, I don't, I have to create, I have to connect to SharePoint Online, but I have to connect to Azure because that's where the user is going to exist. I don't know why they didn't just make it all part of the same thing. Just make one module, create a user, assign a license, and

put them in SharePoint. All right, so what I did was I created a script that did that. So now, when you, if you wanted to, you could take this and say, hey, I'm going to run this script, and it will do whatever I want it to do. So what this is going to do, let me, is this big enough, or do I have to blow it up? Okay, so

I'm going to say, all right, who is, who are you, right? The global admin, because you've got to be a global admin. It's going to check for your creds. Once it does that, it's going to then connect to Azure. It's going to connect to Office 365, and it's going to connect to SharePoint Online.

That way, I'm not going to get any error messages or get prompted to log in because I haven't been logged in yet. Okay, so I'm going to run this, and it says, okay, who are you? So I'm going to type in the global admin name, and I wrote it like this so that I didn't hard code it because I wanted you to be able to do whatever it is

that you wanted to. Okay, org name, oops, that's wrong. Yes, it's wrong.

Let's try it again.

Yes, yes. Okay, so I am connected, right? I am the tenant admin.

Where's my ID? That's the ID of my tenant. I'm connected through Azure. I'm connected to Office 365, and I am in SharePoint Online. Cool, so I want to create some users. So if I go back,

I'm going to create some users, test users, one through ten. Okay, so there's no smoking mirrors. You can see that those users do not exist here, okay? I have an Excel

spreadsheet of all my users, users one through ten. Okay, here is my user principal name. Here is my display name. Blah, blah, blah. Okay, you could put whatever users you want in there. You can actually put a read host in there if you just want to do it onesie-twosie. Okay, so it's going to read from this, and it's going to create those users.

Okay, user create. Okay, so it's going to import

from there, read that, and then you'll see that for each user, right? I'm going to create it,

and I'm going to sign a license, and we're good. So let's run it. Okay, so he's running, and he's creating all the users. Boom, boom, boom. There it is. Now, one thing that you should think about doing is, you also see that the password is right here.

Okay, you can, I do a blog, and I'm doing a PowerShell series, so if you go to blogs.technet.com and look me up, it's called PowerShell for SharePoint Admins, and it goes through, you know, step one, two, three, four, up to whatever,

and I'll take scripts like this, and I'll show you how to build on them. So this one, what I would do is, not only would it create those users, but it will email those users the password, or change the password, anyway, and I'll show you how to do that. All right, so now those users exist in

Azure. We'll refresh. Voila, there they are. So now, what sites do they belong to?

Because I have not assigned them, I just created the users. I didn't actually put them in any SharePoint sites. If you log on as that user, try to get to any SharePoint site, it says, eh, you can't get there because you haven't been given permissions. Okay, so now I'm going to create, you know, the SharePoint sites already exist, but I'm going to assign those users to

those sites, but in order to do that, they actually have to belong to some group, right? They're either going to be an admin, they're going to be a member, they're going to be a visitor, or some other group that I might have already created. Now, caution. If,

there's a script here that creates site collections, if you create a site using PowerShell, the site will exist immediately, but it will not be immediately accessible to you.

Okay, once you create that site, and you go there in Office 365, and you look at it, you'll see the green wheel spin. That means he's thinking. He's thinking. He's thinking. You can't do anything until that wheel stops. So, a lot of times, if you run these scripts, you're like, oh, I'll just run them all.

Bang, bang, bang, bang, bang. You're going to get a whole bunch of errors that say, sorry, site doesn't exist. You'll go to Office 365, you'll see, you know, like, yeah, it exists, it's right there, but you got to look at the green wheel. So, what I suggest is, I put a start sleep in there. I probably put more than three because I found out that five didn't even work, or three didn't work.

I was going one, two, three to see how long it would take. You had a question? Yes. Correct. The default is asynchronous, but even when you do that, the timer service in Azure takes it a while for it to...

That, that's the reason why. So, even though you, they, boom, it's all created, you still got to wait. Alright, so, I'm going to run these line by line because those sites already exist, and I'm not going to do that. So, this one here

creates the site collections. I'm not going to run that one because they already exist. This line here reads from the CSV file, creates the groups, and assigns permissions. This one here will read from a list and put the users in those groups, but the user must exist. So, I want to run this one first.

So, this file name is already, oh, right. Because those users probably already exist, or that group already exists. Actually, yes, that group already exists.

Now, we're going to put those users in the groups. You cannot find the file. Find the file. Right, he's not there. That's because I changed the name. Right, save.

Do it again. Now what? It's a, oh,

yes, yes, thank you, groups and members. I believe that's the one.

That's it. Thank you. There we go. I didn't copy everything.

Come on, Rick. Third time's a charm.

Okay, so that's what he did. Alright, now,

alright, so I've done all that. I'm going to wipe this out. So, now, who does, let's go back to admin for SharePoint, and let's take a look at the site collections.

Alright, project three. I clicked on project three. Let's come up here. Let's go to site settings, people and groups. Actually, it doesn't look like anybody got assigned here. Well, this group got,

yeah, all of these groups got created from that CSV file, but I thought there were users here. Alright, well, guess what?

That's a perfect example to show you my next script. Who's been assigned to what? Well, let's find out. Let us find out, list. What this will do is list the groups, all the group memberships, for all of my SharePoint online sites.

So, let's find out. Okay, so team site three. Who's a member of team site three? Here are the members of that group.

Actually, and there it is. Test user five is a member of that group on that site. Four is a member of this group on that site, for this particular site, and so on and so on and so forth. So, as an admin, this question gets asked a lot. I'll stop it here. Okay, now, who, the next question I get is, who's an admin where?

Right? I want to be an admin, and I'm not an admin. Who's an admin over there? Well, let's find out. Let us see. Who is an admin? Find out admin. I thought I had that.

Get SCA all sites. Okay, it's going to go through all the sites and list who the site collection admins are for each one of those sites. So, let's do that. That's me.

That's me. It looks like it's just me. Of course, it's just because I just created those users. Okay, so no other user, besides me, is an admin, because that's the way it is. So, what if I want to make a user an admin? Okay, so let's do that. What this will do is it will say, okay,

who needs to be an admin and where? Okay, let us do this.

Okay, what's the name of the site? Let's do the team site. H-T-T-P-S Zach dev dot SharePoint dot com slash site slash team site zero three Okay, that's the name of the site.

Who do I want to be an admin there? Doesn't matter. Nobody's an admin there anyway, but I want to show you that there's no smoke and mirrors here. Sites team site 03. Okay, site settings, site collection admins,

just me. Right? Let's run this. Test user

three. Oh, what does it say? URL team site 03. Did I type it right? I think I did. Run the whole thing this time.

That was the name of the site, yeah. Team site 03. Yeah, okay.

Login name. Test user, we'll say four this time.

Cannot validate our URL. On line seven, site co-e- oh.

Wait, no, it's the same one. Yeah.

Admin URL is... There is none. That's why it says it's null. URL

equals n dash n dot dot SharePoint dot com. No, you're right. It's org. There we go.

Now we're good. Set SPO user.

That's the correct... Yeah, so it actually this should work now.

Okay. Well now I got it. Okay, hold on here. Let's do this. What's the site? What's the login name? Let's run both of these again.

Site zacdev dot SharePoint. SharePoint. Yes.

Login name. Test user five at zac. Bingo. Now, let's go here.

Refresh. Bingo. Oh, isn't that funny? That's because I did not run this.

Or did I? Did I run this? I did now. Now five will show up.

Voila. Now, how long does this go to? 445?

All right, I'm going to show you one caveat. So I am going to delete test user three from Azure. Okay, so now delete user. Well, there's one that we removed from the site, which I will run here, but I'm going to delete

him from Azure. So delete user. I'm from outside, but I'm just going to screw that.

Delete. And I guess so. Test user four at

zacdev dot com. Gone. Okay, so this user, if I go here, active users, test user four is not here.

However, you see that test user, even if I refresh, test user four is still a site collection admin here. That's because SharePoint is stupid.

It just holds on to it. So in order for that to be removed, and remember, test user four is not only a site collection admin here, but was added to some groups and all, a whole bunch of other different ones. So I'm out of here. I would run this script here that removes them from all sites. So remove user from all sites.

Bang. User login name, test user four, and it's iterating through all the sites,

removing them. Boom. The only reason why it gives an error here is because the user was not a member of that site, because it's going through every site. If the user is not a member of that site, it just says, oh, I can't find the user.

What I'm going to do is I'm going to do a try-catch. If the user does not exist here, just move on to the next one. And then we're done. And now if I go here, refresh, user four is gone. No. Well, okay, so if I run that script, it will remove the user from all the sites,

but it doesn't delete the user from Azure. All right, so everyone got a copy of the URL where I put all these scripts down?

Knock yourself out. Thank you so much for your time. I'm sorry. I went a little bit over, but please find me. Shoot me any questions. I'd just love it, or find me in room 403. That's where I hang out. Thank you so much.