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'
Note:
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
'docs.microsoft.com/en-us/powershell/scripting/setup/ps-remoting-second-hop?view=powershell-6'
PowerShell Remoting and Kerberos Double Hop: Old Problem – New Secure Solution
‘PowerShell Remoting and Kerberos Double Hop: Old Problem - New Secure Solution | Microsoft Learn’
PowerShell Remoting Kerberos Double Hop Solved Securely
‘PowerShell Remoting Kerberos Double Hop Solved Securely | Microsoft Learn’