Очевидно, существуют разные уровни аутентификации. В большинстве статей, которые я читал, предлагается установить для MaxAllowedZone значение «1», что означает, что зона локального компьютера и зона интрасети разрешены, но «4» разрешает доступ для «всех» зон.
Для получения дополнительной информации прочтите эту статью:
https://support.microsoft.com/en-us/kb/892675
Вот как выглядит мой реестр (я не был уверен, что он будет работать с дикими картами, но, похоже, у меня это работает):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"MaxAllowedZone"=dword:00000004
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions]
"UrlAllowList"="\\\\<network_path_root>;\\\\<network_path_root>\*;\\ies-inc.local;http://www.*;http://*;https://www.*;https://*;"
В качестве дополнительного примечания, как ни странно, ключ «UrlAllowList» потребовался для работы на другом ПК, но не на моем тестовом. Вероятно, это вообще не требуется, но когда я его добавил, проблема устранилась. Возможно, пользователь не закрыл исходный файл или что-то в этом роде. Так что просто соображение. Я предлагаю попробовать по крайней мере и протестировать его, а затем добавить, если необходимо. После подтверждения вы можете выполнить развертывание при необходимости. Удачи!
Изменить: PS Другой метод, который работал, заключался в сопоставлении пути к сети локально с помощью mklink / d (символическая ссылка в Windows 7 или новее), но сопоставление буквы сетевого диска (Z: для тестирования) не сработало. Просто пища для размышлений, и мне не пришлось «разблокировать» какие-либо файлы. Также принятое «Решение» не решило для меня проблему.