Error '0x80040e09' occurred during full-text index population for table or indexed view '[DB Name].[dbo].[CurrentPostCombined]': SQL Full Text Search Continued.

In continuation of the Full text search articles discussed before Article 1 and Article 2. Today we finally cracked the resolution of the error message below with the help on MS.

Crawl Log

"2012-08-31 19:01:39.11 spid19s Error '0x80040e09' occurred during full-text index population for table or indexed view '[DB Name].[dbo].[CurrentPostCombined]' (table or indexed view ID '207548023', database ID '15'), full-text key value 0x0000000000ADD0C4. Attempt will be made to reindex it.

2012-08-31 19:01:39.11 spid19s The component 'sqlfth90.dll' reported error while indexing. Component path 'C:\Program Files\Microsoft SQL Server\90\COM\sqlfth90.dll'."

Error log

2012-08-31 19:05:38.15 spid137     Error: 7683, Severity: 16, State: 1.

2012-08-31 19:05:38.15 spid137     Errors were encountered during full-text index population for table or indexed view '[DB Name].[dbo].[ArchivePost]', database 'ngservices' (table or indexed view ID '1813581499', database ID '15'). Please see full-text crawl logs for details.

Error ‘'0x80040e09' indicates Permission was denied for the account running SQL Server Full-Text Search, hence account will need elevated credentials.

RESOLUTION:

Use a low privileged Domain account to run SQL Server Full-Text Search service and restart the service. Please have a look at the following article for more information http://msdn.microsoft.com/en-us/library/ms143504(v=sql.90).aspx

In our environment the SQL Full text search service was running under Local system account. Changing it to run with the SQL Account resolved the issue.

We monitored the file size and it stopped growing.

Hope this helps you to resolve the issue in your environments.

There was an error opening this document. The selected file cannot be found

Problem Description:

When you print the multiple PDF files in Microsoft Office Outlook 2007, you receive the following error message from Adobe Reader:

"There was an error opening this document. The selected file cannot be found."

Resolution:

To resolve this issue, apply the following update: http://support.microsoft.com/kb/2276479  

After you install the hotfix package, follow these steps to enable the hotfix:

Click Start , click Run , type regedit in the O pen box, and then click OK.

Locate and then select the following registry subkey:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Options

On the Edit menu, point to New , click  Key , type Attachments , and then press ENTER. 

Locate and then select the following registry subkey:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Options\Attachments 

On the Edit menu, point to New, click DWORD(32-bit) Value , type FileTrackIdle , and then press ENTER. 

Right-click FileTrackIdle , and then click  Modify.

In the Value data box, type 5000, and then click OK.

Note If the issue persists, increase the value data by 1000 until you can successfully print all the PDF files. 

Exit Registry Editor.

Note: Before making any changes in the registry, I would request you to take the backup first and then make the changes.

How to back up and restore the registry in Windows XP

http://support.microsoft.com/kb/322756

Please let me know in case of any queries/questions regarding the above mentioned information. I would be more than happy to help you as well as resolves your issues, Thank you.

Acrobat cannot access the network. Please verify your computer's network connection and try again.

Consider the following scenario:

·         You create a French site collection in SharePoint Foundation 2010.

·         You upload a .pdf file to a document library in the French site collection.

·         You check out and edit the file.

·         You try to check in the file.

In this scenario, you receive the following error message:

Acrobat cannot access the network. Please verify your computer's network connection and try again.

If you are facing the above the scenario then Microsoft has already published the resolution for this and here is the link for it: http://support.microsoft.com/kb/2597136

Install the above mentioned hotfix and the issue will be resolved J

I would like to also mention that this hotfix has also fixes lot of issues and you will get a list of those fixes in the above mentioned provided link. Thank you.

Security Management of SharePoint Sites in SharePoint 2013.

Security management of SharePoint sites in SharePoint 2010 has been a bit ‘klugy’, unfortunately, leaving a lot to be desired by both the users and the administrators. Requesting access to a resource or granting access to a resource should not be confusing. In fact, managing security for a site is one of the most fundamental aspects of SharePoint and should be easy and straightforward so you can move on to more pressing things that require your attention. 

The following are a few of the challenges in SharePoint 2010 currently: 

● When site owners are granting rights to other users, they don’t understand which permission level to grant to the other users.
● Once a site owner adds a person to a SharePoint group, they generally don’t understand the rights they are granting that person.
● There is no simple way to figure out who currently has access to a site.
● Once an access request gets submitted by a user, it disappears into oblivion. There is no way to find out the status of that request (aside from emailing or calling the site owner).
● There is no one place where a site owner can go to manage pending access requests.

The SharePoint product team set out to focus on these shortcomings and build a better sharing mechanism in SharePoint 2013. 

When a user doesn’t have access to a site and tries to navigate to it, they are presented with the request "Let us know why you need access to this site." Makes a lot of sense, doesn’t it? It helps the user articulate why they need access when the request is sent, rather than requesting the access and then having the site owner ask this same question in return. See the image below.
                             Figure 1: Why You Need Access
 
This conversation component is visible to both the user who is requesting access and the owner(s) in charge of granting access to the site. It’s a great way for all parties involved to keep on top of the status of the request. The eventual result of the request and the action taken by the site owner is then archived for later reference as needed. 

For the scenario where the site owner wishes to invite folks to the site, it is a simple straightforward process. The site owner clicks the Share link on top left of the site and the dialog appears showing who the site is currently shared with and the fields to invite others to the site. See the Figure 2 below.

                                 Figure 2: Share Dialog Box

Once the site owner decides who to invite and what permission level to grant them, those people get an email notifying them regarding the invitation. This process is pretty straightforward and has worked the same way (but now with a better interface) in SharePoint 2010.


With Permissions from SharePoint Pro.

SharePoint Performance Optimization with SQL Server

How to design your disk system for maximum performance at the database level.

Disk input/output (I/O) performance is the single biggest constraint on database performance in the SharePoint world. Running SharePoint on an underpowered or poorly designed SQL Server environment will slow performance throughout the farm. 

Because it's equally important to make sure SQL Server databases are kept highly available, some level of disk redundancy is usually factored into physical designs for database servers. Disk redundancy is often classified by RAID levels. After I explain how the various RAID levels can help performance and availability, I'll share some tips on how to design your disk system for maximum performance at the database level.

RAID Fundamentals

RAID technologies predate PCs and modern x86 server designs. Three of the most common levels are RAID 1, RAID 5, and RAID 10, so let's take a closer look at them. 

RAID 1. In a RAID 1 design, you have mirrored pairs of disks. If one disk fails, the other has a full copy of all the data and goes on operating. RAID 1 is a high-performance technology but requires purchasing 2GB of raw disk space for every 1GB of data because you need two sets of identical data. So, although RAID 1 might initially seem like an inexpensive solution because there are only two disks involved, it can be an expensive one if you have a lot of data to store. 

RAID 5. In this RAID level, you use groups of disks to create a large synthetic unit. For example, five 150GB disks could be combined to create one hybrid 600GB storage pool. 

At this point, you might thinking, "Wait a minute, that's not correct!" Although I'm not great at math, I know that 150GB ´ 5 should equal 750GB, not 600GB. However, in RAID 5, one disk is dedicated to calculating a checksum, or parity bit, every time data is written to the group. That way, if any of the single disks fail, the data can be redistributed to other disks by reversing the parity calculations. As a result, RAID 5 is highly efficient at optimizing the volume of data stored. It's also great at handling high-volume read operations -- more disks working together means more systems to read bits from a disk platter and fewer chances for bottlenecks. 

Write operations are a different story. Because every write operation requires a calculation, high-volume write operations are slower than they would be in a traditional disk system. However, for SharePoint, that's not always the worst thing, because SharePoint is a read-heavy database consumer. 

RAID 10. Some people make a distinction between RAID 1+0 (stripes across mirrors) and RAID 0+1 (mirrors of stripes). This debate doesn't really matter in SharePoint designs. What does matter is that out of all the RAID levels, RAID 10 offers the highest availability and highest performance possible. However, RAID 10 requires purchasing extra disks for parity and mirroring -- more than 2GB of raw disk space for every 1GB of data, effectively more than doubling storage costs.

Design Tips

SQL Server databases are the largest consumers of disk space in SharePoint. Thus, designing your disk system for maximum performance at the database level is more crucial than for any other level. Here are some general design tips. 

Don't virtualize SQL Server. If possible, don't virtualize SQL Server because it's already an integration platform. If you have to virtualize SQL Server, try to limit the virtualization to test or development systems. Avoid using it for production systems because it raises the bar in disk engineering to get good performance. SQL Server databases stored in virtualized disk files are inherently slow compared with dedicated physical disks. 

Use multiple logical drive letters. It's usually a good idea to break up SQL Server databases into multiple logical drive letters because database files, transaction logs, backup files, and temporary databases (tempdb) benefit from having multiple independent sets of disk spindles. Adding more spindles spreads the load across multiple parallel operations when data is being written to the database. 

If you're going to use a SAN or virtualized environment, make sure you understand where those logical drive letters will be mapped. For example, if the D, E, and F drives will all point back to separate LUNs on your SAN, but those LUNs will be part of the same storage group and same set of physical disks, splitting those files into multiple drive letters will add complexity without significant performance gains. 

Use RAID 10 judiciously. RAID 10 is great, but you might not be able to justify it for all applications. For example, it might be overkill for backup files. Balancing disk performance and cost is a reasonable trade-off. One possible design is to use:

• RAID 1 on boot disks
• RAID 5 on data disks
• RAID 10 on log disks
• No RAID or RAID 5 on backup disks

Break large content databases into multiple database files. If you have large content databases, you can engineer better performance by breaking each large database into multiple database files. Each database file should be on a separate disk. 

Presize SQL Server databases. SQL Server databases can be set to automatically grow as needed, but this can lead to massive file fragmentation. Presizing the databases to a sufficient size at the outset helps ensure contiguous file allocations. Note that SQL Server's tempdb database is heavily used by SharePoint, so you should presize it to about 20 percent of the size of the single largest content database. 

If you want to use automatic database growth settings instead of presizing your databases, you should set the databases to grow in 50MB to 100MB clumps and not by percentage. Setting a 100GB database to grow in 10 percent increments means the database essentially stops to add 10GB or more on each increment. Using a small clump size will lead to more frequent, but smoother, steady state (i.e., continuous) growth.

Design a High-Performance Database Environment

If you use RAID and follow the general design tips, you can design a high-performance database environment that's also highly available. This is essential to a smoothly running SharePoint system.

With permissions from SharePoint Pro.