OneDrive sync client and green locks (read-only sync)


December 7, 2017 - 15:31, by Steven Van de Craen - 0 Comments

The issue

I recently ran into an Office 365 environment where all users were seeing green locks on files and folders synched with the OneDrive For Business client.

OneDrive read-only sync

If this isn’t expected, in cases where the user should definitely have write access to these files you might want to check the following Library Settings:

Require content approval for submitted items?

Go to Library Settings > Versioning:

 Content Approval

If your library has this enabled than OneDrive will only sync in read-only mode. If you disable this setting your sync client should inform you that you now have read-write access and the green lock icon should be gone.

OneDrive read-write message 

If it doesn’t then please read on.

Require documents to be checked out before they can be edited?

Go to Library Settings > Versioning:

Require Check Out

Another feature that’s not compatible with the full OneDrive sync experience. Again as before, you will have to disable this and it should resolve immediately. If not then continue reading…

Required Columns

Go to the Library Settings and check the columns:

Library Columns

Check with the columns on the library, if any of them are “required” this will cause a read-only sync. In the screen this is the case for my ‘Department’ field.

Wait a minute! Does this mean we lose the ability of having required metadata ???

Well, luckily NO. You just have to use a different approach and use Content Types.

The solution

Go to the Library Settings > Advanced Settings:

Allow management of Content Types

 

Content Types are a great way to have different types of content, each with a different set of metadata, workflows, template, and more. You should familiarize yourself with the concept of Site Columns, Site Content Types, List Columns, List Content Types, Content Type Inheritance, etc. It really depends on the use case but in my example I just modified the List-level Column and Content Type, in other cases this may not be the best approach. If you’re looking for more information on Content Types you can easily find this on the web.

 

To make your field required go into the Content Type (you can click on its name) and configure each field as optional, required or hidden.

List Content Type Information

 

The result is that the field/column itself is not configured as Required, but it is configured Required for the Content Type. And when uploading documents of that Content Type the user will still have to provide a value for the field.

Edit Item

 

Almost there…

If you followed the above steps you’ll still be having the original issue. This is because in the background the field will still be “Required”. And if you have Content Types enabled you won’t be able to change this setting because the UI hides it from the List Column Settings!

Here are a few options to resolve this situation:

  1. If you are using Site Columns then you can change the “Require” setting and push the change down to lists and libraries. This is quite easy to do but will impact all lists and libraries where this is used. You’ll have to inspect those lists to see if they have Content Types enabled (and that the Content Type requires the field) or users will no longer have to specify a value (= functionality change)
  2. You can disable Content Types on the Library, change the List Column setting and re-enable Content Types. This is also easy to do from the UI. All Content Types will be preserved during the operation but some users might be impacted during the operation. Afterwards, verify per Content Type which fields should be required.
  3. Use CSOM or PowerShell to directly manipulate the List Column settings.

 

Options (2) and (3) are rather similar, but if you prefer the latter here’s a PnP PowerShell script that should assist you. I like PowerShell because it is transparant and can easily be viewed and modified. And I like PnP and its CmdLets because it really abstracts complex operations. Note that you will have to install the PnP CmdLets first.

https://msdn.microsoft.com/en-us/pnp_powershell/pnp-powershell-overview

Script:

cls ## Variables $userName = "yourusername" $siteUrl = "yoursiteurl" $listName = "yourlistname" ## Script start if (!$cred) { $cred = Get-Credential $userName } Connect-PnPOnline –Url $siteUrl -Credential $cred ### $web = Get-PnPWeb $list = Get-PnPList $listName ### QUERY OR CHANGE $bChangeField = $false Get-PnPField -List $list | % { $f = $_ # List all required fields, except the built-in FileLeafRef field which is required but by design if ($f.Required -and $f.StaticName -ne 'FileLeafRef') { Write-Host ($f.StaticName) -ForegroundColor Red if ($bChangeField) { Set-PnPField -Identity $f -Values @{Required=$false} Write-Host (" -> updated") -ForegroundColor DarkYellow } else { Write-Host (" -> reporting only") -ForegroundColor DarkYellow } } }

The script has a flag to control the actual field update vs reporting only.

After running (with actual update) it should resolve the issue.

OneDrive read-write sync

if it doesn’t I’d be interested to hear about it in the comments!

Wrap-up

Some list settings are not compatible with the OneDrive sync experience and make it a read-only sync. You can disable these via the UI or via code/script.


Windows 10 Creators Update: Slow wireless connection


May 8, 2017 - 11:07, by Steven Van de Craen - 0 Comments

A quick blog for archiving purposes. Since my upgrade to Windows 10 Creators Update last week I had been experiencing very slow wireless performance at work. At home or while tethering everything was as normal.

For me the solution as to disable “Receive Segment Coalescing” (RSC), described as ‘workaround #1’ in this post:

https://answers.microsoft.com/en-us/windows/forum/windows_10-networking/wifi-issues-with-creators-update/4a20ba4f-33dc-4397-9823-e12dcb2607ba

Disable Rsc

Steps:

  • Run an elevated PowerShell prompt
  • Get-NetAdapterRsc to show the status per adapter
  • Disable-NetAdapterRsc –Name "your_wifi_adapter_name" to disable

Immediate fix for me!

Thanks Tripp Parks [MSFT] for the workaround!


TaxonomyService GetTermSets Failed to compare two elements in the array


December 23, 2016 - 16:36, by Steven Van de Craen - 0 Comments

This issue happed on a SharePoint 2013 environment that got upgraded from SharePoint 2010 and the farm includes Language Packs (Dutch in our case). When navigating to the Term Store Management Tool it is impossible to expand the Term Group “Search Dictionaries” for the non-English language. This system group is created for the Search Service Application and contains dictionaries for Company Inclusions, Company Exclusions, Query Spelling Inclusions and Query Spelling Exclusions, but the Term Sets are only provisioned for LCID 1033 (English) and that’s causing the issue.

Search Dictionaries Term Group

 

When Dutch is selected we get ‘Deze bewerking kan niet worden voltooid. Het termenarchief is mogelijk niet beschikbaar’.

Message from webpage – Deze bewerking kan niet worden voltooid. Het termenarchief is mogelijk niet beschikbaar

Failed to compare two elements in the array. 
at System.Collections.Generic.ArraySortHelper`1.Sort(T[] keys, Int32 index, Int32 length, IComparer`1 comparer)   
at System.Collections.Generic.List`1.Sort(Int32 index, Int32 count, IComparer`1 comparer)   
at Microsoft.SharePoint.Taxonomy.TermSetCollection.CreateTermSetCollection(List`1 sharedTermSets, TermStore termStore)   
at Microsoft.SharePoint.Taxonomy.WebServices.TaxonomyInternalService.GetTermSets(Guid sspId, Guid guid, Boolean includeNoneTaggableTermset, Guid webId, Guid listId, Int32 lcid)

Related: http://sharepoint-community.net/profiles/blogs/upgrade-sharepoint-2010-to-2013-metadata-service-application

 

There seems to be no easy way to rename or add a localized name for a system Term Set, but we can make use of reflection and call Microsoft.SharePoint.Taxonomy.TermSet.SetName(string value, int lcid)

In a PowerShell script that might look like this:

asnp Microsoft.SharePoint.PowerShell -ea 0 | Out-Null cls # Functions function Get-InstanceFieldNonPublic($obj, $name) { $t = $obj.GetType() $result = $t.InvokeMember($name, 'GetField, Instance, NonPublic', $null, $obj, $null) return $result } function Invoke-InstanceMethodNonPublic($obj, $name, $params) { $t = $obj.GetType() $result = $t.InvokeMember($name, 'InvokeMethod, Instance, NonPublic', $null, $obj, $params) return $result } ### INIT $tSession = Get-SPTaxonomySession -Site "http://intranet" $tStore = $tSession.TermStores[0] $tGroup = $tStore.Groups["Search Dictionaries"] $tGroup.TermSets | % { $tSet = $_ # 'Add' another language label for TermSet -- 1043 is Dutch Invoke-InstanceMethodNonPublic -obj $tSet -name "SetName" -params @($tSet.Name, 1043) # Query known language labels for TermSet Get-InstanceFieldNonPublic -obj $tSet -name "names" } # Commit changnes -- uncomment to apply # $tStore.CommitAll()

As always; be careful with reflection as it is not supported and allows you to harm your environment beyond repair. That said it did nicely resolve the issue.


SharePoint 2013: InfoPath client forms may open twice [Oct15CU bug]


December 16, 2015 - 20:47, by Steven Van de Craen - 2 Comments

Oops

After a recent Patch Night one of my customers had pulled in SharePoint updates along with Windows Updates and people started complaining about changed behavior

  1. PDF files no longer immediately open in the browser. Instead the PDF client (Adobe Reader) opens up and provides rich integration with options to check-out and such
  2. InfoPath client forms would open twice; meaning the form opens when clicking the link, but also an extra dialog appears to open the form. Users click this and receive messages about the form already being locked (by themselves!)

Hello little bug

We traced it to core.js (and core.debug.js) having a modified date of “15/09/2015 14:45” where functionality to provide “Acrobat Pro X integration” was introduced.

The function OpenDocWithClient is called in two different locations but the return value is ignored. This makes the page refresh that occurs when clicking the InfoPath form link execute more than desired.

Here’s the original (bugged) and modified (fixed by me) versions:

Original (bugged) core.js image

As you can see I added the “return” keyword for the function call, so the event cancelling can continue to bubble up.

For the minified version (core.js) you’ll have to do some digging but if you look for static strings you can find the function call. I think it was “m()” in my case.

Here ya go

You can download this archive which contains both my original and modified versions. If you modify your environment you have to update all web front ends and users will have to clear the browser cache, but no iisreset is required.

Note that later patches may overwrite the system files again and undo your manual changes.

End credits

This bug is introduced with the October 2015 updates, including the full Cumulative Update package. We escalated the case to Microsoft and they confirmed the issue and our workaround. It will probably remain present in the upcoming Cumulative Updates (November, December, …) because it’s not wide-spread and also the PG needs to fit it in into their schedule.


SharePoint: Portal navigation limited to 50 dynamic items


August 12, 2015 - 11:07, by Steven Van de Craen - 0 Comments

I was looking into an issue where the Navigation Settings page wouldn’t show all subsites in the treeview. When reproducing it was limited to 50 dynamic items.

Navigation Settings

The treeview component is a Microsoft.SharePoint.Publishing.Internal.WebControls.HierarchicalListBox which connects to the active Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider. This has a property “DynamicChildLimit” that can be explicitly configured in the web.config.

// Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider public int DynamicChildLimit { get { int? num = this.dynamicChildLimit; if (num.HasValue) { return num.GetValueOrDefault(); } if (this.Version < 14) { return 50; } return 0; } set { this.dynamicChildLimit = new int?(value); } }

The active provider used is “GlobalNavSiteMapProvider”, defined in web.config as

<add name="GlobalNavSiteMapProvider" description="CMS provider for Global navigation" type="Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider, Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" NavigationType="Global" EncodeOutput="true" />

I tried specifying Version=”14” but then it defaulted to 20 items, a path I didn’t further investigate. So I just explicitly specified the DynamicChildLimit=”100” and that fixed the issue.

<add name="GlobalNavSiteMapProvider" description="CMS provider for Global navigation" type="Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider, Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" NavigationType="Global" EncodeOutput="true" DynamicChildLimit="100" />


SharePoint: Users cannot create new subsites


July 13, 2015 - 17:02, by Steven Van de Craen - 0 Comments

Issue

First day after my vacation and I got presented with a nice situation at one of our clients. Most users trying to create new subsites would get “Sorry, this site hasn’t been shared with you” and the site would NOT get created. Troubleshooting this showed that during site provisioning the “SiteFeed” Feature would throw an exception which would roll back the site creation. The relevant lines in the ULS logs pointed towards the “Following” (Social) of the newly created site:

FollowedContent.FollowItem:Exception:Microsoft.Office.Server.UserProfiles.FollowedContentException: ItemDoesNotExist : Item does not exist.     at Microsoft.Office.Server.UserProfiles.SPS2SAppUtility.GetPersonalUrl(UserProfile& profile)     at Microsoft.Office.Server.UserProfiles.SPS2SAppExecutionContext.InitializeForProfile()     at Microsoft.Office.Server.UserProfiles.SPS2SAppExecutionContext.EnsureInitialized()     at Microsoft.Office.Server.UserProfiles.FollowedContent.FollowItem(FollowedItem item, Boolean isInternal)

Could not follow the url https://sharepoint/newsub

Leaving Monitored Scope (Event Receiver (Microsoft.Office.Server.UserProfiles, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, Microsoft.Office.Server.UserProfiles.ContentFollowingWebEventReceiver)).

 

The newly created site could not be added to the user’s Social list on his MySite due to an Access Denied on adding the item to the list.

Cause

The MySites were recently migrated from SharePoint 2010 (classic mode) to SharePoint 2013 (claims mode). MySites work by setting the ‘owner’ as Primary Site Collection Administrator, but the conversion to claims had erased all the classic-mode Site Collection Administrators from the migrated site collections. Querying for the Site Collection Administrators would just return empty which is of course not good.

(Blank) Site Collection Administrators

Solution

I whipped up a PowerShell script that would loop all MySites and report any sites with missing or non-matching Site Collection Administrator. Toggling the ‘report only’ flag in the script will correct the situation.

asnp Microsoft.SharePoint.PowerShell -ea 0 | Out-Null cls $reportOnly = $false Write-Host "ReportOnly:" $reportOnly $mySites = Get-SPSite -Limit ALL | ? { $_.RootWeb.WebTemplate -eq "SPSPERS" } Write-Host "Found" ($mySites.Count) "MySites" $mySites | % { $s = $_ $w = $s.RootWeb $owner = $w.EnsureUser($w.Title) $primaryAdmin = $w.SiteAdministrators | Select -First 1 if ($primaryAdmin -eq $null) { Write-Host -ForegroundColor Red ($s.ServerRelativeUrl) ": no primary SC admin. Owner should be" $owner if ($reportOnly -eq $false) { $owner.IsSiteAdmin = $true $owner.Update() } } elseif ($owner.IsSiteAdmin -eq $false) { Write-Host -ForegroundColor Yellow ($s.ServerRelativeUrl) ": primary SC admin (" $primaryAdmin ") does NOT match owner (" $owner ")" if ($reportOnly -eq $false) { $owner.IsSiteAdmin = $true $owner.Update() } } else { Write-Host -ForegroundColor Green ($s.ServerRelativeUrl) ": primary SC admin (" $primaryAdmin ") matches owner (" $owner ")" } $s.Close() }

After correcting all sites should turn up green.

 All MySites corrected

HTH


SharePoint 2013: Enable 'Change Item Order' Ribbon Action


June 4, 2015 - 17:00, by Steven Van de Craen - 0 Comments

My customer reported an issue where a ‘Links’ List didn’t have the option ‘Change Item Order’ enabled. This was for a list created in SharePoint 2007 and migrated to SharePoint 2013.

When creating a new Links List in SharePoint 2013 it would have this enabled, so it wasn’t related to Site or Site Collection Features. Creating new views in the migrated list showed the same ‘issue’.

image 

With PowerShell it quickly becomes obvious that the View didn’t have the ‘Orderable’ flag set. It is not possible to change this through SPView.OrderedView because it is read-only, however you can set this ‘property’ on the XsltListViewWebPart that’s on the View Form as follows:

asnp Microsoft.SharePoint.PowerShell -ea 0 | Out-Null cls # Get the View page $w = get-spweb http://sharepoint/site/site $f = $w.GetFile("http://sharepoint/site/site/Lists/Links/AllItems.aspx") Write-Host "STARTING" $f.ServerRelativeUrl if ($f.Exists) { $man = $f.GetLimitedWebPartManager('Shared') $wp = $man.WebParts | ? { $_ -is [Microsoft.SharePoint.WebPartPages.XsltListViewWebPart] } | Select -First 1 if ($wp -ne $null) { # Make the view 'Ordered' by expanding the ViewFlags enum $wp.ViewFlags = [Microsoft.SharePoint.SPViewFlags]($wp.ViewFlags.ToString() + ', Ordered') $man.SaveChanges($wp) } else { Write-Host "Web Part not found on page" } $man.Dispose() } else { Write-Host "Page not found" } Write-Host "DONE"

Afterwards users will be able to set the order of the items…

image 

When you create new Views either base them on an existing (‘fixed’ View) or run the above script on them to enable the functionality.


Moving site collections from explicit managed path to wildcard managed path


March 14, 2015 - 07:41, by Steven Van de Craen - 1 Comments

At my current project where we’re upgrading from SharePoint 2007 to SharePoint 2013 we’re running into a high number of managed paths on a Web Application. The recommended limit according to TechNet is 20 but they’re well above that with around 70 managed paths. An internal study showed that a lot of them were Explicit Managed Paths where there was no real requirement to have it that way and they could easily be transformed into a (single) Wildcard Managed Path.

Explicit Managed Path Wildcard Managed Path
/customers/a
/customers/b
/customers/c
/customers
/departments/a
/departments/b
/departments/c
/departments

 

It turns out that it is a rather painless operation to do:

  1. Unmount the Content Database with the Site Collection on the Explicit Managed Path
  2. Delete the Explicit Managed Path (ensure that a corresponding Wildcard Managed Path exists)
  3. Mount the Content Database with the Site Collection and it will make use of the Wildcard Managed Path

With this in mind the following PowerShell script automated this. It doesn’t ensure the Wildcard Managed Path since I wanted to control if the Explicit Managed Path should be transformed or not. In this case it will log a warning and skip that one.

### Script will loop explicit managed paths and restructure so the site collections are inside a wildcard managed path in order to reduce # (explicit) managed paths cls asnp Microsoft.SharePoint.PowerShell -ea 0 | Out-Null $logFile = "C:\temp\managedpath_restructure.txt" $trial = $false $waUrl = "http://intranet" $emps = Get-SPManagedPath -WebApplication $waUrl | ? { ($_.Type -eq "ExplicitInclusion") -and ($_.Name -like "*/*") } $emps | % { $emp = $_ $wmpName = $emp.Name.Split("/")[0] $wmp = Get-SPManagedPath -WebApplication $waUrl | ? { ($_.Type -eq "WildcardInclusion") -and ($_.Name -eq $wmpName) } if ($wmp -eq $null) { # SKIP $log = [string]::Format("{0} - {1} - No wildcard MP '{2}'. Skipping.", (Get-Date), $emp.Name, $wmpName) Write-Host -ForegroundColor Yellow $log $log >> $logFile } else { # RESTRUCTURE $log = [string]::Format("{0} - {1} - Restructuring explict MP to wildcard MP '{2}'.", (Get-Date), $emp.Name, $wmpName) Write-Host -ForegroundColor Green $log $log >> $logFile # Get matching sites' content database $cdbs = @() Get-SPWebApplication $waUrl | Get-SPSite -Limit ALL | ? { $_.Url -like ("*/" + $emp.Name) } | % { $s = $_ $cdb = $s.ContentDatabase if (-not($cdbs.Contains($cdb))) { $cdbs += $cdb } $s.Close() } # Dismount content databases $cdbs | % { $cdb = $_ $log = [string]::Format("{0} - {1} - Dismounting content database '{2}'.", (Get-Date), $emp.Name, ($cdb.Name + " @ " + $cdb.Server)) Write-Host -ForegroundColor Green $log $log >> $logFile if (-not($trial)) { Dismount-SPContentDatabase $cdb -Confirm:0 } } # Remove explicit managed patch $log = [string]::Format("{0} - {1} - Removing explict MP.", (Get-Date), $emp.Name, $wmpName) Write-Host -ForegroundColor Green $log $log >> $logFile if (-not($trial)) { Remove-SPManagedPath $emp -WebApplication $waUrl -Confirm:0 } # Mount content databases $log = [string]::Format("{0} - {1} - Mounting content database '{2}'.", (Get-Date), $emp.Name, ($cdb.Name + ' @ ' + $cdb.Server)) Write-Host -ForegroundColor Green $log $log >> $logFile if (-not($trial)) { $db = Mount-SPContentDatabase ($cdb.Name) -DatabaseServer ($cdb.Server) -WebApplication $waUrl -Confirm:0 } } } Write-Host "DONE"

Cheers


SharePoint Publishing Feature activation failed


December 16, 2014 - 15:19, by Steven Van de Craen - 0 Comments

Last week I ran into an issue while reactivating the Publishing Feature on webs in a migrated (Dutch) site collection. If you have ever upgraded localized SharePoint 2007 Publishing sites this should sound familiar to you. What happens is that while in SharePoint 2007 the Pages library was called “Pages”, since SharePoint 2010 this is also localized to “Paginas” (Dutch), “Zeiten” (German), etc.

There’s an override property “__PagesListName” that is checked by SharePoint to get the correct list name in case it differs from what’s expected. And in case of data migrations it will be different (“Pages”) than expected (“Paginas”).

Microsoft has published a KB article (http://support.microsoft.com/kb/2484317) on it with a PowerShell script to set the override property. This fixes most issues with navigation not displaying correctly, but it seems that at least in SharePoint 2013 this still gives problems with Publishing Feature reactivation.

Publishing Feature activation failed. Exception: System.IO.FileNotFoundException: <nativehr>0x80070002</nativehr><nativestack>OWSSVR.DLL: (unresolved symbol, module offset=0000000000052B3E)

at 0x000007FF151F2B3E OWSSVR.DLL: (unresolved symbol, module offset=00000000000112BD)

at 0x000007FF151B12BD Microsoft.SharePoint.Library.ni.dll: (unresolved symbol, module offset=00000000000A3DA9)

at 0x000007FF15C33DA9 </nativestack>

at Microsoft.SharePoint.Library.SPRequestInternalClass.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder)

at Microsoft.SharePoint.Library.SPRequest.GetMetadataForUrl(String bstrUrl, Int32 METADATAFLAGS, Guid& pgListId, Int32& plItemId, Int32& plType, Object& pvarFileOrFolder)

at Microsoft.SharePoint.SPWeb.GetList(String strUrl)

at Microsoft.SharePoint.Publishing.Internal.Store.GetListByUrl(SPWeb web, String listUrlName)

at Microsoft.SharePoint.Publishing.Internal.AreaProvisioner.Provision()

at Microsoft.SharePoint.Publishing.PublishingFeatureHandler.<>c__DisplayClass3.<FeatureActivated>b__0()

at Microsoft.Office.Server.Utilities.CultureUtility.RunWithCultureScope(CodeToRunWithCultureScope code)

at Microsoft.SharePoint.Publishing.PublishingFeatureHandler.FeatureActivated(SPFeatureReceiverProperties receiverProperties).

The AreaProvisioner.Provision() uses a private field pagesListUrl which seems to be initialized to Microsoft.Office.Server.Utilities.PageUtility.DefaultPagesListName, which in turn reads its information from the localized “osrvcore“ resource value (C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\Resources)

image

image

Solution

I’ve experienced this issue in SharePoint 2013 with Service Pack 1 (15.0.4569.1000) but also November 2014 Cumulative Update (15.0.4667.1000). It may be fixed with any later CU but don’t hope on it.

One workaround would be to temporarily(!) change the value of List_Pages_UrlName in osrvcore.nl-NL.resx to “Pages”, (re)start the process that’s doing the Feature reactivation (powershell or IIS worker process), reactivate the Feature and retrace your steps as to undo the change (don’t forget the process restart). This will allow you to reactivate the Publishing Feature on those Dutch/localized migrated Publishing sites.

HTH


Importing a Summary Links Web Part: List does not exist


October 23, 2014 - 15:23, by Steven Van de Craen - 2 Comments

Issue

Consider the scenario where you have a Summary Links Web Part (part of the SharePoint Publishing functionality) configured on a page and you want to import the preconfigured Web Part on a different page on a different site. If you try this you’ll get “List does not exist”:

image

Note that importing the Web Part in the same site (same or different pages) works just fine.

Cause

This is because the Summary Links Web Part references the list that contains the page where the Web Part resides on. If you open the .webpart file in a text editor you’ll see ListName and ListId containing the GUID of that list. So it can be the “Site Pages” library, the “Pages” library, or any Document Library that has Web Part Pages.

image

You can verify this by navigating to the following URL (note to replace the actual GUID): http://sitename/_layouts/listedit.aspx?List=GUID

Bonus question: what is the value when the Summary Links Web Part is on the “default.aspx” of a site? Answer:

image

Solution

So what’s the solution? Just remove the ListName and ListId elements (or their values) from the exported .webpart file and you’ll have no issues importing it to other sites.

HTH


 Next >>