Deliberations from Dave

Replacing the Windows 7 Network Indicator

One of the things missing from Windows 7 is the network activity indicator in the system tray. It's been replaced with a static icon, supposedly to reduce power consumption on laptops and reduce visual clutter.

I'm not sure I believe the first reason, and the second is invalid because it could be left disabled as it was by default in Windows Vista.

Nevertheless, I've written a tiny .NET replacement for the icon. It's not identical - it's more visual than the original icons. It's also configurable so that the two indicators can show disk or disk activity instead of the network, or show error-type conditions - for example, show the light if the CPU is running at more than 95%.

The download is attached to this post - it's a small MSI. It's really an early beta version, but seems to run OK on my Windows 7 workstation and on the Vista development workstation I built it on.

Please post any bugs in the comments!

VMWare Workstation and Windows 7

I've been having weird connectivity issues with Windows 7 and VMWare Workstation 6.5.2. None of the networking "really" worked, even in bridged mode - nslookup worked, ping worked, but anything using TCP did not (http, ftp and so forth).

Quick Fix for Bridge mode at least: An Inbound firewall rule that permits the VMWare worker application to send and receive all traffic.

Open Windows Firewall with Advanced Security. Right-click on Inbound Rules and choose New Rule:

Ensure Create a Program Rule is selected , and click Next:

Enter the path to the VMWare worker process, vmware-vmx.exe. I'm running Windows 7 x64, so for me it was C:\Program Files (x86)\VMWare\VMWare Workstation\x64\vmware-vmx.exe - yours may be different;  then click Next:

Accept the default values for the Action and Profile pages, and click Next:

Enter a name and an optional description for the rule, and click Finish:

Locate the rule, right-click it and choose Properties. Select the Advanced tab and change the Edge Traversal setting to Allow Edge Traversal:

That's it - networking should work a lot better now.

Windows Mobile 6.1 and Australian DST

I have an HTC Touch Pro. Runs Windows Mobile 6.1 - and I'm really happy with the device. Unfortunately WinMo 6 timezone definitions do not include the right settings for Australia - we changed the start dates and end dates a while back.

I couldn't find a suitable download from Microsoft to fix the timezones, but I did find a TimeZone Editor on MobilitySite. If you're a Firefox user you'll need to allow scripting to be able to download the ZIP file (I've also attached it below - it is not my work but that of "Galina" in New Zealand).

Five steps required:

1. Run the application (extract it to your storage card or \Program Files or similar)
2. Action --> Get Current
3. Change the start and end date rules (not intuitive). I think "5 Sunday" means last Sunday of the month
4. Action --> Set Current
5. Restart the phone.

That last one was the most annoying - I spent ages trying to figure out why the change had not worked.

Australian BlackList released to the world

Well, no surprises there. The Australian list of blocked sites is supposedly now in the wild - and all reports I've seen thus far indicate it's correct, at least for the most part.

ACMA has come down pretty hard on sites linking to blocked material and since the list is sure to contain at least one site that really IS on the list, I can't in good conscience link to the leaked list.

But I'm thinking that if you searched Google for it, you'd find it on a community edited site (a wiki) containing government and corporate leaks. Possibly even run by a non-profit org.

As before, my key concerns are that there's no way to request that you be removed from the list, and that the list contains sites that are, at least at this moment in time, NOT illegal, X rated or R rated. Many of the sites apparently link to dead pages or items, and thus return 404's. Others seem to be miscategorized - a dentist, a tourist operator.

References: OCAU, Sydney Morning Herald, The Australian, WhirlPool.

Fixing WDS Long Boot Times

Here’s a little tip from a colleague of mine, who we’ll call Geoff for no reason other than that that is his name.

When deploying images from Windows Deployment Services (WDS), sometimes the WDS server seemingly does not respond for about 10-15 seconds, even if the response delay is set to 0 seconds. The server will be authorised, it will have boot images, but the PXE “spinning bar” sits there attempting to hypnotise the user instead of booting from the network.

The cause appears to be DHCP configuration. Here’s a screenshot of the WDS console attempting to explain option 60:

And here’s the help information for option 60, referenced directly by the link at the bottom of the dialog:

You can set the Dynamic Host Configuration Protocol (DHCP) configuration options on the DHCP tab of the server properties. The default configuration of Windows Deployment Services assumes that the Microsoft DHCP Server service and Windows Deployment Services server are on separate physical computers. If DHCP and Windows Deployment Services are running on the same computer, then you should configure the following options. You can also configure these options at the command prompt.

• To configure DHCP option 60, run:

  WDSUTIL /set-server /DHCPoption60:yes

• To configure port 67, run:

  WDSUTIL /set-server /usedhcpports:no

The reason you must configure these options in this scenario is because, DHCP must inform the client computer that there is a PXE server listening on the network by including DHCP option tag 60 in the DHCPOffer packet. In addition, because DHCP listens on port 67 by default, when Windows Deployment Services and DHCP exist on the same computer, the Windows Deployment Services PXE server is not able to listen on port 67 for incoming PXE boot requests.

As you can see, the documentation is of no help. So instead of trying to set option 60 to “PXEClient”, set it to the IP address of the WDS server.

I did this in my test environment and the average boot time of both new and existing PXE clients went from 25 seconds to 2 seconds.

Awesome Geoff!