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 (,

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,

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, 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,, 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

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Authentication Basic -Credential $UserCredential

 Note that the Authentication has been set to Basic and the ConnectionUri has been set to the above. The 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

Exchange Server 2010 SP1 Beta Hosting Deployment... Part #2 - Creating New Organization

Exchange Server 2010 SP1 Beta Hosting Deployment... Part #3 - Creating New Mailbox

Exchange Server 2010 SP1 Beta Hosting Deployment... Part #4 - Wait wait... are you saying mail contact actually works now? No way!

Exchange Server 2010 SP1 Beta Hosting Deployment... Part #5 - Exchange Control Panel (ECP) in Hosting Deployment...

Continue Reading


Comments (12)
  1. Anonymous says:

    @ Shah

    Are you talking about hosting or normal enterprise? In a normal hosting environment, you probably not going to have the configuration that you are talking about. In hosting deployment, you consolidate everything to one site.

  2. Anonymous says:

    I am glad it is able to help you. Cheers. Kip

  3. Anonymous says:

    I do not believe that is possible but I will check.

  4. Anonymous says:

    The idea is that everything that calls to Exchange, you should be able to do it through powershell. Think of it like in HMC, you have Provider, Managed and Hosted layer. Cmdlet is provider layer and big part of managed layer. Any other business logic like calling the SQL and etc. To be honest, Powershell is really powerful. Today, I almost entirely do a lot of my stuff through powershell, including charting graph, parsing XML files, performing bulk import, application updates and etc.

    Having to say all the above, I am not saying that this change of approach is not without  it's shortcoming. For one, it will make migration to there rather painful because the whole change of model. Having working with the hosters for quite a while now, believe me, I do feel your pain.

  5. Anonymous says:

    I appreciate the feedback, Mark. Do not hesitate to let me know if you have any suggestion on topics you like to see here.

  6. Anonymous says:

    Hi Sean,

    Take a look at the following to see if it answers your question.…/thinking-about-migrating-to-exchange-2010-sp1-from-hmc.aspx…/planning-to-move-from-hmc-to-exchange-2010-sp1-hosting-deployment.aspx

    Basically, the approach is slightly different as compared to HMC. Powershell has been extended to do some of the provisioning process. The control panel creation process is now totally open and Microsoft no longer create the middle layer that dictates. It gives you guys better flexibilities in inserting your own business logic and stuff but it does come with a cost, which is you may have to build that layer to integrate with the powershell.

  7. Mark says:

    These posts are great. Thanks for all the information. I'm looking forward to reading more.

  8. Biz says:

    You are surely helping me out a lot with these posts.

    The ECP is awesome, I'm sure we're going to use this for our customers!

    There isn't some enterprise account we can use to administer all companies within Exchange 2010 through ECP?

    Instead of "Manage 'my organization'", select all the other organizations aswell from the dropdown list? This would save us a scripting effort every time we need to create a new user.

  9. Sean Hook says:

    In HMC, you had the option to access the WebServices in order to execute functions and facilitate the control panel creation process.

    What is the equivalent technology here?

  10. Sean Hook says:

    Thanks for the response kip.

    I was hoping for something else to hook into – to hopefully get support from MS. But I guess it is what it is. The only promblem then I guess is understanding what each commandlet does – since we will essentially have to write dlls to accomplish the same thing – as I cannot see an enterprise solution just triggering powershell commandlets to get work done.

  11. kurdt says:

    You're awesome. I've been just spending second evening trying to figure out why I cannot connect to my Exchange from a workgroup pc You saved me a lot of time, the deciding trick was -SkipRevocationCheck. As my exchange is behind TMG2010 I published Powershell virt dir but my client couldn't find crl and now everything works like a charm.

    Thank you.

  12. shah says:

    nice work!

    how to configure SSL for multiple sites?

    if we have 50 remote sites lying in one AD(forest)

    with different namespace of each site!

    SAY, site2@xyz.local etc

Comments are closed.

Skip to main content