Enabling anonymous access on MOSS 2007 / WSS 3.0 web applications

To enable anonymous access for a web application within SharePoint:

1. Go to Central Administration >> Application Management >> Authentication Providers.

  • make sure to pick correct web application from the drop-down list at the top-right corner of the page.
  • select the Membership Provider (most likely it will be "Default") and enable check "Enable anonymous access" checkbox.
  • click OK to save the settings.

2. The step above will usually enable anonymous access in IIS Manager, but just be sure:

  • open IIS Manager
  • right-click on your website and click on "Edit" under Authentication and Access Control
  • make sure "Enable anonymous access" is checked

3. We now need to explicitly enable anonymous access on our website(s)

  • browse to the website
  • click Site Actions >> Site Settings >> People and Groups >> Site Permissions
  • click on Settings >Anonymous Access and enable anonymous access for the site

* Anonymous access will be also enabled on all subsites that inherit security settings from the parent site.



Related resources:

Installing SQL Server 2005 on Windows Vista or Windows 2008: IIS 7.0 problem

Recently I tried to install SQL Server 2005 on Windows Vista and I have received a warning message for IIS Feature requirement on the System Configuration Check page of the SQL Server 2005 Setup program. This means that you won’t be able to install SQL Server components, requiring IIS, such as Reporting Services. The problems occurs because IIS 7.0 is much more customizable and has much more components, so some of the components required for RS installation are missing from the default IIS 7.0 install. Here is the list of the IIS components required for Reporting Services:

Component

Folder

Static Content

Common HTTP Features

Default Document

Common HTTP Features

HTTP Redirection

Common HTTP Features

Directory Browsing

Common HTTP Features

ASP.Net

Application Development

ISAPI Extension

Application Development

ISAPI Filters

Application Development

Windows Authentication

Security

IIS Metabase

Management Tools

IIS 6 WMI

Management Tools

 

For instructions on how to install missing IIS components in Windows Vista, go to: http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=957 (http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=957).

For instructions on how to install missing IIS components in a Server Core installation of Windows Server 2008, go to: http://www.iis.net/default.aspx?tabid=2&subtabid=25&i=956

The solution is also explained in Microsoft KB920201.

 

Fixing TFS reports after an upgrade/migration to TFS 2008

Microsoft has made quite a few changes to reports in TFS 2008. As you can see form the table below in TFS 2008 we do not only have 6 new reports, but some of the existing reports have been modified/removed (new reports are in red, removed reports are in orange).

TFS 2005 default reports

TFS 2008 default reports

Actual Quality vs Planned Velocity
Bug Rates
Bugs by Priority
Bugs Found Without Corresponding Tests
Builds
Load Test Summary
Project Velocity
Quality Indicators
Reactivations
Regressions
Related Work Items
Remaining Work
Scenario Details
Tests Failing Without Active Bugs
Tests Passing With Active Bugs
Unplanned Work

 

Actual Quality vs Planned Velocity
Bug Rates
Bugs by Priority
Bugs Found Without Corresponding Tests
Builds
Exit Criteria
Issues List
Load Test Detail
Load Test Summary
Project Velocity
Quality Indicators
Reactivations
Regressions
Related Work Items
Remaining Work
Scenario Details
Tests Failing Without Active Bugs
Tests Passing With Active Bugs
Unplanned Work
Work Item with Tasks
Work Item with TestResults
Work Items

This means that when you upgrade/migrate to Team Foundation Server 2008, your reports will no longer work as the schema has changed. To resolve the issue you need to download the new process template (http://msdn2.microsoft.com/en-us/teamsystem/aa718795.aspx) and add or update your reports on TFS server.

To add new report:

  1. Go to your Reports server (http:// [SERVERNAME] /reports)
  2. Click on Upload file
  3. Browse to the report file (.rdl) you want to upload and click OK to upload
  4. Click on newly uploaded report file and click on Properties
  5. Set up data sources by clicking on Data Sources (Don't forget to click Apply button)
  6. Depending on report, you might also have to set up default parameters by clicking on Parameters (Don't forget to click Apply button)
  7. Click on View to make sure that report is displaying properly

 

To update existing report:

  1. Go to your Reports server (http:// [SERVERNAME] /reports)
  2. Click on report that you want to update and click on Properties
  3. Click on Update
  4. Browse to the report file (.rdl) you want to upload and click OK to upload
  5. Make sure that data sources are configured properly by clicking on Data Sources (Don't forget to click Apply button)
  6. Depending on report, you might also have to set up default parameters by clicking on Parameters (Don't forget to click Apply button)
  7. Click on View to make sure that report is displaying properly

Note: You will have to update reports for each TFS project

Missing Timer job definitions after SharePoint move

If you have recently moved your SharePoint site (WSS 3.0 or MOSS 2007) from one hardware to another using backup/restore procedure, you might have noticed a few missing timer jobs definitions: Scheduled Approval, Scheduled Page Review, Scheduled Unpublish, Variations Propagate Page Job Definition, and Variations Propagate Site Job Definition. In our case, we had multilingual SharePoint site that stopped propagating variations after SharePoint move, so the content created in one language was not re-created in another. Very frustrating…

After looking into the problem, I discovered that SharePoint does not restore those timer job definitions by default. Naturally, not having those jobs will cause problems with scheduled publishing as well as variations propagation. To get those timer job definitions back on the list and running again, you will have cheat a little by creating a new site collection using Publishing Portal or Collaboration Portal templates. Creating new site collection using Publishing Portal or Collaboration Portal templates will force SharePoint to create missing timer job definitions. New site collection can be removed shortly after created.

Note: Changes made in variations since the SharePoint move might take while to propagate. To expedite the propagation you can manually force the variations update.

SharePoint search and anonymous users

If you have a public Sharepoint site (MOSS 2007 or WSS 3.0) that is accessible to anonymous users and you’re not using custom scopes, you probably already noticed that every time users try to search they get a user prompt. To get pass this prompt you must enter valid username, otherwise you’ll get famous “Access Denied” page. So much for anonymous access, right?

Anyway, the problem is with OSSSearchResults.aspx page, specifically with one of the inheritance reference that ASPX page. I’m talking about the part of the code that sets the inheritance of the page from the generic application page base class, which is not really required for this page to function properly.  

To allow anonymous users to search your publicly available sites you need to remove that inheritance from the code, so find part of the code inside the <Page>  tag that states “Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase"  and remove that part of the code (not the whole line, just the part that inhertis the application page base.) OSSSearchResults.aspx page is usually stored at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS on your SharePoint server. Make sure you backup the file before making any changes!

Making those changes will not only allow anonymous users to search the SharePoint content, but also will keep the SharePoint search secure, meaning that anonymous users will only be able to search the part of the SharePoint they have permissions to view.



Related resources:

Installing Service Pack 1 on your WSS3/MOSS2007 server(s)

First of all, you must backup SharePoint. Upgrading to SP1 should not break your WSS3/MOSS2007 install, but it's always better to be safe than sorry.

In my case we have 32-bit installation of SharePoint server, so these guidelines will refer to 32-bit version of SP1 for WSS3/MOSS2007, but as far as I know the guidelines can also be used for installation of SP1 on 64-bit instances of SharePoint server (just make sure you download 64-bit version of Service Pack file). You can download Service Pack 1 from Microsoft website (For MOSS installations, Service Pack 1 for both WSS3 and MOSS2007 must be installed):

  1. Windows SharePoint Services 3.0 Service Pack 1 (27.3Mb)
  2. Microsoft Office SharePoint Server 2007 Service Pack 1 (78.9Mb)

Now that you've backed up your SharePoint install and downloaded the updates, you're ready to install the service pack. First, let's install Service Pack 1 for WSS3:

  1. Stop the World Wide Web Publishing Services
    1. Go to Start >> Administrative Tools >> Services
    2. Select World Wide Web Publishing Service and click Stop
  2. Install the Windows SharePoint Services Service Pack 1
    1. Run the downloaded executable file WSS3 SP1 (wssv3sp1-kb936988-x86-fullfile-en-us.exe)
    2. Accept the licensing terms. Technically you should read the EULA terms before accepting, but nobody I know actually does it, so...
    3. Click Continue and click OK when prompted to remind the administrator to update all SharePoint servers.
    4. Click OK when the installation completes.
  3. If you have MOSS2007 installed then skip SharePoint Configuration Wizard (i.e. close it, if prompted) and proceed to installing SP1 for MOSS 2007. If, however, you only have WSS3 installed, then run SharePoint Configuration Wizard, start World Wide Web Publishing Service and that's it.

Second, if you have MOSS2007, we need to install SP1 for MOSS2007:

  1. Install the Microsoft Office SharePoint Server Service Pack 1
    1. Run the downloaded executable file (officeserver2007sp1-kb936984-x86-fullfile-en-us.exe)
    2. Accept the licensing terms. Technically you should read the EULA terms before accepting, but nobody I know actually does it, so...
    3. Click Continue and click OK when prompted to remind administrator that you update all SharePoint servers.
    4. Click OK when the installation completes.
  2. Run SharePoint Configuration Wizard
    1. If SharePoint Configuration Wizard won't run automatically after SP1 install go to Start >> All Programs >> Microsoft Office Server >> SharePoint Product and Technologies Configuration Wizard
    2. Click Next at the Welcome screen and click Yes when prompted with the warning about restarting services
    3. Click Next at the Completing the SharePoint Product and Technologies Configuration Wizard and click OK when prompted to remind the administrator to update all SharePoint servers
    4. Go get a cup of coffee because the wizard might take a while to complete
    5. Click Finish after the configuration completed
  3. Start World Wide Web Publishing Service to make your SharePoint server accessible by users again
    1. Go to Start >> Administrative Tools >> Services
    2. Select World Wide Web Publishing Service and click Start

If you want to make sure that you have successfully updated your WSS3 or MOSS2007 to Service Pack 1 you can do that through SharePoint Central Administration or Add/Remove Programs. To verify the SharePoint version through SharePoint Central Administration:

  1. Open SharePoint Central Administration, go to Operations tab
  2. Under Topologies and Services section click Servers in farm to list your SharePoint server(s)
  3. If you see "Version: 12.0.0.6219" next to your SharePoint server, then you have successfully upgraded that server to Service Pack 1.

Alternatively, you can verify the SharePoint version through Add/Remove Programs in Control Panel:

  1. Go to Start >> Control Panel >> Add/Remove Programs
  2. Select Microsoft Office SharePoint Server and click on "Click here for support information"
  3. If you see "Version: 12.0.0.6219", then you have successfully upgraded that server to Service Pack 1.

Please note that if you have multiple SharePoint Servers (WSS3 and/or MOSS2007) you need to update all of them to Service Pack 1!!!



Related resources:

Fixing MSSQL Reporting Services add-in after the migration of SharePoint site to a new server (WSS 3.0 or MOSS 2007)

 

If you're thinking about migrating WSS 3.0 or MOSS 2007 sites to a new server, you need to remember to reinstall any third-party webparts you have installed on the old Sharepoint server. So if your Sharepoint instance have Reporting Services webpart installed you will have to re-install it, but before you do that make sure you remove old webpart from the Web Part Gallery and remove (or comment out) any references to the old RS webpart from web.config file in the Sharepoint's virtual directory.

 

<SafeControl Assembly="Microsoft.ReportingServices.SharePoint.UI.ServerPages, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" Namespace="Microsoft.ReportingServices.SharePoint.UI" TypeName="*" Safe="True" />
<SafeControl Assembly="Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" Namespace="Microsoft.ReportingServices.SharePoint.UI.WebParts" TypeName="*" Safe="True" />
<SafeControl Assembly="RSWebParts, Version=8.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" Namespace="Microsoft.ReportingServices.SharePoint.UI.WebParts" TypeName="*" Safe="True" />

 

<add verb="*" path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<add verb="*" path="_vti_bin/ReportServer" type="Microsoft.ReportingServices.SharePoint.Soap.RSProxyHttpHandler, RSSharePointSoapProxy, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />
<add verb="*" path="Reserved.ReportViewerWebPart.axd" type="Microsoft.ReportingServices.SharePoint.UI.WebParts.WebPartHttpHandler, Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />

 

<location path="_vti_bin/ReportServer/ReportServiceAuthentication.asmx">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>

 

Note: If you don't remove the references to the old RS webparts, you won't be able to get reports to display properly no matter how many times you re-install the webpart.

 

TFS and Sharepoint

To install TFS you must have Sharepoint Services 2.0 installed on the same server. Even though there hacks that allow you to integrate TFS with Sharepoint 3.0 that could be installed on another server, there still certain restrictions in place. One of them is Sharepoint naming conventions for when you install TFS:

Application Pool Name: TFSWSS (use TFSSERVICE account)

Application Pool Name: TFSWSSADMIN (use TFSSERVICE account)

Configuration Database Name: STS_Config_TFS

Content Database Name: STS_Content_TFS

Username to use: TFSSERVICE account

 

You can change those names later on though. Hopefully this issue will be addressed in Orcas…

Uploading large files to TFS

We used to get a timeout error every time we tried to upload files larger than 48Kb to TFS. The timeout error was caused by one of numerous IIS hidden settings, i.e. UploadReadAheadSize parameter in IIS. Because this parameter is not set by default, IIS uses the default schema value of 48Kb. 

To allow larger files to be uploaded to TFS, we had to change this parameter to a larger value (in our case I've set it to 10Mb). Here is how it's done:

  1. Open Command Prompt
  2. Go to your Inetpub\adminscripts folder
  3. Type in adsutil get w3svc/UploadReadAheadSize to check your current setting
  4. To change this parameter, type in adsutil set w3svc/UploadReadAheadSize SIZE_IN_BYTES. For example to set this parameter to 10Mb use "10000000" as the size
  5. Type in adsutil get w3svc/UploadReadAheadSize again to make sure that the parameter has been changed

   

TFS authentication and time synchronization

Since, it's my first post I thought that I should start with something simple yet very frustrating. For about a week we had a problem with our TFS server. Occasionally users were not able to login to TFS server using Team Explorer for no apparent reason. After numerous attempts to find the cause of all this problems, the solution turned out to be pretty simple. There was a time synchronization problem between TFS server and Time Server on the network (which in our case was one of domain controllers).

To resolve I have set up TFS server to sync time with the domain controller and set a domain controller to sync time with one of the public time servers on the Internet. To me, it's always better to have all your servers to synchronize their time settings with one of the internal server and only that internal server would synchronize with external time servers, instead of all servers synchronizing with external servers. Here is how it can be done:

ON TFS SERVER:

  1. Make sure that you have Windows Time service running and set to Automatic start-up on TFS Server
  2. To check whether your time service is set, type NET TIME in Command Prompt:
    net time /domain:DOMAINNAME
  3. If no time servers have been set, use NET TIME command to set up the time server:
    net time /setsntp:DOMAINCONTROLLER

ON DOMAIN CONTROLLER:

  1. Make sure that you have Windows Time service running and set to Automatic start-up on Domain Controller
  2. To check whether your time service is set, type NET TIME in Command Prompt:
    net time /domain:DOMAINNAME
  3. If no time servers have been set, use NET TIME command to set up the time server for Domain Controller:
    net time /setsntp:PUBLICTIMESERVER
    For the list of the Simple Network Time Protocol (SNTP) time servers that are available on the Internet go to http://support.microsoft.com/default.aspx/kb/262680

After I have set up the time synchronization, our TFS server has been running smoothly ever since (knocking-on-the-wood)...