Udostępnij za pośrednictwem

Creating a remote PowerShell Direct shortcut

  • Artykuł

So here is the scenario:

  1. I have a remote Hyper-V server running Nano Server.
  2. I have PowerShell remoting setup to manage this system (details on how to do this here: https://technet.microsoft.com/en-us/windows-server-docs/get-started/manage-nano-server).
  3. I then have a number of Nano Server virtual machines running on the this system.

What I want is to be able to easily access PowerShell in each of these virtual machines.  What I want to avoid is configuring each one to have PowerShell Remoting configured – and to have that port exposed on the network.  The simple solution here is to use PowerShell Direct.

What I have actually done is to create a simple little script like this:

$VM = "NS1" $HVServer = "hyperv.test.com" $c = get-credential $session = New-PSSession -ComputerName $HVServer -Credential $c invoke-command -Session $session {Enter-PSSession -VMName $using:VM -credential $using:c} Enter-PSSession $session

Then I create a shortcut that launches:

Powershell.exe -NoExit -File C:\Users\benja\Desktop\NS1.PS1

Now when I double click on that shortcut – I get a prompt for my credentials, and I get connected directly to my virtual machine.  First a PowerShell session is created on the Hyper-V server – then a second session is created to the virtual machine.  Finally I am connected to it.

Nice and simple.

Cheers,
Ben

Comments

  • Anonymous
    November 09, 2016
    Mr. Armstrong, I'm sorry to bother you, but I haven't had any luck asking this question in other forums.While testing the TP5 release of Windows Server 2016 as a guest OS on my Windows 10 v1511 host, I noticed that the RemoveKvpItems method of the Msvm_VirtualSystemManagementService WMI class would no longer delete the associated registry key on the virtual machine.I did some further testing this evening with RTM S2016 Standard and Core (my Windows 10 host having since upgraded itself to v1607), and found that the behavior remained consistent with what I saw while testing TP5... and inconsistent with the behavior of every other guest operating system from Windows 7 to Windows 10 v1511. Even more worrisome is that Windows 10 v1607 guests exhibit the same behavior!I recognize KVP is not the most commonly-used feature in the Hyper-V space -- there's not even any PowerShell interface for it -- but I have found it to be very helpful in scripting build-out of isolated test lab environments. If only for the additional dependency on guest credentials, I would hate to need to augment use of KVP with a PowerShell Direct shim.