Exchange Server 2010 SP1 Beta Hosting Deployment... Part #6 - Btw, Remote Powershell works too. Now, that's wicked!

In Part #5, I blogged about how you can utilize Exchange Control Panel (ECP) in a hosting deployment. Those are all really good. What I didn't tell you is that, Remote PowerShell works too for tenant organization in a hosting deployment.

Now, most of you already know that in Exchange Server 2010, the PowerShell concept (2.0) changes slightly as compared to the PowerShell in Exchange Server 2007. Let me do a copy and paste here from the Exchange Help File (https://technet.microsoft.com/en-us/library/dd638170.aspx),

Microsoft Exchange Server 2010 uses Windows PowerShell command-line interface remoting to establish a connection between the server or workstation from which you're administering Exchange and the server running Exchange 2010 that you're administering. In Exchange 2010, this is called remote Exchange Management Shell, or remote Shell. Even if you're administering the local Exchange 2010 server, remote Shell is used to make the connection. For more information about local and remote Shell, see Overview of Exchange Management Shell .

The key sentence here is that "Even if you're administering the local Exchange 2010 server, remote Shell is used to make the connection. " These are all good for Administrations and stuff.

Anyway, I am sure you can find tons of blogs and help on that topic. To cut the story short, think of it like you can remotely 'Telnet' into the server and do all kind of stuff. However, what's really neat is that at the same time, your permissions, your control, your access to different cmdlets are all being properly enforced. All these are done primarily through RBAC. This is really a big plus in Exchange Server 2010 where you can provide, for example a PowerShell to certain people and only limit them to run certain cmdlets, like just do Get-Mailbox and nothing else. All these are possible.

Now, let us move back into the Hosting Deployment. The capability has also been extended to the hosting deployment where you can now offer your tenant organization to remote PowerShell to your hosting environment and only see what's in their organization. They can create mailbox, create accepted domain and etc. In my opinion, if you think ECP is cool, this is way cooler (partly also because I am a geek) because this opens up tons of possibility for various integrations. For example, your customer can run script remotely and do all sort of funky stuff. Now, take a minute, smile and think of the possibility...

Now, let me go through a couple of steps so that you guys can start to set this up and play with it in your lab. I am going to use our old and faithful company name, AlpineSkiHouse here. I created the organization earlier and it has an admin account, Administrator@alpineskihouse.com

Step 1: Make sure your user has been Remote PowerShell Enabled.

In my vanilla environment, when I created the organization with the administrator, this administrator is enabled for Remote PowerShell by default. If you need to confirm, execute the following,

Get-User -Organization AlpineSkiHouse administrator | FL

Look for RemotePowerShellEnabled and make sure that it is set to True if it is not. You can refer to this site, https://technet.microsoft.com/en-us/library/dd298084.aspx for help if you need to know how to do it (of course, you should make sure the above highlighted Organization parameter is passed in too).

 Step 2: Prepare CAS Server

Next, go to your CAS server (assuming that's the server that your tenant organization admin will use, make sure that the authentication method of the PowerShell folder also has Basic auth enabled. By default, this is set to false. So, perform the following to set the specific CAS server's PowerShell virtual directory's Basic authentication to true.

Set-PowerShellVirtualDirectory "CASHT01\PowerShell (Default Web Site)" -BasicAuthentication $true

For this purposes, I am not going to go through the external URL and redirection stuff but similar to the OWA's external URL, I am sure you guys know what you need to do.

 

Step 3: Ensure SSL is configured.

Needless to say, you should have https being configured properly. If not, there are more things to do like you have to allow unencrypted traffics, deal with trusted CA, CRL and etc.

Step 4: Let's get connected.

Next, go to a machine is not part of this hosted environment's domain, say a workgroup machine with PowerShell 2.0 installed. In my case, I am just using another Windows 2008 R2 box that has TCP port 443 to the CAS server. Then follow the following, Connect Remote Exchange Management Shell to an Exchange Server,  https://technet.microsoft.com/en-us/library/dd297932.aspx, with some changes, of course,

$UserCredential = Get-Credential

When you are prompted for credential, enter the credential of a tenant organization administrator, in this case administrator@alpineskihouse.com

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://mail.consolidatedmessenger.com/PowerShell/ -Authentication Basic -Credential $UserCredential

 Note that the Authentication has been set to Basic and the ConnectionUri has been set to the above. The mail.consolidatedmessenger.com will point to my CAS server. If everything is successful, then nothing will be shown. If there is an error, you will know it.

Set-ExecutionPolicy RemoteSigned

Import-PSSession $Session

Lastly, just set the execution policy so that it takes remote signed run scripts and then import the PSSession and that's it. Then you can execute a Get-Mailbox and you will get mailboxes of all the users in that organization only. Voila!

Now, you may notice that in the picture, I have an additional parameter called -SessionOption $a.  I used that because in my testing, I happened to use one of the box that can't reach the CRL URL (which is my AD server). So, I ran  the following additional cmdlets to instruct the PowerShell to skip the checking of CRL.

$a = New-PSSessionOption -SkipRevocationCheck

 This will instruct it to skip the CRL revocation check. So, that's it for now, folks.

 Previous Articles

Exchange Server 2010 SP1 Beta Hosting Deployment... Part #1 - The First Look
https://blogs.technet.com/b/provtest/archive/2010/06/25/exchange-server-2010-sp1-beta-hosting-deployment-the-first-look-part-1.aspx

Exchange Server 2010 SP1 Beta Hosting Deployment... Part #2 - Creating New Organization
https://blogs.technet.com/b/provtest/archive/2010/07/08/exchange-server-2010-sp1-beta-hosting-deployment-the-first-look-part-2.aspx

Exchange Server 2010 SP1 Beta Hosting Deployment... Part #3 - Creating New Mailbox
https://blogs.technet.com/b/provtest/archive/2010/07/14/exchange-server-2010-sp1-beta-hosting-deployment-part-3-creating-new-mailbox.aspx

Exchange Server 2010 SP1 Beta Hosting Deployment... Part #4 - Wait wait... are you saying mail contact actually works now? No way!
https://blogs.technet.com/b/provtest/archive/2010/07/16/exchange-server-2010-sp1-beta-hosting-deployment-part-4-wait-wait-are-you-saying-mail-contact-actually-works-now-no-way.aspx

Exchange Server 2010 SP1 Beta Hosting Deployment... Part #5 - Exchange Control Panel (ECP) in Hosting Deployment...
https://blogs.technet.com/b/provtest/archive/2010/07/18/exchange-server-2010-sp1-beta-hosting-deployment-part-5-exchange-control-panel-ecp-in-hosting-deployment.aspx

Continue Reading

https://blogs.technet.com/b/provtest/archive/tags/exchange+2010+sp1+hosting/