First, let's define what a Local Runspace is and how that differs from the one you would use for Exchange 2010.  A Local Runspace is a runspace configured to load the local Exchange Powershell snapin via the RunspaceConfiguration object.  This was the standard type of Runspace created when automating Powershell with .NET in Exchange 2007. The runspace would execute all cmdlets in the command pipeline on the machine in which the application hosting Powershell ran.  By default, the cmdlet's would run in the security context of the launching user of the process hosting Powershell.

In Exchange 2010, we now have the ability to remotely administer an Exchange server from the comfort of our Windows 7 client machines without any additional management tools installed!  This is done through Powershell 2.0's remoting behavior.  It is now possible to have a PSSession that is controlled locally but the command pipeline is executed remotely.

If application developers want to execute Exchange cmdlet's in their application, they now need to establish a Remote Runspace before attempting to execute their command pipeline.  I have a sample of this already posted and you can read about the sample as well.  Or you can look at the samples published by the Powershell team too.

This is an important topic because developers who have developed applications for Exchange 2007 using Local Runspaces will not be supported on Exchange 2010.  This is because Local Runspaces are not supported for Exchange 2010, you must use Remote Runspaces.  Also, the snapin for Exchange has been renamed in Exchange 2010 so a developer would need to recompile anyway to get this to work on 2010.

Here is a side by side comparison of a Local Runspace and a Remote Runspace in the context of Exchange 2010:

Local Runspace

  • Cmdlets execute in the application hosting Powershell.
  • Cmdlets make direct connections to the target of the data operation.  For example, a cmdlet might make a direct connection with Active Directory to retrieve data from it.
  • Cmdlets run in the security context of the launching user based on Windows permission such as Access Control Lists (ACL)s.

Remote Runspace

  • Cmdlets execute in a IIS application on the Exchange Server
  • The hosting process is primarily used to maintain the connection most everything else occurs on the server-side.
  • Cmdlets execute in the security context of the IIS application, but the RBAC Trusted Subsystem authorizes the user before permitting the operation to complete.

[Edit: 3/7/2013] Important Note: If you are using Exchange 2013 and transport agents please see my related post.