Як фіксити проблему "The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID"

Якщо у вас проблема, як і в мене:

 Малюнок 1.

То після "куріння" мікрософтівських і навколо- фрумів, найкраще все таки зробити наступне: 

• руками в реєстр не лазити і не змінювати там привілеї, не перебирати на себе (поточного адміна) права Trustedinstaller
• не морочитися потім з повертанням всього того назад в реєстрі.
• не лазити руками в ComponentServices i не змінювати там права DCOM компонентам ні для якихось окремих програм. ні тим паче глобально.
  (Про цей весь непотріб написано тут. Почитати можна абись-те знали про що мова. Заодно побачите, що не всім допомагає, і що буває, якщо це таки зробити) 

А краще зробити це наступним чином (план згрубша, недеталізований):

1. Поставити ПоверШелівську компоненту, яку розробив гуру від MS (дай йому Боже, здоров'я) і виклав ту.
2. З її допомогою надати права відповідному користувачу, що згадується в помилці. Це робиться в обхід заборон на зміну прав, задля якої інші танцюють з регедітом навколо тамтих CLSIDшок. Дуже зручно і, що головне - залізно працює. Причому працює точково, прицільно і правильно.

Покроковий мануал:

1. Аналізуємо помилку: нам потрібний ідентифікатор програми (AppID, на Малюнку 1 -виділено зеленим), що викликав помилку, та користувач, для якого ця помилка виникла (на малюнку - виділено жовтим)
2. Запускаємо PowerShell з Elevated Permissions. (якщо Ви не знаєте, як то зробити - краще Вам не робити нічого з того, що тут написано)
3. Перевіряємо права поточного користувача командою
     Get-ExecutionPolicy -scope CurrentUser
   Якщо права - Undefined чи Restricted, то в мене є дуже великі сумніви, що Вам вдалося запустити PShell з правами ЛокалАдміна. Але якщо Ви таки впевнені в цьому, то тимчасово підніміть права поточного користувача до RemoteSigned командою
     Set-ExecutionPolicy RemoteSigned -Scope CurrentUser (Не забудьте потім цією ж командою повернути попередні права!)
4. Завантажуємо PS модуль, який надав гуру від MS у своєму дописі (наприклад, в D:\Temp) . І ставимо його командою
     import-module "D:\Temp\DCOMPermissions.psm1"
5. Перевіряємо поточні доступи нашої програми з APPID {4839DDB7-58C2-48F5-8283-E1D1807D0D7D}. Це робити не обов'язково, але бажано, бо ж ми маємо пересвідчитися, що проблема саме в тому, що для користувача LOCAL SERVICE дійсно відсутні права активації програми з APPID {4839DDB7-58C2-48F5-8283-E1D1807D0D7D}. Це можна зробити:
• як командою
  Get-DCOMPermission -ApplicationID "{4839DDB7-58C2-48F5-8283-E1D1807D0D7D}" -Type Launch
  (і пересвідчитися, що користувача взагалі не згадано в переліку прав)
• так і візуально, запустивши dcomcnfg і знайшовши там відповідну програму по назві ( в мене це ShellServiceHost), яку, відповідно, треба взнати, запустивши regedt32 і знайшовши її по CLSID чи APPID з помилки:
   Мал. 2
  
  
• Мал. 3
  
  
6.  Надаємо права командою
   Grant-DCOMPermission -ApplicationID "{4839DDB7-58C2-48F5-8283-E1D1807D0D7D}" -Account "LOCAL SERVICE" -Type Launch -Permissions LocalLaunch,LocalActivation -OverrideConfigurationPermissions
   в якій значення ключа Permissions - лише локальний запуск, без віддаленого, що добре, а ключ OverrrideConfigudationPermissions - дає можливість зробити це в обхід деяких заборон, які видно, зокрема, на мал 3.
7. Результат: