В моей практике достаточно часто возникают ситуации, когда из-за кривой настройки приложений и системных компонентов в журнале System начинают появляться сообщения о проблемах с доступом к DCOM-приложениям. Раньше у меня как-то никогда не доходили руки до подробного исследования, как эти проблемы решать. Однако сегодня я впервые поставил агента SCOM на Windows Server 2012 с включенной дедупликацией на томах и тут же получил в SCOM груду предупреждений о том, что дедупликация не настроена нужным образом (хотя она настроена). В конечном итоге все свелось к тем самым разрешениям DCOM, и я все-таки убил два часа, чтобы докопаться до корней проблемы и найти общий алгоритм ее решения. Привожу его ниже.
== Проблема
В журналах сервера появляются предупреждения с источником DistributedCOM, кодом 10016 и сообщением вида
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{CLSID} and APPID {APPID} to the user USERNAME SID (SID) [...]
В зависимости от сценария на сервере могут возникать дополнительные проблемы со службами и приложениями.
== Причина
Отсутствие прав доступа к DCOM-приложению у пользователя, от имени которого работает некая служба или приложение (имя указано в сообщении об ошибке).
== Решение
1) Определить, о каком DCOM-приложении идет речь
* Запустить Regedit и открыть раздел HKEY_CLASSES_ROOT\CLSID
* Найти в этом разделе подраздел с именем {СLSID}, упомянутым в сообщении в журнале.
* Убедиться, что в ключе AppID в этом разделе прописан {APPID}, упомянутый в сообщении в журнале.
* Запомнить название, фигурирующее в ключе (Default) в данном разделе - это название приложения DCOM, к которому не удается получить доступ.
* Перейти в Панель управления и в разделе Administration Tools открыть оснастку Component Services.
* Перейти в раздел Computers -> My computer -> DCOM Config.
* Найти в этом разделе приложение с названием, совпадающим или похожим по смыслу на запомненное на предыдущем шаге.
* Войти в его свойства и убедиться, что в поле Application ID прописано значение {APPID} из сообщения из журнала.
Если похожее по смыслу название найти не удается, у разработчиков этого приложения больная фантазия или кривые руки. В таком случае единственным способом определить нужное DCOM-приложение - подряд просматривать свойства всех DCOM-приложений в разделе DCOM Config, сравнивая их Application ID с {APPID}, фигурирующим в сообщении в журнале.
2) Настроить права
После обнаружения проблемного приложения необходимо дать на него права локальной активации для нужной учетной записи. Следует войти в свойства приложения, перейти на вкладку Security и в разделе Launch and Activation permissions установить радиофлажок Custimize. Нажать кнопку Edit, добавить нужную учетную запись кнопкой Add и установить для нее флажки Local launch и Local activation.
3) Если элементы управления правами недоступны
В случае, если все элементы управления на вкладке Security серые и неактивные, у текущего пользователя отсутствуют разрешения на правку разрешений для данного приложения. Необходимо выдать их следующим образом:
* Запустить Regedit и перейти в раздел HKEY_CLASSES_ROOT\AppID.
* Найти в этом разделе подраздел с названием, совпадающим с {APPID} в сообщении в журнале.
* Войти в разрешения этого раздела и нажать кнопку Advanced. Назначить себя владельцем данного раздела. Сохранить изменения и закрыть окно разрешений.
* Заново открыть окно разрешений и добавить себе (или группе Administrators) разрешение Full control. Сохранить изменения.
* Перезапустить оснастку Component Services. Теперь вкладка Security нужного DCOM-приложения доступна для редактирования.
Например, если DCOM-компонент дёргался в IIS, то iisreset или Recycle в соответствующем пуле...
О чем я, собственно, и написал.
вставить выделенную цитату в окно ответа