I went through the process of enabling SSL on our SharePoint 2010 website.  However, whenever I tried to use it I would be presented with a login screen.  I was using the farm admin UserID so I knew it had authority.

I was able to find the following Microsoft document: You receive error 401.1 when you browse a Web site that uses Integrated Authentication and is hosted on IIS 5.1 or a later version
I already had the DisableLoopbackCheck registry entry, so I tried Method 1 and it worked great:

Method 1: Specify host names (Preferred method if NTLM authentication is desired)

To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

1. Set the DisableStrictNameCheckingregistry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
   281308  Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
2. Click Start, click Run, type regedit, and then click OK.
3. In Registry Editor, locate and then click the following registry key:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
4. Right-click MSV1_0, point to New, and then click Multi-String Value.
5. Type BackConnectionHostNames, and then press ENTER.
6. Right-click BackConnectionHostNames, and then click Modify.
7. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
8. Quit Registry Editor, and then restart the IISAdmin service.

Use the following SQL to find the sites that have missing assemblies that are found in the Review Problems and Solutions Central Admin page:

SELECT w.FullURL, w.Author, w.Title,w.[Description]
  FROM [dbo].[EventReceivers] with (nolock)
  inner join dbo.Webs w with (nolock) on WebId = w.Id
  where [Assembly] like '%<MISSING ASSEMBLY NAME>%'

I had to install the Oracle 11g client on our new Sharepoint 2010 server.  Iran through the install and then when I tried to bring up Central Admin, I got the error below explaining that the connection string for “OraAspNetConString” was empty.

To fix this issue, I commented out all references to“OraAspNetConString” in the machine.config file.

Extended web applications are not listed in the web application list and cannot be deleted using the Delete Web Application link in Central Administration.

Use the following steps to delete extended web applications:

1. Start Central Administration
2. Go to Application Management
3. Click Remove SharePoint from IIS Web Site to get a page with a form similar to the following.
   
4. Select the web application that the extended web app was extended from
5. Select which extention/zone to delete
6. Select whether to keep or delete the IIS Web site
7. Finally click OK

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

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.

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

One of our developers reported to me that the SharePoint Alerts were not sending emails.  The initial notification that the alert was setup was sent but not the alerts themselves.

I was able to find a great article by a MS MVP named Susan Bradley called How to Troubleshoot Alerts in WSS 3.0 / MOSS.

In going through all the steps, I was able to determine that my issue was caused by the permissions setup on the list.

Thanks, Susan!

Below is the contents of the article:

Question:  How to Troubleshoot Alerts in WSS 3.0 / MOSS
Answer:

The most common issue in alert is the user will get the initial email, but will not get when changes are made to the list where he configured the alert.  Check the following settings in order and ensure that it is correct.

1. Is it an upgrade from V2 to V3?  If yes, check the upgrade section at the bottom of this page.

2. If this is a new install of V3 (WSS or MOSS), then do the following

a. Create a new web app and see if the alerts work there.  If yes, you can move the content db of the non-working site to this one. If customer is not ready to do that, then try the following.

b. Open the command prompt and go to the 12Bin folder. Run this command and see whether alerts are enabled for the web application.  

Stsadm.exe-o getproperty -url http://problemsite  -pn alerts-enabled

The expected output is <Property Exist="Yes" Value="yes" />.  If you don’t get this, run the following command to change the value.

stsadm.exe -o setproperty -pn alerts-enabled -pv "true" -url http://problemsite

If the property is Yes and still the alerts are not sent, toggle the property from Yes to NO

and then from No to Yes.  This may delete all the existing alerts and warn the customer

about this.

c. Check the property job-immediate-alerts schedule through command prompt.  Run this command from the 12bin folder.  If we have issues with Scheduled alerts like daily or weekly, then check the property job-daily-alerts and job-weekly-alerts.

stsadm.exe -o getproperty -url http://ProblemSite  -pn job-immediate-alerts

The expected output is

<Property Exist="Yes" Value="every 5 minutes between 0 and 59"/>.  If you don’t get this, run the following command to change the value.

stsadm.exe -o setproperty -pn job-immediate-alerts -pv "every 5 minutes

between 0 and 59" -url http://ProblemSite

d. Confirm the above step through the UI. Central adminàOperationsàTimer Job Definitions and ensure that a job named Immediate Alerts is present for the web application.

e. Configure the alert for a user in a list.  Instead of typing the domain name user name, type the email address of the user and see if he gets initial email.  Then make a change to the list and see whether he gets the mail related to the change.

f. If he gets the alert as expected, then create a new alert and this time select the user from the people picker or type the domain nameuser name. 

g. If the alert is not working after doing the above step, then check the ImmedSubscriptions / SchedSubscriptions table of the content db of the web application depending on the type of alert and see a new record is added and ensure that the email field for the user is populated correctly.  If not, check whether the email address is present in the user’s profile through the SSP admin page.

h. The initial alert is not security trimmed. So irrespective of whether the user has privileges on the list or not, the initial alert will be sent.  If the user is not getting alert for any changes, then check whether the user has Read permission on the list.

i. This also happen if there is some issue in their mail provider (third party email providers.  In this case, capture the ULS log with all information events in the verbose mode and check for lines which says Alert has been sent.

j. Email enabled security groups can also be used for configuring alerts.  If the changes are not notified to the members of the group, check whether the group is added to the list with minimum Read permission.  Also some email providers block email groups if the number of members are more than certain number.

k. Open SQL Query Analyzer; connect to the content database of problematic site. Run the following query.

Select * from timerlock

This server is responsible for processing the timer service.  You can follow this KB –

http://support.microsoft.com/kb/934838 to sync the accounts and password across the

Farm

The internal working mechanism of how an alert should work in v3:

The EventCache table records the SQL level events as they occur and the EventData and ACL columns are not NULL for an alert event.  There is an alerts timer job that runs periodically to process the records in the EventCache. After the alerts timer job runs, it nulls out the EventData and ACL columns. Then, it will log an event into the EventLog table.  So check the following in SQL.

select * from eventcache where EventData is not null

This will output all of the subscriptions which have not been processed yet. We can see if there are some alerts which are not processed.

select * from eventlog where ListID = ‘xxx’

You can get the ListID from the EventCache table by running

Select * from EventCache and check the documents which correspond to the problematic list.

If you cannot find any record, perform the following tests:

Run filemon on the MOSS server which is responsible for the timer service and check if the Timer

service picks up the alert template during the whole process.

             Upload a new document to the document library which is supposed to have the alerts. Begin running 

             the filemon and analyze the logs.

p. select * from eventcache order by EventTime DESC

Check if the latest log is the one corresponds to your uploaded document. Make sure the EventData and ACL columns are not NULL.

After 5 minutes or more minutes, check the EventCache table again to see if the EventData and ACL columns are NULLed.

If so, stop filemon after the EventData and ACL columns are NULLed . Review log.

Upgrade from V2 to V3

1. Check this KB – http://support.microsoft.com/kb/936759/en-us

2. If no alerts are getting triggered even for a new web app, then run the Psconfig Wizard without changing any options. 

The timer job displayed an older date because the upgrade job was hung

3. If the alert works on new web apps, then you can move the site collections from the upgraded web app to the newly created web app through stsadm –o backup / restore or stsadm –o export / import.  This action will be useful only if you have fewer site collections and this is only a workaround.

Case Study

ERROR MESSAGE:
================
Running the psconfig wizard fails immediately with "Unable to upgrade SharePoint
Products and technologies because an upgrade is already in progress"
No psconfig process in task manager

CAUSE:
=======
The timer job displayed an older date because the upgrade job was hung
RESOLUTION:
============
Sharepoint central administration page->Operations->Timer job definitions
Asked client to delete the "Upgrade job"
Now the psconfig wizard ran fine
Timer job definition showed all the jobs with the latest date. Especially the
Immediate alerts job

!!!*** NEVER, NEVER, NEVER, NEVER EVER STOP WINDOWS SHAREPOINT SERVICES WEB APPLICATION ***!!!

The Windows SharePoint Services Web Application is what identifies your server as a SharePoint Web Front-End.  If you stop this “service” it will remove all SharePoint websites and the directories from which they are served. 

So, unless you know exactly what you are doing, DO NOT STOP THE WINDOWS SHAREPOINT SERVICES WEB APPLICATION!!!