Things they stole back in Vista

(Originally posted Nov. 25, 2007 - the the list of complaints keeps on growing...)

If this continues, I will have torn all my hair off in pure frustration as to what Microsoft decided I do not need. It turns out that Vista (as in my Vista Business) has taken away several features that I had gotten used to in standard Windows XP. Aaaaargh - this just makes my point as to whether to choose a freely developed OS, with freely available features thrown in (Linux), or yet another time stay with so-called (un)supported licensed software. Enough said, here's my frustration list:

• Backup is gone! That is, they did add some substitute only good for backing up your whole disk to an external source. What I used to do in XP was backing up a subset of files (my data) to a local file destination, and then took that file and burnt it to a CD for offsite storage. Forget it - the old NTBackup software is gone. I found a good substitute in the free Simply Safe Backup software, but that's beside the point.
• Telnet is gone! Not too much of an alarm though, I found it under Control Panel-Programs and features-Turn Windows features on or off.
• Windows Explorer no longer lets you completely turn off the "Remember each folder's view settings" (although the choice is there under Tools-Advanced). When I browse the folder hierarchy, I normally choose to see file details. If Explorer decides to however, it just jumps to thumbnail view, I guess when you enter a folder where graphics files are present. You'll also notice that they took away the "up" button to go one level up the directory tree. You can always go "back" to the previous folder you visited, but that's not always the parent folder. And of course, there's no way to customize the toolbar to bring that button back...
• The defragmenter has lost the little that was left of its visual interface (it had already suffered the transition from 9x to XP badly). Luckily, there are good third-party tools out there, like the free Defraggler, that shows you where each file is located on the disk and even gives you the option to only defrag the files you need quick access to. With the new "improved" Windows, this is a necessary addon.

Apart from that, I found a couple of tricks to be most necessary to get around:

• Run as administrator seems to be the general medicine if a program fails to do what you expect it to. Especially programs that access any part of the computer other than your screen/desktop (like registry, folders for programs, network ports etc.). I guess this is part of the new security model requiring you to say that you are sure a dozen times before actually doing what you are sure you want to do.
• Ethereal Wireshark network packet tracer needs to be run with this option - otherwise you will not find any network adapters to inspect.
• DevPHP had to be run as administrator to avoid loosing all settings upon exit. Assumingly this has to do with the new way Microsoft has invented to handle writing to the HkeyLocalMachine hive of the registry - where you THINK you write to that key, whileas actually writing to your HkeyCurrentUser hive. This is not comfirmed though.
• Check out this brilliant website for clues: Vista Rewired -It made it right into my group of favourite bookmarks!

If Microsoft could just do a little bit more than pleasing newbies to Windows (do they?) and let us nerdies also have a few goodies, they might actually have some of us recommend their stuff. As for now, I sincerely hate Windows Vista and recommend everyone (including my customers) who buys a new computer to stick with XP. Vista is just a really bad idea.

View Source with something else than Notepad in Internet Explorer

I'm doing some web development at the time, and since Internet Explorer is the customer's and their customers' preferred web browser, it is a good idea to check how the pages look even in IE (of course, Mozilla Firefox is my own open source preference).

If you want to check the source the browser is actually reading, the IE7's Page-View Source menu item will take you to a Notepad window with the source. I want to look at it in my favorite plain text editor, Notepad++ though, where I can view the code color highlighted. I might even want to clean up what I see so that the source is indented in a readable format, using the TextFX with HTML Tidy option.

So - to my business: How do I change the View Source option to run the text editor I want? Simply by a small registry hack:

------------8<----------------8<------------------
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\View Source Editor\Editor Name]
@="\"C:\\Program Files\\Notepad++\\notepad++.exe\""
------------8<----------------8<------------------

Cut and paste this into a .reg file and import to registry (if you are uncertain of how to do that, don't even try - messing with the registry is not for you). Of course, if you want to use another text editor, just change the file path accordingly. If you need to undo this hack, just delete the "View Source Editor" registry key with its full contents.

This is actually just a copy of another blog I found googling for a solution: The Thea Burger's Blog and Will's blog - Thanks for helping me out!

How to talk to a remote device that only talks to local network devices

I was asked to find out how to spare an engineer the trip to his customer abroad only to do a five minute's upload job to a device that was talking TCP/IP. The device was on a subnet that had a VPN site-to-site connection to his office, however, the device did not have a routing entry making it aware of the subnet on the other side of the VPN tunnel.

Because of limitations to the device, configuring the needed routing entry into the device was not an option, even if we were able to telnet into the device from a Remote Desktop session on a Windows computer on the same subnet.

Solution: The solution was to create a simple PPTP VPN dial-in access on that Windows computer, so that the engineer's computer could receive an IP from the same IP pool as the device he wanted to control. Yes, it meant creating a PPTP VPN tunnel back through the established site-to-site VPN tunnel, but it would work.

Caveat: Only trouble was, it didn't. Setting up a simple Routing and Remote Access server in Windows Server 2003 is a simple task, still, it just did not work. What I found after scratching my head pretty sore was that the firewall in the site-to-site VPN device on my side (the one responsible for the "outer" tunnel) was blocking all traffic that did not originate from my subnet. The PPTP GRE protocol packets from the remote site did not look like they were talking to established traffic from my side, and hence was blocked, effectively blocking the creation of the PPTP tunnel within the site-to-site tunnel. To make it work, I had to open the firewall on the site-to-site device to allow full traffic flow while running the PPTP tunnel.

After that it worked, but was quite slow, probably due to the double encrypted, double tunneled packets.

Slow Windows login (Gone in 60 seconds)

I decided that today was going to be the day I solved why my Windows XP always takes excactly 1 minute to "think" after clicking the login button and until it shows my Windows desktop and starts to load traybar applications etc..

First try was to minimize the profile size. If I were using a roaming profile this would certainly have helped, because the size of my profile folders were around 800 megs. I moved out the Thunderbird mail profile and sqeezed some more unnecessary bits out of it and came down to around 150 megs. Still a bit much, but the change in login speed should be noticeable. Result: Nada. Still took a minute to think it all over before letting me in.

The solution was right under my nose the whole time - actually letting me know upon each login that "some network drives could not reconnect". Of course not - I use my laptop on different places and I am not always connected to those network drives. I just find it convenient to have them all ready for use in explorer. No longer. I disconnected them and did a login, and the whole minute's wait was gone.

The login was no longer "Gone in 60 seconds" - the 60 seconds were gone. :)

I just wonder where I can find the time to fetch my coffee now...

Narrow-masked site-to-site VPN caveats on a Checkpoint device

I consider myself to be relatively experienced in setting up site-to-site (LAN to LAN) VPN tunnels, and to pinpoint what is wrong if the tunnel does not come up, but working today with a technician on the other side of the Atlantic to set up such a link turned out to be a challenge.

We had agreed on all cryptographic parameters, on what private subnet to be used on each side of the tunnel and of course the preshared key. The guy in the other end seemed experienced enough, but going over and in a structural manner fiddling each parameter to try to find a match did not give the break. The scenario was quite funny:

Scenario: Tunnel clears phase 1 of the negotiation, meaning that the preshared key and the IKE parameters are a match on both sides. In phase two, some discrepancy makes a "no proposal chosen" message appear in the logs on the Checkpoint.

Strange: Even though the tunnel did not come up on the Checkpoint side, it did on mine. I was able to ping devices on his side, but he was not able to ping my side.

Solution: After having tested virtually everything, the guy on the other side mentions that his device has defined a class B private network on the interface. The tunnel definition, however, was to be for a much narrower range, a 29 bits mask (255.255.255.248). Although it would be shooting sparrows with a cannon, we broadened the tunnel definition to match his device's network interface, and voilla, it worked! It seems to be a limitation of the Checkpoint device this guy was using (or a limitation of knowledge on how to configure this device correctly) - I have without trouble set up dozens of other links with a narrower tunnel IP range than what the device is running on its network interface.

Caution: If someone else experiencing a similar problem is reading this, my advice would be first to check any firewall that might be blocking traffic (it was my first guess). If you can temporarily isolate vulnerable parts of your network while testing your new tunnel, I would first bring up the tunnel with the firewall completely off.

Fileshares: Connecting with the wrong hostname

Situation: Occasionally I need to connect to servers with names formed from a spoon of alphabet soup - impossible to remember. Of course, since the customer is always right, he gets to choose the names of his own server. I however, need to refer to computer names I can remember or that has a meaning.

Workaround: Put an entry in your hosts/lmhosts file (in the c:\windows\system32\drivers\etc folder), or if you have access to the DNS or WINS server, put the entry there, using your preferred name and the IP of the server you want to reach. If, for instance, a server is named something like SA823SX3B and you want to name it FILESERVER, just put in an entry for FILESERVER with the SA823SX3B's IP. It works for ping and many other services, but:

Problem: This does (by default) NOT work if you want to connect to a NetBIOS fileshare. You can verify that firewalls etc. is not the cause of this problem by connecting via \\SA823SX3B\fileshare and even by using \\192.168.0.1\fileshare (given that that's the IP of our example server).

Solution: You need to hack the following registry key on the server in question:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\
DisableStrictNameChecking

Set the value to 1 and reboot. You can now connect to the server using any name you please, as long as it is referring to the right IP address.

Caveat: On a NT4 computer, you will still not be able to connect without using either the real name or the IP address as reference.

See Microsoft KB 281308 for a description of this parameter.

eBay thumbs - Always with Greasemonkey!

Not very technical this time, but definitely nerdy

Ever been annoyed by eBay ads with only the green camera icon on the item list page? eBay charges extra to let sellers display a thumb aside the item title, so obviously many eBay sellers only put images inside their ads - showing up after you click to view the ad.

With Greasemonkey and the Firefox web browser, the world in this respect looks a bit brighter. Greasemonkey is a client-side scripting engine addon to Firefox that processes web pages that you view in realtime.

Add this script to Greasemonkey and you get thumbs on all eBay ads that have images!

WinMed Connect preferences & setup

Situation: A client computer that were running the WinMed healthcare software application had been replaced and an attempt had been made to transfer the software to the new computer. The WinMed program and data files all reside on a server network share with no values stored in registry, so apparently recreating the shortcuts to the server located apps on the new computer should do the trick.

Problem: The WinMed Connect program was asking for path specifications every time it was run.

Solution: The WinMed Connect shortcut points to a program called xmlparse.exe in the xml subfolder of the WinMed system files. There was also a xmlparse.ini file in this folder. This needed to be copied to the Windows folder and modified with the right paths. Also the winmed.ini file located in the WinMed folder on the server had to be copied to the local Windows folder. Both files had to be given change permissions to the user who was running the program.

Which Default Gateway is default?

This is kind of a lightweight post, but still nice to know:

Scenario: I wanted to configure a new VPN device using my laptop. The laptop uses wireless to connect to the company LAN and the internet. I would use the wired network interface to connect to the VPN device to configure it.

Problem: Once the VPN device is connected to the wired interface, all traffic destined for the internet insists on being routed through the wired, not the wireless connection. That's a problem when the wireless interface is on the subnet where internet can be reached.

Dead end: I tried to go to Control panel-Network connections, selecting Advanced-Advanced settings from the menu, to set the wireless interface on top of the "connections" list. This did not work - it would only have worked for network services like file sharing etc..

Clue: Using the command-prompt command "route print" (listing the current routing table of the computer), I can see that the computer has chosen the default gateway (given over DHCP by the VPN device) on the wired interface as default. The default gateway given by the company LAN DHCP server over the wireless interface has a higher metric (30) than the wired interface gateway route (20). Result: Wired interface default gateway becomes the computer's first choice of gateway.

Reason: So I need a way to change the metric of the default gateway defined on the wireless network interface. On Microsoft Knowledge Base, I found article no. 315088. It explains that Windows assigns metrics based on the connection speed. That's normally fine, but it did not tell me how to accomplish what I wanted. The referenced article no. 258487 however does:

Solution: I opened the wireless interface network properties, selected the Internet Protocol and opened its properties, clicked advanced, and manually overrided the Adapter Metric by setting it to 15.

I could set up my VPN device and stay online on the internet while doing it, however I reset the Adapter Metric when I was done. I think Microsoft's assumption that the faster interface should be preferred is generally a good idea, only not in this case!

MTU too large, communication stalls (under research)

I have been researching this problem for some time now, found a workaround, but no problem reason and no good permanent solution:

Environment and problem: LAN1 is connected to LAN2 via a LINUX PC with two network interfaces, running NAT in both directions. On LAN2, a VPN device has a site-to-site VPN tunnel over the internet to a remote LAN3. When computers on LAN1 tries to talk to computers on LAN3, it works well on some computers, while on others, all comms stalls after a few packets. There are other LANs connected to LAN2 via the same VPN device where the problem never occurs.

Clue: When connecting to LAN2 over a VPN client from a remote location, the communication to LAN3 always works.

Technical details: Using the Ethereal Wireshark network protocol analyzer, a bunch of TCP DUP ACK messages occurs around the time of the freeze.

Workaround: On computers where this is a problem, if the MTU value of the network interface used is modified to 1300 (or 514 hex), the problem goes away. This is done here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ID for Adapter
For a reference on this value, see Microsoft Knowledge Base art. no. 314053.

Potential negative effects of workaround: Smaller MTUs cause more network overhead because smaller and thereby more network packets must be transmitted, all with their own network packet header. In practice though, I could see no negative effect in my case.

Problem cause: Not found. The MTU that should have been used for the overall transfer should have been determined by the lowest MTU given by any router along the path the packets take. My assumption is therefore that some router "out there" is set up with a MTU larger than the network packet size it can actually handle (is this possible?). It works for the first few packets, then the router gets overloaded and freezes.

Permanent solution NOT found: A permanent solution where the MTU value of each client computer is untouched has not been found. Given that my assumption is right, a permanent solution can only be found if the router working under false MTU conditions can be identified and accordingly modified.

Further research: I want to try setting the MTU of the interfaces on the LINUX computer that routes between LAN1 and LAN2 to 1300. If my theory holds, this should lower the overall packet size so that the problem goes away. Since traffic load between the two LANs are never significant, it is acceptible in my case to live with that, even though it does not address the problem at the router that I assume is causing the real problem.

UPDATES ON MY RESEARCH WILL (may) FOLLOW

Intro

Hello all, just a very brief intro on what you will find on this blog. Contents will be nerdy notes from my nerdy work as a consultant on practically anything that has to do with computers, in addition to the occasional note on technology related hobbies. It is supposed to work as an easily accessible brain dump to get back to the next time I encounter the same problem again. Use it if you like, comment on my posts if you like, but please note that:

• This blog will NOT be updated regularly
• This blog will NOT necessarily have technically correct info (it just worked for me)

Enjoy!

Event: i8042prt failed to start

On an HP Proliant DL 380 G5 server with Windows 2003 Server, the annoying "A device or service failed to start" occurred during boot. The computer shared screen, mouse and keyboard with another computer via a KVM switch. Event log showed a "i8042prt failed to start" event.

The solution was found on HPs support pages. In brief, it states that the following regkey must be changed:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\i8042prt\Parameters

The value Headless must be changed to value 0x1 (REG_DWORD)
Data: 0x1 (Allow Hotplugging) | 0x0 (Hotplugging not allowed)

Problem cause (assumed): This happens when the computer boots without finding any keyboard/mouse. This occurs when the computer is connected to a KVM switch and the KVM serves another computer during boot.

Ni-DAQ test panel does not run

Platform: Windows Server 2003 with NiDaq 8.0

User is not allowed to run test panel under Ni-Daq's "Measurement and Automation" (the choice is grayed out). A program that uses Ni-Daq's libraries terminates silently with user credentials. Both problems are related.

Solution: Users who want to be able to run the above mentioned programs must be given Modify or Full control permissions on this folder:

C:\Program Files\National Instruments\Shared\platform\memory\sharedMemoryFiles

It took a lot of research and experimenting with permissions on files and registry keys to reach this conclusion, but it seems consistent that this was the problem.

Caveat: When connecting to the server via Remote Desktop as a user, I was not allowed to run the test panel or other programs using the Ni-Daqs libraries, even if the above solution was applied. Being an administrator, I was allowed. Researching the problem via Remote Desktop at first certainly put a few extra hours of work into finding the solution :(

Caveat 2: On older NT4 systems this will probably not be a problem, because it does not restrict the permissions on C:\program files to readonly for standard users (by default).

Caveat 3: On older Ni-Daq versions (ver. 6.9.1 comfirmed), the above mentioned folder does not exist. Whether that means that the problem is then irrelevant or to be solved differently is not known.