My event logs on my production front end servers are getting filled with error messages:
"Failed to determine definition for Feature with ID"
Now, I've found the offending feature on one of the development servers - it is an InfoPath form with some code behind. But, it is nowhere to be found on the production servers.
I've tried running the following command on the production servers:
stsadm -o uninstallfeature -id (your GUID) -force
There was no change - the error is still being generated.
How do I get rid of the error?
I'm not sure but I think copying that feature definition to the production's 12/TEMPLATES/FEATURES and then uninstalling it may help.
But it is not clear from this error message "Failed to determine definition for Feature with ID" what part of your production system is tied to the feature and what action is performed which leads to this error. Increasing the verbosity of Sharepoint logs could help you to more precisely determine what exactly causes the error.
Try this: SharePoint Feature Administration and Clean Up Tool
Find faulty FeatureDefinitions and cleanly uninstall them.
Find Feature remainders in Sites, SiteCollections, WebApps and in the Farm, from e.g. forcefully uninstalled Features from farm without deactivating them before, causing errors.
Also, de-/activate Features Farm wide.
Related
My first publish attempt (for a site that I've been publishing for months with no problem) post-.NET 6 is generating this error.
Unable to perform the operation ("Create File") for the specified directory ("C:\inetpub\ECM2\wwwroot\Identity\lib\bootstrap\LICENSE")
I'm publishing as the Administrator and, as indicated, this has been working for months.
I was having the same issue. I'm using web deploy from VS to an Azure App Service, changing the setting 'Remove additional files at destination' to true fixed it. It's found in the settings for the publishing profile.
My first inclination was to tick the 'remove files' box as well. This allowed me to publish the site but it also had a follow-on effect (for anyone else with this issue).
I didn't consider that this would also delete the web.config file, the absence of which caused a very ambiguous 403 error.
Reconstituting web.config on the server took care of that.
Here's the error I received as well. I clicked on "Remove extra files" in the publisher profile and the error went away.
It looks like I have just happened to find an easy reproducible solution for infamous:
'Load operation failed for query 'GetUser'.
The remote server returned an errror: NotFound'
issue for WCF RIA Services (Silverlight 5) web setup: when using VS2012 Web Publishing Wizard with 'Precompile during publishing' option checked-on then the issue does raise its ugly head. When the 'Precompile during publishing' option is checked off then deployed WCF RIA Services works well with Silverlight client. Please check on your system.
I have used fuslogvw etc.etc. - nothing helped. Never used Web Publishing Wizard before - xcopy was my friend, this time I wanted to automate the whole deploying process - and lost a couple of hours of precious time.
I still don't know what is the cause of the issue but I can proceed with my work. Next time when there will be more free time I will probably use this technique to localize the causes of the subject issue.
Edit for clarification: I have effectively solved the subject issue on my localhost but I have it still appearing in one program but not in another when releasing on an external web hosting environment, and I'm yet to find what causes this issue - do you know any good sources where this issue's various solutions are classified and accompanied with solution walk-throughs?
I'm trying to deploy a winform application with IIS and ClickOnce. I can access the publish.htm page and the install even starts when I click on the provided link.
However I get this error during the installation process:
Downloading http://MyWebSiteUrl/.../Interop.SHDocVw.dll did not succceed.
The remote server returned an error: (500) Internal Server Error.
Can anybody help me out on this ?
Thanks,
Bruno
I found out that I needed to check "use .deploy file extension" (under properties>Publish>Options>Deployment
[Answering this old question because it comes up as the best match in my case and the accepted answer was of no use to me].
Background, in an IIS hosted ClickOnce scenario, the downloadable components are itemized in a manifest file at the root of the deployment (that's how you can specify a single download link and deploy all the supporting components).
I was converting a tested application from a WiX installation to a lightweight version with ClickOnce and received the HTTP 500 error without anything else in the logs. Naturally, I failed to think it through and instead found myself getting dragged down the rabbit hole on the internets, with instructions for detailed logging, magic spells, etc.
Upon more sober reflection, the problem was simple and I should have been able to tell immediately from the IIS log: a 500 followed by a 0 is shorthand for 'you're an idiot, the content isn't where you said it was' and it had almost nothing to do with ClickOnce.
I had copy/paste/edited an existing download link template in MVC that was in use for simple apps and it happened to cater to only two levels of subfolders in the manifest. When I ported a more complex project structure, I ended up leaving items in a Resources sub-sub-subfolder that looked fine in the manifest but the path was being truncated in MVC so that the related item could not be found.
Moral of the story - if you get a 500 error always check first to make sure your non-functioning appliance is plugged into a working outlet...
I have created a feature and i am auto activating it whenever 'My Site' gets created.
I am activating it for the template SPSMSITEHOST.
This feature changes the Picture URL property of User Profile.
Now, the problem is my feature gets activated but it seems it does not execute the code by default and and does not change the picture URL property.
When i deactivate the feature and activate the feature again then feature works absolutely fine as expected.
P.S: I am facing this issue on Production server, surprisingly this work fine on Staging server , i mean the same code !!
Any help ??
Thanks.
Sounds like something becomes out of sync on your production environment. Could it be caused by load balancing?
Are you doing this through STSADM commands?
I would stick the following line after after each command:
stsadm -o execadmsvcjobs
This will make sure processing for previous commands is done before moving on.
If thats way off then I would think its something to do with:
a) The way you're activating the feature... if you're using feature stapling, are you sure that the latest version of your stapling mechanism is in place?!
b) Assuming you have some sort of feature receiver in your code behind. Are you sure there isn't an error occurring thats being hidden by a try catch? If there is then you need to see what the exception is...
If it works when you deactivate/activate the feature, that almost eliminates security issues.
Hope this helps..
After long investigating and search for this problem i tried to rearrange the features at package file depending on the features dependencies, it seems SharePoint activate these features one by one as it's arranged in the package file and this is worked for me :)
I have 12.0.0.6421 showing in Central Admin, which would seem to indicate that SP2 was installed. However, when I run an STSADM command to backup a site collection, I do not see the message informing me that it's "setting the site collection to be-read only for the duration of the backup" as described here:
http://bobfox.securespsite.com/FoxBlog/Lists/Posts/Post.aspx?ID=121
I simply get the "Operation completed successfully" message I used to get pre-SP2. Does this mean that SP2 wasn't installed correctly?
Anthony,
Showing a build of 6421 does indeed indicate that SP2 is in-place. Just to make sure, I checked my own farm and VMs as well as a reliable external source (an entry from Todd Klindt's blog: http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=154). I didn't doubt the build number, but it never hurts to confirm :-)
At first, I thought I understood where the issue might be, so I ran some tests. First, I ran an STSADM backup in catastrophic mode to backup my entire farm. Since this isn't a site collection backup, no locking should occur:
stsadm -o backup -directory \\ss-nas3\backups\test -backupmethod full
My catastrophic backup ran without issue, and I didn't receive any message about a lock or read-only behavior. I looked at my ULS logs, as well, and confirmed that no lock was being established (searching for "sitelock" and "lock"). This was as I expected, as I was doing a catastrophic backup -- not a site collection backup.
Next, I tried a site collection backup:
stsadm -o backup -url https://www.sculpted-system.com/pictures -filename \\ss-nas3\backups\test\SiteCollectionBackupTest.bak
Strangely enough, I didn't see a locking message here, either. I took a look at the ULS logs, and I saw nothing to indicate that a lock was put in place. Finally, I performed an
stsadm -o getsitelock ...
... while the backup was running and was greeted with this:
<SiteLock Lock="none" />
ARGH! That's not what I wanted (or expected) to see! Clearly, there was a problem ... so, I tried coming at it from a different angle. I took a look at the MSDN documentation for the STSADM -o backup command, and it clearly indicated that a lock should occur by default. It also indicated that the -nositelock switch should work to override the behavior. So, I tried adding -nositelock to my site collection backup command line.
Guess what: it choked on -nositelock with a command line error (invalid parameter).
Doing an STSADM -help backup indicated that -nositelock was not a valid switch for my environment. None of the new switches I expected (e.g., -nositelock and -force) were present. It's as if my production farm was stuck in pre-SP2 with regard to backups.
I decided to check a development VM I had that was also build 6421 (but different image -- amongst other things, Win2K8 instead of Win2K3 R2), I saw that the -nositelock was a valid command line option. So I checked another development VM that was also build 6421 (but Win2K3 R2 like my "regular farm"). -nositelock was a valid option there, too.
I had applied SP2 the same across all three environments when upgrading (WSSv3 SP2 bits, following by MOSS 2007 SP2 bits, followed by a run of the configuration wizard), so I wasn't sure what was going on.
For fun, I ran a site collection backup on each of the VMs that correctly displayed that -nositelock was a valid command line switch for site collection backups, and I was met with the locking message I didn't see earlier (and that you weren't seeing, either). Clearly, the SP2 updates were operating as I expected them to everywhere except my primary (production) farm.
I concluded I must have somehow done something wrong as part of upgrading my farm, so I tried re-running the WSSv3 SP2 update (first) and MOSS 2007 SP2 update (second) on each box. With each update on each box, I was told the that the update had already been applied. So, I dropped back and punted: I re-ran the configuration wizard to see if it would do anything. I then rebooted the two (virtual) boxes in the farm.
No change.
At this point, I can only confirm that you aren't losing your mind. Two of my all-in-one development VMs with SP2 build 6421 operate as expected, but my two-server/VM farm that is build 6421 that should be locking on site collection backup is not.
I think I'll probably follow up with a friend who is a Microsoft TAM. If I learn anything, I'll post it here and probably on my blog. In the meantime, you might want to follow up with Microsoft, as well. Clearly, something isn't working as expected.
For what it's worth!
There is a list of SharePoint Versions maintained by the SharePoint community here:
http://www.sharepointdevwiki.com/display/SharePointAdministrationWiki/SharePoint+Versions
Your version is correct for SP2; I wouldn't worry about the STSADM message appearing; it's a pretty inconsistent tool.