SharePoint 2007 sites do not open. SQL Server problem?

Recently, I received a MOSS 2007 VPC image from my network administrator so that I can do my R&D work when not in office. After firing up the VPC image, I was just not able to start even the Central Administration site of SharePoint. It kept shouting "Cannot connect to the configuration database..." or something of that sort (Can't really remember the exact error message).

Since it very clearly said cannot connect to database, I fired up the SQL Server Management Studio (2005). This too would not let me connect to the database. Upon checking the Event Log, it had a couple of SQL Server related errors as follows:

1) Event ID 17182: TDSSNIClient initialization failed with error 0x7e, status code 0x3a.
2) Event ID 17826: Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.
3) Event ID 17120: SQL Server could not spawn FRunCM thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.

I had no idea what this meant. All I knew was there's some configuration problem with SQL Server. So I started the SQL Server Configuration Manager. Under the "Protocols" section of the "SQL Server 2005 Network Configuration" section, there are 4 protocols listed:

• Shared Memory
• Named Pipes
• TCP/IP
• VIA

I noticed that all of these were "Enabled". I smelled something fishy here because I had never seen the VIA protocol "Enabled" ever in previous SQL Server 2005 installations. So, all I did was "Disable" the VIA protocol. I restarted the SQL Server service and then tried accessing the Central Administration of SharePoint and viola, it worked.

Frankly, I have no idea what the VIA protocol is used for and why enabling it would affect SQL Server execution. But, to get SharePoint working, it should be disabled. Maybe there is a way to enable it and still get SharePoint to work. Anyone has any idea on this?

SharePoint 2007: Using AllowUnsafeUpdate to Dynamically Change User Id

For a recent development, the customer had a requirement wherein the user should be able to change his/her user id at any time. For this, the user need not log on to the site (created in WSS 3.0). Just selects an option on the "Login" page, which then takes the user to the page where he/she can provide a new user id.

Of course, the system first validates the user's old id and password, but that's what not this post is about. The interesting bit is how we got this working. Also, just FYI, we would delete the old user id and create a new one (for reasons out of scope of this blog). If we consider this practically, there are only a few ways in which this can be done:

1. User makes a request to change the id. Task is created for the administrator, who then does the needful. Ideal!!!
2. Let the users themselves make the change.

There's no issues in the first approach. In the second one, there are a couple of problems. In the code to make the relevant changes to SharePoint:

1. ...it can automatically log on with the provided credentials and "try" and make the changes.
2. ...or, it could - again, automatically - log on as an administrator and make the changes.

In the first approach - log on as user - the moment the current user id is deleted, the system would either throw an exception or not allow the operation at all because the user is indeed currently logged on. Also, the user may not have sufficient priviliges to perform "delete" operations.

In either case, you have to log on as "someone" so that you can access the SharePoint resources. Or else it would shout (read "throw execptions") at you.

So, the only viable solution here seems to be the code automatically logs on as administrator. This again could be done by having the administrators credentials stored in some config file somewhere (or in some registry entry) and get it to work.

But, the way my co-worker resolved this problem was what I was not happy about. He used neither of the above two methods to change the user id. All he did was use a property called AllowUnsafeUpdate of the SPWeb class. He just set it to true and voila! Everything worked.

He was setting it to false immediately afterwards, but what I kept pondering over was "Is this the right approach?". I couldn't spend much time on it and neither could ask the developer to look for an alternative as the team was anyways short of time (ho-hum). But if anyone can enlighten me on this, I'd really appreciate it.

Alerts not going from SharePoint 2007 site.

Problem: Alerts not going from SharePoint 2007 site.

Description: On my SharePoint 2007 Portal, like any other portal, I had quite a few document libraries. I had also configured alerts to be sent to users whenever a change would happen to the document libraries. Some users had subscribed to the alerts themselves. But for some reason, the alerts were just not being delivered to the users' mailbox. If a user subscribes to receive alerts, he/she would receive the initial email informing about the subscription, but they wouldn't receive subsequent actual alert mails.

Context: Users are authenticated from Active Directory. Their email ids etc. are also picked from AD. All the users have valid email ids (obviously. Duh!). Regular email from Outlook works fine. Sending and receiving of emails from external domains also works fine.

Solution: There are many possibilities why this could happen. I have tried to list down all possible solutions. One of these should work for you.

1. Check the account running SharePoint
a. Make sure the WSS service is running under an account that has rights to the Exchange Server and (of course) the SharePoint database server.
b. Make sure that account has a valid entry in the AD
c. Make sure there is an email id create in the Exchange Server for that account
d. Make sure the account has rights to send emails on the Exchange Server (this should be there when you add the account in Exchange, but just double check)

If, after doing the above steps, alerts are still not working, then follow these steps:

· Check the database tables that are used for subscriptions and alerts. There has been a known issue where some errors have arisen from incorrect information with them so just check them. Checked these tables:

* SchedSubscription

* ImmedSubscription

· Check the Event Log for errors
· Check the “Timer Job Definitions” page within Central Administration. This page lists all the job definitions defined within MOSS2007, such as "Backup and Restore", "Content Deployment" and as you would expect "Alerts". On looking at the list you noticed the following lines:

"Immediate Alerts MOSS_MYSITE"
"Immediate Alerts MOSS_SSP"

This shows that my "Shared Services" and my "My Sites" web applications were working fine for alerts and had a timer job associated with them. What I would have expected to see also was a similar line to below for my "Intranet" web application but this was not there.

"Immediate Alerts MOSS_INTRANET"

(Note: in your case, MOSS_INTRANET would have the name of your web application)

· Now run the following STSADM command to enable alerts:

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

(Note: replace “intranet” with the name of your web application)

· Then run the following to set the alerts to run every 5 minutes:

stsadm.exe -o setproperty -url http://intranet -pn job-immediate-alerts -pv "every 5 minutes"

· Then, wait for a few minutes and bingo, it works. There is a side effect though. You will receive a bunch of alert emails. All of the alerts in the queue get sent in one shot. :)
· Then, re-configure the process to run every 1 minute instead of 5 minutes with the following command:

stsadm.exe -o setproperty -url http://intranet -pn job-immediate-alerts -pv 1

OR

stsadm.exe -o setproperty -pn job-immediate-notification -pv 1

This should do it!