One item that is very prevalent is people directly loading the Exchange PowerShell snapin into the Integrated Scripting Environment (ISE). This is not supported from the Exchange point of view, as Exchange requires that Remote PowerShell be used with Exchange 2010 and 2013.
Let’s look at how this should be done.
Choosing The Correct Profile
As discussed in the previous post on ISE profiles, ensure that you are saving the profile script as the correct file.
Profile Type
|
ISE Path
|
| Current user, PowerShell ISE |
$Profile.CurrentUserCurrentHost, or $profile |
| “All users, PowerShell ISE” |
$Profile.AllUsersCurrentHost |
| “Current user, All hosts” |
$Profile.CurrentUserAllHosts |
| “All users, All hosts” |
$Profile.AllUsersAllHosts |
Typically for what we are discussing here, the settings are specific for ISE and should NOT be applied to the Exchange Management Shell as that already connects to Exchange using Remote PowerShell. Thus we will use the Current User, ISE specific profile. This file should be saved as:
C:Users<profile>DocumentsWindowsPowerShellMicrosoft.PowerShellISE_profile.ps1
This is the $Profile or $Profile.CurrentUserCurrentHost as shown in the above table. You could also consider using the All users, ISE specific profile. That would be the $Profile.AllUsersCurrentHost profile, and would apply the settings to all users who logged onto the machine where you modified the ISE profile.
Create & Save Profile Script Code
We need to specify the remote PowerShell session details, and then import it the session. The code to add will typically look like the below:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://consea-mb1.contoso.com/PowerShell/ -Authentication Kerberos
Import-PSSession $Session
(Note that the $Session line may wrap. It should be on a single line)
This is hardcoding PowerShell to a single server, in a later post we can come back and revisit this so that the connection will succeed should that server be unavailable.
As mentioned earlier since the customisation is only to apply to the ISE environment for the current user the profile script will be saved as:
C:Users<profile>DocumentsWindowsPowerShellMicrosoft.PowerShellISE_profile.ps1
This file and its contents are shown below:
In this example we are running ISE from a machine that is joined to the same domain as the Exchange server. Thus we can use the current logged on credentials of the user, assuming that the correct Exchange RBAC assignments were previously done for the user’s account. This avoids the credential prompt. Should the machine running ISE reside in a workgroup or remote forest we need to prompt for credentials. This can be done by use the PowerShell session example here.
Running ISE With Profile Script
After creating and saving the PowerShell profile script as the correct file name in the correct location we can then test it out!
Opening ISE will cause the ISE profile script to be processed for the current user. This is shown by the status note in the bottom left corner, and is highlighted by the purple line. After a brief pause a popup window appears which signifies that the server side runspace has been created, and is currently being imported into the client. Do not hit the stop button, or press a key else that will abort the process.
In the below screenshot , note the two highlighted areas. They are the Get-PSSnapin and Get-Module cmdlets respectively. This is to show that the Exchange 2010 snapin was not directly loaded, and that the cmdlets have been made available by downloading and importing the module which represents the PowerShell cmdlets in the server side runspace.
WARNING: Some imported command names include unapproved verbs which might make them less discoverable. Use the Verbose parameter for more detail or type Get-Verb to see the list of approved verbs.
Happy days! This allows us to continue using ISE, and also connect to Exchange 2010 & 2013 via remote PowerShell.
Cheers,
Rhoderick
