Unable to activate Office SharePoint Server Publishing Infrastructure from site collection features

Issue: Unable to activate "Office SharePoint Server Publishing Infrastructure" from site collection features.

We had "Office SharePoint Server Publishing Infrastructure" activated since beginning but for some reasons it was deactivated and when I tried to activate it, I received "Access denied" error.

Note: We have followed Microsoft Guidelines for setting up administrative and service accounts.

Solution:

1. Open IIS Admin.
2. Locate the Web Site for your MOSS web application.
3. Go to the properties and select "Home Directory" tab.
4. Make a note of Application Pool used for this web site.
5. Expand Application Pools in IIS.
6. Go to the properties of Application Pool, which you have noted in step 4 and select "Identity" tab.
7. Make a note of the account used under "Configurable".
8. Change the Application Pool identity to SharePoint Service Account - This is the same account, which you have used for installation of MOSS 2007.
9. IISRESET
10. Activate "Office SharePoint Server Publishing Infrastructure" from site collection features.
11. Change the Applciation Pool identity back to the original (same account which you have noted in step 7).
12. IISRESET.

Permission issues in SharePoint 2007

Issue: Unable to access Spell Checker in Rich Text Editor of Content Editor web part.

Your sub site has custom permissions (NOT inherited from parent site) and you have "Full Control" access to your sub site but you are unable to use Spell Checker in Rich Text Editor of Content Editor web part.

Solution: Create a custom permission level and name it "Reader Plus" (or any other appropriate name) by copying "Reader" permissions and adding "Browse Directories" permission at top level site. Allow "Reader Plus" access to the account at top level site, which has this issue.

Issue: Unable to access "Information management policy settings" from Document Library settings or List settings.

You have "Read" permissions at top level site and "Full Control" permissions to your sub site but you are unable to access "Information management policy settings" from Document Library settings or List settings.

Solution: Same As Above

Note: These permission issues seem to be addressed in Service Pack 1 for SharePoint 2007 however I haven't got a chance to install Service Pack 1 in our SharePoint environment yet.

Crawl doesn't work and Query server is not responding; Search works only for old (crawled) contents

We had this search issue in January' 2008 and here is the description,

We have following three servers with MOSS 2007 STD deployed in SharePoint server farm,

App01- Query Server
App02 - Index Server (We are using this server as dedicated web front end computer for crawling)
SPDBServer - SQL 2005

Search was working fine till 01/05/2008 and it stopped working after this date only for new contents meaning search is still working fine for the old contents which were added before 01/05/2008 but not for new contents added after 01/05/2008.

We have been working to find out reasons why did that happen? We have found following event ids on Query server,

Event ID:10042 - A new query machine, 'App01', has been added to the query rotation based on changes to farm topology.

Event ID:27745 - The following information is part of the event: #50071: Unable to connect to the database SharePoint_Config on SPDBServer. Check the database connection information and make sure that the database server is running..

Event ID: 7888 - A runtime exception was detected. Details follow.
Message: A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - Not enough memory is available to complete this request)

We had some database backup client issue on database server but after fixing that issue and rebooting all the three SharePoint servers, we noticed that crawl was not responding. Last incremental crawl, started on 01/05/2008 did not stop even on Monday (01/07/2008).

We have incremental crawl scheduled at every 6 hrs. everyday and full crawl scheduled on every saturday.

After coming back to work on Monday 01/07/2008, we tried search and noticed that it was working only for existing contents(added before 01/05/2008) and not for all the new contents, which were added after 01/05/2008.

When we check Search settings, it says "Query server not responding" and we are unable to stop/pause the incremental crawl, which was started on 01/05/2008. Only way to stop that crawl is to stop Office SharePoint Server Search service from services.msc on both App01 and App02 server.When we stop the crawl this way and start it again, it goes on and on and never stops. We have tried to start both full and incremental crawl this way but that didn't help.

Only resolution to this issue, I have found is to readd App01 - Query server to the farm from SharePoint Central Administration however I am still wondering, if that will fix our "Query Server not responding" error. As per our research, it seems few other people also have noticed this issue for some unknown reasons and if SharePoint doesn't have any operational errors, we can safely ignore them. Microsoft is aware of this isse and they are expecting to get this resolved in SharePoint 2007 Service Pack 1.

I was also thinking of resetting all crawled contents and rebuilding the content index. I was affraid, if resetting the crawled contents will not regenerate/rebuild the new content index. If crawl will not work after resetting the crawled contents then SharePoint search will be completely down and it will stop working even for old contents.

Has anybody tried this KB?
http://support.microsoft.com/kb/925609

Can we move content index(search catalogs) from shared location to some other location on Query server and then try resetting crawled contents? Can we move content index back to its original location if resetting crawled contents will not generate a new content index or it will not propagate it to Query server?

If above KB article gives us the flexibility of reusing content index in case of resetting crawled contents fails to build a new content index or propagating it to Query server, we would like to try it first before we can try readding Query server to the SharePoint server farm (Stop and then restart Office SharePoint Server Search service for Query server from SharePoint Central Admin)

Does anybody know an appropriate solution to fix this issue? Search works only for old (Crawled) contents and not for new contents, Crawl never stops (hangs) and there is "Query server not reponding" message on search settings so basically it is not propagating the content index.

Solution:

Here is how we fixed this issue in our environment. This issue might be specific to our environment and this resolution may not work for similar issue in the other environment.

- We noticed few memory leaks in SQL Server 2005. We(our Windows Server team with SQL Administrator) fixed those issues first however fixing memory leaks in SQL didn't help us to fix search issues in SharePoint and we still had "Query Server not responding" error in SharePoint and Search was not working.

- We created a new location for content index propagation on Frontend Server, which is also a Query Server.
Note: Do not move existing crawled contents from old propagation location to a new location manually. In fact, SharePoint does it automatically once you create a new location for content index propagation with the following command. It is strongly recommended that you start a "Full Crawl" after this to rebuild content index for updated contents.

- Ran following command to propagate search index to the new location,

stsadm.exe –o osearch –propagationlocation index file path

Please allow some time to move existing content index from previous location to a new location. You may see few known events in event viewer while SharePoint is moving content index to a new location however you can safely ingnore them. Please check status on Search Administration (SSP => Search Settings) page and for Query Server response. You can start a Full Crawl after few minutes once you see Query Server starts responding in Search Settings.
This has fixed our SharePoint search issue and it works fine now.

- Hope this will help others to resolve similar issue. Please make sure you do not have any SQL Server issues before you troubleshoot it in SharePoint.

References:
http://support.microsoft.com/?kbid=925609http://blogs.msdn.com/pdesai/archive/2007/09/27/moss-2007-search-scope-error-query-index-server-event-log-error-how-to-fix-it.aspx

Technet Post on this issue:
http://forums.microsoft.com/technet/ShowPost.aspx?postid=2706585&siteid=17

Incoming e-mail feature in SharePoint 2007

I am pretty excited about enabling incoming e-mail feature in our SharePoint production environment in this week ends finally. We have really tested it thoroughly in our SharePoint stage environment before enabling it in production envionment. In fact, we follow this process all the time to be on safe side :-)

Alright, so we will talk about incoming e-mail feature and e-mail enabled lists and libraries in SharePoint 2007 today.

Before I start, let me tell you that we do NOT have MS Exchange server setup in our organization for e-mail routing but we have unix based mail routing system called - Majordomo. So it may differ from configuring incoming e-mail feature in MOSS 2007 with Microsoft recommended mail routing system- MS Exchange.

As you all know we can enable incoming e-mail in MOSS 2007 by going to Central Administration > Operations > Incoming E-Mail Settings. Here is how we have configured it,

1. Enable sites on this server to receive e-mail? Yes

2. Settings mode: Automatic

3. Use the SharePoint Directory Management Service to create distribution groups and contacts? Yes

Note: This setting is required ONLY if you want contacts to be created in your organization's user directory allowing people to find e-mail enabled SharePoint lists in their address book. This service also provides support for the creation and management of e-mail distribution groups from SharePoint sites. If you don't want contacts to be created in your organization's user directory you can choose "No". Incoming e-mail feature will work regardless of what you select for this option.

If you have selected "Yes", you need to provide additional information. If you are not sure of this information, please contact the person who manages Active Directory and domain services for your organization. For example, we have

4. Active Directory container where new distribution groups and contacts will be created: OU=SPOU, OU=Organization, OU=ControlledObjects, DC=hq, DC=MyDomainName, DC=com

Note: I have changed few settings to keep the privacy.

5. SMTP mail server for incoming mail: MOSSServer1.hq.MyDomainName.com

6. Accept messages from authenticated users only? Yes (We have enabled incoming e-mail feature for intranet use only however we don't want any spam e-mails in our system when we enable it for external accounts so it is always safe to select "Yes" option here.

7. Allow creation of distribution groups from SharePoint sites? Yes

8. Distribution group request approval settings: Create new distribution group and Delete distribution group are selected.

9. E-mail server display address: sharepoint.hq.MyDomainName.com

Note: This option is little tricky to provide a custom address here. Please note that the SMTP server name for incoming mail is "MOSSServer1" however we want contacts for e-mail enabled lists and libraries with suffix "@sharepoint.hq.MyDomainName.com". We can do this by adding another domain alias in IIS for SMTP Virtual Server. Here are the steps to add the domain alias for SMTP Virtual Server,

(i) Open IIS, where you have SMTP Virtual Server installed.
(ii) Expand Default SMTP Virtual Server.
(iii) Right click on Domains and select New => Domain.
(iv) Select Alias.
(v) Provide Name (Another Alias of this SMTP Virtual Server e.g. we have used sharepoint.hq.MyDomainName.com and click Finish button.

Note: MS Exchange or your mail distribution system (Majordomo in our case) must be configured to route all emails that suffix with @sharepoint.hq.MyDomainName.com to C:\Inetpub\mailroot\Drop folder of SMTP Virtual Server installed on MOSSServer1.

10. Safe E-Mail Servers: Accept mail from all e-mail servers is selected.

That's it, incoming e-mail feature for MOSS 2007 is configured...Congratulations!

Now, Let's talk about testing this feature...(Please keep in mind that we have Unix based Majordomo mail distribution system in our organization) Most of the time it worked fine for receiving e-mails in SharePoint however we stopped receiving e-mails after 2-3 days of testing. We were unable to telnet into server on port 25. SharePoint server(with Virutal SMTP Server installed) was not listening on port 25. We checked “Connection” property under “Access” tab of SMTP Virtual Server properties and noticed that SMTP server is accepting connection only from 196.X.X.123 server however we configured to receive e-mails from any e-mail server. So We removed that IP Address (196.X.X.123) from the “Computers” tab and set connection settings to “All except the list below” by keeping “Computers” tab empty. After this change, we started receiving e-mails in SharePoint as normal but question was how this change was occurred and who made changes to “Connection” settings? and here is the answer :-)

While testing incoming e-mail feature in SharePoint, we set “Accept mails from these safe e-mail servers” with the above IP Address (196.X.X.123) and that changed “Connection” settings of SMTP Virtual Server in IIS. This was the root cause of this issue. So be very careful when you make any configuration changes to your incoming e-mail settings.

As I mentioned before I am pretty excited about announcing this feature in our SharePoint production enviornment however here are the few things what I am concerned about,

How can we manage undelivered emails?

1. What happens to emails, which are sent to wrong email addresses? SharePoint logs refer that as Unknown Alias. How does SMTP server handles it? Is there anyway we(or SharePoint Admin email account) can get notified for undelivered email messages? We tried to set email account in SMTP server properties for Undelivered emails but that didn't help. We would like sender to receive bounce back email when email is sent to wrong email address or at least SharePoint administrator account get notified when email is not delivered to SharePoint.

2. We have Distribution List set for different groups. Let's say for example, dl-spadmins has all email accounts of SharePoint administrators. If we add email address for SharePoint document library in this DL and then send email to dl-spadmins, all members of that DL receive email but SharePoint document library does NOT receive this email. Is there anyway to troubleshoot this issue?

Why we want to add email address for SharePoint document library to Distribution List (DL)? Because we can not find those contacts in SharePoint even though we have configured Directory Management Service for incoming email feature in SharePoint and that is because we have Majordomo mail distribution system instead of MS Exchange (I believe this is the reason, we can not find those contacts in MS Outlook but I am not sure) So if we add contacts for important SharePoint document libraries to DL of relevant department (Site Collection), anybody can send email to DL, which will send email/document to all the members of DL as well as SharePoint document library and nobody needs to remember email address of SharePoint document library. All they need to do is, just send an email to DL and it will reach both the members of DL and SharePoint document library, which these members are going to access later.

When you add email address of email enabled Document Library to Distribution List(DL), permissions for email must be set to "Accept e-mail messages from any sender" in order to receive email in SharePoint and yes, It shows "System Account" for those messages or the documents received in Document Library. This is already been discussed in this Blog and unfortunately we are still struggling for an appropriate solution. If you set "Save all attachments in folders grouped by e-mail sender" , it creates a new folder for each new sender and then add attachments to that folder however it still shows "System Account" under "Modified By" field but at least it gives you an idea (by looking at the folder name) who sent that email/documents to your Document Library.

If you set "Accept e-mail messages based on document library permissions" then the email will not be received in SharePoint.

One more thing...

If you set "Accept e-mail messages based on document library permissions" option for your Document Library and if somebody, who doesn't have permissions on your Document Library sends an email to your Document Library, it never arrives in your Document Library. Also Sender will not receive any bounce back. So Sender assumes that he has successfully sent an email to your Document Library and you never receive it. Now, this issue might be specific to Majordomo(Unix based) email distribution system and may work well with MS Exchange configuration. I have tested this in my Lab with MS Exchange and I believe it sends the bounce back message if you don't have permissions on the Document Library but I am not 100% sure. :-(

Finally here is the matrix for reusing same contact name for same library or different library in SharePoint,

















References:
http://www.combined-knowledge.com/Downloads%202007.htm
http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=31

How to install Office 2003 web parts in MOSS 2007?

Back in September 2007, we upgraded SharePoint Portal Server 2003(SPS 2003) to Microsoft Office SharePoint Server 2007 (MOSS 2007). For some unknown reasons, after finalizing upgrade to MOSS 2007, We have MOSS 2007 environment depending on configuration database of SPS 2003. We are unable to create a new site collection/site if we detach old SPS 2003 configuration database.

One of the best possible way to fix this issue is to reconfigure existing SharePoint 2007 environment and get rid of both old SPS 2003 configuration database and old MOSS 2007 configuration database, which was created as a part of migration to MOSS 2007. We can also think of creating a new web application (Portal Site) and move content databases from original web application to a new web application however we did not want to take any risk of inviting new issues without thoroughly testing it in our MOSS 2007 stage environment, which is almost identical to our MOSS 2007 production environment. I will talk about these two approaches for fixing old (SPS 2003) configuration database dependency issue some other day but my intension of mentioning this issue is to talk about how to make Office 2003 web parts and components to work if in case you upgrade or reconfigure your MOSS 2007 environment.

As I mentioned before, the best possible way to resolve SPS 2003 configuration database depedency issue in MOSS 2007 is to reconfigure MOSS 2007 and that is what we tried first in our MOSS 2007 stage environment. SharePoint stage environment was upgraded to MOSS 2007 the same way as production environment and stage environment also has SPS 2003 configuration database dependency issue. So we reconfigured SharePoint stage environment successfully (I will talk about it in detail some other day) and we noticed that we were unable to install Office 2003 web parts and components after this. We are still using MS Office 2003 company wide. So the only option, we were left with was to reinstall Office 2003 web parts without installing WSS 2.0/SPS 2003. We tried to install Office 2003 web parts and we received following error:

"You must install Windows SharePoint Services 2.0 before you install Office 2003 Web Parts and Components."

We found following KB Articles, which explain more about this error message and its work around.

http://support.microsoft.com/kb/929320
http://support.microsoft.com/kb/927602

Here is the link for downloading Office 2003 Add-in for MOSS 2007,

http://www.microsoft.com/downloads/details.aspx?familyid=38be67a5-2056-46a1-84b1-337ffb549c5c&displaylang=en

So if you upgrade SPS 2003 to MOSS 2007 or if you reconfigure existing MOSS 2007 environment and if you want to reinstall Office 2003 web parts (to use it with MS Office 2003, I know nobody would personally prefer it over MS Office 2007 but if your company is still using MS Office 2003 with MOSS 2007), you can download and install Office 2003 Add-in from above link, which will allow you to use Office 2003 web parts in MOSS 2007.

Thanks to Microsoft for releasing this Add-in on time otherwise we would require to start from the scratch, meaning refresh OS on the servers, install SPS 2003 and then upgrade it back to MOSS 2007 just to have Office 2003 web parts working in MOSS 2007.