The HTML help in Windows uses IE objects to render the pages within your CHM file. Anything that could be written in a web page could be written into one of your HTML help pages as well. This includes active scripting, which can be devastating to you if your launch something malicious. Because you open CHM files locally, security for the HTML is less than if you were browsing the internet. One of the things Microsoft did was to make an assumption that things residing on your local computer were local, and everything else, including network drives, was not. What you're experiencing is a blocking by Microsoft of CHM files when opened from a non-local source. Nothing you did in your copy from the CD was wrong.

Your friends who can read it probably have had their local computer reset to allow reading of HTML CHM help files from the network. There is a very (and I do mean very) long Knowledge Base article on Microsoft's site describing the issue and how to work around it. But here is my boiled down version.

Add this registry key:

1. Open your Registry Editor and navigate to:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x
2. If you see a subkey called ItssRestrictions, click it, otherwise right-click the 1.x folder, select New | Key, and add it - then click on it.
3. In the right-pane, look for an entry called MaxAllowedZone. If you do not see it, right-click in the right-pane and select New | DWORD Value, then add it.
4. Once added, double-click it to edit it's value. Enter a 1 and press OK
5. Close the Registry Editor.

You should now be able open CHM files located on the network. A word of advice however, don't open help files you don't trust.

Additionally, read Microsoft's KB #896358

If you're computer is not connected to the network at all, Windows knows this as it can detect no traffic on the NIC card. In this instance, it uses cached information to authenticate you. If you are connected to a network, but not the network that your computer belongs to, then Windows will take a few minutes to query for your domain and then a domain controller. If not found, again with the cached data. When you are logging on to your own network, local traffic and server availability can play a role in how fast you are authenticated and allowed to proceed with the logon routine; the more network traffic or the higher the server load, the slower your response time is.

However, not over a minute slow. If you had told me that it was an all the time thing, I might pointed you to either have someone look at your built-in NIC or check out the cabling from your laptop to the network drop. But you mention that it is primarily during business hours and localized to a specific area in your building. I might suggest that what is happening is that both your built-in NIC that plugs into your local network, and your wireless NIC are connecting to networks, and two different networks at that. Both formal wireless networks and informal peer-to-peer wireless connections can be very easy to set up and can broadcast for up to 30 feet. If you laptop is indeed connecting to an available wireless connection, Windows may be attempting to search for your domain (and authentication server) on the wireless network first. This search can take time before the broadcast your computer made times out and Windows starts looking at the built-in NIC connection and starting the entire process over again.

The next time you see this behavor, once you are logged in, access your Network Neighborhood properties and select to have your wireless NIC show up in the task bar when connected (if it doesn't already). Then check to see if you are, in fact, connected to someone's network as well as your own. The easiest way to deal with this is to simply disable your wireless NIC when you don't need it. That way, you can be sure that the only network Windows is talking to is the expected one.