In some bootstrapping environments, you don't have fancy things like Active Directory domains or valid DNS entries. You have to connect to machines with IP addresses and no machines have certificates yet. This is the scenario where Workflows can matter most and it's where most Powershell Remoting howto's have failed me. However, there is a fast and (relatively) easy way to have Powershell Remoting (and, thus, Workflows) in such arid, hostile environments.
The Situtation
You're logged into machine Foo. You want to execute remote Powershell scripts (or get a Powershell session) on machine Bar. There is no AD environment and you can only address machines by IP.
The Details
Foo's IP: 192.168.0.1
Bar's IP: 192.168.0.2
Do this
On both machines, in a Powershell session with Admin rights:
Enable-PSRemoting -Force
This enables the WinRM service, pokes a hole in the Windows Firewall, and does a few other things to enable remote Powershelling.
Then...
Set-Item WSMan:\localhost\Client\TrustedHosts -Value '192.168.0.*'
This adds the network 192.168.0.* to the list of Trusted Hosts, which is a requirement when you use Remote Powershell with 'default' authentication in WinRM.
You could even run the above commands in an OS template, so that all new Windows machines in your virtual environment will accept remote Powershell sessions.
Test it
On Foo, run:
Enter-PSSession -ComputerName 192.168.0.2 -Credential $(Get-Credential)
The other requirement when using Remote Powershell with 'default' authentication is that you specify explicit credentials (no pass-through creds). So enter your credentials at the prompt and enjoy your new remote Powershell session. You can also now run Workflows in your environment, so you can get back to bootstrapping your datacenter!
No comments:
Post a Comment