http://www.minasi.com/newsletters/nws1304.htm
If you work with PowerShell remoting, event log collections, IIS 7/8 management or any other number of Windows remote management issues, you may have to enable the protocol “WinRM.” Windows Remote Management first appeared in Vista and it’s a important computer-to-computer protocol that is slowly replacing the old standard Remote Procedure Call (RPC) protocol that’s been in Windows since the mid-80’s. (Start up Outlook and get your email from Exchange and you’re talking over RPC.) RPC’s a nice protocol and has served us well, but Microsoft designed it in a time before we all decided that it’d be a great idea to connect our home and office networks to a single world-wide network that happens to be populated by millions of criminals. (I speak in that context, of course, about the Internet.) Microsoft designed WinRM from the ground up with security and cross-platform compatibility in mind, and as far as many of us are concerned, the more WinRM-based remoting — which implies less RPC-based remoting — the better.
By default, most Windows boxes from Vista onward can make requests over WinRM — act as clients — but are cannot hear (and therefore cannot respond to) to requests from other systems. To allow a Windows system to be able to respond to WinRM requests, you have to enable what Microsoft calls a WinRM “listener.” The easiest way to turn on a WinRM listener on a system is to open an elevated command prompt and type
winrm quickconfig -q
That normally works fine (or you can use a group policy setting in Computer Configuration / Administrative Templates / System / Windows Remote Management (WinRM) /WinRM Service called “Allow remote server management through WinRM”), but sometimes you get this fairly scary-looking error:
PS C:\windows> winrm quickconfig WinRM service is already running on this machine. WSManFault Message ProviderFault WSManFault Message = WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again. Error number: -2144108183 0x80338169 WinRM firewall exception will not work since one of the network c onnection types on this machine is set to Public. Change the netw ork connection type to either Domain or Private and try again.
So the first time I connected to a network on one or more of my NICs, then Windows asked me if the network it was connecting to was public or private. Vista and Windows 7 pop up a Windows dialog to ask, but Windows 8 shows something like this:
So, assuming that I want to mess with PowerShell remoting on my Windows boxes, I’ve got to figure out which NICs are set to public, and from there I need to know how to change it.
The Metro piece above doesn’t tell you your current settings, but if you go to the Network and Sharing Center (doesn’t that sound like a place that’s got milk and cookies available 24/7?) then you see something like this:
Now, in Vista and 7, you could change the network type between public and private right here in the Center, but Windows 8’s got another way. Go to the settings configuration page — press the Windows key and “I” — and then click the icon in the lower left-hand part of your screen that represents your network. Right-click on any NIC’s connection and you’ll get the choice to enable or disable sharing, as you see in this screen shot:
As you’ve probably figured out, turning sharing on leads to your network being classified as “Private,” and turning sharing off makes it “Public.” I have to admit that doing this stumped me when Windows 8 first came out, as I kept wanting to poke around the Network and Sharing Center — the cookies there are great — to locate what I imagined was a well-hidden icon that would let me do the Public/Private shift. Finally, my colleague Doug Spindler posted it on a distribution list we’re both on. (“Duh!” Can’t win ’em all, I guess.) That led me to do a bit more research, and so I can tell you that…
There is also a PowerShell way, via two commands: Get-NetConnectionProfile and Set-NetConnectionProfile. If you type simple “get-netconnectionprofile,” then you get a list of your NICs and several pieces of information about each one, including
- “Name,” which would probably be better named “network name” or “SSID.” The network and access point names that you see in the above screen shot — PleaseStayOff5G, JP4620L, PleaseStayOff, TWDB815 and the rest — are what these two PowerShell commands call your NIC’s “name.”
- “InterfaceAlias,” which is just the name that your NIC shows in ipconfig. Pre-Windows 8, most wired NICs got names like “Local Area Connection” or “Wireless Network Connection,” but Windows 8 changes those to “Ethernet” or “Wi-Fi,” which are nice — no blanks in the names to make scripting harder.
- NetworkCategory: this is the firewall profile type value that we’re looking for. It’ll either be DomainAthenticated, Public, or Private.
- IPv6 and IPv4: what kind of connectivity you have on either or both flavors of IP.
For example, here’s a run of get-networkconnectionprofile for just my wireless card which, again, is named “Wi-Fi;”
PS C:\> Get-NetConnectionProfile -InterfaceAlias wi-fi Name : PleaseStayOff InterfaceAlias : Wi-Fi InterfaceIndex : 13 NetworkCategory : Public IPv4Connectivity : Internet IPv6Connectivity : Internet
To change this from a Public NIC to a Private NIC, I just use Set-NetConnectionProfile and identify the NIC that I want to change either with its name (“PleaseStayOff” in this example) or its InterfaceAlias (“Wi-Fi” here). Thus, I could run either of the following two commands to change this adapter to Private:
Set-NetConnectionProfile -name "PleaseStayOff5g" -NetworkCategory Public Set-NetConnectionProfile -interfacealias Ethernet -NetworkCategory Public
So if you’re playing with PowerShell remoting but can’t get to first base, check to see if you can’t make the silly thing happy by shifting your NIC’s “NetworkCategory.”