Identifying Problem Publishing Image Libraries

The problem:

In one of my previous posts (http://kiwiboris.blogspot.com/2013/08/migrating-publishing-images-libraries.html) I talked about publishing images libraries and how the images from these libraries might need to be re-migrated and the specific steps needed to create such libraries and perform the migration. It is nice, however, to identify all such problem libraries in every site collection on the farm. Usually, when these libraries are not migrated correctly, one of the symptoms is that each image is checked out by the farm admin (the reason is that since the metadata for these images is faulty they cannot be checked in.)

The solution:

First of all, it is useful to remember that the base template for the publishing images library is 851 (fa propos, it is 850 for the publishing pages library.) Also, we are only interested in the libraries that have at least one item, each of them checked out. The following script will do the job:

cls

$w = Get-SPSite "https://main.coolsite.myserver.com"
$wa = $w.WebApplication

$wa.Sites | % {
   $_.AllWebs | % {
    $_.Lists | Where-Object { $_.BaseTemplate -eq 851 -and $_.Items.Count -gt 0} | % {
       $itemsCheckedOutCount = $_.Items | Where-Object { $_.File.CheckOutType -ne "None" } | Measure-Object
       if ($itemsCheckedOutCount.Count -eq $_.Items.Count)
       {
            Write-Host "All the images in the document library" $_.Title "in site" $_.ParentWeb.URL "are checked out"
       }
    }
   }
}

$w.Dispose()

Unknown Feature in Site Template

The problem

You are trying to create a site according to some site template, and then you're getting this error:



You have no idea what feature is mentioned, and you want to activate it ASAP.


The solution

This script will work:

$a = (Get-SPFeature | Where-Object { $_.ID -eq "e978b1a6-8de7-49d0-8600-09a250354e14" })
Enable-SPFeature -identity $a.Id -url https://main.yourserver.com/sites/yoursite

Migrating Publishing Images Libraries

The problem:

A team site was migrated from SharePoint 2007 to SharePoint 2010 using the Metalogix Content Matrix tool. After the migration, one of the users discovered that every image in the Images library is checked out by the farm administrator and not visible.

Attempting to remigrate the problem libraries resulted in an error, "One or more field types are not installed properly. Go to the list settings page to delete these fields."

The solution:

First of all, let's clarify what the Images library is. It is NOT a picture library; rather, it is a document library that is created by the Publishing site feature when this feature is activated. Also, it is usually not a good idea to use the Images library for storing your own images - see this link, http://social.technet.microsoft.com/Forums/sharepoint/en-US/7713e6b9-bf0e-418f-a857-960890839d81/what-is-the-difference-between-a-sharepoint-publishing-images-folder-and-a-picture-library .

Second, this library (just like other libraries created by the Publishing feature, such as Pages) supports item scheduling. If the versioning settings are configured so that both major and minor versions are created, and the submitted items require content approval, you can enable scheduling for the library by going to the "Manage Item Scheduling" link of the list settings and checking the "Enable scheduling of items in this list" checkbox. This adds two new columns to the library, "Scheduling Start Date" and "Scheduling End Date," of the types "Publishing Schedule Start Date" and "Publishing Schedule End Date," respectively.

The problem is that when you migrate such a library using the Metalogix Content Matrix tool, the scheduling of the library does not seem to migrate correctly. Therefore, in the SharePoint 2010 environment we need to carry out some additional steps. Here is what worked for us:

1) If the Publishing feature is not enabled on the SharePoint 2010 environment, delete the Images library.
2) Activate the Publishing feature. This will re-create the Images library. Note that this library is much richer in SharePoint 2010 than in SharePoint 2007, as it supports content types such as Audio and Video.
3) In the new Images library, make sure that the versioning settings are configured correctly (i.e., both major and minor versions are created, and all submitted items require content approval.)
4) Enable item scheduling for the Images library.
5) Re-migrate the images from the SharePoint 2007 Images library to the SharePoint 2010 Images library. Make sure you only migrate the items, not the list itself.

Migrating a Multiterabyte Site Collection

The problem

A certain site collection grew too large (8TB, while the Microsoft-recommended limit is 100 GB), and it needs to be migrated to a SharePoint 2010 environment and split into many smaller site collections.

The solution

In this presentation, I show the approach my company (Exostar) took to solve this problem. The main idea is to use a third-party product (we recommend Metalogix) and to write automated scripts to be run in parallel.

Migration and Task Forms

The problem

We migrated a SharePoint 2007 site collection to SharePoint 2010, using the database attach method. This site collection contains a custom workflow with multiple task forms. After the migration, we found that one of the fields in the completed task forms is blank, even though it was a mandatory field that was indeed completed before the migration.

The solution

First of all, we needed to make sure that the data was there. The completed task form data is stored in the task's ExtendedProperty. So, we ran this script and made sure that the correct attribute was there:

cls

$w = Get-SPWeb "https://main.myveryownsite.com/sites/somesite"

$tasks = $w.Lists["Tasks"]

$iscs  = $tasks.Items | Where-Object { $_.Title -eq "Some task on Some List Item."}

$iscs | % {

Write-Host " "

$_.Title

$_["ExtendedProperties"]

}

After we found that the data was stored correctly, the next task was to make sure that the InfoPath form was displaying this field correctly. Unfortunately, the InfoPath 2010 form had some problems with this field and would not display its value, even though the task's ItemMetadata.xml was perfectly correct.

The solution involved renaming the field in the InfoPath form, and then changing the migrated data so that the field is mentioned by its new name. Here is the PowerShell script that does the trick.

cls

$site = Get-SPSite "https://main.myveryownsite.com/sites/somesite"

$webs = $site.AllWebs | Where-Object { $_.IsRootWeb -ne $true -and $_.WebTemplate.StartsWith("STS")} 

foreach ($web in $webs)
{
    $web.AllowUnsafeUpdates = $true

    Write-Host "Processing " $web.Url ", web template:" $web.WebTemplate
   
    $web.Lists | Where-Object { $_.BaseTemplate -eq [Microsoft.SharePoint.SPListTemplateType]::Tasks -and $_.Fields.ContainsField("ExtendedProperties") }  | % {
        Write-Host "  Task list" $_.Title " in web " $_.ParentWebUrl " contains ExtendedProperties - investigating..."
  
        $listItems = $_.Items
  
        $listItems | % {
       
                try
                {
                    $itemEP = $_["ExtendedProperties"]
             
                    if ($itemEP -ne $null -and $itemEP.Contains("ows_AuthoritiesComments"))
                    {
                        if ($_.Title.StartsWith("ISC Chairperson task on"))
                        {
                            $itemEP = $itemEP.Replace("ows_OldFieldName", "ows_NewFieldName");
                                                                                      
                            $_["ExtendedProperties"] = $itemEP
                  
                            Write-Host "      Trying to update " $_.Title " extended properties"
                            $_.SystemUpdate($false)
                            Write-Host "      Finished updating " $_.Title " extended properties"
                        }
                    }
                }
                catch [Exception] {
                        Write-Error $_.Exception.ToString()
                    }
            }
        }
        $web.AllowUnsafeUpdates = $false
        $web.Dispose()
}

Worked like a charm!

Programmatically Uploading a Large Number of Documents to a Library

The problem:

I need to see how well my document library performs when it has more than 5,000 documents. To do that, I need to generate more than 5,000 documents and upload them to the library. It would be nice to do it automatically.

The solution:

I have a simple Aha.docx file. First, I need to copy it 5,000 times. I chose to do it via PowerShell:

$path = "C:\Users\Administrator.TWS\Documents\TestDocs\Aha.docx"
$i = 1
do  { $newPath = "C:\Users\Administrator.TWS\Documents\TestDocs\" + $i + ".docx"; Copy-Item $path $newPath; $i++ }
while ($i -le 5000)

Now my TestDocs folder has the Aha.docx file plus 5,000 other files, and I need to upload them to the Documents library. Here is the corresponding PowerShell script:

$spWeb = Get-SPWeb -Identity https://main.my.server.com/sites/Boris/TheSiteIAmTesting
$spFolder = $spWeb.GetFolder("Documents")
$spFileCollection = $spFolder.Files
$path = "C:\Users\Administrator.TWS\Documents\TestDocs\Aha.docx"
$file = Get-ChildItem $path
$spFileCollection.Add("Documents/Aha.docx",$file.OpenRead(),$false)
#Now, let's copy 5000 other files
$i = 1
do { $path = "C:\Users\Administrator.TWS\Documents\TestDocs\" + $i + ".docx"; $file = Get-ChildItem $path;  $spFileCollection.Add("Documents/" + $i + ".docx",$file.OpenRead(),$false); $i++; }
while ($i -le 5000)

Now the Documents library contains the Aha.docx document plus 5,000 more documents, from 1.docx to 5000.docx.

SharePoint 2013 Public Beta - First Impressions

So, today I spent about an hour with the public beta of SharePoint 2013. My first impressions:

1) Blue top bar, having the Static word "SharePoint" (IMHO, it is just taking up valuable space!), followed by (on the right side) Newsfeed, SkyDrive, and Sites.
2) The long-running operations now have the "Sorry to keep you waiting." How cute.
3) However, too many errors result in the "Something went wrong" error messages - I wish they were more specific.
4) Borrowed a lot of ideas from NewsGator, such as Community Portal, Community Site, "following" sites, etc. I created a new Community Portal as well as another site collection (with "Team" being the top-level site and a "Community Site" being the only subsite.)
5) Navigation is not as easy as in SP 2010, the UI is a bit hard to follow, no breadcrumb navigation.
6) Icons where there used to be words. Sometimes it is helpful, but in many cases it is rather confusing.
7) Content is not just list, libraries, and sites, it now also has "apps" (a new buzzword from SharePoint 2013 lingo.) Oh, and lists and libraries are "apps," too.
8) Central Administration has not changed that much. Same UI as it was in SharePoint 2010. But when you create a new site, it has a little "Experience" dropdown box where you can choose whether you want the 2013 experience or the 2010 experience.
9) There are three or so more service applications (Machine Translation, Security Token, and App Management.)
10) Visual Studio 2012 now allows Visual WebParts in Sandbox solutions and provides designers for lists and content types, the Microsoft Fakes framework for testing SharePoint code (always a good idea), profiling tools for SharePoint projects, Intellisense for JavaScript, and a new item template for Project Item.