This topic contains 5 replies, has 3 voices, and was last updated by
June 14, 2018 at 5:49 pm #102490
To get exchange full flavour in ISE or in blue powershell I do load
. 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto
This way, all DLL are loaded in memory and all the command run exactly the way they work in exchange shell
If I try to load this in a remote powershell session I get an error :
Connecting to remote server failed with the following error message : A specified logon session does not exist. It may already have been terminated. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) , PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionOpenFailed
Exception calling "GetComputerSite" with "0" argument(s): "An operations error occurred.
Can we work around this?
Thank in advance
June 14, 2018 at 6:01 pm #102493KeymasterPoints: 1,673Rank: Community Hero
When you load those, they attempt to use your current user credential to connect to Exchange. That works fine locally.
In a remote session, you're operating from a delegated credential that, by default, can't be used to connect to network services requiring a credential (that would involve re-delegating, it's called the "second hop problem" and it doesn't work in a default environment). So you'll get that error.
There's not a workaround, because it's a secure-by-default setting. You can read up on the Second Hop Problem in "Secrets of PowerShell Remoting" (on our Ebook menu), but changing this is a pretty serious security decision that affects your entire environment.
June 14, 2018 at 6:09 pm #102499
Hi Don, It a pleasure to be reply by you, I am a big fan. Seam a lot of video (lynda.com youtube) have some of your book!
I try really hard to go powershell remoting.
I have arround 250 exchange 2010 server to migrate to 2016. All different domain (different customer). I am having a hard time with public folder migration script. The only way I found it to work is using exchange shell. I can tell you one thing, I try very hard. load snapin, remoteexchange.ps1, invoke-command, full language etc. I cannot figure it.
Do you thing It possible?
For now I am working on Export-publicfolderstatistic.ps1
Actually, my customer are small org, I can handle losing some security while I migrate to exchange 2016. I can restore to default after job done.
Let me know if you think of a solution
Thank in advance
June 14, 2018 at 6:01 pm #102496KeymasterPoints: 1,673Rank: Community Hero
(Oh, and we call "blue PowerShell" the console; bear in mind that ISE is deprecated and you should start looking at moving to VS Code at some point)
June 14, 2018 at 8:39 pm #102515ParticipantPoints: 307Rank: Contributor
You can easily load the EMS cmdlets and use them in the ISE of VSCode when directly on the Exchange server.
You just do this.
This is what I have in my ISE and VSCode profiles so that the EMS cmdlets are loaded when I use the ISE or VSCode.
# Administrative User ISE profile Set-Location -Path 'C:\Scripts' Add-PSSnapin -Name '*Exchange*'
The above is really not a thing for PSRemoting though. For that you simply do this for EXP (on-prem) or EXO (online), but you have to have PSRemoting properly enabled and you must be a admin locally and remotely.
# Exchange PowerShell Remote Management # # Read creds from encrypted file $creds = Import-Clixml -Path $CredPath $ExchangeSession = New-PSSession -ConfigurationName 'Microsoft.Exchange' ` -ConnectionUri ('http://' + "EX01.$env:USERDNSDOMAIN" + '/PowerShell') ` -Authentication Kerberos -Credential $Creds.DomainAdmin Import-PSSession $ExchangeSession -Prefix 'EXP' $ExchangeOnlineSession = New-PSSession -ConfigurationName 'Microsoft.Exchange' ` -ConnectionUri 'https://outlook.office365.com/PowerShell-liveid/' ` -Authentication Basic -Credential $Creds.CloudAdmin -AllowRedirection Import-PSSession $ExchangeOnlineSession -Prefix 'EXO'
In the ISE, you have to remember to click that 'Refresh' button on the 'Commands' tab before the cmdlets will show up in the list.
DONJ is correct on the depreciation of the ISE, it will still be available for the long haul as per MS own announcements.
MS Statement on PowerShell ISE futures.
The PowerShell ISE has been the official editor for PowerShell throughout most of the history of Windows PowerShell. Now with the advent of the cross-platform PowerShell Core, we need a new official editor that's available across all supported OS platforms and versions. Visual Studio Code is now that editor and the majority of our effort will be focused there.
However, the PowerShell ISE will remain in Windows supporting Windows PowerShell with no plans to remove it.
We will consider investing effort there in the future if there is a high demand for it, but for now we think that we will be able to provide the best possible experience to the PowerShell community through Visual Studio Code.
'blogs.msdn.microsoft.com/powershell/2017/05/10/announcing-powershell-for-visual-studio-code-1-0/“>Announcing PowerShell for Visual Studio Code 1.0!'
So, keep doing what you are doing via the ISE, because that will be there, but as DonJ says, get up to speed on VSCode for PoSH development and efforts. To really get it to be a good experience, be prepared to spend some time customizing it. Also, if you have *NIX/OSX in your life, for PoSH, VSCode on those platforms is all you are going to get and that is PSCore only and not on par with all you can do with PoSH for Windows.
VSCode, has its quirks just like anything else, so, be prepared and accepting those idiosyncrasies and figure out ways to deal with them as they happen. You can customize VSCode to get really close to the ISE but not all the way. There are things you can do in one and not the other, but that is to be expected. Yet, it's the future of MS Scripting offering.
Of course, they can be loaded and use side-by-side.
You'll find that many, if not all of your customers will not appreciate you install VSCode on their servers or even workstations. Stuff you own is a different story.
For that '2nd hop security topic' DonJ speaks to. See this articles.
Making the second hop in PowerShell Remoting
PowerShell Remoting and Kerberos Double Hop: Old Problem – New Secure Solution
PowerShell Remoting Kerberos Double Hop Solved Securely
June 14, 2018 at 9:40 pm #102524
I manage to get the credssp working. Still not able to load remoteexchange.ps1. Also try to load the snapin. The error is different but it not working.
I am remoting from a non domain computer. Will try tonight from a domain computer.
But I guess at this point running those migration script from a remote session might be just not possible.
The topic ‘remoteexchange.ps1 in a remote session’ is closed to new replies.