Adding users to Project Server PWA site

To grant users access to the PS PWA site they need to be added via the Server Settings / Manage Users page in the PWA site. Simply adding them through Site Settings / Advanced Permissions will not work.

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.

Event ID 0 - The description for Event ID ( 0 ) in Source ( .NET Runtime ) cannot be found

The Problem:

Event ID 0

The description for Event ID ( 0 ) in Source ( .NET Runtime ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Unable to open shim database version registry key - v2.0.50727.00000.

The Solution:

KB918642 - A .NET 2.0 application may require Read/Write permission to a registry

Download the hotfix and apply to the server displaying the error - in my case this was the Index server.

Event ID 7888

The Problem:

I found the following error on my Index Server:

Event ID 7888

A runtime exception was detected. Details follow.
Message: Access Denied! Only site admin can access Data Source object from user profile DB.

Techinal Details:
System.UnauthorizedAccessException: Access Denied! Only site admin can access Data Source object from user profile DB.
at Microsoft.Office.Server.UserProfiles.SRPSite.
AdminCheck(String message)
at Microsoft.Office.Server.UserProfiles.DataSource.
_LoadDataSourceDef(IDataRecord rec)
at Microsoft.Office.Server.UserProfiles.DataSource.
_LoadDataSourceDef(String strDSName)
at Microsoft.Office.Server.UserProfiles.
DataSource..ctor(SRPSite site, Boolean fAllowEveryoneRead)
at Microsoft.Office.Server.UserProfiles.
DataSource..ctor(SRPSite site)
at Microsoft.Office.Server.UserProfiles.
UserProfileConfigManager.GetDataSource()
at Microsoft.Office.Server.UserProfiles.
BDCConnector.RefreshConfiguration(String sspName)

The Solution:

1. Open your SSP and navigate to Personalization Services Permissions.
   
2. Select Add User and add your SSP process account with Manage User Profiles permissions.
   
   

Crawl Scheduling Error - Access Denied

When you set up your SSPs one of the things you will come across is Crawl Scheduling. This comes under Search Settings and allows you to configure Incremental Crawls and Full Crawls to the frequency you would like. For example, Full crawl once a day, Incremental Crawl every 5 minutes of each day.

The problem:

I received an error whilst building a new farm this week when trying to set the Crawl Schedules.

When I hit Ok I received the error:

ACCESS is DENIED. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))

The Solution:

To fix this you need to add the account WSS_WPG to the C:\Windows\Tasks folder on your Index server and apply modify rights.



If you cannot see the Security tab on the Tasks folder you need to open a command prompt and type is:

attrib -s %windir%\tasks

When you right click on the tasks folder having done this you should be able to see the Sharing & Security option.

To remove the option once you have applied the changes to the folder open command prompt again and type:

attrib +s %windir%\tasks

Changing MOSS service accounts & passwords

I have been preparing some servers for a bunch of testing with PerformancePoint Server (more to follow on this later) which required me to change our MOSS service accounts. Reading around the steps to update these credentials appeared pretty straight forward but as usual MOSS' idiosyncrasies were all to apparent. Here's what i did and how i managed to solve the issues that arose. Hope it helps someone else with the same challenge.

The accounts to be changed were as follows:

1. old_moss_admin ----> new_moss_admin
2. old_ssp_ap ---->new_ssp_ap
3. old_ap1_process ---->new_ap1_process

I followed the following MS KB instructions: 'How to change service accounts and service account passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0'

1. MOSS Admin Account Update

To update the account old_moss_admin to new_moss_admin:

1. Update the password for the account that is used by the Central Administration application pool. To do this, follow these steps:


1. On all servers in the server farm, open a command prompt, type the following line, and then press ENTER:
   cd %commonprogramfiles%\Microsoft Shared\Web server extensions\12\Bin


2. On the server that hosts the Central Administration Web site, type the following line at the command prompt, and then press ENTER:
   stsadm -o updatefarmcredentials -userlogin DomainName\UserName -password NewPassword


3. On all other servers in the server farm, type the following line at the command prompt, and then press ENTER:
   stsadm -o updatefarmcredentials -userlogin DomainName\UserName -password NewPassword -local


4. Restart Microsoft Internet Information Services (IIS) 6.0. To do this, type the following line at the command prompt, and then press ENTER:
   iisreset /noforce


2. Verify that the Administration Application Pool Credential Deployment job definition is no longer displayed on the Timer Job Definitions page of SharePoint 3.0 Central Administration. To do this, follow these steps:


1. Open SharePoint 3.0 Central Administration, click Operations, and then click Timer job definitions under Global Configuration.


2. Verify that the Administration Application Pool Credential Deployment job definition is no longer displayed in the list.

Error: My Central Administration is now no longer available with the error: 'Service Unavailable'

• I checked & retyped the password in CA web app pool.
• I checked the WSS_WPG, WSS_RESTRICTED_WPG and WSS_ADMIN_WPG local groups on each of the servers - all seemed to be up to date.
• Restarting the CA web app pool makes no difference.

At this point i rolled back to the previous credentials. I then tried again from the start following the same steps above. Result - my Central Administration was still unavailable with the error: 'Service Unavailable'

• I checked the IIS_WPG local group on each server. The new_moss_admin account was not updated so i added it to the group.

I then discovered a couple of DCOM errors in the System Event viewer.

1. I updated the new CA account 'new_moss_admin' to:


• IIS Admin Service
• IIS WAMREG Admin Service


2. Restarted IIS.

Success: Central Admin is up and running again.

2. SSP Account Update

To update the SSP account old_ssp_ap to new_ssp_ap:

Attempt 1 - The wrong way...

1. Open Central Administration
2. Navigate to the Operations page
3. Select Service Accounts
4. Select the radio button Web app pool
5. Select the web service - WSS Web App
6. Select the App Pool - SSP1
7. Select the radio button Configurable
8. Input the new credentials
9. Ok
10. Restarted IIS on both my servers

Error: This had no effect other than stopping me from accessing the SSP. Checking in IIS the account was not updated to the new credentials. I then tried to update the accout via IIS but this had noeffect either and on opening the App Pool properties again i discovered that the account credentials had changed themselves back to the old account.

Attempt 2 - The right way...

I then tried a different approach:

1. Open Central Administration
2. Navigate to the Shared Services Aministration homepage
3. Hover over SSP1's title and select Edit Properties from the drop down.
4. Scroll down to SSP Server Credentials
5. Delete the old credentials and input the new account username & password
6. Ok
7. I then changed the SSP to be the default SSP.
8. Open Compnent Services and update the DCOM services IIS Admin & IIS WAMREG with the new account.
   
9. Restarted IIS on both my servers.

Checking IIS the account was still not updated to the new credentials and i still could not access the SSP website.

Success: 10 minutes later having searched on Google again and felt thoroughly annoyed at there being no pages I hadn't yet read on this topic I checked the SSP website again and it worked! Checking IIS the accounts have now updated to the new credentials.

At this stage I discovered some new errors in the Event View

1. Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (5d77cabf-3414-40cc-a5ef-f30226a9288b).
   
   Reason: The program attempted to update an object that was updated by another user.
   
   
2. Eventid 6482 - Reason: Access to the path 'C:\WINDOWS\system32\drivers\etc\HOSTS' is denied.
   
   This error was now occuring every minute.
   
   The solution to this (and the previous error) can be found in my previous post here: http://bytelab.blogspot.com/2008/02/sharepoint-search-service-cannot-find.html
   

3. Application Pool Process Accout Update

To update the web app pool process account old_ap1_process to new_ap1_process:

1. Open Central Administration
2. Navigate to the Operations page
3. Select Service Accounts
4. Select the radio button Web app pool
5. Select the web service - WSS Web App
6. Select the App Pool - MOSS Portal
7. Select the radio button Configurable
8. Input the new credentials
9. Ok
10. Open Compnent Services and update the DCOM services IIS Admin & IIS WAMREG with the new account.
11. Restarted IIS on both my servers

Success: All updated and working ok.

************************************************************

Useful web sites i visited for this:

• Change passwords for Central Administration and Timer service (Windows SharePoint Services) http://technet.microsoft.com/en-us/library/cc288991.aspx
• How to change service accounts and service account passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0 http://support.microsoft.com/kb/934838
• MOSS 2007 Setup Accounts Clayton J http://claytonj.wordpress.com/2007/04/23/moss-2007-setup-accounts/
• How to change service accounts and their passwords in MOSS and WSS 3.0 http://weblogs.asp.net/erobillard/archive/2007/07/06/how-to-change-service-accounts-and-their-passwords-in-moss-and-wss-3-0.aspx
  

Enable Anonymous Access

This info originally came from: http://weblogs.asp.net/bsimser/archive/2006/09/25/Enabling-anonymous-access-in-SharePoint-2007.aspx

First, enable anonymous on the IIS web site:

• Launch IIS - Start / Administration Tools / IIS
• Select the web site, right click and select Properties
• Click on the Directory Security tab
• Click on Edit in the Authentication and access control section

Or, using the Central Administration section:

• Central Administration / Application Management
• Select “Authentication Providers” in the “Application Security” section
• Click on the “Default” zone (or whatever zone you want to enable anonymous access for)
• Under “Anonymous Access” click the check box to enable it and click “Save”
  
  
  

NOTE: Make sure the “Web Application” in the menu at the top right is your portal/site and not the admin site.

You can confirm that anonymous access is enabled by going back into the IIS console and checking the Directory Security properties.

Next, enable anonymous access in the web site.

• In your web site navigate to the site settings page. MOSS: Site Actions / Site Settings / Modify All Site Settings. WSS: Site Actions / Site Settings.
• Under the “Users and Permissions” section click on “Advanced permissions”
  
  
  
  
• On the “Settings” drop down menu (on the toolbar) select “Anonymous Access”
• Select the option you want anonymous users to have (full access or documents and lists only)
  
  
  

Now users without logging in will get whatever option you allowed them.

A couple of notes about anonymous access:

• You will need to set up the 2nd part for all sites unless you have permission inheritance turned on
• If you don’t see the “Anonymous Access” menu option in the “Settings” menu, it might not be turned on in Central Admin/IIS. You can manually navigate to “_layouts/setanon.aspx” if you want, but the options will be grayed out if it hasn’t been enabled in IIS
• You must do both setups to enable anonymous access for users, one in IIS and the other in each site

Create Page Access Denied

Users need to be in the Readers group for the Master Page Gallery in order to create pages in the portal.

User access to MOSS blocked

This is so far unresolved

A user is unable to access the portal.

They changed their password 3 weeks ago. The error msg they get is as follows:

The local security authority cannot be contacted.

They can access the portal when logging in as themselves through someone elses PC, but not their own.

Their profile has been reset and we can access using a runas cmd.

Google suggested this...

See link for full details: http://www.sharepointu.com/forums/Dodgy_logins_and_deleted_files/m_39098/tm.htm

When a student changes his/her Windows password after being prompted, they are unable to access their Sharepoint sites (ERROR: "The local security authority cannot be contacted") although they can still log in to Windows. Our workaround to this at the moment is to temporarily make the student an administrator (the command prompt is blocked for students), log them in to Windows and use the command prompt to run "control keymgr.dll" and delete any stored usernames and passwords for Sharepoint. Once that is done we can remove the admin privileges and they can log in OK. The only time this is not a problem is when the user changes their password at the end of the day because some sort of synching is set to run overnight that resolves the issue.

Site Security

Site security proved to be a bit of a nightmare - needless to say once we figured it out it turned out to be really straight forward.

Each site collection in the farm has been secured using new & existing Active Directory (AD) groups in the domain.

The Intranet portal site collection has one SharePoint security group called Viewers which contains the AD group: DOMAIN\adm dl u portal domain users and which is set to Read, Restricted Read & View Only. This enables all domain users to access and view unsecured content across the site collection.

Each site within the portal site collection either inherits the top level or is set up with individual permissions. In most cases the permissions are individual with AD groups specified as required to grant access & visibility to specific user groups.