I messed up my DNN azure website by deleting my modules and want to go back to a previous date. I've heard this was possible and have searched the web for several days, not finding an answer.
As far as I know, this issue might belong to DNN. Here is a similar thread restore-deleted-module-from-database-recycle-bin in DNN support forums, you could refer to it.
If a module is deleted from a page, the IsDeleted field in the Modules table is sat to true. If it gets restored from the Recycle Bin, it would be sat to false. Please try to find that whether you could find the modules you deleted in your Modules table.
Related
We run a classic JavaScript app on multiple tenants on SharePoint online. The app uses the Microsoft.SharePoint.Client.Search.Query.KeywordQuery to search for documents within the site collection where the app is installed. On one of the systems we get the error:
Microsoft.Office.Server.Search.SubstrateSearch.SubstrateSearchException:
Remote executors failed, local failback not allowed.
Despite the specific words in the error message, I was not able to find any documentation about its meaning. When I copy the search string used in the SP search field the search works. Any clues what could be the cause?
Any developments on this? We just started seeing this same error in one dev environment but not another, despite running the same code.
I have the exact same problem, but if I include "-contentclass:STS_ListItem_DocumentLibrary" in the keyword query it works, but since i need items from document libraries this wont help me.
We have only seen this issue one one environment, I am not sure how to fix it. It looks like it is having issues with document libraries specifically, unless i include a some text it also should search for (besides the keywords). If i didn't know any better i would almost say it was some kind of overflow, but that just seems far fetched, and we do have limits on the query anyway.
Update:
Subsequently if I wrote a keyword for a specific library like ListId:73C91192-89CD-4C06-A322-388CEAE456ED instead, it also works
we just recently started to see this same issue.
In our case we were using a Classic SharePoint Online site, with the search web parts on it. The search results web part had a number of different Hit-highlighted managed properties that it was trying to bring back. One of these properties was "Topic". I checked the search schema and for some reason, this managed property had disappeared. Removing this property from the search results web part fixed the page and search results web part.
No one had touched our search schema in a long time so this property had simply disappeared. Definitely seems like search schema updates are causing issues.
Hit-highlighted properties
Does anybody have some usefull information or pointers on this issue? We just came across this issue on one tenant for one specific user. We have a multi-tenant app that executes a search query looking for document libraries with 3 conditions:
We do use the ContentClass:STS_List_DocumentLibrary condition as we are looking for document libraries
External content specifier: "-isexternalcontent:1"
Generic search term: just a single word
As mentioned we get this error on one tenant when one specific user executes it. I can't reproduce it with other user accounts. Since we are providing a multi-tenant SaaS we are afraid this will start popping up for our customers..
I am facing a huge problem with Sharepoint Online. We have two sites and both of them have the same solution deployed. Both solution are subsites and have their features at web scope.
The solution has a main list that we put some data in it depending on some rules but as it is not part of the main issues this is not important.
The problem is that recently something really annoying is happening in these environments. This main list, usually during the week and during the morning is being deleted, and also the features of the solution are being deactivated.
The team came up with some ideias about what is happening:
Some code in the solution that delete the main list.
Someone is deleting the main list (someone really bad).
List is being deleted by a sharepoint job.
To configure the main site is affecting the subsites and causes the deletion of the list.
I think that options 1,2 it are not happening.
Everything would be resolved if we have access to central administration or even to some log, but for security reasons we don't have access to them, what is really bad for us, as developers because we have to guess what is going on.
Can someone give some tips about how to identify this problem?
Please let me know about any more important additional information that I havent written so far.
Thanks in advance!
Indeed not being able to read logs is very inconvenient.
Also, in CSOM, property AllowDeletion for List isn't exposed; as it is for SSOM instead.
The only way I'm thinking you have to intercept when this happens, is to create a custom Remote Event Receivers, which hooks ListDeleting / ListDeleted events
This should be a rather up-to-date and good start if you're new to RERs
https://msdn.microsoft.com/en-us/library/office/jj220048.aspx#RER
I'm fairly new to SharePoint but I'm learning fast. However, I've encountered a confounding issue that has me completely stumped, and the internet hasn't been able to provide anything useful as of yet...
I'm running SharePoint 2010 in a VM, and I am getting a repeated issue with libraries spontaneously disappearing from the GAC. This is happening on average about once a day at the moment, but at different times of day and with no apparent trigger. The VM I am running (and the source code thereon) are identical to my colleagues', yet I am the only one to have encountered this issue. I have rebuilt my environment several times and thought I'd cracked it with this latest one, but the issue has just reoccurred. Since it happens at different times of day I don't think it can be a timer job, and it can happen spontaneously with no user input (no changes to code, settings, environment, anything).
I can provide more details of the libraries affected if required, although it seems to be a mixture of proprietary libraries specific to the project, and standard Microsoft assemblies.
Any help or pointers would be gratefully received!
Had the same issue. I fixed it by recompiling one the conflicting dll files with a different version number and some different number. Then i made sure that every webpart that uses this dll had this dll in their individual sharepoint package, then i deployed the webparts again and this time they didnt disappear.
I also found out that disappearing was not random and was the result after another webpart was being installed. Pretty weird.
I'm experiencing problems when trying to deactivate a custom feature through the GUI. When I press the 'deactivate' button I'm, as expected, redirected to the warning page which asks if I'm sure I want to deactivate.
Upon confirming, the page starts loading.
The feature in question should normally be activated very fast, however on this occasion the page loads for more than 5 minutes without anything happening.
After concluding that the page seems to be stuck in an eternal loading cycle, I had to refresh the page to see if there had been any changes, but no, the feature remains active.
Any ideas?
Details:
The site I'm working is a previously existing office365 site. I've just made some changes to my custom solution (modifying one feature and adding another)deactivated the old solution and uploaded the new solution, so I'm trying to deactivate and reactivate the feature which I've modified.
It depends what's happening during deactivation - 5 minutes might not be very long if the deactivation has to perform a lot of updates (e.g. removing columns from lists in lots of subsites). I did once have a feature deactivation that took 45 minutes (?) to run.
I guess another possibility is that you've got C# code that contains an infinite loop? Though that seems a bit of a long shot.
Otherwise, Office 365 is very hard to debug; I'd suggest raising a support call with Microsoft through the O365 portal to see if they can see any logs.
When the feature is removed are you trying to remove items like CT's or anything that is dependant on another thing?
I've seen features get glitchy when this occurs on our test enviroment and make sure this is ironed out before deploying to live.
Theres a feature checker somewhere on codeplex but i'm not sure if this will connect to the office365 site. It's called something like FeatureAdmin.exe This might help you in removing the feature and clearing out left over stuff from the feature however it will not remove whatever your feature is struggling to remove(if it is of course!)
When the original feature was deployed did you test it could be deactivated cleanly?
I have a customer using the Access 97 runtime to support part of their product. Ideally, given the budget to do so, I would have replaced that dinosaur by this point, but that isn't an option today. I am not the system's original author, but am attempting to provide ongoing support.
To distribute this to their customers, they bought the Office 97 Developer Edition Tools, and once every few years they go through its Setup Wizard to package a new distribution.
This time, the Setup Wizard appears to reach a point where it wants to do something with AXDIST.EXE, and instead puts up a dialog box saying only "Path not found". The only reference I've located on the web is a tantalizing glimpse of a page from a domain that no longer exists, where Google has purged the cache retaining only the sentence that appears with the search result. It isn't enough of a hint to help me...
(Edit: Aside from lots of reported issues caused by AXDIST.EXE itself, or installations that are trying to use AXDIST.EXE in some way, that is. Our issue is a problem during the creation of a setup package using the ODE setup wizard. Its own documentation only references AXDIST in one place, and does not contain the text "path not found" at all.)
(Edit 2: Further investigation reveals that AXDIST.EXE itself is not the culprit. Removing that file from the setup wizard's list caused the wizard to stop on the next file in the list. There does not appear to be any significant differences between the description of the file on which it stopped, and the dozen or so files listed above it that were successfully processed. I'm guessing at this point that the resolution is going to be manually recreating the template from scratch, which would be a lot easier if it weren't trapped inside a horrible UI and stored in the form of an Access database containing a bunch of undocumented tables.)
My question is this: What mistake did we make this time with the setup wizard, and how can we fix it?
The issue turned out to be related to a feature of the Access run time that was explicitly listed in the setup wizard, but should have been left for the wizard to infer.
My general advice to anyone also stuck with dealing with the wizard would be to go back to the start and review all the settings carefully and methodically.