Создать папку и файл в профиле текущего пользователя из профиля администратора

Наш клиент позволяет устанавливать приложения только после входа в систему с правами администратора. Приложение, которое необходимо установить, должно быть установлено для текущего пользователя машины. Приложение устанавливается нормально, моя проблема возникает, когда мне нужно сбросить файл конфигурации в папку appdata / user profile пользователя. Так как это то, где они хотят, в настоящее время конфигурация сбрасывается на профиль администратора при установке. Как мне пройти через это, есть ли способ проверить установку, если есть другие профили и, возможно, написать в них, но это грязно.

Источник

3 ответа

Я просто подведу итог тому, что в основном упомянули другие, немного конкретизируя, пытаясь сделать "небольшую ссылку".

Может быть, стоит взглянуть на упоминание функции защиты от вымогателей Win10 ниже, чтобы понять, как это изменение Windows может повлиять на развертывание файлов профиля пользователя.

ОБЩИЕ ПОДХОДЫ

  • Есть много способов получить файлы, развернутые для каждого пользователя на компьютере, но есть много недостатков и проблем с большинством подходов. Честно говоря, есть проблемы со всеми подходами, в той или иной форме.

  • Ниже приведен список некоторых распространенных подходов к развертыванию, а затем упоминание о некоторых "облачных подходах". В будущем это обсуждение может стать неактуальным, так как настройки полностью основаны на облаке и синхронизируются на лету, и развертывание может полностью переключаться с развертывания на отдельную машину на развертывание на основе пользователя. Придется подождать и посмотреть, как получится.

    • 1: Шаблон для каждой машины

      • Установите файл конфигурации в папку для каждого компьютера, доступную для чтения всем пользователям, затем скопируйте файл оттуда и поместите его в профиль пользователя при запуске приложения, используя само приложение, чтобы выполнить копирование один раз для каждого пользователя.
      • Это рекомендуемый подход. Вы даже можете обновить свое приложение с помощью логики для принудительного обновления для каждого пользователя, если вам нужно использовать такой подход: http://forum.installsite.net/index.php?showtopic=21552.
      • Вы всегда будете работать в правильном пользовательском контексте, когда происходит копирование, и вам не нужно беспокоиться о сложных сложностях олицетворения, кондиционирования и последовательности MSI.
      • Приятным преимуществом этого подхода является то, что он будет работать, даже если источник установки (MSI) отсутствует во время запуска приложения.

    • 2: Создать файл при запуске - "Внутренние настройки по умолчанию"

      • Как предполагает Гиллидак, просто создайте файл конфигурации при запуске, используя внутренние настройки приложения по умолчанию, и не устанавливайте файл вообще. Происходит один раз на пользователя, с тех пор вы используете файл, который там. Хранение такого файла в вашем установщике означает, что вы исключаете риск того, что установщик случайно перезапишет его или удалит его.
      • Очевидный вопрос: зачем вам вообще нужен такой файл - если вы можете создать его из внутренних значений по умолчанию? Ответ, очевидно, заключается в том, что вы, возможно, захотите применить некоторые конкретные значения, которые являются уникальными для среды пользователя после создания файла. Тем не менее, такие настройки можно сохранить в реестре?
      • Вы можете установить соответствующие пользовательские настройки в разделе реестра HKLM через ОБЩЕСТВЕННЫЕ СВОЙСТВА во время установки (настраивается пользователем в командной строке или с помощью преобразования, см.: Как лучше использовать файлы MSI для получения информации об этом), и применять их для всех пользователей при запуске приложения - другими словами, записать их в HKCU. Или вы могли бы просто сохранить настройки "только для чтения" в HKLM и применить их для всех пользователей в вашем приложении? (не настраиваемые пользователем параметры - например, имя сетевого сервера или аналогичные).
      • Вы по-прежнему можете использовать метод из приведенной выше ссылки, чтобы принудительно обновлять существующие конфигурационные файлы при запуске приложения, установив в настройке флажок HKLM, чтобы уведомить, что развертывание "произошло" с момента последнего запуска.
      • Или, как указано, вместо этого используйте реестр для хранения настроек.

    • 3: MSI Self-Repair

      • Поместите файл конфигурации на место для каждого пользователя с помощью самовосстановления MSI. Это происходит при вызове рекламируемой точки входа, такой как рекламируемый ярлык, используемый для запуска приложения.
      • Требуется доступ к источнику установки во время ремонта. Обязательно кешируйте свой файл MSI на коробке.
      • Самовосстановление может не работать на серверах терминалов (отключенная функция). Прошло много лет с тех пор, как я в последний раз проверял это. Я не уверен, как серверы настроены из коробки в эти дни.
      • Если не указано иное, деинсталляция может деинсталлировать файл конфигурации для пользователя, который выполняет фактическую деинсталляцию, или, что очень важно, это может произойти во время крупного обновления (которое действительно является деинсталляцией и переустановкой вашего продукта). Другими словами: установите компонент постоянным (и никогда не перезаписывайте) - или ваш файл может выглядеть перезаписанным во время обновления (но он действительно удаляется и переустанавливается).
      • Для настроек реестра HKCU необязательно иметь доступный источник установки. Проверьте объяснение Стефана Крюгера: http://www.msifaq.com/a/1011.htm. Процедура та же, что и для запуска установки файлов userprofile (но тогда необходим источник установки). Связанное обсуждение - в случае, если это полезно.
      • Хотя я и не проверял, я рассмотрел возможность установки значения пути к ключу реестра: HKCU\Software\MyCompany\MyApplication\Version\HKCU_KeyPath = [ComputerName] чтобы сделать значение ключевого пути "движущейся целью", чтобы самовосстановление надежно срабатывало при входе пользователя в систему на новом компьютере (несмотря на то, что профили роуминга вводят существующие настройки HKCU).
      • Как я уже сказал, непроверенный, поскольку я в значительной степени отказался от этого подхода - поскольку он менее надежен, чтобы зависеть от каждого нового обновления для Windows. Нечто странное меняется каждый раз, с непредсказуемыми результатами.
      • Хотя это и не связано на 100%, я могу упомянуть новую функцию защиты от вымогателей в Windows 10 в качестве примера - кажется, что она вызывает периодические ошибки времени выполнения для любого MSI, пытающегося записать в папки пользовательских данных. Еще неизвестно, сколько будет проблем с развертыванием - пока мы видим неустойчивые результаты - что произойдет, когда и если они включат эту функцию по умолчанию?
      • И, как и выше, стороннее программное обеспечение безопасности также создает препятствия для развертывания, блокируя определенную активность файловой системы и изолируя файлы, помеченные по какой-либо причине (включая ложные срабатывания), что приводит к самовосстановлению, которое никогда не может завершиться, но сохранить работает напрасно.
      • Итак, вкратце, вот несколько причин, по которым становится все более и более полезным избегать развертывания файлов пользовательских профилей посредством самовосстановления:
        • Осложнения в роуминге.
        • Функция защиты от вымогателей помех.
        • Вмешательство программного обеспечения безопасности (особенно ложные вредоносные программы).
        • Ограничение терминального сервера на самовосстановление.
        • Сброс данных или параметры удаления проблемы во время серьезного обновления.
        • Может быть, у тебя такое же чувство, как и у меня: еще больше, и оно будет ухудшаться.
        • Мои два цента: немедленно поговорите с вашим менеджером о лучшем управлении файлами данных для вашего приложения и оставьте все попытки быть "умными" во время развертывания. Развертывание для каждого машинного файла только с MSI - если возможно.
        • В будущем это предпочтение может измениться по мере изменения технологии развертывания, и установка выполняется только для пользователя (возможно).
        • Более подробное описание проблемы, написанное ранее: Почему рекомендуется ограничивать развертывание файлов профилем пользователя или HKCU при использовании MSI?
        • И целая грязная болтовня о проблемах развертывания в целом: как избежать общих недостатков дизайна в моем решении развертывания WiX / MSI?

    • 4: Активная настройка

      • Поместите файл конфигурации на место с помощью Active Setup. Это происходит при входе пользователя в систему (который затем требует выхода из системы и входа в систему, если только вы не убедитесь, что файл также установлен в текущий профиль пользователя при установке).
      • По сути, это вариант подхода 1. Вы должны установить файл конфигурации в папку для каждой машины, доступную для чтения всем пользователям.
      • Затем вы регистрируете задачу в реестре, чтобы запускать "что-то работоспособное" один раз для каждого пользователя. Вы можете запустить что-нибудь, например, пакетный файл, исполняемый файл, сценарий или мой предпочтительный метод восстановления MSI, который позволит разместить файл userprofile на месте (в этом случае вам не нужен файл в расположении для каждой машины, но есть доступ к источнику установки при запуске Active Setup).
      • Остерегайтесь не перезаписывать файл конфигурации, установленный во время установки для текущего пользователя. Или отключите запуск Active Setup для этого пользователя, написав ключ HKCU, который пишется после запуска Active Setup для данного пользователя (см. Ссылку ниже).
      • Процедура описана в моем ответе здесь: Обновление реестра каждого профиля в Windows Server 2003. Все это основано на ключе HKLM, который запускается один раз для каждого пользователя. Проверьте связанный ответ для деталей, и там есть несколько внешних ссылок, которые предоставляют намного больше деталей.
      • ОБНОВЛЕНИЕ: при установке на сервере терминалов вы переводите сервер в "режим установки", а затем записи реестра для каждого пользователя записываются в HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install и затем записывается в улей каждого пользователя HKCU при входе в систему. Это может конфликтовать с ActiveSetup - насколько я знаю. У меня никогда не было возможности проверить это. Упаковка для сервера терминалов, как правило, выполняется специальной, специализированной серверной группой.

    • 5: MsiProvideComponent

      • MsiProvideComponent Фила интересный, я никогда не использовал его. Я должен.

ОБЛАЧНО-СТИЛЬНЫЕ ПОДХОДЫ

  • Поскольку хранилище данных, похоже, перемещается в облако, общие подходы к развертыванию файлов данных могут быстро устареть.

    • 6: Загрузите файл настроек

      • Загрузите файл настроек - один раз для каждого пользователя при запуске приложения - из локальной сетевой базы данных / общего ресурса или из Интернета вместо этого - если это вариант.
      • Удаленный файл может быть сохранен администратором для обновления значений, если есть новые значения по умолчанию или что-то нужно удалить.
      • Механизмы конфигурации в файле настроек, понятные вашему приложению, могут принудительно применять новые "принудительные" значения для всех пользователей.
      • Разрешить настройку списка серверов в HKLM? Настраивается ли в MSI через ОБЩЕСТВЕННЫЕ СВОЙСТВА?
      • Или задайте один URL-адрес в настройке во время установки и ведите список серверов по этому URL-адресу (вы перенаправляете на какой сервер он указывает через DNS, чтобы конфигурация была задачей sysadmin без повторного развертывания?). Настоящий выбор установлен в HKCU.

    • 7: чтение / запись настроек из удаленной базы данных

      • Вместо этого читайте / записывайте настройки напрямую в / из локальной базы данных AD или Интернета.
      • Нет файла локальных настроек вообще или кэшированная копия только для чтения, когда сервер недоступен? Или просто запустить с внутренними настройками приложения, если сервер не может быть достигнут? Нет файла вообще, чтобы управлять в последнем подходе.
      • Вы можете написать список серверов (URL) для использования в HKLM (даже с помощью групповой политики?) И даже поддерживать текущий выбранный сервер в HKCU для каждого пользователя. Тогда все остальное происходит онлайн.
      • Пока широко используется в корпоративных клиент-серверных приложениях, но облачные платформы навсегда изменят развертывание, особенно для домашних пользователей. Мы видели, как браузеры долго сохраняют настройки через Интернет (Chrome, Opera, Firefox и т. Д.).
      • Удаленное хранение в базе данных означает, что вы можете поддерживать пользовательские настройки в качестве задачи управления базой данных, и вы даже можете создавать версии пользовательских данных в базе данных и легко применять новые значения по умолчанию или принудительно обновлять существующие значения для всех пользователей пользователей как централизованную задачу DBO.
        • Больше не надоедает проблема с перемещаемым профилем.
        • Больше не удалось развернуть файлы userprofile.
        • В итоге: нет пользовательских настроек для развертывания вообще, и данные никогда не будут синхронизированы на разных машинах.
        • Проблемы с брандмауэром / прокси и сетевым подключением?

Резюме

Мне больше не нравятся вариант 3 (Самовосстановление) и вариант 4 (Активная настройка), хотя я использовал их много раз - и они работают, когда все сделано правильно. Однако они не защищены от проблем с перемещаемым профилем (файлы не копируются на месте во все системы, в которые входит пользователь) и не имеют доступа к источнику установки MSI во время восстановления, что может вызвать проблемы развертывания. Также часто возникают сложности при крупных обновлениях с настройками сброса, и самовосстановление на терминальных серверах не удается. Самостоятельное восстановление может завершиться ошибкой при установке в профиль пользователя из-за защиты от вымогателей или вмешательства софта безопасности. Командная строка, указанная в параметре 4 (Active Setup), может содержать ошибки и уничтожать данные (например, вы активируете неправильный флаг для восстановления msiexec.exe и принудительно перезаписываете файл настроек случайно - это часто не обнаруживается, пока не станет слишком поздно и ущерб уже сделан). И есть другие проблемы, которые избегают меня прямо сейчас. Оба подхода имеют схожие, но немного разные ограничения.

Я все больше и больше предпочитаю облачные подходы, чтобы сделать файлы локальных (и изолированных) пользовательских настроек ушедшими в прошлое, но я редко смог развернуть вещи таким образом. Эти облачные подходы могут столкнуться с проблемами с брандмауэром / прокси и проблемами с сетевым подключением - и, возможно, с некоторыми другими вещами, о которых я пока не знаю (теперь разработчики будут ссориться с DBO, а не со специалистами по развертыванию и т.д...;-)). Распределенные вычисления имеют свои ошибки: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing. Кроме того: в облачных подходах для приложений все еще может быть хорошая идея разрешить резервное копирование настроек на диск, поэтому очевидно, что некоторое управление файлами все еще необходимо - или вы просто экспортируете пару таблиц базы данных? Также: если вы устанавливаете пробную версию своего приложения, вы можете захотеть, чтобы оно работало вообще без подключения к сети - в случае, если пользователь находится за очень жестким межсетевым экраном. Это очень дорогая ошибка, чтобы не позволить вашему пользователю тестировать функции вашего приложения из-за технических проблем.

Большим преимуществом вариантов 1 и 2 является то, что они будут работать, даже если исходный установочный носитель отсутствует при запуске восстановления. Это особенно важно для развертывания дома и в небольшом офисе, где развертывание может происходить довольно случайно без централизованного общего доступа к пакетам. Вы можете обойти эту проблему (отсутствует исходный MSI), используя методы кэширования для кэширования всего MSI в системе во время установки (доступно в Installshield, я не проверял WiX или Advanced Installer).

Источник

Не создавайте файл конфигурации при установке, проверьте и посмотрите, существует ли он при запуске программы, если нет, то создайте его в папке профиля работающих пользователей. Если он существует, используйте данные в нем и продолжайте.

Источник

Вы можете сделать это с помощью функции восстановления. Общая картина заключается в том, что файл был установлен для одного пользователя во время установки в месте профиля пользователя, и при установке для каждой системы это будет означать, что файл будет отсутствовать, когда другой пользователь входит в систему, чтобы использовать приложение. Это зависит от структуры компонентов MSI, функций и ярлыков, но запуск приложения с объявленным ярлыком может привести к установке отсутствующего файла с самовосстановлением. Очевидно, что для этого требуется, чтобы исходный MSI оставался доступным.

Однако самый безопасный способ установить файл для любого нового пользователя - это явно вызвать MsiProvideComponent, передав код продукта MSI, имя компонента, идентификатор компонента и т. Д., Как описано в документации. Как сказано в документации, компонент будет установлен, если он отсутствует, снова требуя наличия исходного MSI.

Эта функция относится к случаю, когда существуют учетные записи пользователей, которые еще не были созданы, поэтому очевидно, что вы еще не можете помещать файлы в папки их профилей.

Будет ли это лучший подход по сравнению с другими, будет зависеть от конкретных деталей приложения.

Источник
Другие вопросы по тегам