Собрание заметок об информационных технологиях
В некоторых случаях на SCOM может появится сбивающее с толку предупреждение о недоступности того или иного логического диска:
Это может быть вызвано тем, что WMI класс Win32_LogicalDisk возвращает значение TRUE для свойства VolumeDirty для проблемного логического диска при опросе ОС скриптом SCOM.
После установки рекомендуемых обновлений с WSUS, которые включают в себя новую версию браузера IE9 может перестать корректно работать консоль управления Forefront TMG 2010 на базе MMC - Forefront TMG Management. При попытке перехода к любому разделу управления TMG консоль будет порождать ошибку типа:
Есть жёсткий метод решения проблемы – редактирование файла C:Program FilesMicrosoft Forefront Threat Management GatewayUI_HTMLsTabsHandlerTabsHandler.htc как это описано например здесь: Технический блог Евгения Протопопова - TMG 2010 Console Error
Но можно избавиться от этой ошибки и более простым способом – изменением региональных настроек ОС. Открываем апплет изменения региональных настроек intl.cpl и на вкладке Formats сменить Format на English (United States)
После этого консоль заработает и можно будет спокойно дождаться выхода обновления исправляющего эту проблему и после его установки вернуть региональные настройки назад.
Столкнулся с ситуацией, когда на одном из серверов с Windows Server 2003 перестало отображаться содержимое списка установленных программ:
Дополнительно выяснилось, что помимо этого на данном сервере не работает запуск сценариев VBScript и попытка исполнения любого сценария приводит к общей ошибке:
Уловить момент, когда и по какой причине начались эти проблемы по логам, - не представилось возможным и поэтому осталось хотя бы попробовать победить «последствия».
В статье KB266668 - Add/Remove Programs tool displays installed programs incorrectly было найдено описание одной из имеющихся проблем и методов её решения. В итоге получился вот такой командный файл перерегистрации некоторых системных компонент, запуск которого с последующей перезагрузкой ОС вернул сервер к работоспособному состоянию:
regsvr32 "%systemroot%System32Appwiz.cpl"
regsvr32 "%systemroot%System32Mshtml.dll"
regsvr32 "%systemroot%System32Jscript.dll"
regsvr32 "%systemroot%System32VBscript.dll"
regsvr32 "%systemroot%System32Msi.dll"
regsvr32 "C:Program FilesCommon FilesSystemOle DBOledb32.dll"
regsvr32 "C:Program FilesCommon FilesSystemAdoMsado15.dll"
regsvr32 "%systemroot%System32Mshtmled.dll"
Развернул свежую Windows Server 2008, установил, как полагается, на неё все текущие обновления с WSUS и после перезагрузки обнаружил проблему с работой mmc.exe. При попытке использования сборных оснасток, таких как Server Manager или некоторых отдельных типа Event Viewer система стала возвращать ошибку «MMC could not create the snap-in»
В логе ServerManager.log расположенном в C:WindowsLogs не удалось обнаружить никаких событий, происходящих после установки всей пачки последних обновлений. Чтобы проверить то, что проблема заключается не в повреждении файлов какого-либо из обновлений, пришлось прибегнуть к помощи средства System Update Readiness Tool. Описание и ссылки на свежие версии этой утилиты можно найти в статье KB947821 - Description of the System Update Readiness Tool for Windows Vista, for Windows Server 2008, for Windows 7, and for Windows Server 2008 R2
В процессе установки System Update Readiness Tool выполняет проверку всех установленных обновлений и создаёт лог-файлы из которых можно узнать результат проверки:
В моём случае проверка не выявила никаких проблем с файлами обновлений:
В большом количестве источников в интернете можно найти информацию о подобной проблеме, её корнях и способах решения. Есть даже такие кардинальные, как например, описано в одном блоге: Jared Heinrichs Blog - MMC error 18ea3f92-d6aa–41d9-a205-2023400c8fbb
Jared Heinrichs предлагает произвести замену конфигурационного файла Framework в каталоге C:WindowsMicrosoft.NETFrameworkv2.0.50727CONFIG (для 64-битных систем соответственно - C:WindowsMicrosoft.NETFramework64v2.0.50727CONFIG). А именно имеющийся файл machine.config (который в большинстве случаев и является источником проблемы) переименовать machine.config.bad а файл machine.config.default скопировать в эту же папку с новым именем machine.config, то есть восстановить старый конфигурационный файл по умолчанию.
Из других источников выяснилось, что при установке .NET Framework 3.5 в файл machine.config в указанном каталоге могут быть внесены некорректные данные и поэтому я решил попробовать удалить эту версию .NET Framework 3.5 штатным способом. Итак, используя оснастку установки/удаления программ, был удалён пакет Microsoft .NET Framework 3.5 Service Pack 1 (KB951847) и сразу после этого все оснастки mmc заработали.
После запроса к WSUS, система опять предложила установить данное обновление. Устанавливаем его..
Сразу после этого делаем повторный запрос к WSUS и устанавливаем несколько доступных обновлений к переустановленной версии .NET Framework 3.5 SP1:
После этого все оснастки работают, так что можно считать этот метод ещё одним работающим вариантом штатного решения проблемы.
Не так давно было замечено, что клиенты MS Outlook 2007 в процессе создания нового профиля подключения к серверу Exchange на этапе автодискаверинга вместо адреса электронной почты (атрибут mail) пользователя возвращают значение атрибута userPrincipalName (UPN) этого пользователя:
с такими параметрами процедура авто-настройки профиля завершается с ошибкой. После разбора полётов выяснилось, что виновником такого поведения Outlook 2007 стало недавно выпущенное и развернутое через WSUS обновление KB2412171
О других “косяках” этого обновления можно почитать в “чистосердечном признании” в официальном блоге - The Microsoft Office Blog - Issues with the recent update for Outlook 2007
Если произвести удаление этого обновления с клиентского ПК, то процедура авто-настройки начинает работать штатно:
Соответственно, для решения данной проблемы можно пойти двумя путями:
1) Произвести удаление данного обновления с пользовательских ПК;
2) Дожидаться выхода нового обновления Office, устраняющего эту проблему, а пока оно не вышло, в случае необходимости подключения нового профиля Outlook в поле “Адрес электронной почты” заменять автоматически подставленное значение UPN на mail и оставлять появившиеся поля для ввода учетных данных пустыми (в таком случае процедура авто-настройки будет завершаться без ошибки).
При попытке развернуть последнюю версию JRE на Windows 7 столкнулся с ситуацией, когда программа установки завершается с ошибкой:
Имя журнала: Application
Источник: MsiInstaller
Дата: 26.01.2011 8:37:12
Код события: 11330
Категория задачи: Отсутствует
Уровень: Ошибка
Ключевые слова: Классический
Пользователь: mydomuser
Компьютер: WS001.mydom.com
Описание:
Product: Java(TM) 6 Update 23 -- Error 1330.A file that is required cannot be installed because the cabinet file \sccm-serverSourcesJRE_1.6.0_23x86Data1.cab has an invalid digital signature. This may indicate that the cabinet file is corrupt. Error 266 was returned by WinVerifyTrust.
Проблема в данном случае заключается в отсутствии доверия к корневому сертификату в цепочке корневых сертификатов того сертификата, с помощью которого подписан *.cab файл в составе дистрибутива.
При этом на компьютерах с Windows XP данной проблемы нет, так как эти ОС получают с WSUS соответствующее обновление - Update for Root Certificates [October 2010] (KB931125)
Для того чтобы обеспечить обновление корневых сертификатов на всех клиентских системах Windows можно скачать файл rootsupd.exe и форсированного распространить его. В моём случае, для этой цели я воспользовался SCCM, создав новый пакет распространения:
Для пакета сделана соответствующая программа, которая в скрытом режиме будет запускать исполняемый файл rootsupd.exe.
![clip_image001[4]](https://blog.it-kb.ru/wp-content/uploads/2011/01/clip_image0014.png "clip_image001[4]")
После распространения созданного пакета на все точки распространения SCCM и объявления на коллекцию клиентских ПК, проблема с развёртыванием JRE будет исчерпана.
Для тех, у кого нет возможности использовать SCCM, распространить это обновление можно и другими доступными способами, например через GPO.
При вводе в эксплуатацию партии новых рабочих станций HP с предустановленной ОС Windows 7 Pro OEM столкнулись с ситуацией, когда новые клиентские компьютеры успешно обновлялись с локального сервера WSUS, но при этом не появлялись на консоли WSUS. Вернее сказать, на консоли отображался лишь один новый компьютер, который последним обратился на WSUS. Изучив WindowsUpdate.log на нескольких таких клиентских компьютерах, стало очевидно, что каждый из них использует один и тот же SusClientId, что и приводит к цикличному переписыванию на WSUS сведений о новых клиентах.
При попытке установки нового пакета Windows Live Essentials 2011 с сайта Windows Live запускается веб-инсталлятор и если мы работаем через прокси с NTLM авторизацией, то в ходе инициализации процесса установки может возникнуть ошибка настройки инсталлятора
Судя по логам прокси сервера, инсталлятор в определенный момент по какой-то причине пытается использовать анонимный доступ вместо учетной записи, от имени которой запущен веб-инсталлятор. Если же установка с сайта производиться с прямым подключением к Интернету, то подобной проблемы нет.
Для тех кто работает за прокси и испытывает подобную проблему нашёл прямую ссылку на дистрибутив полного offline-инсталлятора: Windows Live Essentials 2011 Russian
Столкнулся с ситуацией, когда при создании нового задания в планировщике задач (Task Scheduler) на Windows Server 2008 R2 возникла необходимость запускать это задание в фоновом режиме от имени определенной учетной записи доменного пользователя. Попытка сохранения задания с введенными учетными данными завершалась ошибкой
Как выяснилось, ОС попросту блокировала попытку сохранения учетных данных, так как была изменена политика безопасности Network access: Do not allow storage of passwords and credentials for network authentication
По умолчанию эта политика находится в состоянии Disabled, и её включение приводит к вышеописанной проблеме.
Найти этот параметр можно в оснастке Local Security Policy (Панель управления (Control Panel) > Администрирование (Administrative Tools) > Local Security Policy). Параметр может изменяться как на уровне локальной политики компьютера, так и задаваться доменными GPO.
В один момент заметил, что на одном из контроллеров домена под управлением Windows Server 2008 перестал работать механизм GP Preferences. При этом в логе System периодически фиксировалась ошибка
Log Name: Application
Source: Group Policy Registry
Date: 08.06.2010 6:04:43
Event ID: 8194
Task Category: (2)
Level: Error
Keywords: Classic
User: SYSTEM
Computer: DC02.mydom.com
Description:
The client-side extension could not remove computer policy settings for 'Default Domain Controllers Policy {6AC1786C-016F-11D2-945F-00C04fB984F9}' because it failed with error code '0x8007000d The data is invalid.' See trace file for more details.
Как выяснилось, проблема связана с тем, что по какой-то причине ломается кэш преференций какой-либо групповой политики, что в дальнейшем приводит к проблеме обработки преференций и в других политиках применяемых на данном компьютере.
начиная с версии FOS 9.1 появился secure boot, теперь, чтобы сбросить пароль нужно меньше телодвижений: ребутаем свитч - останавливаем автобут…
Да, верно. Спасибо, исправил.
RSS - Записи
Последние комментарии