We have a SharePoint 2010 feature that works fine on my development machine, but won't activate on the staging system. It's SiteCollection scoped, the containing solution was successfully deployed on one WebApplication.
When we try to activate the feature, we get an error message with a Correlation ID. But we can't find this ID or the name of the feature in the SharePoint Logs nor in the Windows Event Log.
Maybe logging wasn't configured right or there is an error with ULS on the machine, but we haven't changed the SharePoint Logging options from the state they were after installation. Where can I find exception / error messages that happen in ULS? How must Logging be configured to allow the failed feature activation to be logged?
Under SharePoint 2010, go to Central Administration. There is a Monitoring link. Click there and under reporting is a Configure Diagnostic logging link. If you set the Least Critical event to Trace and Least Critical Event items to verbose, you should get more information in the SharePoint log files. Make sure you switch back though after diagnosing because the process is chatty and can result in extra IO and large files.
Out of the box, I don't believe logging is set. You can also verify the location of the log files to make sure they are not on setup elsewhere on this page.
More information at TechNet
Download the ULS Viewer tool from here: link text and filter by the correlation ID.
This is an old post, but if soone gets the same problem, please try the following:
Check who is your farm account user (the user under which SharePoint Timer Service is running).
Add this user to local administrators
Restart Timer Service.
Please mark this as answer if my solution works for you.
You can always get information from the logs from all servers in the farm using the Merge-SPLogFile cmdlet. The example below filters on a correlation ID, but there are more filter options (tip: Get-Help Merge-SPLogFile -Full).
$corrID="some correlation id"
Merge-SPLogFile -Path "path to output file" -Correlation $corrID
It is worth emphasizing that the OP's substantive question,
Where can I find exception / error messages that happen in ULS?
is answered by the OP himself in a comment to #noebierzo,
I found the log entry ... by checking all log files on all front-end
servers.
So be aware if you have a multi-server farm; look at all servers in the farm when checking or searching for errors and trace log messages.
Fortunately Microsoft recently released an updated ULS Viewer v16.0.3129.1000 that provides basic multi-server aggregation of the trace logs. Bill Baer, Senior Technical Product Manager for SharePoint at Microsoft has a nice blog post on the new version which outlines this feature.
The new version of ULS Viewer is available from the Microsoft Download Center. Note that this version of ULS Viewer requires at least .NET 4.0 which your SharePoint 2010 farm may or may not have installed. Bill blogs about this but doesn't comment on the impact of installing .NET 4.0 on your SharePoint 2010 farm.
If you want the old version of ULS Viewer v2.0.3530.27850 that only requires .NET 2.0 you can no longer count on Microsoft as they took down the Archive Gallery where it used to live. Fortunately a few people have posted it online, include Benjamin Athawes on his blog.
Given the .NET version dependency, and the fact that SharePoint 2010 is still a supported product, Microsoft really should keep an official link around for this prior version ULS Viewer. Suggest you ask Bill about this on his blog. Perhaps SharePoint 2010 SP2 is fully supported side-by-side with .NET 4.0, it would be good to know.
Related
I recently inherited an application from a developer who is no longer with the company. This application restores SharePoint sites from backups and extracts metadata and files from lists in the site. The application runs on a SharePoint server and uses the Microsoft.SharePoint assemblies in C# and VB.Net.
The backups come to us from various outside companies, and some of them have custom features installed. SharePoint Health Analyzer shows a warning about "Missing server side dependencies". When I look at the report there is a lot of "[MissingFeature] Database [db name] has reference(s) to a missing feature..." etc. The previous developer was supposed to implement a check for missing features, but it is obviously not working.
How can I identify features that the restored site references, but are not installed on the farm?
Thanks!
RH
You can use SQL Management Studion and check Features and FeatureTracking tables to see list of features, its' IDs, titles etc.
But do not modify these tables.
To solve missing features error. You can:
1. install missing feature (if you have it).
2. try to remove it (probably will fail as you don't have it).
3. as the last chance option you can create empty feature with the same ID as missing feature, pack it in WSP package and install it.
Does anyone here know what could cause a new feature to not show up in the SharePoint UI?
The solution it is part of has been correctly deployed to the GAC and shows up in the central administration list of deployed farm solutions, the feature appears in the FEATURES folder of the 14 hive, yet the feature itself does not appear in the features list for the site collection, either in the UI or in PowerShell using Get-SPFeature.
Yes, the feature is correctly scoped, and no, it is not hidden. :)
Any thoughts or pointers would be very welcome!
Answer supplied on sharepoint.stackexchange.com, with thanks to Simon Doy. https://sharepoint.stackexchange.com/questions/73871/sharepoint-2010-feature-not-appearing-in-ui
Somehow, something had gone wrong with the installation of the feature, and neither the UI nor commands like Get-SPFeature revealed its existence, although the Install-SPFeature -ScanForFeatures command emboldened below displayed the missing feature.
"Check that the feature has been installed. For example, if you are
performing Update-SPSolution and a new feature has been added between
solution deployments then the feature is not installed by default.
To check do the following:-
Run SharePoint 2010 Management Shell from one of the SharePoint
servers Type Install-SPFeature -ScanForFeatures This will show you any
features that are available in the SharePoint Root but have not been
installed. You can install any missing features using the command :-
Install-SPFeature -AllExistingFeatures
See the following TechNet
Article for more information.
http://technet.microsoft.com/en-us/library/ff607825(v=office.14).aspx"
Look in central admin to see what site collection the feature is deployed to. Make sure in that site collection the feature is turned on.
Also, check the deploy job status to see if it actually finished.
Is there a on install event receiver? If it errors out, the feature will not finish installing even after the DLL is copied.
Starting today, whenever I try and use security editor on either of two similar roles I get a timeout. If I try again IIS reaches an error threshold of some kind and stops that Application Pool. Then all of our users receive a "Service Unavailable" message from IIS.
I can edit other roles. This error can be recreated.
I assume I have some kind of database corruption, but I can't find an error that helps me in Event Viewer or the Sitecore logs. Where else can I look for more detail?
IIS6, Windows Server 2003, Sitecore 6.2
It sounds to me like you've got a circular reference in your roles.
Are you using the default role provider, ASP.NET membership? If so, try using the default Microsoft security tools (you can get at 'em via Visual Studio). If that doesn't work, you can programmatically modify these roles using the API.
Also, I believe there is a known issue which may be fixed in a 6.2.x update. I would check the change list at SDN. Here: http://sdn.sitecore.net/Products/Sitecore%20V5/Sitecore%20CMS%206/ReleaseNotes/ChangeLog.aspx
Yep... take a look at the 6.2.0 rev 100701 update list.
We have a brand new SharePoint 2007 Intranet farm running on new 64-bit hardware with lots of processor and memory. We are using Kerberos for security and have carefully followed all the written guidance from Microsoft and blogs to configuring Kerberos and Excel Services correctly. Generally everything is running great.
Currently we can add Excel Web Access web parts on SharePoint team site pages and connect them up to SQL 2005 Analysis Cubes for use with doing Pivot Tables, Graphs, etc... As part of this, we have created a test dashboard page that has six of these web parts that display upon page load. However we have noticed that we get intermittent errors when a user does things like refresh the connection or workbook, or change the filter on PivotTables. The user gets a generic error messages such as "An error has occurred. Please contact an administrator." and then their session in Excel Services is hosed up. They have to shut down IE and come back to the site in order to interact successfully with the Excel web parts again.
I have looked at the logs but just see generic messages like "EcsSoapException: An error has occurred." that don't give me something that I can really act on. Also I have checked the application event logs but didn't find anything relevant.
Any ideas on how to troubleshoot this?
It turns out this is a bug with Kerberos in Windows 2008. Microsoft has just released a hotfix for this (see link below). The hotfix completely resolved all my issues.
http://support.microsoft.com/kb/969083
We have a long standing issue in our bug tracking system about the dreaded "ERROR: request not found in the TrackedRequests. We might be creating and closing webs on different threads." message in SharePoint's trace log.
As we develop Workflow software for the SharePoint market, we look into this issue from time to time to make sure it is not caused by our products. I have personally come to the conclusion that this is a problem in SharePoint, but perhaps someone else can prove me wrong.
Here is what I know:
According to the hundreds of search results returned by Google on this topic, this issue appears to be mainly related to SharePoint Workflows, both SharePoint Designer and Visual Studio based workflows.
Assuming ULS logging is set to Monitorable, the easiest way to reproduce this problem is to create a new SharePoint Designer Workflow, attach it to a document library, set it to auto start on add/update, don't add any actions, save the workflow and upload a file to the document library.
The error is only visible in the SharePoint trace log, it does not appear to impact the execution of the workflow at hand.
I have verified that the problem occurs on 32 bit as well as 64 bit systems, Win2K3 and 2K8, WSS and MOSS with SharePoint versions up to the December 2009 Cumulative Update (6524).
The problem does not occur when a workflow is started manually.
There are dozens of related posts on MSDN Forums, hundreds on Google, one on StackOverflow and none on SharePoint Overflow. There appears to be no answer.
Does anyone have any idea about what is going on, what is causing this and if we should worry or file this under 'Red Herrings'.
Update: Microsoft has confirmed this is a known issue that can be safely ignored. It will not be fixed in SP2007, but is no longer a problem in SP2010.
File it under Red Herrings. You say "The error is only visible in the SharePoint trace log, it does not appear to impact the execution of the workflow at hand." There are so many errors logged in the ULS Log that are beyond our control and do not immediately impact our environment. If you want to improve the product you could attempt a support call that may be non-incremented as a bug. However, what if it's not a bug, but just a verbose ULS Log message?
In fact, this verbosity isn't limited to just the ULS Logs. Have you seen the Microsoft Office SharePoint Server 2007 Management Pack for System Center Operations Manager 2007? It filters out the noise events from the Event Logs on your farm so you can concentrate on the events that flag an actual problem.
This is a really good question and I'm starving to see good responses to this. I've seen this error in my workflows in very different contexts.
For instance, In my case it happens in a home-baked custom activity when I catch the "task created" event and try to "breakroleinheritance" of the SPListItem (the new task).
My custom activity gets workflow context through a property wfActProps which is of type SPWorkflowActivationProperties. Then I typically use wfActProps.Web to access the web object.
The first thought I had that maybe it's a bad tone to pass SPWorkflowActivationProperties between different activities, however I have not found any different way yet.
I'm setting "community wiki" to my answer since this is not an actual answer, rather an example of a situation where this error can be seen.
When I look at the stacktrace (I'm assuming the person who posted that message is referring to the same error), it looks like an OOTB event receiver (Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver) which is responsible for autostarting workflows is disposing an SPSite that may not have been created by the event receiver code.
Unfortunately the AutoStartWorkflow() method is obfuscated so I can't really see in Reflector which SPSite is being disposed. You could experiment writing your own EventReceiver that disposes any existing SPSite it can get it's hands on and see if that causes the same error to be logged.