![Word 365 Разрешить макросам работать в режиме «Только чтение»/«Защищенный просмотр»](https://rvso.com/image/1684438/Word%20365%20%D0%A0%D0%B0%D0%B7%D1%80%D0%B5%D1%88%D0%B8%D1%82%D1%8C%20%D0%BC%D0%B0%D0%BA%D1%80%D0%BE%D1%81%D0%B0%D0%BC%20%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D1%82%D1%8C%20%D0%B2%20%D1%80%D0%B5%D0%B6%D0%B8%D0%BC%D0%B5%20%C2%AB%D0%A2%D0%BE%D0%BB%D1%8C%D0%BA%D0%BE%20%D1%87%D1%82%D0%B5%D0%BD%D0%B8%D0%B5%C2%BB%2F%C2%AB%D0%97%D0%B0%D1%89%D0%B8%D1%89%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9%20%D0%BF%D1%80%D0%BE%D1%81%D0%BC%D0%BE%D1%82%D1%80%C2%BB.png)
Я пытаюсь обновить нашу компанию до Microsoft 365 x86 с Office 2019x86. В настоящее время мы застряли на 32-битной версии, поскольку наш электронно-управляемый процесс обработки документов в настоящее время имеет макросы VBA, которые используют 32-битные библиотеки DLL. Эти библиотеки DLL используются в макросах VBA для загрузки новых данных в файлы DOC и обеспечения точности в них при каждом открытии.
Все это работало нормально в Office 2019. Когда эти документы загружаются, они открываются и помечаются как защищенные, так как в свойствах файла они отмечены как «только для чтения». В Office 2019 это не останавливает запуск макроса. В M365 эти документы не запускают макрос, так как они отмечены как «Только просмотр». Я попытался вывести GPO, который принудительно устанавливает доверенные расположения и доверяет запуску макросов, но они все равно терпят неудачу. Ошибка, которую я получаю от макроса VBA, приведена ниже.
Run-time error '6124': You are not allowed to edit this selection because it is protected.
Мне удалось обойти это, удалив все записи реестра в 'HKEY_CURRENT_USER\Software\Microsoft\Office'
, а затем перезагрузившись. Ожидаемое поведение временно работает с этим методом, но затем проблема возвращается через случайный промежуток времени.
Другой обходной путь — перейти в свойства файла и снять отметку «только для чтения». Это не вариант для наших конечных пользователей, но работает для администраторов при тестировании.
Каковы еще возможные решения этой проблемы или точный ключ/значение реестра, вызывающие такое поведение?
решение1
Что-то для тестирования, как обходной путь:Изменение владельца в разделе реестра HKEY_CURRENT_USER\Software\Microsoft\Office
в TrustedInstaller и удалите разрешение на его изменение/запись, чтобы снизить вероятность вмешательства MS Office в него.Примечание.Перед внесением изменений экспортируйте ключ в файл .reg, чтобы упростить откат. После этого проверьте, может ли другой экспорт в .reg изменить владельца на другом ПК.
Однако смена владельца имеет некоторые очевидные недостатки.
- Это сделает будущие обновленияОфиструднее.
- Офисне сможет спасти ни одногодругойизменения в этом ключе. Попробуйте сузить конкретныйподключкоторые необходимо защитить, и передать право собственности только им.
- Развертывание этого на многих машинах может оказаться затруднительным, если это невозможно сделать с помощью файла .reg.
- Могут возникнуть проблемы с безопасностью при сохранении старых 32-битных DLL.
Конечно, лучшим решением было бы связаться с поставщиком оригинального приложения для проверки соответствия документов и получить версию, совместимую с более новыми версиями MS.Офис.
[Кстати, вы пробовали альтернативуОфис, такой какLibreOffice, для совместимости с существующими макросами? Поскольку в корпоративной среде может быть непрактично менять наборы приложений, это будет сделано для удовлетворения любопытства и, возможно, для мотивации поставщика программного обеспечения обновить DLL.]