I needed to adjust the scope of a built-in firewall rule in a couple of servers, restricting the remote IPs to a list of UVM subnets in CIDR notation. The netsh documentation describes the syntax for a list as comma-separated values (no spaces). But I kept getting errors with the command:
netsh advfirewall firewall set rule name="Windows Internet Naming Service (WINS) (NB-Name-UDP-In)" remoteip="10.10.0.0/16,10.11.0.0/16,10.12.0.0/16"
Finally, I actually read the error message:
For ‘set’ commands, the ‘new’ keyword must be present and must not be the last argument provided.
And the related part of the usage text:
Values after the new keyword are updated in the rule. If there are no values, or keyword new is missing, no changes are made.
One little three-letter keyword was all I needed:
netsh advfirewall firewall set rule name="Windows Internet Naming Service (WINS) (NB-Name-UDP-In)" new remoteip="10.100.0.0/16,10.101.0.0/16,10.102.0.0/16"
It’s one of the first questions that we ask clients when we’re helping diagnose a problem with a network resource. There are several different ways to determine your IP address. There’s even a website, whatsmyip.org which will show you what Internet servers think your IP address is.
In this post, I describe how to determine your IP address(es) on Windows 7 using the control panel. You can also use the ipconfig command-line tool, but if you know about that tool, you probably don’t need me to tell you about it.
Network and Sharing Center
One of my favorite aspects of Windows 7 is the search feature in the start menu. As you type a search term, Windows will show you matching programs and documents.
As a case in point, you can type Network in the Start Menu search box, and click the Network and Sharing Center control panel item in the search result.
Alternatively, you can open Control Panel, then Network and Internet, and then click the Network and Sharing Center item.
I’ve been working with client to try to identify why we sometime log onto the UVM wifi network successfully before workstation logon, but frequently this fails and drive mappings are not performed successfully.
In consulting with a colleague, he suggested that it could be a race condition between the network authorizing the connection and the Windows system DHCP Client behavior.
In looking for details of the dhcp process on a Windows Vista client, I found a couple useful resources:
TCP/IP Fundamentals for Microsoft Windows
PDF book discussing TCP/IP protocols and services, and their configuration. Over 500 virtual pages.
Microsoft Enterprise Networking Team blog: DHCP Client Behavior
Now this is good detail! I have to review this blog in more detail.
Last night, I stumbled across this video:
Office Casual: How to work with the ribbon
The Inside Office Online blog post for the video includes links to the interactive guides for the big five office applications.
I haven’t watched the whole thing, yet, but it also links to video of a presentation that discusses the evolution of the ribbon interface. My son and I watched the first ten minutes or so before bed last night, and he’s interested in watching the rest. Hurray for GeekKids!
Other agenda items, today:
I got the windump capture to work, using the local computer policy startup script setting. I did the same thing using the nmcap.exe command-line component of Microsoft’s Network Monitor 3.2. And one thing I learned is that I don’t know nearly enough about network communications.
I like GUIs, but I also like getting things done via the command line. I was hunting around to see if there was a way to change the MTU setting for my NICs without having to edit the registry, and I found that the netsh interfaces context exposes this attribute:
netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Local Area Connection" mtu=1500 store=persistent
I used this to change the MTU for my Wifi and Ethernet interfaces from 1300 — Cisco’s preferred setting from Win9x days — back to the Windows default. And now the performance problem I was having yesterday has been resolved.
[ via http://www.annoyances.org/exec/forum/winvista/t1158155937]