SharePoint esetén - legyen az Office SharePoint Server (MOSS) vagy Windows SharePoint Services (WSS) - érdemes megszabadulni minden piros vagy sárga bejegyzéstől az eseménynaplóban, mert annyira komplex rendszerről van szó, hogy szinte minden komponense hatással van a másikra. Tehát még ha nem is tűnik relevánsnak a hiba a leírása alapján, okozhat gondot valahol teljesen máshol.
Az alábbi 10016 kódú DistributedCOM hibát például már több helyen láttam a Windows System logban:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {61738644-F196-11D0-9953-00C04FD919C1} to the user DEMODOM\SspAppPool SID (S-1-5-21-1716361853-3848672439-3488686640-1120) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.
A hiba tipikusan akkor jön elő, ha nem vadul mindenhol a helyi admin felhasználót adjuk meg service accountként telepítéskor, hanem próbáljuk magunkat a least privilege elvhez tartani. Ebben az esetben az IIS application pool felhasználókra érkezik panasz, amilyen az én esetemben a Shared Service Providernél használt DEMODOM\SspAppPool felhasználó.
Íme a megoldás:
- Nyissuk meg a Component Services MMC-t.
- Nyissuk ki a Component Services -> Computers -> My Computer -> DCOM config ágat.
- Keressük meg a rengetegben az IIS WAMREG admin Service elemet, ez ugyanis a hibaüzenetben említett {61738644-F196-11D0-9953-00C04FD919C1} .
- Nyissuk meg a Properties ablakot.
- Kattintsunk a Security fülre, majd a Launch and Activation Permissions csoportban válasszuk a Customize opciót és kattintsunk az Edit gombra.
- A megjelenő ACL ablakban vegyük fel a hibaüzenetben szereplő felhasználót és adjuk neki Allow Local Activation jogot.
- Végül eresszünk el egy IISRESET-et, mint minden SharePoint matatás végén :)
Természetesen létrehozhatunk egy security csoportot is, beletehetjük a felhasználókat és adhatunk annak Local Activation jogot. Ezzel nekem az volt a problémám, hogy single server scenarioban, tartományvezérlőn az Active Directory Users and Computers sehogy nem engedte, hogy az NT AUTHORITY\NETWORK SERVICE felhasználót hozzáadjam egy security grouphoz.