Needed to audit a farm to see if a CodePlex solution was being used in SharePoint Designer workflows. In my case, I needed to see where the iLove SharePoint solution was being used. The script below is only targeted at one web and is looking for word “ILoveSharePoint” in the XML.
You are using the Document ID Service in SharePoint and you want to move your documents to another location. For whatever reason, you notice when you move the documents that your document id’s are lost or reset. This can be real bad if other systems outside of SharePoint leverage the document id to locate documents in SharePoint.
Here are the steps I used to get around this.
Move the documents from location A to B, keeping the original documents in A.
Run a crawl.
Execute the script below (input your own values for the site and libraries).
Remove / delete the documents from location A. For safe measures, also empty the recycle bin, both at the site and site collection level.
Run another crawl.
Trigger the Document Id Settings to update.
What the script is doing:
Get all the documents in the Shared Documents library of site A.
Loop through the documents.
Locate the document by name in the Shared Documents library of site B.
Update the Document ID of the item.
Things you could improve on:
Get all the documents in site A and output the Name and Document ID to a csv file.
– Then process the csv file with the script.
– Output your pass / fail items to csv file.
Expand the search to query a site.
– Then update the returned item.
Recently had the need to find and update most every InfoPath form in a production farm. This, mixed with the future demise of InfoPath, prompted the need to find or write a script. The below script will traverse every list and library in a given web app. The script can be easily modified to include every web app in a farm.
In the script, you will notice that I’m trying to capture the title of the item. The above script wasn’t working because I failed work with this list item, instead I was trying to work with the list object.
You installed SharePoint, then your power users enabled the content organizer feature all over your farm. This isn’t necessarily a bad thing, but if it’s not being used, turn it off! Less load on the farm, the better off you will be.
You will find plenty of examples on the web about cleaning up this mess, but I took a slightly different approach. Before disabling the feature and deleting the library, I first checked to make sure the library was empty and no content org rules had been created.
$web = Get-SPWeb "http://webapp.sharepointed.com"
$feature = Get-SPFeature "7ad5272a-2694-4349-953e-ea5ef290e97c"
$corList = $web.lists["Content Organizer Rules"]
$dolList = $web.lists["Drop Off Library"]
#check for Cont Org Rules and items in Drop Off Library
if(($corList.ItemCount -eq 0) -and ($dolList.ItemCount -eq 0))
#disable the feature
Disable-SPFeature -Identity "7ad5272a-2694-4349-953e-ea5ef290e97c" -Url $_.URL -Confirm:$false
#remove the Drop Off Library
$dolList.AllowDeletion = $true
Recently had a scenario where I needed to move a bunch of libraries from different sites, to another farm. Every library was titled the same, so when I went to import the libraries, I ran into a small issue. Using a combo of Export-SPweb and Import-SPweb, I moved a library over, then updated the library url and name to the source site name.
#Change the URL of the library
$web = Get-SPWeb $webURL
#Update the library name
$web = Get-SPWeb $webURL
$list = $web.Lists[$after]
$list.Title = $after
You might be able to shorten the script to rename and update in a couple lines of code.
If you use the script to change the URL of a list, the list will moved to the root of the site. it will no longer live at site/lists.
*I have not tested this with libraries or list that workflows associated with them. It’s also safe to assume any links to documents would be broken.*
One or more field types are not installed properly. Go to the list settings page to delete these fields.
After much research, I have found that this error can be the result of a couple things.
1. Programmatically create a site column / content type and the process fails. The result is a broken column that you have to hunt down and remove from the content database.
2. Using a combination of Export-SP and Import-SPweb, an imported list or library will display the error.
In my case, #2 needed to be fixed. Basically, I had a lookup column that had become orphaned from its parent list.
When you look at the field settings (Library/List Settings –> click on your lookup column) you will see that the Get information from: property is empty.
So how do you reconnect or refresh the lookup field property?
Using PowerShell, the fields web ID and source list ID schemaXML need to be populated.
What’s going on here?
Load the SharePoint snapin.
Get site that holds the broken list / library.
Get broken list / library.
Get source list / library that the broken lookup references.
Get broken field.
Update the broken field schemaXML.