У меня есть совершенно новая машина, на которую мы только что установили Windows Server 2008 Enterprise около двух месяцев назад. В журнале событий я вижу тысячи зарегистрированных EventID 1035. Это MsiInstaller, который снова и снова меняет конфигурацию около дюжины продуктов, зацикливаясь примерно каждые полчаса.
Кто-нибудь это видел? Вначале я провел общий поиск в Интернете, и большинство решений касались установки Dell System Center или панели инструментов Google в качестве виновника.
У нас не установлен ни один из этих продуктов.
Спасибо за вашу помощь,
Дол
ОБНОВИТЬ:
Возможности установщика Windows "самостоятельный ремонт"для установленных приложений. По сути, это означает, что он будет продолжать проверять, соответствуют ли файлы на диске и настройки в реестре тому, что было первоначально установлено в соответствующем пакете. Эти проверки обычно выполняются не для всего, что установлено в пакете, а для того, что указано как "ключевые пути".
В ситуациях, когда вы видите Самостоятельный ремонт работает циклично, это обычно означает, что какой-то процесс в системе или другой MSI изменил настройки в системе, которые также изменил пакет, который впоследствии самовосстанавливается. Как сказал парень, это похоже на борьбу увлажнителя и осушителя в одной комнате - или на собаку, преследующую собственный хвост. Вы никуда не денетесь, пока конфликт не будет обнаружен и устранен. Файл MSI будет повторять «это мой ресурс, я меняю его обратно» снова и снова.
Что необходимо, так это определить конфликт, из-за которого спорят файлы MSI или системные процессы: http://www.installsite.org/pages/en/msifaq/a/1037.htm .
В файлах MSI есть и другие ошибки проектирования, которые могут вызвать ту же проблему, например, для ключевых путей заданы жестко заданные пользовательские пути: C: \ Documents and settings \ user1 \ Desktop. Этот путь не будет найден для другого пользователя, входящего в систему, и результаты самовосстановления. Другой пример - ключевые пути, установленные для папок, которые не могут быть записаны для учетной записи System. Еще один пример - это ключевой путь, установленный для временного файла (который система в конечном итоге удалит).
Как видите, существует множество сценариев, но всегда одна и та же проблема: файл MSI проверяет правильность текущей установки и находит несоответствие, которое затем пытается исправить.
Я могу подтвердить, что проблема вызвана запросами WMI к классу Win32_Product. Но, как описано в этом другом вопросе ниже, вы не можете использовать Win32reg_AddRemovePrograms, если у вас не установлен SCCM / SMS, и даже если вам придется использовать Win32reg_AddRemovePrograms64 для получения списка 64-битных программ.
Ничто из этого не было задокументировано как плохое, фактически как правильный способ сделать это. Я думаю, что решение Microsoft провести проверку ремонта одновременно с ответом на запрос - это просто плохой дизайн. Запрос никогда не должен вызывать изменения в системе, это должна быть другая «функция» (метод WMI). Разумный дизайн мог бы включать периодическую проверку их «системного обслуживания» новых операционных систем, потому что это также настраивается и имеет смысл для пользователей / администраторов.
В любом случае, это был старый сервер, который собирался списать (Windows 2003 64bit). Но это действительно происходило на всех наших серверах в течение многих лет (это серьезно сказалось на производительности, теперь это подтверждено). Поэтому мне придется еще раз проверить новые серверы 2008 R2, чтобы узнать, будет ли это постоянной производственной проблемой или нет.
Но что меня действительно интересует, так это как, черт возьми, я могу объяснить командам упаковщиков и инженеров службы поддержки, что они не должны использовать этот запрос / API WMI. У нас есть сотни скриптов и инструментов, написанных множеством разных людей для тысяч пакетов. Это никогда не случится. Таким образом, это поведение должно быть исправлено MS как критическая ошибка проектирования, если она все еще встречается в 2008 R2 и других поддерживаемых версиях ОС. Мы обязательно его обострим, если так будет!
После тщательного исследования я обнаружил эта статья Microsoft KB указывает, что эти сообщения могут быть созданы фильтром групповой политики ИЛИ приложением, запрашивающим класс WMI Win32_Product. К сожалению, сложно определить, какое приложение вызывает проблему.