I know that Office 365 and SharePoint are all that we seem to talk about today on Twitter and everywhere else.  But I do still work with some clients using SharePoint on-premises and they needed some help recently.  I was finally able to overcome and I want to share my struggle for others to benefit.  I’ve seen examples of doing things like this in server-side code but not PowerShell.

My client required that multiple library web parts (XSLTListView) on the homepage of hundreds of subsites in a single site collection be updated.  Specifically I needed to do a few things:

• Add site columns to a library
• Modify the default view of the library to add the new site columns
• Create a new view
• Modify the left-side quick launch navigation to add a link to the new view
• Modify the views of two library XSLTListView web parts to change the visible columns and add a filter

All of this was straight-forward until we got to the last item – modifying those web parts.  I wasn’t sure this was possible when I started looking but I was able to get it done with PowerShell.  Let’s take a look how I did this last requirement.

WHAT YOU NEED TO KNOW

Logic would tell you that to edit the view of those web parts, the settings are in that web part.  You would be wrong.  The view you need to edit is actually stored in the library.  I got a glimpse of this in this blog using a version in server-side code.  Once you understand this, you update the view just like you normally would.  These are the web parts in question:

In the interface, you just edit the page, edit the web part, then edit the view like you are used to.  But how do we do that in PowerShell?  I wrote a function that updates a single web part, and we just call it twice with the different name of the web part on the page. 

Add-PSSnapin microsoft.sharepoint.powershell

$web = get-spweb "http://intranet/subsite"
$lib = $web.lists.TryGetList("Opportunities")

function Update-wpView ($viewnm) {
         $page = $web.GetFile("default.aspx")
         $webpartmanager = $web.GetLimitedWebPartManager($page.Url,[System.Web.UI.WebControls.WebParts.PersonalizationScope]::Shared)
         $webpart = $webpartmanager.WebParts | ?{$_.Title -eq $viewnm}
         $wpview = $lib.Views | ?{$_.ID -eq $webpart.ViewGUID}
         $ViewArray = "DocIcon","LinkFilename","Description","Identifier","Document Type", "Doc Status"
         $wpview.ViewFields.DeleteAll();
         foreach ($col in $viewArray) {
             $wpview.ViewFields.Add($col);
         }
         $query = "<OrderBy><FieldRef Name='Modified' Ascending='FALSE' /></OrderBy><Where><And><Neq><FieldRef Name='DocStatus' /><Value Type='Text'>Archive</Value></Neq><Neq><FieldRef Name='DocIcon' /><Value Type='Computed'>csv</Value></Neq></And></Where>"
         $wpview.Query = $query
         $wpview.update()
}

#Update the web parts
Update-wpView "Recently Updated Opportunities"
Update-wpView "Recently Updated Opportunity Files"

$web.Dispose()

Explanation

First we get a reference to the subsite and library in question.  Then we have our function that does all the work.  We get a reference to the page, then we go through all the web parts on the page to find the one we want to change. 

I highlighted the critically important line in yellow.  What you do is you get the view GUID from the web part, then go to the library and get the actual view matching that GUID.  Once you have that, you update the view like you normally would, here I’m modifying columns and adding 2 filter queries and save.  DO NOT try to edit the View Schema XML in the web part properties, it will not work.

Please reach out to us if you need any help with this script, other PowerShell scripting, or getting your SharePoint governance and adoption back on track!