MOSS: Unable to view the stack trace in Central Administration

Problem:
Unable to view full stack trace in Central Admin site.

Web.config of central admin site has

<safemode maxcontrols="50" callstack="true">

and

<customerrors mode="Off">

Solution:
You must set AllowPageLevelTrace to true as well like this:

<safemode maxcontrols="50" callstack="true" AllowPageLevelTrace="true" />

MOSS: Failed to compile audience. Exception was: 'Failed to obtain crawl status.'

Problem:
When trying to populate audiences nothing happens. Errors are logged into application event log:

5693: Failed to compile audience. Exception was: 'Failed to obtain crawl status.'

and

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 DOMAIN\USERACCOUNT SID (S-1-5-21-2339047900-2053458781-3908873488-1605). This security permission can be modified using the Component Services administrative tool.

Solution:
The tricky part was that when looking at the DCOM Config list, there are no items with the GUID {3D42CCB1-4665-4620-92A3-478F47389230}. However, doing a search on the registry revealed that the problematic item was OSearch.

So, in Component Services, give Local Activation permission on the OSearch application to the account that is used as your SSP Service Credentials (Central Administration > Application Management > Manage this Farm's Shared Services > New Shared Services Provider).

Note! If SSP Service Credentials account is different from the account mentioned in the error message, the reasons for the error message is probably slightly different, so give permissions to the user mentioned in the error message.

MOSS: PartCacheWrite and PartCacheRead not working using Storage.Personal

Problem:
Unable to get cached items from Storage.Personal as it always returns null.

Also when using CacheableWebPart the RenderCachedOutput returns false meaning the cache is empty.

Thoughts:
When using Storage.Shared everything works fine.

MSDN article: "The problem is that when a Web Part is not yet personalized, you must read and write cached data using shared cache storage, even if the current mode is personal. Web Parts use shared storage, even for personal properties, until a user actually saves a personalized setting."

Still it doesn't explain if CacheableWebPart doesn't work.

Solution:
Unknown

MOSS: SPWeb.SiteGroups vs. SPWeb.Groups

Problem:
When creating a site and adding groups to it programmatically, I add groups to the new site's SiteGroups collection like this:

newSite.SiteGroups.Add(grpOwnersName, currentUser, currentUser, grpOwnersName);

Then I'd like to define some properties of the new group, and I try to do this:

grpOwners = newSite.Groups[grpOwnersName];

Oh no, the Groups collection is empty! How and when is it populated?

Workaround:
Of course I can use SiteGroups, but I'd very much like to use Groups collection since there are zillions of groups in the SiteGroups collection, and I'm a performance freak.

grpOwners = newSite.SiteGroups[grpOwnersName];

Solution:
Unknown