Null Routes on Windows 7

Null routes are a useful way to quickly discard packets from an unwanted address or network, especially when you’ve not got immediate or any access to the upstream/gateway router.

I had a client PC that was being hammered over a port forward from a router I had no administrative control. I logged a support request for the upstream router, but rather than wait two days to chase up the request, I added a null route to the client PC.

Typically I add a route to a non-existent IP on the network, but the upstream router was intercepting the ARP requests for the non-existent IP and forwarding on the packet.

I then tried adding a route for the host to point to the loopback address (127.0.0.1), but got a “The route addition failed: The parameter is incorrect” error. Helpful.

After trial and error I got the null route working by specifying the current default gateway address and the software loopback interface like this:

route  -p add <IP address> mask 255.255.255.2555 <gateway address> if 1

You may need to use route print to check to see that the interface number for the loopback interface is 1. If the number isn’t 1, then use that number instead of 1 above.

If you’re looking at null routing for sshd/OpenSSH/RDP, then have a look at the ServerFault entries here and here.

Navigating Remote Symlinks on a Windows Server from a Windows Client (or, Poor Man’s DFS Links Without DFS Installed)

I set up a bunch of symlinks in a share on a Windows Server 2008 R2 install, pointing to a range of different UNC paths. My testing on the server showed that the symlink traversal was working fine, but on a Windows 7 install I was getting the following error:

“The symbolic link cannot be followed because its type is disabled.”

Odd error. After much mucking about I found that the fsutil command is used to control this behaviour. The following command was used to display the current symlink evaluation methods:

fsutil behavior query SymlinkEvaluation

which resulted in the following:

Local to local symbolic links are enabled.
Local to remote symbolic links are enabled.
Remote to local symbolic links are disabled.
Remote to remote symbolic links are disabled.

Bingo. The Remote to Local evaluation mode is disabled, which is causing the error. Local to Remote evaluation mode is enabled, which is why the symlink traversal was working on the server. I verified that the problem was resolved by issuing the following command on the Windows 7 install:

fsutil behavior set SymlinkEvaluation L2L:1 L2R:1 R2R:1 R2L:1

Excellent, the symlinks are now followed without error. Finally I rolled out the above change via Group Policy. The four modes can be controlled by using Group Policy Editor and navigating to Computer Configuration > Administrative Templates > System > Filesystem and configuring "Selectively allow the evaluation of a symbolic link".

Cannot Install RSAT on Windows 7 with SP1

If you try and install Remote Server Administration Tools for Windows 7 on a Windows 7 PC with SP1 installed, you’ll get the following error: "The update is not applicable to your computer."

Either install RSAT prior to installing SP1 or wait until Remote Server Administration Tools for Windows 7 with SP1 is released in Spring 2011 (March-May for those of us who are Northern Hemisphere challenged).

Windows 7 Experience Index and VMWare Workstation 7.0

Here’s the WEI for my Lenovo ThinkPad T410 (Core i7-620M, 4GB DDR3 RAM, 128GB 2nd Gen Samsung SSD) running Windows 7 Ultimate with latest drivers from Lenovo and the latest laptopvideo2go.com Modded INF for NVidia’s latest WHQL drivers (197.16) – only installed due to the instabilities with Lenovo’s supplied 188.25 ones.

And here’s the WEI for a Windows 7 Pro VM running inside VMWare Workstation 7.0.

Yes, the VM is running Aero with transparency! Also interesting to note that the host must be performing some VMDK caching for the increased score on the hard drive performance.

With these figures I’m going to be spending more time inside VMs than on the host. I was quite stunned to see how well the Internet Explorer 9 Preview ran – in particular the speed tests - inside the VM.

Restoring Computer Description in the Network Folder on Windows Vista and Windows 7

OK, this is definitely a rant. One of the biggest UI changes made to Vista and 7 that really gets my back up is the inability to add the Computer Description as a column to the Details view in the Network folder. A lot of organisations name their PCs by asset number, service tag, or use an auto-increment through RIS/WDS/etc.
I suppose Microsoft consider that small businesses will name their PCs on a personal or role-based model and that Enterprises will use an appropriate Service Desk application for finding PCs in the network, but apparently removing a folder view that was available in XP is definitely a regression in my books.
A picture paints a thousand words, so here’s a folder view from XP:

Name provides the NetBIOS/DNS Name of the PCs in the network and Comments provides the Computer Description field found in the Computer Name tab in the System Properties window.
Here’s the corresponding default view from Vista/7:

Try as you might, you can’t add the Computer Description column to that view.
After much cursing, wailing and gnashing of teeth I managed to find a way of getting around this, thanks to “Rico Dog” at this Windows Vista IT Pro Forum post. The solution is to use an existing Windows XP PC to get a shortcut copied across to your Vista/7 machines. if you don’t have an XP machine, consider using Virtual PC and XP Mode on Windows 7 or running up a Windows XP virtual machine using Virtual PC 2007 on Windows Vista.
Here’s the process for getting the shortcut:

• Open up My Network Places
• Open up Entire Network
• Open up Microsoft Windows Network
• Drag the required workgroup/domain icon to the Desktop
• A shortcut for the workgroup/domain will be created on the Desktop
• Copy the shortcut from the Desktop over to your Windows Vista or Windows 7 PC
• Open up the shortcut

You’ll now have a window looking like:

The Comments column contains the Computer Description fields for the corresponding PCs.
There must be a way to do this through the GUI, or even create the script via VBScript/Powershell but I haven’t worked it out yet.
Hope this helps anyone else trying to achieve the same thing.

EDIT: an anonymous commenter (thanks!) mentioned that creating a folder named "Network.{208d2c60-3aea-1069-a2d7-08002b30309d}" without the quotes will enable this functionality without a need for an XP/2003 system. The reference for the source is the following TechNet Forum post.