Michael Sorens's questions

I am trying to bring up a virtual machine that needs to be able to create new sessions (with New-PSSession). The highly engaging about_Remote_Troubleshooting is my constant companion, of course!

After bringing up a basic machine (Win 8.1 Enterprise):

• My company's primary domain is, say, mycompany.com.
• We have a development domain dev.mycompany.com so that developers have a sandbox to play with.
• I added the new VM (named my-vm) to the development domain dev.mycompany.com.
• I have a local account on the new VM, my-vm\msorens which is in the Administrators group on the local machine.

First Hurdle:

Attempting to run just New-PSSession failed with access denied because of cross-domain issues. Per the troubleshooting page referenced above:

When a user in another domain is a member of the Administrators group on the local computer, the user cannot connect to the local computer remotely with Administrator privileges.

I am not convinced this is true (due to my inexperience in domain issues) but applying the recipe for that remedy allowed the basic New-PSSession to work:

New-ItemProperty `
-Name LocalAccountTokenFilterPolicy `
-Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System `
-PropertyType DWord `
-Value 1

(And that, while less secure, is fine, as it is just a sandbox VM.)

Second Hurdle:

With the above patch in place I could successfully do any of these:

PS> New-PSSession
PS> New-PSSession -ComputerName localhost
PS> New-PSSession -ComputerName my-vm

However, my actual need is to give the FQDN of the machine:

PS> New-PSSession -ComputerName my-vm.dev.mycompany.com

That fails because of missing credentials. Which brings us to this:

PS> New-PSSession -ComputerName my-vm.dev.mycompany.com -Credential (Get-Credential)

I have tried my local (my-vm) credentials, which resulted in WinRM cannot process the request; no logon servers available.

I have tried my company domain credentials (note that is mycompany.com not the domain the VM is actually on dev.mycompany.com), which resulted in Access is denied.

Is there a way to make this work?

Technet has a nice article (Windows PowerShell for Windows Server 2012 and Windows 8) listing a myriad of PowerShell cmdlets available on the latest OSes. Often there are easy (or not so easy:-) ways to backport some of those to earlier OSes. In particular I am interested in installing the MSMQ cmdlets in Windows 7. Can this be done and if so how? My searches thusfar have drawn a blank.

The presence of the special PowerShell variable $_ in the replacement string causes odd behavior; I am wondering if there is something about escaping I am missing or if this is just a defect.

The output of this code...

$text = "WORD1 WORD2 WORD3 WORD4"
$newText = 'new $_ text'
$newText
$text -replace "WORD3",$newText

... is this, where $_ is interpolated with the original contents of $text for some reason during the replace operation:

new $_ text
WORD1 WORD2 new WORD1 WORD2 WORD3 WORD4 text WORD4

Replace should treat its second parameter as a literal--using no interpolation--which is true for most anything, including things that look like regular variables like this:

$foo = "HELLO"
$text = "WORD1 WORD2 WORD3 WORD4"
$newText = 'new $foo text'
$newText
$text -replace "WORD3",$newText

... and its output is:

new $foo text
WORD1 WORD2 new $foo text WORD4

But the presence of $_ causes interpolation. Similar problem with $$. As far as I can tell no other special variables cause interpolation.

Note that the same problem occurs with inline code like this:

$text -replace "WORD3",'new $_ text'

I split it out above just to show that the replacement string was correct before the replace operation. Curiously, if I replace the single quotes with double quotes here to ask for interpolation, the result is different. That is, this code:

$text -replace "WORD3","new $_ text"

produces the expected

WORD1 WORD2 new  text WORD4

not the baffling

WORD1 WORD2 new $foo text WORD4

In attempting to create a PowerShell script using remoting I ran into what I believe is the double-hop problem. In that article, Perriman gives a succinct description of the problem as well as the specific steps to resolve the issue (almost trivial if you know the commands, but for someone less familiar like myself, that information was invaluable!).

I ran Enable-WSManCredSSP Server on my Win7 server without incident, but attempting to run Enable-WSManCredSSP Client –DelegateComputer <FQDN of the server> on my Win7 client generated this error:

Enable-WSManCredSSP : The client cannot connect to the destination specified
in the request. Verify that the service on the destination is running and
is accepting requests.
Consult the logs and documentation for the WS-Management service running
on the destination, most commonly IIS or WinRM. If the destination
is the WinRM service, run the following com mand on the destination
to analyze and configure the WinRM service: "winrm quickconfig".

Running winrm quickconfig confirmed my server was running WinRM:

WinRM already is set up to receive requests on this machine.
WinRM already is set up for remote management on this machine.

And Get-WSManCredSSP confirmed my server was ready to accept credentials from a client:

The machine is not configured to allow delegating fresh credentials.
This computer is configured to receive credentials from a remote client computer.

I also found Boessen's article on WinRM wherein he describes general WinRM setup and found one tidbit to get a useful data point in diagnosis; this command run on the client uses the winrs tool to remotely access the server:

winrs -r:http://<FQDN of my server>:5985 -u:<myDomain>\msorens "dir c:\"

That command returned the expected result, the contents of the root directory on the server, without incident, confirming that my FQDN is correct and that WinRM is enabled.

Boessen indicates port 5985 is the default for Win7; this command run on the server confirms a value of 5985:

get-item wsman:\localhost\listener\listener*\port

The question: Why am I unable to execute the Enable-WSManCredSSP command on the client side?

2011.06.07 Update

I found a solution to the above question: invoking Enable-PSRemoting, advertised to configure a computer to receive remote commands, allowed the Enable-WSManCredSSP on the client to work successfully! Curious, but its man page indicates it does a number of different actions, so I assume one of those inadvertantly did what I needed.

But then I reached another roadblock when I attempted to use CredSSP authentication. Here is the command:

Invoke-Command { Write-Host "hello, world" } -computername $serverName `
-credential $testCred  -Authentication Credssp

And here is the response:

Connecting to remote server failed with the following error message:
The WinRM client cannot process the request. A computer policy does not allow
the delegation of the user credentials to the target computer. Use gpedit.msc
and look at the following policy: Computer Configuration
-> Administrative Templates -> System -> Credentials Delegation
-> Allow Delegating Fresh Credentials.  Verify that it is enabled and
configured with an SPN appropriate for the target computer. For example,
for a target computer name "myserver.domain.com", the SPN can be one of
the following: WSMAN /myserver.domain.com or WSMAN/*.domain.com.
For more information, see the about_Remote_Troubleshooting Help topic.

I verified the settings just as this remarkably helpful error message suggested, and it looks to me like it is configured properly.

The new question: What does this remote connection attempt with CredSSP fail?

In answering please keep the following in mind: Let me dispell in advance any notion that I know what I am doing here, any appearance to the contrary notwithstanding.:-) Windows admin is not my area of expertise!

I have been fighting a VNC configuration issue for sometime now. Even with the additional recent assistance of a friend/guru more skilled than I, the issue continued to elude me:

Running a TightVNC server on machine "myServer" (WinXPsp2) set to display/port 1, one could use vncviewer on machine "myClient" to connect iff someone is locally logged in to myServer. So if I am logged in locally to the server, on my client I could connect with vncviewer. Logout of the server locally; vncviewer could not establish a connection. Log back in on the server, and vncviewer again connects from the client.

I just finished poring carefully through all permutations of test cases (I have a spreadsheet of test results available) and my remarkable conclusion is this:

(1) When logged out on server, the VNC service reverts to display/port 0. When logged in on server, it honors the port set in the configuration.
(2) When logged out on server, the VNC service reverts to an unknown default password. When logged in on server, it honors the password set in the configuration.

So with the VNC server set to port 1, if I am logged in on the server, vncviewer connects to port 1. If logged out, vncviewer connects only on port 0! Unfortunately, it connects but it will not authenticate, because, as I said above, it not only reverts the port but also the password, and I do not know what the default password is (TightVNC site claims there is no default password).

Note that my test cases include:

• Connecting with and without a putty-secured tunnel.
• Connecting with client on internet and client on intranet.
• Connecting with vncviewer and with a browser.

Is this a known defect? I could find nothing on it with a web search. Is there any workaround so that one could connect with vncviewer?