CHMs On A Network

What's covered?

In 2004 Microsoft Security Update 896358 that meant that CHM files located on a server would not work properly, most commonly clicking a topic in the TOC got a Page Cannot Be Displayed message.

Initially there were various workarounds and these are what is described on this page. However, over time the restrictions that were imposed because of security concerns with CHM files, these were tightened and the Help and Manual site that posted several solutions now states that none of them work.

In short, if you want to use CHMs, they need to be installed on the user's desktop.

Introduction

Before you read on, please read the What's Covered section above. The rest of this page is of historic interest only.

The identification of the cause of these problems and the workarounds are not my work.

• The methods of allowing all chm files to run on an intranet were identified by Pete Lees. Pete, as always, has done an excellent job of trawling through some highly technical documents and making some sense of them. That information has then been covered in Pete's responses to various postings.
• Fabio Pagano then posted a solution allowing only files in a designated folder to run. This is more restrictive but limits the risks.

What I have done is pull that information together into one topic and explain the issues involved. I am also grateful to Pete Lees for his counsel on the general content.

The workarounds involve registry changes so great care is required. My registry knowledge is pretty much limited to making changes described by others so I cannot help you if you get it wrong!
Remember, unless you have the knowledge, the golden rule with the registry is DFA. (Don't fiddle about, or something like that.)

About 896358

Since the introduction of Security Update 896358 (Jun 2005) there has been a flurry of postings about chm files that no longer work properly, most commonly clicking the TOC contents gets a Page Cannot Be Displayed message. It also affects Related Topics commands and other instances of the HTML Help ActiveX control. In all cases this is where the chm file is located on a server. Files on the users hard disk are not affected by this patch. So the first obvious workaround is to move the chm file!

At first sight that may not be an option you want to consider so it is worth looking at why Microsoft have introduced this patch. It was not out of spite for technical authors or because their developers had a quiet afternoon and wanted to develop a patch for fun. It was identified that running a chm file posed a security threat which simply means that someone could use it to run malicious code on your PC. The same threat does not exist when then the file is run from your hard disk.

At this point, I can almost hear you screaming "... but we have several hundred users accessing the chm file over an intranet, we cannot install it on their hard disk". Wrong. You can. The point here is that understandably you do not want the overhead of managing that every time there is an update. It may also be that you are a software company whose help is placed on a server at your customer sites and they do not want that overhead.

Well there are workarounds but they involve editing the registry and compromising security! You are undoing part of the protection created by the security patch. You need to reflect on that before rushing on and making these changes.

• If it is on machines within your own company and the IT people are OK about making these changes at the expense of security, then go ahead.
• If the machines are those of your customers, you better be very sure they fully understand the implications. In the event that security is compromised later, you might not be top of their hit parade (thinking some more about it, you actually might be top of their "hit" parade!).

Some people seem to be expecting Microsoft to issue a patch to fix this. Unlikely I think as it was a patch that deliberately caused the problem rather than it being an unexpected side effect.

The Safer Options

At this point you may be coming around to view that hacking the registry is not too cool an idea. Your safe options, quite simply, are to move the chm file to the users hard disk or implement webhelp.

For those of you who have not produced webhelp before, the considerations are

• The output comprises a large number of files in different folders. I have seen people say their installers go mental about this which seems like a hangover from the days when PCs were slower, hard disks were small and expensive and so on. So what that the help comprises hundreds or thousands of files. They are all off of one root folder so there is nothing difficult about it.
• The developers will have to rework context sensitive help calls. You cannot change from one output to another without involving the developers.
• How do you create the webhelp? The output from RoboHelp is proprietary and there was speculation that it would not be developed further. Also it was speculated that it might not work in Internet Explorer 7 which would have left you high and dry. The good news is that since Adobe took over Macromedia, they have developed a new version and webhelp continues to work without any reported problems.

Not a welcome scenario but those are the facts and you have to decide how you want to proceed.

The Microsoft Workarounds

If you have jumped straight to this heading be aware that you have missed the cautions about resolving the issue in this way.

Proceeding beyond this point involves editing the registry. You do so at your own risk. Do not edit the registry unless you have the necessary level of knowledge.

You are comprising the security that Security Update MS05-026 was designed to provide.

Microsoft Topic	Comment
Knowledge Base Article 896358 Update 19 April 2019. This is not the original article but the nearest thing I could find with the requisite information.	This is the lead article on all the problems caused by the patch that was announced in Security Bulletin MS05=026. It contained some pertinent warnings as below but the page is no longer available. However, see the article below for resolving the most common issue. Note Microsoft's warning in the first paragraph under the heading Things To Try. You must involve your IT department. If your help is installed on customer intranets, then their IT deparments must be cautioned. The warning is reinforced later, see "Approaches to working around application compatibility issues in security upate 896358".
Knowledge Base Article 896054 Update 01 January 2022. Microsoft have removed the page the above text linked to that provided more information.	This topic deals with The Page Cannot be displayed problem. To run any chm on the intranet Pete Lees points to two solutions in the article. These will allow any chm to be run on the intranet. It is for your IT people to decide whether or not these changes should be made in the light of their assessment of how likely it is that a malicious chm file will find its way onto the intranet. Single PC Follow these steps to allow a single PC to run chm files stored in any shared folder in your intranet. Locate the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions and create a >DWORD value called >MaxAllowedZone and give it a value of 1. (In a HATT topic (No longer available) Rob Cavicchio advised that this needs to be set to 3 under Vista). This will remove the block on all files in the Local Intranet zone. See the Microsoft topic for details of other values that can be applied. The instructions for a single PC are more fully described in the article under "Consumers and non-enterprise customers - Method 2" All PCs Essentially the same method is employed using a Group Policy object. This is described in the article under "Enterprise customers - Method 2" To run any chm in a specific folder on the network (intranet) Fabio Pagano posted a solution that only allows chm files within a specified folder to run. You (or your IT people or your customers) may prefer that as it is more restrictive and any malicious attacker would rely on you saving their chm file to your folder. It's for you to decide how likely that is. Locate the key (same key as above) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions and create a string value called UrlAllowList. Give it a value of \\hostname\sharename\;file://; where >hostname is the name of your server and >sharename is the folder path where the chm files are located. If multiple paths are to be enabled, the value would be \\hostname1\sharename1\;\\hostname2\sharename2\;file://; The above will allow any CHM in those folders to be opened. Use this format to restrict it to a specific file \\hostname\sharename\yourhelp.chm;file://; Any CHM except yourhelp.chm in the same folder will continue to be blocked. Paths containing full stops (periods) will not work. You can also used mapped drive paths if you are happy the mapping from that PC will not be changed. Again this method could be deployed on all PCs on the intranet using a Group Policy object. Make the changes using HH Reg If you prefer not to make registry changes, then you might like to use HHReg provided free by from EC Software. It works on the registry of a single PC. Provided you have admin rights over your PC, this tool will enable you to authorise a specific CHM to run or all CHMs in a specific folder. Even if you do have admin rights, you should check with your IT Administrator that they are happy for you make this change. Your developers can also use this tool as part of their installation routine. Note that whilst it can be run in silent mode you should consider doing so very carefully. Even in silent mode, the user installing your software must have admin rights to enable the changes to be made. However, if they have such rights they will be unaware of the registry change made and the IT administrator might not be too happy about that. It could be politically unwise. Much better to point out that this change will be made and give the user the chance to opt out. Click here to visit the Help and Manual site.
Knowledge Base Article 892675 (Update 19 April 2019 - This article is no longer on Microsoft's site)	This topic deals with HTML Help ActiveX controls being disabled unless the file is on the local drive. In .chm help, this will, for example have the effect of disabling Related Topics controls if the file is not on the local drive. In webhelp if an instance has been inserted to add a TOC or index in a file for example, then it will not work when the file is uploaded to the server. The issue does not affect the TOC or index in the navigation pane of a chm file. Apply the same solutions as described above except that the key to amend is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\HHRestrictions