MOSS: Unable to import custom SPFields of type User

Problem:
Imagine the following scenario: You have created custom SPField for your Content Type. SPField is of type "User", i.e., a PeopleEditor field where you can select a one or several Active Directory users or groups.

In my case the SPField definition is something like this:

<Field ID="{UNIQUE_GUID}"
Name="ProjectOwner"
Group="MyGroup"
Type="User"
DisplayName="Project Owner"
SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"
StaticName="ProjectOwner"
Required="FALSE">
</Field>

Then you do a STSADM EXPORT and IMPORT for the SPWeb using Content Type using this SPField.

STSADM EXPORT succeeds, but STSADM IMPORT throws error:

Progress: Importing ListItem /a/windows-hardening/Pages?id=1.
FatalError: Value cannot be null.
Parameter name: g
at System.Guid..ctor(String g)
at Microsoft.SharePoint.Deployment.ListItemSerializer.UpdateFieldData(SPListItem listItem, ImportObjectManager objectManager, Guid docId, String fieldName, String value, String value2, Guid gFieldId, Boolean& bCreated, Dictionary`2 brokenFields)
at Microsoft.SharePoint.Deployment.ListItemSerializer.UpdateFieldData(SPListItem listItem, Guid docId, Boolean& bCreated, SPContentTypeId contentTypeId, ImportObjectManager objectManager, Object data)
at Microsoft.SharePoint.Deployment.ListItemSerializer.SetObjectData(Object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector)
at Microsoft.SharePoint.Deployment.XmlFormatter.ParseObject(Type objectType,Boolean isChildObject)
at Microsoft.SharePoint.Deployment.XmlFormatter.DeserializeObject(Type objectType, Boolean isChildObject, DeploymentObject envelope)
at Microsoft.SharePoint.Deployment.XmlFormatter.Deserialize(Stream serializationStream)
at Microsoft.SharePoint.Deployment.ObjectSerializer.Deserialize(Stream serializationStream)
at Microsoft.SharePoint.Deployment.ImportObjectManager.ProcessObject(XmlReader xmlReader)
at Microsoft.SharePoint.Deployment.SPImport.DeserializeObjects()
at Microsoft.SharePoint.Deployment.SPImport.Run()

Thoughts:
If you use -nofilecompression parameter when exporting and importing using STSADM, you can look at the exported Manifest.xml and see the difference between fields that have List="UserInfo" and the ones that don't.

OOB field PublishingContact value is exported like this:
<Field Name="PublishingContact" Value="2;UserInfo" FieldId="6677cf63-f416-4e1e-9e6e-f77f243ef4a6" />

while custom ProjectOwner field value without List="UserInfo" in its definition is exported like this:
<Field Name="ProjectOwner" Value="2;691e9a30-76c4-42b6-869f-294c2c68267d" FieldId="6677cf63-f416-4e1e-9e6e-f77f243ef4a6" />

You can see that the custom field contains the GUID of the list where the item is located in, while the OOB field contains clear reference to UserInfo list.

Solution:
First of all, remember to always include List="UserInfo" when defining SPFields of type "User", like this:

<Field ID="{UNIQUE_GUID}"
Name="ProjectOwner"
Group="MyGroup"
Type="User"
DisplayName="Project Owner"
SourceID="http://schemas.microsoft.com/sharepoint/v3/fields"
StaticName="ProjectOwner"
Required="FALSE"
List="UserInfo">
</Field>

If you realize this requirement too late, you can modify the exported Manifest.xml and replace the values of the fields affected from:

<Field Name="ProjectManager" Value="2;GUID_OF_PAGES_LIST" FieldId="6677cf63-f416-4e1e-9e6e-f77f243ef4a6" </>

to

<Field Name="ProjectManager" Value="2;UserInfo" FieldId="6677cf63-f416-4e1e-9e6e-f77f243ef4a6"</>

and import after that.

In addition you need to have custom application that enumerates all existing items and fix field definition on them using API.

Using WFETCH to call MOSS Web Services

Problem:
I needed to call /_vti_bin/webs.asmx?op=GetColumns web service to get a list of all fields in our SharePoint 2007 installation. I needed to use POST and GetColumns couldn't be called using a browser as it has non-primitive types as parameters.

Solution:
Install WFETCH and configure as described in the image below.

MOSS: No search database is associated with the search shared application

Problem:
When trying to run Configuration Wizard after hotfix updates, Config Wizard stop at step 8/9 and C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\Upgrade.log says:

Upgrading (search) shared database from the searchApplication is null but it should not be.

Unable to locate SearchDatabase for the SharedResourceProvider

Exception thrown was: System.ArgumentNullException: Value cannot be null.
Parameter name: No search database is associated with the search shared application,
at Microsoft.Office.Server.Search.Upgrade.SharedResourceProviderSequence.get_SearchDatabase()
at Microsoft.Office.Server.Search.Upgrade.SharedResourceProviderSequence.AddNextLevelObjects()

Re-run upgrade using stsadm -o upgrade to ensure the search database gets upgraded appropriately

No search database was found, so skip upgrading it

Thoughts:

• Running stsamd-o upgrade -inplace doesn't help, as it just says: Upgrade completed with errors.
• Stopping and starting Office SharePoint Server Search in Central Admin doesn't help.
• In Central Administration > Application Management > Manage this Farm's Shared Services, you might see that Search Database is empty, typing in new search database and re-running the Configuration Wizard doesn't help.
• Central Administration > Application Management > Check Services Enabled in this Farm says: The Search Service is not enabled for SSP . You should assign an indexer and a search database to this SSP.
  

Workaround:
Delete SSP and create a new one.

Solution:
Unknown.

MOSS: Central Admin search pages give Unknown error

Problem:
When going to almost any search related page in Central Admin or SSP you get plain white screen with black text saying: "Unknown error"

Solution:
This one falls probably in the category 'many things can cause this', but in my case I had modified the application.master because of branding.

Luckily in this scenario the Central Admin site is located on a separate application server (indexing), so best solution was to revert the application.master into default OOB version only on that server. No end-users will access sites on that server, so I consider that a safe workaround.

In cases where you really need to modify the application.master, there comes other solutions, such as presented here.

MOSS: Timer lock for Web server was overridden

Problem:
In a MOSS farm, you get the following error messages in Application log of all WFEs.

On WFE1:
The timer lock for Web server 'WFE2' was overridden by Web server 'WFE1' because the lock had not been refreshed within the 20 minute timeout. The timer service on 'WFE2' may be malfunctioning.

On WFE2:
The timer lock for Web server 'WFE1' was overridden by Web server 'WFE2' because the lock had not been refreshed within the 20 minute timeout. The timer service on 'WFE1' may be malfunctioning.

Thoughts:
Verify if this error is preceded with errors indicating WFE unable to connect DB server, such as Could not open a connection to SQL Server.

Educated guess would be that WFEs put a timer lock in DB during some sensitive operations to block access from other timer services. If there is connection issues between WFEs and DB, timer jobs are unable to clear the lock which might lead to these kind of error messages.

Solution:
Check network connections and that WFEs have access to DB server.

MOSS: Infrastructure Update for Microsoft Office Servers throws PostSetupConfigurationTaskException

Problem:
After applying Infrastructure Update for Windows SharePoint Services 3.0 (KB951695) and Infrastructure Update for Microsoft Office Servers (KB951297) and trying to run the SharePoint Products and Technologies Configuration Wizard, the wizard stops on task 8 of 9 and gives error message:

An exception of type Microsoft.SharePoint.PostSetupConfiguration.PostSetupConfigurationTaskException was thrown. Additional exception information: Failed to upgrade SharePoint Products and Technologies.

How to start solving:
Looking at the log provided below the error message leads you to PSCDiagnostics file, but that file doesn't really contain any good error messages. However, it mentions that you should look at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\Upgrade.log for further information regarding the failure.

Looking at Upgrade.log tells us what the problem is.

Error 1:
The access control list on C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\template\layouts\web.config could not be modified because the path could not be located in the file system.

Solution 1:
Trying to locate the web.config file quickly reveals the real cause of the problem: there is no such file in that folder. Reasons for that are (again) unknown at least to me, but copying that file from another SharePoint 2007 installation to the correct folder and restarting the Configuration Wizard should get you around this issue.

If the file exists, you may want to verify that the syntax of web.config is valid.

NOTE! There are several other possibilities for PostSetupConfigurationTaskException, so please post your errors and solutions here and I keep updating the article. Thanks!

MOSS: Using Session_OnStart

Problem:
Want to do something in Session_OnStart event in your MOSS web application? Modifying global.asax doesn't have any effect? Getting frustrated?

Solution:
No worries, just create HttpModule like in the following example. In my code I'm creating a "WWW" cookie that is required by Load Balancer and setting cookie value from an appSettings key in web.config.

---
class NLBModule : IHttpModule
{
#region IHttpModule Members

public void Dispose()
{}

public void Init(HttpApplication context)
{
SessionStateModule sessionModule = (SessionStateModule)context.Modules["Session"];

sessionModule.Start += delegate(object sender, EventArgs e) { sessionModule_Start(sender, e, context); };
}
#endregion

void sessionModule_Start(object sender, EventArgs e, HttpApplication context)
{
context.Response.Cookies.Add(new HttpCookie("WWW", ConfigurationManager.AppSettings["NLB_ID"]));
}
}
---

Finally register the HttpModule in web.config like this:

<system.web>

<httpModules>

<add name="NLBModule" type="MyProject.HttpHandlers.NLBModule, MyProject.HttpHandlers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=XYZ" />

</httpModules>

</system.web>

MOSS: The type specified in the TypeName property of ObjectDataSource could not be found.

Problem:
When using ObjectDataSource in Web Part and you only have your Assembly in GAC, you'll might see the following error:

The type specified in the TypeName property of ObjectDataSource
'myOds' could not be found.

You init the ObjectDataSource in your Web Part e.g., like this:

ObjectDataSource ods = new ObjectDataSource("Namespace.Class", "SomeMethod");
ods.ID = "myOds";
this.Controls.Add(ods);

Solution:
Add reference to the assembly in web.config like this (where MyAssemblyName is the name of the assembly of your Web Part).

<system.web>
<compilation>
<assemblies>
<add assembly="MyAssemblyName, Version=XYZ, Culture=neutral, PublicKeyToken=XYZ" />
</assemblies>
</compilation>
</system.web>

MOSS: Compressing MOSS log files

Problem:
I needed to e-mail a 62 MB MOSS log file to MS support. Yeah, there were in fact some problems in our MOSS installation?!

Knowing that RAR (which I prefer for the reasons you will soon find out) wasn't necessarily available for MS support personnel and that you can't open packages made with newer WinRAR with older versions of WinRAR, I was polite enough to ZIP the log file. A relatively good compression ratio of 13%, so the file was about 8,5 MB, not bad.

Well, of course our Exchange server bounced the mail back complaining about the size of the email (which was near but under 10 MB, so I don't even dare to guess how low the limit on the server really is).

Well, I first opened a new e-mail message window and started writing a complaint to our IT Support so that they'd increase the e-mail size limit, but being a nerd I decided to try compressing the file with RAR as I've had good experiences using it.

Solution:
Guess what, with RAR, the compression ratio was 0% and file size 561 KB! I've been impressed several times with RAR's compression ratio, but I believe this one is something I have to tell my grandchildren (one day) about.

I don't think WinRAR uses the latest version of ZIP, so this comparison is not probably a fair, but as I only want to use one software for my compression needs, it is fair comparison for me.

Some proof:
These screen shots show the files when Best compression ratio was used in both RAR and ZIP.

ZIP, 8,6 MB:

RAR, 0,56 MB

MOSS: The system cannot find the file specified

Problem:
When having two WFE servers configured so that one acts as Search Indexing server and the other acts as Search Query server, you get multiple errors in event log and the search does not work.

On the Indexing server, errors are:

10038: Query machine 'IndexingServer' has been taken out of rotation due to this error: The system cannot find the file specified. 0x80070002. It will be retried in N seconds. Component:

10039: Retry of query machine 'IndexingServer' has failed with error: The system cannot find the file specified. 0x80070002. It will be retried again in N seconds. Component:

10040: The last query machine has been taken out of rotation. Check previous event logs to determine cause. Propagation may be necessary. Component:


On Query Server the errors are:

6482: Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance ().
Reason: Object not found.
Techinal Support Details:
System.Collections.Generic.KeyNotFoundException: Object not found.
at Microsoft.Office.Server.Search.Administration.SearchApi.get_App()
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

10039: Retry of query machine 'QueryServer' has failed with error: The system cannot find the file specified. 0x80070002. It will be retried again in N seconds. Component:

Solution:
Make sure the permissions are set correctly. More exactly see that the Farm Search Service Account is in Administrators group and in WSS_ADMIN_WPG group on the Indexing and Query servers. After that stop and start the Office SharePoint Server Search service in Central Admin.

MOSS: Cannot define same Internal and Public URL in AAM

Background:
We have a LB (Cisco CSS11503) in front of our two WFE's. The LB device functions also as SSL Offloader. The URL of our service for the internal users is https://service.company.com.

Upon page request, SSL Offloading and load-balancing takes place on Cisco, and the requests are redirected to one of the WFE's. Cisco device cannot modify the HTTP-Header of the request, so while the requests are redirected to one of the WFE's, the Request-URI of the request itself is the same FQDN but with http protocol, http://service.company.com.

Problem:
There are some good blog posts about how to configure MOSS AAM in NLB senarios. However, none of them explains how to make the previously mentioned case working. In AAM you just cannot define (or so it seems) Internal URL FQDN to be the same as Public URL FQDN so that in Internal URL the protocol is http and in the Public URL the protocol is https.

Solution:
The order in which you define the URLs is important. The key is that you must first have a single URL in a zone which is using https protocol. After that you may add another URL and define it's protocol to http.

1. In the beginning you only have one URL defined, and this URL is the one you want to use, but you just would like to have the Public URL for Zone URL to say https://service.company.com.





2. No worries, select the Internal URL link http://service.company.com and change the Internal URL to https://service.company.com (or something else than the URL you want to use for the service), click OK.





3. Select "Add Internal URLs" link and type in the http-URL of your service, http://service.company.com, and select Default zone. Click Save.





Now you have the same FQDN for the service, but different protocol in Internal and Public URLs.

We did also define "Front-End-Https: on" header on Cisco, but I don't know if it is required.

MOSS: Deleting site gives error message

Problem:
When deleting a site, you get error: 500 INTERNAL SERVER ERROR. Error is just black text on white background, nothing else.

Some errors are logged into MOSS log:

There is no Web named "/SiteA/testi/_layouts/webdeleted.aspx".

Possible mismatch between the reported error with code = 0x81070504 and message: "There is no Web named "/SiteA/testi/_layouts/webdeleted.aspx"." and the returned error with code 0x80070002.

Thoughts:
Simple.master page has been altered to brand the layout of different pages, which is causing the problem.

Workaround:
Revert Simple.master to original version that came with MOSS.

Solution:
You cannot have

<wssuc:Welcome id="IdWelcome" runat="server" EnableViewState="false"></wssuc:Welcome>

on the simple.master page. Remove it and it works, if not, remove controls from the page one by one until you find out the one causing the error.

MOSS: Backup and restore path-scoped and host-scoped site collections

Problem:
You cannot backup a host-based site collection and restore it as a path-based site collection. For example, you cannot backup site collection from http://service.company.com and restore it to http://anotherservice.company.com/sitecollection.. You could restore it without problems to http://anotherservice.company.com.

The backup and restore procedures will most probably succeed, but you will run into strange "File not found" errors when accessing some sites. Some sites work fine, but others give the error. When you run IISRESET sites that were working might start giving the error as the sites that were giving the error might start working.

Workaround:
According to MS Support, the site structure must be the same in source and destination environments. So, what it means, is that you cannot really use stsadm backup/restore for moving content between different environments if the structure of the web applications differ.

According to MS Support, the following steps should function as a basis for a workaround, although I haven't tried it. Basically what you do is that you alter the web application site collection structure in source environment before taking the backup. If you have tried this and it worked, please let me know.

Source environment:
Site collection 1: http://serviceA.companyA.com
Site collection 2: http://serviceB.companyA.com

Destination environment:
http://serviceA.companyB.com/serviceB
(where http://serviceA.companyB.com is site collection 1 an /serviceB is site collection 2)

So, the two site collections are backed up from source environment and combined under the same URL in destination environment so that source's site collection 2 is located under the site collection 1.

And finally, the steps for the workaround:

1. In source environment, create another site collection underneath the Web application where your site collection 1 is located (http://serviceA.companyA.com/serviceB)
   
2. In source environment, backup site collection 2
   
3. In source environment, remove site collection 2, the web application it belonged to and associated Databases
4. In source environment, restore the backup of the site collection 2 to the new site collection you created under site collection 1 (http://serviceA.companyA.com/serviceB) in step 1.
   
5. Backup and restore to the destination environment.

Solution:
Unknown

MOSS: BlobCache not working

Problem:
When enabling blobCache, the following interesting things occur:

1. Access Denied errors to blobCache folder are reported in Application Log:
   
   An error occured in the blob cache. The exception message was 'Access to the path 'D:\BLOBCACHE\988970710\\STYLE LIBRARY\IMAGES' is denied.'.
   
   
2. Your custom stylesheets stop working. You can see your stylesheet in blobCache folder but the content of that file is something totally different from your stylesheet.
3. Some images are displayed, most of them are not, of some images you can only see half.
   

Workarounds:

According to MS support:

"...there may be a fix being worked on to resolve this type of issue..."

and

"The first is to set 'AllowUnsafeUpdates' However the information covering this is vague and further research has shown that this change will cause a security risk by allowing cross site scripting.

The second workaround is quite simple to apply.

...

For this workaround all you should need to do is add 'NT AUTHORITY\authenticated users' to the site. From my tests it appears that you can add 'NT AUTHORITY\authenticated users' to any group and you can even remove all permissions from 'NT AUTHORITY\authenticated users' and it will still work as a workaround."

Second one was not applicable in my case as I already had the group on the site. Working workaround in my case was that I Checked the image OUT with SharePoint Designer, and Checked it back IN (without doing anything else) and Published it. It started to work immediately. As soon as I run the "Reset to Site Definition" on the image it breaks again.

Solutions:

1. Set Modify privileges to your blobCache folder for IIS_WPG user group
2. Unknown. Please try the second or third workaround.
   
3. Office SharePoint Server 2007 hotfix package that is dated April 30, 2009 seems to contain fix for this, as it says in the hotfix description: After a reghost operation (Reghost.aspx) on a publishing Web, all files that have been customized at least once will have a hardcoded size of 200 bytes in the alldocs table after these files are restored to the original versions. This causes Blobcache to save only the first 200 bytes of the affected files to the cache. This behavior causes invalid images, .css files, and corrupt .js files served to visitors. The Blobcache reset is not enough. You must modify the files to have the correct size information in the alldocs table.

MOSS: Unknown error on Central Admin

Problem:
The front page of the Central Admin site works, but clicking on any link on the page gives "Unknown Error" (just black text on white background).

Workaround:
Reinstall MOSS and hope that it won't break again. Don't waste your time fiddling with Configuration Wizard, it won't do any good.

Ok, you might find the cause of the error by disabling custom error messages on the site.

Solution:
Many, depending on the error.

MOSS: One or more errors deploying administration application pool credentials.

Problem:
When trying to change passwords for Central Administration and Timer service according to Technet instructions you get error:

One or more errors deploying administration application pool credentials. Please check the application event log and fix manually. The path specified cannot be used at this time. (Exception from HRESULT: 0x80070094)


Thoughts:
Surprisingly the application event log is as helpful as always when it comes to MOSS errors as it says:

---------
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchAdminSharedWebServiceInstance (a1356919-7519-4867-a715-6f7bbcb02d2b).

Reason: The path specified cannot be used at this time. (Exception from HRESULT: 0x80070094)

Techinal Support Details:
System.Runtime.InteropServices.COMException (0x80070094): The path specified cannot be used at this time. (Exception from HRESULT: 0x80070094)
at System.DirectoryServices.DirectoryEntry.CommitChanges()
at Microsoft.SharePoint.Metabase.MetabaseObject.Update()
at Microsoft.SharePoint.Administration.SPProvisioningAssistant.ApplyIisVirtualDirectorySettings(VirtualDirectory virtualDirectory, String path, AccessFlags accessFlags, String applicationName, String applicationPoolId, String[] scriptMaps)
at Microsoft.SharePoint.Administration.SPProvisioningAssistant.ProvisionIisRootVirtualDirectory(WebSite webSite, String path, AccessFlags accessFlags, String applicationName, String applicationPoolId, String[] scriptMaps)
at Microsoft.SharePoint.Administration.SPProvisioningAssistant.ProvisionIisWebSite(String serverComment, String[] serverBindings, String[] secureBindings, AuthenticationMethods authenticationMethods, String[] authenticationProviders, String path, AccessFlags accessFlags, String applicationName, String applicationPoolId, String[] scriptMaps, String sslCertificateSubjectName)
at Microsoft.SharePoint.Administration.SPMetabaseManager.ProvisionIisWebSite(String serverComment, String[] serverBindings, String[] secureBindings, Int32 authenticationMethods, String[] authenticationProviders, String path, Int32 accessFlags, String applicationName, String applicationPoolId, String[] scriptMaps, String sslCertificateSubjectName)
at Microsoft.Office.Server.Administration.SharedWebServiceInstance.Synchronize()
at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
---------

If you open Internet Information Services (IIS) Manager you will probably also see pretty much nothing, just empty tree with empty Internet Information Services node and nothing under it. This is tightly related to the problem as if you look closely the error in the application event log, you see that the error occurs at ApplyIisVirtualDirectorySettings. If there is no Virtual Directory to apply settings to, no wonder an error occurs. Maybe the application log event was a bit useful after all.

Workaround:
Restart IIS 6.0, or you restart the process that uses the IIS ADSI provider.

Solution:
There is a hotfix KB946517 for this issue.

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