Printable View
I have a HTML Help File (.chm) that is accessible on the host but access from the "station" (non-Host) results in "Action Cancelled" and "Page Not Available" messages. To use the UNC Path Ive changed the specification for the file to:sportsware2 is the name of the Host and GHM is the name of the shared folder. Any suggestions?Code:App.Help = "\\sportsware2\GHM\GHMHelp.chm"
Sounds like it may be a permissions issue on the share that the chm is located in.
I don't think it's a permission issue but how do I find out if it is?
Another possibility thought -- could the situation be related to the presence/absence of Microsoft HTML Help components on the non-Host computer?
1. Right click on the folder name and look at the security settings to see if it might be a permissions thing.
2. I would suggest installing and registering those components.
Even though the file/app is on a network drive or server share etc you still need all dependancies installed on each workstation that will be accessing the program/file.
The Security settings are fine -- access is allowed. It looks like the next step is to determine what the "dependencies" are, then determine if and how I can include them for installation on the workstations. I'm using the VB P&DW to create the Setup package.
"Action Cancelled" is a strange error to get even on the host computer. Do you have this app on a server? If you type in the unc path from explorer on some workstation will the chm file open? That is where you should start testing for permissions issues.
You might want to read this for a start Installer Problems to help you with what a proper VB installation needs.
For a deployment "newbie" like me this is getting crazy. However, in my search through the maze of KB articles and various forum posts, I have discovered a possibility that relates to permissions. The net of it is that a recent Security Patch for IE disables all HTMLHelp files from being viewed from a network drive.
FYI for all responders to this thread, the subject is covered on the website for a freeware product named HHreg. The link is: http://www.EC-software.com/products_hhreg.html
Comments are welcome.
Here is your solution.
http://support.microsoft.com/kb/896054
Yes, the KB link you mention is referenced on the HHreg site that I referenced. I have the article but I am unable to follow and use it. I may be a newbie with respect to all the things that go into network management, but this article is one of the worst examples of complexity I have ever seen. How can Microsoft create such a situation with something as fundamental as an application's Help File?
Nonetheles, I'll continue to try to plow through the maze.
Yes, the link was on the link's page you posted but I didnt think it was complicated. Basically you can either adjust your internet security zone settings or you can edit the registry to allow that location to be trusted.
What is it that you are having trouble with?
The simplest method seems to be to use the MaxAllowed Zone and set the dword to either 2 or 3. Where I'm having trouble is deploying the registry keys. I'm stuck at Step 5 in the KB article. I don't know anything about GPO or how to use it. In fact I don't know which computer (host or workstation) to proceed with and dsa.msc doesn't run on either.
By the way, thankings for your assistance and putting up with me.
No prob ;)
What server os are you running there? I have done some work with GPOs and they are fun and powerful once you know whats going on.
Also, the users that are going to be logging on to these workstations all use their own or do they log on to different workstations?
The "server" (host computer) is running under XP. What I'm testing on is a simple in-house wireless network. At this point there's only one workstation user who logs on with a personal ID. In "real life" with this program the ultimate end users won't be logging on at all -- the workstation(s) will be set up by staff who will also open the program for end-user use.
How about this as a simpler solution:
After exporting the current Resitry setting to save the current settings (for safety's sake), edit the Registry to set the dword value for ItssRestrictions to 1. If the ItssRestrictions key does not exist (which it didn't on my workstation), create the key by:
- Access HKEY_LOCAL_MACHINE, then SOFTWARE, the Microsoft, then HTMLHelp, then 1.x
- Right-click the 1.x key, choose New and Key, and enter ItssRestrictions
- Right-click the ItssRestrictions key, choose New and click DWORD Value. Then type MaxAllowedZone and press the Enter key. Next, right-click MaxAllowedZone, click Modify, enter the number 1 in the Value data box and click OK.
I did the above on my workstation and was able to access topics in my app's Help File.
What are the downsides of this approach, if any?
It says you should not set it to 3 or higher or you will be exposed to security threats.
Using the UrlAllowList method (#1) is more safe. You can do the reg setting and then export the key to a .reg file. That file can be used to merge it with the other workstations registry to produce the same effect.
RobDog888, thanks for your continued input.
MaxAllowedZone settings (Zones allowed) - Method #2
0 - Local Zone only (the default - no access to network Help Files)
1 - Local Zone plus Local Intranet Zone
2 - Above plus Trusted Sites Zone
3 - Above plus Internet Zone
4 - Above plus Restricted Sites Zone
Obviously in Method #2, settings higher than 2 create exposure. Using the UrlAllowList (Method #1) is safer only because it allows access only to specific Help Files files in specific server folders and/or from specific sites. However, if the Local Intranet Zone can be trusted it would seem that the setting of 1 in Method #2 creates little if any exposure; so too a setting of 2 which by definition includes "trusted" sites.
The nature of our application environment (a small local network in a very small business) is such that a setting of 1 under Method #2 is sufficiently safe.
It also seems to me that implementing Method #2 the way I did (direct Registry modification) is much easier than the Group Policy method outlined in the KB article, at least in our application environment where there will only a handfull or less workstations.
No prob, as long as you keep it at less then 3 you are safe as the article mentions. Using the registry hack is easier but harder to manage down the road as computer reinstalls or replacements will require re-editing of the registry etc. Since you are a small network it should be still manageable.