Enabling MOSS Anonymous Access

1. From Central Administration > Application Management > Application Security > Authentication Providers, select a Web application and the zone you want to modify. This is usually default.

2. In the middle of the page, check Enable Anonymous Access and choose Save

3. All site collections in that Web application can now have anonymous access enabled.

4. Go to a site collection in the Web application you just enabled anonymous access for

5. From Site Actions > Site Settings, open Advanced Permissions

6. From the Settings drop-down menu, select Anonymous Access

7. For this example, enable anonymous access for Lists and Libraries and click OK

8. Browse to any document library in this site collection

9. From the Settings drop-down menu, select Document Library Settings

10. In the Permissions and Management column, select Permissions for this document library

11. From the Actions menu, select Edit Permissions to break inheritance

12. From the newly appeared Settings drop-down menu, select Anonymous Access

13. Check View Items and click OK.

Issues after restoring MOSS to a previous VM snapshot

We restored our VM MOSS farm this morning from a snapshot taken a couple of months ago. Various issues occurred. Please note i am still working through some of the errors and will update this post as i find the answers.

1. I could no longer login to the server because the snapshot was older than 30 days - the computer account for the server had expired and so needed to be reset and reconnected to the domain. See this blog for steps to fix this.
   
2. The MOSS environment although appearing correct in Central Administration was not configured in IIS. The Central Administration site was the only site appearing in IIS even though all the web applications were still there.
   
   To fix this:


1. Delete the old web application using Central Administration.
2. Delete all the SSP web apps & DBs, apart from the default SSP which cannot be deleted.
3. Recreate the web applications with Temp DB names.
4. Recreate the SSPs with new DBs.
5. Change the default SSP to one of the newly created SSPs, then delete the original default SSP inc DB, then recreate it's web app and set back to the default updating any associations as required.
   
   At this point I ran in to some issues recreating the SSP with the following errors. First of all the SSP failed to provision with the error:
   
   Provisioning failed: A transport-level error has occurred when sending the request to the server.
   
   Looking in the Event Log i found the following related errors:
   
   Event ID 5554
   Failure during sweep synch. Exception was A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.).
   
   Event ID 7888
   A runtime exception was detected. Details follow.
   Message: A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
   
   Event ID 5586
   Unknown SQL Exception 10054 occured. Additional error information from SQL Server is included below.
   
   A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
   
   Solution:
   http://social.msdn.microsoft.com/forums/en-US/sqldatabaseengine/thread/0671c03b-5488-4be4-bc5a-579849fa0950
   Reboot the server and kill any remaining connections (delete the Admin accounts from local users & groups, reboot, add the Admin accounts back in).
   
   Also in the event log were the following errors:
   
   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}
   
   Solution:
   http://sharemypoint.wordpress.com/2007/12/18/error-event-id-6398-and-6482-about-security-rights-of-osearch-service/
   Add the WSS_WPG, WSS_ADMIN_WPG, Search & Admin accounts to the OSearch DCOM Service
   
   Event ID 6141
   The site /ssp/admin could not be created. The following exception occured: This page has encountered a critical error. Contact your system administrator if this problem persists.
   
   Event ID 6610
   Safe mode did not start successfully. This page has encountered a critical error. Contact your system administrator if this problem persists.
   
   Event ID 5629
   Failed to load the SafeControl assembly paths for web.config. C:\Inetpub\wwwroot\wss\VirtualDirectories\ssp180
   
   Error importing WebPart. Assembly Microsoft.Office.Server.Search, Version=OAssemblyAssemblyVer, Culture=neutral, PublicKeyToken=OAssemblyPublicKey, TypeName. Microsoft.Office.Server.Search.WebControls.ActiveCrawls
   
   
1. I deleted the SSP web apps again.
   
2. Stop the search query & index services.
3. Start the search query & index services.
4. Restart IIS.
5. Recreate the SSP web app.
6. Recreate the SSP & set back to default with any associations required.
   
   Success - the SSP provisioned correctly.
   
   
1. Restore the DB from by opening the Content Database page in Central Administration. Delete the Temp DB then in STSADM associate the original DB:
   
   cd C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN
   
   stsadm.exe -o addcontentdb -url http://portal -databasename MOSS_MyDB_WSS_Content -databaseserver MyServer
   
   
3. If you receive the error 'An unexpected error has occured' open the web.config and update as follows:
   http://blog.thekid.me.uk/archive/2007/02/15/a-solution-to-quot-an-unexpected-error-has-occurred-quot-in-wss-v3.aspx
   
1. Change <SafeMode MaxControls=“200“ CallStack=“false“ to <SafeMode MaxControls=“200“ CallStack=“true“…>
2. Set custom errors to 'Off' <customErrors mode=“Off“/>

Adding New SSP Administrators

http://blogs.msdn.com/sgoodyear/archive/2007/06/20/adding-new-ssp-administrators.aspx

When you add a new user account to the SSP site, even if you grant them Full Control permissions or add them as a Site Collection Administrator, initially they will experience access denied error messages when they click on any of the following links on the SSP Admin page:

* User profiles and properties
* Profile services policies
* My Site settings
* Personalization services permissions
* Audiences
* Import application definition
* Business Data Catalog permissions

These sections need to have permissions explicitly set. Initially, the setup account will have full access to the SSP, so use that account to grant rights to new SSP administrators you wish to delegate SSP administrative duties to.

Notice the items highlighted in bold in the list above. These are where you assign the remaining SSP permissions. Adding new SSP administrators to the "Personalization services permissions" section and granting appropriate rights will grant rights related to the first five links in the list above. Repeating the process in the "Business Data Catalog permissions" section will grant rights related to the last two links.

At this point, the new SSP administrator has all the appropriate access permissions they need to administrate the SSP.