In my case, I was using PowerShell to create a bunch of links to folders on a file-share in a SharePoint list. I came across errors when I used the 2010 method in 2013. Below I have provided examples of each method:
$urlValue = New-Object Microsoft.SharePoint.SPFieldUrlValue("")
$urlValue.Description = "This is an awesome description"
$urlValue.Url = "http://MyUrl.com"
$item["URL"] = $urlValue
$newItem = $list.Items.Add()
$newItem["URL"] = "$urlString , $descriptionString"
$newItem["Comments"] = $descriptionString
After creating a SharePoint 2013 Wiki library, the quick launch navigation under Updated Pages reports “an error has occurred on the server.” When you click on the Updated Pages link it displays the error: Invalid index. (Exception from HRESULT: 0x80070585).
This error occurs when there is no index column in your Wiki list. To fix it, add a column for indexing:
Library Settings -> Index Columns: Create a new Index on the ‘Modified’ column.
There you have it. The problem should now be solved.
I was seeing this error when trying to check in a document after completing the required metadata in Word (via DIP). I found this post claiming the issue was due to the content type of the document containing a managed metadata field. Although that sounded far fetched, I ended up following the workaround instructions and adding a new managed metadata field directly to my library (Test with one term- test). I then deleted the field, and suddenly I could check my document in! Weird.
I also saw this error when I used the Specify default content feature of Document Sets – automatically creating a number of documents from templates, within a new set. I could not complete the metadata and check those documents in. When I turned off check in/out on the library, I could no longer get to the DIP properties in Word. The only way to set the document metadata was to use the edit form in SharePoint. I never got around this issue. If anyone has an ideas, please let me know.
There are a few circumstances under which you may come across this error :
We’re having a problem opening this location in File Explorer. Add this web site to your Trusted Sites list and try again
Here I will provide a solution for one of those – You are trying to open a SharePoint document library in explorer view while on the SharePoint server.
There is an excellent post here that provides a detailed description of the problem and solution, but to summarise, you need to install the Desktop Experience feature under User Interfaces and Infrastructure on the server.
If you attempt to execute a PowerShell script on the SharePoint server and see : “Script cannot loaded. The file is not digitally signed. The script will not be executed on the system” or “… the execution of the script is disabled on the system…”
It means you either need to :
Sign the script OR
Set the PowerShell execution policy to allow you to execute unsigned scripts, e.g.
powershell.exe -executionpolicy bypass -file C:\script.ps1
If you want to make changes to a PowerShell script but you are always prompted to save as a new version, the file may be locked. Right click the script file and select Properties. Ensure the Read-Only checkbox is unchecked. If there is a Unblock button next to the Read Only property, click Unblock.
When using Visual Studio to package and deploy an event receiver to be associated with SharePoint list, you may come across this error:
Error occurred in deployment step ‘Activate Features’: <nativehr>0x80070002</nativehr>
This probably means that your List URL is incorrect in the receiver elements file. The format needs to be :
You may also see a Invalid Function error when you try to activate the feature manually in your site. Double check the URL of your list and ensure the list either exists or is being created at this URL prior to the receiver activation.
After migrating a SharePoint site to a new collection; which utilised a globally reusable SPD workflow, I of course expected that the workflow would not be available to the migrated sub site until I published an update. What I didn’t expect though was that updating the workflow would break it everywhere.
First of all I tried updating the workflow settings on the content type (in this case Document) to cascade the workflow settings down to all child content types (including those in the migrated sub site). This got me one step closer to my goal as the workflow then appeared associated with documents in the sub site, BUT once I tried to start a workflow, I got a big fat error: User cannot be found.
So next I opened SPD and updated the workflow and republished it (globally). That all worked and so I tested the workflow in the sub site again- User cannot be found.
So next came Google. I found plenty of people reporting the issue and many of those also bagged Microsoft for telling them that it could be fixed by simply re-publishing the workflow. Since I’d already tried that, I sympathised with their frustration.
Finally, with the magic of Google, I found this post which gave me the right answer. I logged in as an SCA and deactivated and then activated the site collection workflow feature and then started a workflow in my sub site.. Success!