Our second posting about Search continues with first post with the theme of items not showing in SharePoint Search. It touched on items not showing because of how permissions are set. This is about when recently added items will show up. When a new item is added to a SharePoint site, or to a network drive that is searched by SharePoint, it does not show up immediately. The search must first find the new content. It goes through a process called a crawl. There are different types of crawls that are done and they occur at different times. In our company, when something new is added to SharePoint, we need to wait until after the top of the hour. The crawl runs on new and modified items every hour, on the hour from 5:00 am through 5:00 pm. Full crawls, of all items, are done once a week. Crawls can be started manually too. We don’t usually run them during the day as it can affect performance. To check your crawl schedule go to Central Administration | Application Management | Manage Service Applications | SharePoint Server Search | Content Sources (in the Quick Launch Bar) and click on the Name field to see the settings. Or, the dropdown will give you multiple functions including viewing the crawl settings or starting a crawl.
Getting into the holiday spirit, I am asking, “Do you see what I see?” I am hearing from more and more employees on their use of SharePoint Search. There is definitely the good, the bad, and the ugly when it comes to search. I am hoping to have more of the good. I thought I would try to cover some of the issues and offer some tips over the next couple of weeks. Let’s start with what you see in search and what I see and what another employee sees. One of my favorite Search Cynics* stopped by to challenge me to find something he could not find. When I did a search, from the intranet home page, like he did, I got different search results. It gave him an opportunity to give me a good “ah-ha”. So why was it different? I had different permissions then he did. There were documents and sites that I had access to that he didn’t and there could have been items he had access to that I didn’t. This works the same for searches in SharePoint and network drives that are searched. He didn’t take back his “ah-ha” but it was a good opportunity to provide some content for this article.
*Search Cynics (SC) – one of my favorite types of employee because they offer challenges and an opportunity for me to make them Search Evangelists. My favorite (SC) quote to date just came in today, “They will not show up in search for at least an hour, maybe not until morning,….. probably never”. And that will lead us into Part 2 of Search, coming soon, not “never”.
The Scenario: A user was moving documents, pdfs, into a document library. The library did not require check-out, and did not require content approval. It also did not have versioning enabled. The user scanned a document, emailed it to herself, right clicked and did a Save As to the SharePoint Library. The user could see them, but no one else could, no matter their permissions.
The Solution: It turned out the pdfs were all checked out. When I checked them in, two of them gave me errors that required fields were not complete. If she had uploaded the documents, she would have been required to complete the required fields, but she was doing a save-as to the documents, so SharePoint kept them checked out to her. Even after she completed the fields, she was unaware, that she had to check them in.
It was a little confusing considering all the right buttons had been checked to not require check-in. We typically upload documents, but because of the method of making the pdf, scanning from a copier next to her desktop and emailing it to her, we deviated from our standard way and learned something in the process.
As with so many issues in SharePoint, an error like this can be very difficult to troubleshoot. And, in my case, we are often looking at something that seems so out there that no one could possibly have the issue. I’m putting this out there for other users with one-off errors like this.
Our SharePoint 2010 install is undergoing some configuration changes. The original install was not quite right and although SharePoint was running, our error logs were stacking up, certain features just didn’t quite work right, and it seemed we had issues that just surfaced out of nowhere. We were fortunate to get a consultant in that noticed these configuration issues and was able to clear them up. It was not an easy process as everything is connected. Profile services led to Search Services led to App Pool logins, led to our error. I don’t know the nitty-gritty details of our error but can describe the symptoms, in the order they appeared and solution.
- A user emailed an error message to me that the Sandboxed solution was busy – restarted the service.
- A couple hours later, a Document set in a site collection produced this error (#1 and #2 are in different site collections):
- The document set would be created, but a document that was supposed to be created inside it was not.
- Yellow information in the document set said the content types needed updated, and they didn’t.
- Removed the document that was automatically being created in the document set – same error
- Attached the core document set content type to the library – same error
- Created a new library with the core document set content type – same error
- Created a new library in a different site collection with the document set content type – no error
- Issue with the site collection and not the web app, thank goodness
- Decided it would be quicker to create a new site collection and start over.
- The site collection was new and being rolled out the next day, so time was of the essence.
- I hated to do this with the error and not knowing when/if it might appear again
- Created a new site collection and discovered missing site columns when creating a content type
- The missing site columns were part of a Codeplex Sandbox Solution
- Uploaded the Solution to the site collection and Activated it
An ah-ha moment
- The Solution uploaded though
- I was not going to continue with an error
- I deleted the Solution
- Restarted the Sandbox service
- Reloaded and activated the solution – No error
- Returned to the original site collection with the error and tried again – No error
The errors were probably a result of the many changes that had happened the day before with the configuration. We have services that were restarted, a Search crawl that “crashed” and who knows what else. Although you may not have exactly the same issue, the steps I did may lead you to your own solution.
Disclaimer: As you can see by the url, this is Out of the box (OOTB) SharePoint. I am not a programmer, I resist PowerShell, unless I have someone over my shoulder watching, and if I keep things ootb then when I upgrade or need to troubleshoot an issue, I have a better chance of finding someone else with the solution.
This problem inspired me to start blogging my issues. Most of my solutions I am finding elsewhere and will certainly give credit where credit is due. I created some test content types in a site collection. I was using content types from the content type hub and customizing them in another site collection. Once I was done testing I did everything right so I could delete the test content types:
- Deleted all the documents associated with the content type
- Deleted the actual library that had the documents in it
- Deleted all the documents from the recycling bins, don’t forget the site collection recycling bin accessed from Site Settings
Still my content types would not delete.
I came across a SharePoint blog dated back to February 2010, which had buried deep in the posts, someone said you also had to delete any tasks that may have been assigned by workflow using that content type. That was it! I cleared out the Task list, the Workflow task lists and emptied all the recycling bins again. Voila, my content types deleted beautifully.