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.
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.
The SharePoint install is a SP2010 install on a 2008 R2 server. Everything is fully patched. I am running the SP Designer on the SharePoint Server directly.
I have a workflow which is intended to send an email when a new document is created in a custom list. I have deliberately kept the workflow very simple in order to illustrate this problem.
After creating this single step workflow in SP Designer, I click "Check for Errors" and SP Designer reports "The workflow contains no errors".
I then click "Publish" but the Workflow Error dialog is displayed with the message
Errors were found when compiling the workflow. The workflow files
were saved but cannot be run.
Clicking the advanced button reveals more information:
Could not publish the workflow because the workflow configuration file
contains errors
Any suggestions gratefully received
I'll share what fixed it for me - deactivating all workflow features at the site collection level (that is, Workflows, Three-state workflow, Publishing Approval Workflow) and then reactivating the features. I was then able to publish my workflow. This post helped, not sure whether this only works for 365 though, but it's sure worth trying first if you are considering a reinstall.
after googling for quite some time, i think it's an authentication issue. How is your SharePoint set up? Do you use HTTPS for authentication? If so check out this article.
I know this error message from sharepoint. I got this by dealing with multiple lookup fields refering to other lists. Even when I check the worfklow for errors SharePoint says that its all fine but i can't publish it at all.
Try to build a new Test-Site on your Site Collection. Build a Custom Document Library, leave it standard and then set up a new simple workflow just sending a mail.
Fill out the needed fields in mail only using simple values. Send to your mailadress, simple mail subject and simple mail body.
Set the workflow to run only manually.
Try to publish the workflow.
When this is working, then compair to your existing workflow and change your values by trail and error.
After doing a clean install of the OS and SharePoint, workflows are working flawlessly. I can only conclude that the problems were caused by left over registry settings from MOSS 2007. Thanks for the suggestions that people made.
This could also happens if you chage the URL of the web application, all you have do is click the Design button from the library itself.
when changinf the URL from http://server/Site to example: http://server.xx1.net/site, and you try to publish it tries the old url.
what helped in my situation is changing from start workflow automatically to manually.some times answers for critical situation is very easy. hope it helps, many thanks
I ran into this problem and after digging for days and folks suggesting to rebuild the servers, disabling and re-enabling site features, remove previous workflow versions, etc. and trying everything except rebuilding the servers (not practical for clients production environment). I decided to try some tests and found that this issue was only happening on one particular list no matter how simple or complex the workflow was... And when I would check the box for start automatically on item create (or when item changed) it would fail to publish and give the error above, but if I published it with just manually start worked fine. Finally after deleting views and some more testing, I discovered that there was over 240+ columns in this list (I did not create it...) and 50+ workflows set to run on create... Thankfully I have a test environment I built out for the client so I sync'd the Site Collection database back to test environment from Production re-ran my tests and got same error... So what resolved the problem and what was the ultimate cause of the problem, there was to many columns defined in the list and I had to delete several columns to publish the workflow in the test environment. This actually issue translates into the there is a limit in SQL Server on how much data the list can store each type of column takes up so much space read more about it here:
https://technet.microsoft.com/en-us/library/cc262787(v=office.15).aspx#Column
So what I did in production was worked with my client to determine how to break up the list into multiple lists and have relationships between them, thus moving some of the columns and data to another list (Think database/list normalization)... I hope this solution helps someone.
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.
How do you handle improvements and added functionality to your existing SharePoint code?
Did you deploy your original code as a feature?
Do you create a new feature_V2 and deactivate the original?
What processes have you found that led to problems in the future?
I am specifically interested about WebParts, EventHandlers, and WorkFlows.
From what I can find, MS did not leave a "Best Practices" around updating existing code. (Actually, I'm not sure they left a "Practice" much less a "Best Practices")
You can see other questions around this topic:
how-to-upgrade-a-long-running-sharepoint-workflow-already-in-production
how-to-update-spitemeventreceiver-assembly-version-for-a-list-in-sharepoint
should-i-keep-solutions-and-features-in-a-1-1-ratio
What is your method?
I understand this question may be subjective, but I feel there is a large information gap surrounding this area of SharePoint development.
Thank you,
Keith
We always deploy custom code as features and solutions. When it is time to upgrade the existing code, all you have to do is stsadm -upgradesolution and everything works very nicely. I do not like the idea of having feature_v2 type features around...it makes it extremely difficult to keep track of the current version. I think you should only have one version of each feature in your production environment.
Leave the version control to your source control system.
I'm working at a shop that does a lot of SharePoint development. You want to deploy by feature with a solution package. You can easily upgrade your features as you go along and you will need to upgrade the solution package. This solution package can be created from a TFS Build server with WSPBuilder. As you along, the only thing left is to upgrade the solution and "Force" reactivate your feature to have the new feature of the feature.
Don't forget to do an IIS reset for any new code deployment that is done through the GAC. If you put anything inside like sitemaps and resources inside your 12, you will want to do a stsadm -o copyappbincontent.
If you deploy features that contain application files, you want to unload your application on ALL servers of the farm. It can easily be done by putting an App_Offline.htm at the root of every application on every machine.
When completed, remove App_Offline.htm (or rename it) and you are done. Your site is back online.
I applied the MOSS infrastructure upgrade w/o applying the WSS one before it -- uh, help!
Quoting:
Infrastructure Update for Microsoft Office Servers (KB951297)
Other Relevant Updates It is strongly recommended that you install the Infrastructure Update for Windows SharePoint Services 3.0 (KB951695) before installing this update on any of the Office Servers listed in the system requirements section above.
Therefore not applying first Infrastructure Update for WSS seem to be not recommended but not unsupported
I believe that is a supported, but unrecommended configuration. You should be able to get help from microsoft :)
I am assuming that you have also run the Configuration wizard after you applied this and brought your system online? If you have not, you are in a much better position, as you can apply the WSS upgrade - then run the wizard and you should be fine.
If you have run through the wizard - and brought the system back online - its not the end of the world. What you will want to do - is go back and follow the steps to upgrade your system just as if you had not done anything. The infrastucture update makes some significant changes and improvements to portal search - so once you start trying to configure that, you'll see some errors in crawling etc - as the indexer (which has been updated) tries to crawl content (which has not).
Apply the WSS bits, then reapply the bits for MOSS, then run the Config wizard and bring everything back. You should be okay at that point.
Obviously, before you do anything, backup all systems and take them offline.
Hope this helps.
Sounds like time for a full restore. The MOSS upgrade steps did explicitly ask for a restore, didn't it?
The TechNet article Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007) has a dicussion on this in the community content section. Someone commented that the WSS update must be run first. There is no suggestion for what to do if you don't or what the consquences are.