Today I ran into something interesting, and was wondering if
anyone knew what the cause might be.

Basically, what are the requirements for viewing a .chm file
over a network? Previously, opening a .chm from a network location
would cause it to display a "file now found" message on my system,
but today I unintentionally opened one and found it worked
perfectly. I've just changed computers here at work, which included
moving from an XP to a Vista machine, and thought that the change
in OS might have something to do with it.

However, a coworker who's in the process of changing his
computers (and has both running at the moment) tested this for me,
and found that he could open his from his old XP machine, but not
from his new Vista machine, so it doesn't look like this is an XP
vs Vista issue.

We were wondering if viewing a .chm over a network is tied to
any rights or permissions settings, and I thought I'd ask here in
case someone already knows.

Just to add that I believe you're right as far as the XP vs.
Vista issue is concerned. There shouldn't be any difference between
these two operating systems in the way they handle remotely
accessed help files.

If we assume that the same registry changes have been made to
all four of your machines, there are at least two reasons why the
contents of remote help files may be viewable from one machine but
not from another.

If IE7 is installed, and you have set the
MaxAllowedZone registry key to 1 so that you can view the
contents of all help files in the Local Intranet zone, you must
also make an additional change to the Internet options in IE before
you can access the help files. See this article for more
information:

This additional change was unnecessary in IE6 and earlier.
Perhaps the version of IE is a factor in your case?

The
UrlAllowList registry key, which is designed to let you view
the help files in specific network folders only, was reportedly
broken for quite a long period. This was eventually fixed by a
Microsoft update last year, but machines that haven't been updated
for some time may still exhibit the problem. See:

A co-worker of mine discovered a file named "HTMLHelp.reg"
that is on some of our systems, but not all.

If you have this file, it seems that you can view .chm files
over a network. If you don't, you can't. Unfortunately he is out at
the moment and I can't find where this file is supposed to be in
Vista.

He found it in an XP machine and copied it to Vista, where it
appears to work. What's odd is that several of our new Vista
machines allow us to view .chm files over a network right "out of
the box", without any changes or updates made to the registry or
elsewhere, or AFAIK without this file being specifically added or
altered.

Anyone familiar with where to find this file in Vista? We are
now trying to see if we can view chm files from SharePoint (even
machines with the above file cannot view chm files opened directly
from SharePoint).

> What's odd is that several of our new Vista machines
allow us to view .chm
> files over a network right "out of the box", without any
changes or
> updates made to the registry or elsewhere, or AFAIK
without this file
> being specifically added or altered.

That's certainly odd. If you open Registry Editor and
navigate to the following key, is there nothing there that might
permit you to view remotely-accessed .chm files?

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions

I'd expect to find a UrlAllowList or MaxAllowedZone value
that unblocks the remote .chm files in specified nework folders or
security zones. In the absence of these values, viewing remote
files should be impossible.

> Anyone familiar with where to find this file in Vista?

It wouldn't be shipped with Vista, as by making the registry
changes you're relaxing the security of your PC and potentially
exposing it to attacks from malware writers — not something
that Microsoft could ever be seen to encourage.

> even machines with the above file cannot view chm files
opened directly
> from SharePoint

Yes, that's right. The same security update is responsible
for both issues, but each issue has its own set of workarounds.