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

Related posts

• No related posts.

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/<site identifier>/SecureBindings ":443:<host header>"

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:\Inetpub\AdminScripts.

IIS 6.0

IIS 7.0

Related posts

• WssRemoveFeatureFromSite + BAT File (0)
• WSS v3 & MOSS 2007 Features (0)
• SharePoint Alerts Not Working (5)
• Error Running The Configuration Wizard (0)
• Unable To Enable Office SharePoint Server Publishing (0)

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.

Related posts

• WssRemoveFeatureFromSite + BAT File (0)
• WSS v3 & MOSS 2007 Features (0)
• Unable To Enable Office SharePoint Server Publishing (0)
• Unable To Activate Office SharePoint Server Publishing Infrastructure (0)
• Stop Windows SharePoint Services Web Application (0)

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 Shared\Web Server Extensions\12\bin

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 <port> [-ssl] [-admapcreatenew] [-admapidname] <application pool name>

   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

Related posts

• Unable To Enable Office SharePoint Server Publishing (0)
• Unable To Activate Office SharePoint Server Publishing Infrastructure (0)
• SharePoint Alerts Not Working (5)
• Faulty Feature Tool (0)
• WssRemoveFeatureFromSite + BAT File (0)

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 12\Bin 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 12\bin 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 name\user 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

Related posts

• WSS v3 & MOSS 2007 Features (0)
• Unable To Enable Office SharePoint Server Publishing (0)
• Faulty Feature Tool (0)
• WssRemoveFeatureFromSite + BAT File (0)
• Unable To Activate Office SharePoint Server Publishing Infrastructure (0)

!!!*** 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!!!

Related posts

• SharePoint Search Services Error (0)
• Error Running The Configuration Wizard (0)
• An update conflict has occurred, and you must re-try this action (0)
• WssRemoveFeatureFromSite + BAT File (0)
• WSS v3 & MOSS 2007 Features (0)