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 :
Thank in advance
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.
(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)
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
You can easily load the EMS cmdlets and use them in the ISE of VSCode when directly on the Exchange server.
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'
DONJ is correct on the depreciation of the ISE, it will still be available for the long haul as per MS own announcements.
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.
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.
You must be logged in to reply to this topic.