The other day we came across an issue where a user inadvertently inserted a “https” in the URL of a SharePoint site.  The resulting page that was displayed was the Central Administration site.

The only site that is secured with SSL on our SharePoint servers is the Central Admin site.  The Central Admin site also has a host header.  So, I thought that all traffic on port 443 would require the correct host header for Central Admin to respond.

I was wrong.

I was able to find a script on Microsoft TechNet that will enable host headers for SSL sites.  Run the following from the commandline:

cscript.exe adsutil.vbs set /w3svc//SecureBindings ":443:"

Where <host header> is the host header for the Web site and <site identifier> is the site’s unique identifier.

You will find the adsutil.vbs file in several places but you should probably use the one located at C:InetpubAdminScripts.

IIS 6.0

IIS 7.0

From time-to-time we have incremental deployments fail because of issues with checked out pages or other objects.  So, I searched for a way to find all the checked out files and came across Ryan Steeno’s blog.

Here is an overview of the process:

1. Create a new managed property in the Shared Service Provider (SSP)
2. Perform a full crawl on the SharePoint content source
3. Use the new managed property by searching something like: checkoutuser:<author_name>

Go to Ryan’s blog post for details: Find checked out files using MOSS Enterprise Search

We were having trouble adding a user to a site collection.  Every time we hit the search button or clicked the check userid button the system would just sit there and spin. I added the following section of the web.config to resolve the issue.

The error that we were getting in the trace logs is similar to below.

Exception Type: System.Web.HttpRequestValidationException  Exception Message: A potentially dangerous Request.Form value was detected from the client (ctl00$PlaceHolderDialogBodySection$ctl04$OriginalEntities="").

via Solien Technology

I have been wanting to setup a non-www host header for our external websites and found that there are 2 steps to get this working:

1. Setup an Alternate Access Mapping in the default zone that specifies the domain without the “www”.
2. Manually add the host header to the IIS properties of the website.

Lately, we have been getting a lot of errors on our content deployment jobs.  The error that the jobs seem to have in common is “An update conflict has occurred, and you must re-try this action”.

I followed this Microsoft KB Article to resolve the issue: Error message when you try to modify or to delete an alternate access mapping in Windows SharePoint Services 3.0: "An update conflict has occurred, and you must re-try this action" – 939308

There are several steps that you need to take in order to enable anonymous access.  Below are the steps taken from Microsoft TechNet.

Enable anonymous access for a zone of a Web application

1. From Administrative Tools, open the SharePoint Central Administration Web site application.

2. On the Central Administration home page, click Application Management.

3. On the Application Management page, in the Application Security section, click Authentication providers.

4. On the Authentication Providers page, make sure the Web application that is listed in the Web Application box (under Site Actions) is the one that you want to configure. If the listed Web application is not the one that you want to configure, click the drop-down arrow to the right of the Web Application drop-down list box and select Change Web Application.

5. In the Select Web Application dialog box, click the Web application that you want to configure.

6. On the Authentication Providers page, click the zone of the Web application on which you want to enable anonymous access. The zones that are configured for the selected Web application are listed on the Authentication Providers page.

7. On the Edit Authentication page, in the Anonymous Access section, select Enable Anonymous Access, and then click Save.

At this point, the Web application zone has been enabled for anonymous access.

Enable anonymous access for individual sites

Now you need to enable anonymous access for individual sites in the site collection.

Enable anonymous access for individual sites

1. Go to the site on which you want to enable anonymous access and click the Site Actions menu.

2. On the Site Actions menu, click Site Settings.

3. On the Site Settings page, in the Users and Permissions section, click Advanced Permissions.

4. On the Permissions page, on the Settings menu, click Anonymous Access. The settings for anonymous access lists three options:

   • Entire Web site   Select this option if you want to enable anonymous access for the entire Web site.

   • Lists and libraries   Select this option if you want to limit anonymous access to only the lists and libraries on your site.

   • Nothing   Select this option if you want to prevent anonymous access from being used on your site.

5. Click OK.

At this point, your site is configured for anonymous access based on the options that you have selected.

Enable anonymous access for individual lists

If you select Lists and libraries, enable anonymous access for individual lists.

Enable anonymous access for individual lists

1. Go to the home page of your Web site and, in the left navigation pane, click View All Site Content.

2. Click the list on which you want to enable anonymous access.

3. On the Settings menu, click List Settings.

4. On the Customize List page, in the Permissions and Management section, click Permissions for this list.

5. On the Permissions page, on the Actions menu, click Edit Permissions. A dialog box is displayed informing you that you are about to create unique permissions for this list. Click OK.

6. On the Settings menu, click Anonymous Access.

7. Select permissions for users who have anonymous access to the list, and then click OK.

At this point, users have anonymous access to the list you have configured. You can control whether users have anonymous access to other lists, the home page, or other pages on this site.

The Sharepoint Knowledge Base blog has a great post about setting the user’s Time Zone and other locale info.

Change the Central Administration Web site port number

Use this procedure to change the port number of the Central Administration Web site.

Change the Central Administration Web site port number by using the Stsadm command-line tool

1. On the drive where SharePoint Products and Technologies is installed, open a command-line window and type the following command:

   cd %CommonProgramFiles%Microsoft SharedWeb Server Extensions12bin

2. To determine the current port number for the Central Administration Web site, at the command prompt, type the following command, and then press ENTER:

   stsadm -o getadminport

   For more information, see Getadminport.

3. To change the port number for the Central Administration Web site, use the following command, including any options that apply to your environment:

   stsadm -o setadminport -port  [-ssl] [-admapcreatenew] [-admapidname] 

   For more information, see Setadminport.

Note: You can only change the port number for the Central Administration Web site by using the Stsadm command-line tool.

via Microsoft Technet

While working to email-enable SharePoint lists I ran across a great post on Microsoft Support about testing SMTP:

SMTP relay behavior in Windows 2000, Windows XP, and Exchange Server

The basic test:

Start a command prompt.

Type telnet ServerName 25, where ServerName is the SMTP server name or IP address and 25 is the port number, and then press ENTER.

Type EHLO, and then press [ENTER].

At the Telnet session prompt, type RSET. The telnet session responds with text that is similar to the following:

1. 250 2.0.0 Resetting

2. Type MAIL FROM:UserName@DomainName.tld, where UserName is the name of the user, DomainName is the name of the domain, and tld is the top level domain such as .com or .net.
   The telnet session responds with text that is similar to the following:

3. 250 2.1.0 UserName@DomainName.tld….Sender OK

4. Type RCPT TO:RecipientName@DomainName.tld, where RecipientName is the e-mail address of the recipient.
   The telnet session responds with text that is similar to the following:

5. 550 5.7.1 Unable to relay for RecipientName@ DomainName.tld

A great resources for

• DevExpertise – SharePoint List Template IDs and Site Template IDs.
• Tech Training Notes – SharePoint: RegistrationId List Template Type IDs