Friday, January 11, 2008

MOSS audiences and missing AD groups

I had a problem where I was trying to construct audiences in MOSS with members based on certain Active Directory groups, but I had a handful of groups that did not appear in the "browse" dialog on the Add Audience Rule page. It turns out these groups were empty, and that the group list is populated by reading the groups each user is a member of during the profile import. This dialog does NOT contact AD.

I added an account to the groups in question and repeated the profile import. Voila--the groups appeared in the browse dialog.

Thursday, January 10, 2008

Zenoss Core web site (Zope application server) crash

We had two Zenoss winexe processes go out of control yesterday. They consumed all available CPU and RAM and caused the rest of the daemons to crash/slow down. When we restarted Zenoss ("zenoss stop" followed by "zenoss start"), all Zenoss daemons came up, but zopectl (the Zope application server daemon) immediately died.

We found several of the following errors in $ZENHOME/log/event.log that appeared to be related:

2008-01-09T10:15:36 ERROR Zope.SiteErrorLog http://server.domain.local:8080/zport/RenderServer/render
Traceback (most recent call last):
File "usr/local/zenoss/lib/python/Zope2/App/startup.py", line 167, in zpublisher_exception_hook
File "usr/local/zenoss/lib/python/ZPublisher/Publish.py", line 120, in publish
File "usr/local/zenoss/lib/python/Zope2/App/startup.py", line 233, in commit
File "usr/local/zenoss/lib/python/transaction/_manager.py", line 84, in commit
File "usr/local/zenoss/lib/python/transaction/_transaction.py", line 381, in commit
File "usr/local/zenoss/lib/python/transaction/_transaction.py", line 379, in commit
File "usr/local/zenoss/lib/python/transaction/_transaction.py", line 424, in _commitResources
File "usr/local/zenoss/lib/python/ZODB/Connection.py", line 462, in commit
File "usr/local/zenoss/lib/python/ZODB/Connection.py", line 495, in _commit
ConflictError: database conflict error (oid 0x3b, class Products.ZenUtils.PObjectCache.PObjectCache)

Remediation:
  1. Make sure zeoctl is started (as zenoss, "zeoctl start" followed by a few seconds pause and then "zenoss status" to confirm it has a PID and is running).
  2. cd $ZENHOME/var
  3. rm *.zec (this deletes invalid cache files that are causing the above error)
  4. zopectl start
  5. Wait a few seconds, then check if Zope stays running (use "zenoss status" or just hit the website to confirm).

Friday, January 04, 2008

WSS/MOSS SP1 application caused DCOM activation error

I applied the WSS 3.0 SP1 and MOSS SP1 to one of my MOSS installations and started getting the following errors:

Application Log
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 6482

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{3D42CCB1-4665-4620-92A3-478F47389230}
to the user HCHB\moss-svc-prd SID (S-1-5-21-796845957-484763869-839522115-12856). This security permission can be modified using the Component Services administrative tool.

System Log

Event Source: DCOM
Event Category: None
Event ID: 10016

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
{3D42CCB1-4665-4620-92A3-478F47389230}
to the user HCHB\moss-svc-prd SID (S-1-5-21-796845957-484763869-839522115-12856). This security permission can be modified using the Component Services administrative tool.

I tracked down these class IDs and it turns out they belong to the OSearch DCOM application. I swear, I wish in this modern era that MOSS didn't use DCOM. To fix this, verify that your primary MOSS service account is in the Distributed COM Users group on the MOSS server. Then, in dcomcnfg, locate the OSearch application and choose Properties.

On the Security tab, click Edit on the Launch and Activation Permissions area and add the Distributed COM Users group to the ACL. Check both the Local Launch and Local Activation for this group. Restart OSearch (net stop osearch followed by net start osearch at a command prompt) and that should fix the problem.