Exchange Server 2010 is built completely on top of Remote PowerShell. It also runs in the cloud with Office 365 so you can actually use PowerShell Version 2.0 Remoting to run the commandlets against the Exchange servers in the cloud. It’s actually really simple to set up, and we’ll take a look at how to do it.
I’ve got a standard PowerShell Version 2.0 console open and the first thing to do is create a credential object and supply Office 365 Microsoft Online Services credentials.
I’m going to do “$cred” so this is a variable, “=” and then I’m going to run the getcredential commandlet. That’ll actually prompt me for my credentials. So this is just going to store my credentials; I’m not actually authenticating anywhere right now.
What I’m going to do here is type in “firstname.lastname@example.org.” So this is actually my Microsoft Online Services administrator account. Then I’ll enter the password in here. Once that credential object is created, I’m ready to create a new session. So I’ll say “cloud=.” And I can call that whatever I want. I’m just going to do “cloud=newpssession.”
I need to specify the configuration name. In this case it’s going to be “micosoft.exchange.” And the connection URL is going to be at the public endpoint of HTTPS, “ps.outlook.com/powershell.”
Also since we’re outside of the forest hosting the Exchange environments, we’ve got to authenticate with basic authentication. And then finally we need to allow this session configuration to redirect us to the appropriate server, because there’s hundreds and possibly thousands of Exchange servers out there.
Finally I need to specify my credential object and provide my Office 365 administrator account. So with all that in place, if I hit enter it should go out and create that session against that public endpoint. As you can see, I’m getting these warnings here. Those are OK. That’s basically just saying, “Hey, you’re being redirected. Instead of being on ps.outlook.com, you’re over on Pod 51011psh.” So it’s actually sending me to right place.
And if I do get PS Session at this point, you’ll see I’ve got this connection opened against this computer name. If we actually look at that computer name, I’ll type that out to FL or format. FL is the alias for Format List. So I’ll type if out to computer name. You can see that there’s our actual Exchange server that are mailbox is and all that, all our recipients are located on.
OK, now that I’ve got this session open and we’re connected to Office 365, I’m actually going to create a new variable and call it “Office 365,” and I’m going to an Import PS Session on my cloud object, which is my session that’s out there on Office 365.
So when I hit enter here, we’re basically going to go out, ask the Exchange server which commandlets are available for my account, and now those have been imported without any errors. So I can actually see here, can do a “get mailbox.” You can see that there’s all my user accounts, all my mailboxes out on the public server here, out on Office 365.
And what you’ll notice here, if you do like a “get command” on this module that we’ve created, so “$office365,” that’ll give me all the commandlets in that module. You can see that there’s a number of them out there in Office 365, so you can do things like retrieve mailboxes with “get mailbox.” Look at the inbox rules or create inbox rules, that kind of thing. You could do other things such as retrieving just users that aren’t mailbox-enabled and creating mailboxes for those users. Creating inbox rules. I think we already said that. You get the idea. There’s a ton of commandlets in here.
Clear the screen here. All right, so if you look at that other command, “get command module,” “$office365,” we wrap that in parentheses and do a “.count,” you’ll see that we get back about 297 commandlets. So even though we’re logged in as an administrator, this is about what half of what you would see in an on-premise environment.
So you would typically see about 600 commandlets with an administrator account right out of the box in an on-premise environment. So you’ll get a little bit less because Exchange 2010 is hosted. You’ve got less control to configure server base things, such as server settings and that kind of thing.
But from here I can say “get mailbox.” Typical things that you would typically do in the shell, maybe pipe it out to “set mailbox,” change the max or change something like set a custom mail tip, or do some kind of bulk modification, moderation or retention URL, or any of that stuff. All this stuff that you typically do in the shell. You can use the help system, use “getcommand-officemodule365” to figure out commandlets are out there, and you can start scripting from there.
That’s all there is to loading the commandlets for Office 365 in Exchange Online into your PowerShell Version 2.0 console. I hope this is helpful. Check out more Drill Bits on interfacett.com.
Is there a Video you would like to see?
Let us know in the comments section below. If it’s a popular technical problem, we’ll make a video with the solution.