SharePoint 2013: How to move a website

Introduction

This posting documents the typical steps for moving a website, or "web" in Microsoft terminology, to a new location, whether in the same web application or a different web application.  The website here is a subwebsite to an existing website or to the root site collection website.  The focus will be on using PowerShell.  The general steps are: 1) identify the web template of the source website; 2) export the website; 3) create a new blank website at the destination having the same web template; and 4) import the source website over the destination blank website.

Procedure

1. Note down the core URL of the website you want to move.
2. As a farm administrator, log into any SharePoint server of the farm containing the website you want to move.
3. Launch an elevated SharePoint Management Shell.
4. Execute the following commandlets to identify the source website's web template:

   $web=Get-Spweb -Identity "[website core url]"
   $Web.WebTemplate
   $web.WebTemplateId

5. Note down the WebTemplate and the WebTemplateId that are returned. Combine these using the number symbol "#".  For example, if the WebTemplate returned was "STS" and the WebTemplateID returned was "1", combine these as "STS#1".
6. Execute the following commandlet to export the source website, including all versions and its security configurations:

   Export-SPWeb -Identity "[website core url]" -Path "[eg D:\MyExportFolder\MyWebExport.cmp]" -IncludeVersions "All" -IncludeUserSecurity -CompressionSize 1000 -Force

7. If moving to a new farm, log into any SharePoint server on the destination farm, and then copy the export file to this server.  Otherwise remain logged into the current SharePoint server.
8. Execute the following commandlet to create a new website using the same web template that you found earlier:

   New-SPWeb -Identity "[Core URL of the new website]" -Template "[SourceWebTemplate]" -Name "[title of new website]"

9. Now execute this commandlet to import the exported website:

   Import-SPWeb -Identity "[new website URL]" -Path "D:\][pathtoyourfile]\[exportfilename].cmp"

10. You're done.  Note that the only user to this website will be you; and the usual user groups (Visitors, Contributors, etc) have not yet been created.

References

• Microsoft TechNet
• Export-SPWeb
• New-SPWeb

Notes

• The "-CompressionSize 1000" parameter helps ensure that the export will comprise a single file.  The number "1000" is in MB.

SharePoint 2013: This form cannot be opened in a web browser.

Problem

This message appears to be associated with several different problems.  The particular problem discussed here involves experiencing this message when trying to run a 2010 workflow.  This posting captures the steps undertaken to resolve this problem.

Created a new 2010 workflow using SharePoint Designer 2013 (SPD), saved it and published it successfully.  No errors were encountered when performed a "Check for Errors" in SPD.  When then tried to execute the workflow, saw the following message:

After clicking the Close button, then saw this message:

This experience was repeatable.

Troubleshooting

1. Try to repeat problem
1. Found that problem occurred whenever tried to run the workflow.
2. Try workflows in other lists and site collections
1. Found that 2010 workflows created and deployed to lists in other site collections worked fine.  Problem localized to target site collection.
3. Try other accounts
1. Found that problem persisted no matter what account used to create and deploy and run workflow.
4. Check ULS
1. Found several messages ( among 20 associated with problem correlation ID)  indicating potential access or permissions issue: 
1. Cannot open file ".../Workflows/SendStatusUpdate/SendStatusUpdate.xsn".
2. System.Runtime.InteropServices.COMException: Cannot open file "Workflows/SendStatusUpdate/SendStatusUpdate.xsn".,...
3. The XSN is null and its not a cross server issue. Most likely a permission issue
5. Check Workflows document library permissions
1. Found that the Workflows document library had same permissions as website.
2. Found that versioning was enabled.  Disabled this, tried to run workflow again: still got error.
3. Found that two workflow files, the .XOML and .XSN files, were listed in the document library's Manage files which have no checked in version listing, when viewed under different accounts (one standard and another an admin).  Using the other admin account, took control over the files in the hope that the other admin account could then check them in.  After performing this operation, experienced error when attempting to navigate back to this page: could not bring page up; in fact, also could no longer navigate to the document library's Settings page.  Since this was root site collection website, and on development, performed restore of site collection database to return to initial state: was able to get back to library's Settings page and also view the no checked in version listing again.
6. Check Website Permissions
1. Verified that account used to create the workflow, an admin account, was a member of the site collection administrator group.  
2. Added the account used to create the workflow, an administrator account, to the Full Control group of the website containing the list.  Afterwards, noted that Limited now appeared next to the Full Control designation in the website's permissions listing (showed Full Control, Limited).  After this, added admin account to website permissions and specifically granted Full Control: the Limited designator no longer appeared.
7. Explore issue in SharePoint Designer
1. In SPD, connected to website using an admin account.  Then in the left Navigation panel, expanded All Files > Workflows, and then selected the target workflow.  The right action panel listed the constituents of this workflow (four items).  Two of these items, the .XOML and .XSN, were indicated as being checked out.  Selected the .XSN file and then clicked the Delete button.  This resulted in an error prompt:

   Microsoft SharePoint Designer
   Server error: The file "[website URL]/Workflows/WorkflowName/WorkflowName.XSN" is checked out for editing by [another admin account].

2. Next, clicked the Check In button.  This resulted in another error prompt:

   Microsoft SharePoint Designer
   We can't do that for you because the file is no longer checked out or has been deleted. 

3. In SPD, created and published another test workflow attached to same list and attempted to run: experienced same type of error.
8. Internet Research
1. Conducted search on "SharePoint 2013 We can't do that for you because the file is no longer checked out".  This didn't seem to apply as it essentially discussed checking files in and this was already proven impossible using SPD capabilities.
2. Conducted search on "SharePoint 2013 This form cannot be opened in a Web browser. To open this form, use Microsoft InfoPath".  All of the search results involved Infopath issues.  These didn't seem to apply. Reference 3 indicated that the SharePoint Server Enterprise Site Collection features should be activated.  Checked this and found that it was activated. Reference 4 indicated browser configuration and Infopath issues; however, these didn't seem to apply.
3. Conducted search on "SharePoint 2013 workflow files checkin".  Reference 5 seemed to provide the right clues: it discussed the same error messages but associated with content type configuration.  This seemed to have more likelihood of applying to current situation.  Returned to troubleshooting.
9. Check Workflows document library content type configurations
1. Launched SPD, expanded All Files to Workflows document library, right-clicked on Workflows document library and chose Properties...  Reviewed Workflows tab in action panel. Reviewed Content Types section.  Did not find Document content type (as discussed in reference), but found User Workflow Document content type instead. Clicked on User Workflow Document.  User Workflow Document tab appeared. In Customization section, clicked on Edit content type columns.  Found that Title property was set to Required.  
2. Selected Title property, and then clicked on Administration Web Page button displayed in SPD.  Changed setting to Optional, and then clicked OK.
3. Created new, simple workflow attached to target list (wrote to log only).  Manual trigger. Completed successfully.  Repeated testing and again completed succesfully.  Problem determined to be resolved.

Solution

• Check the website's Workflows document library User Workflow Document content type and ensure that its Title property is set to Optional.
• If making this change still results in the error message, try creating a new workflow to the same list.  The new workflow must have a different name.

References

• Microsoft Forums
1. SharePoint 2013 Designer error: we can't do that for you because the file is no longer checked out or been deleted
2. This form cannot be opened in a Web browser. To open this form, use Microsoft InfoPath
3. This form cannot be opened in a Web browser. To open this form, use Microsoft InfoPath
4. Unable to open InfoPath form on the browser
• StackExchange
5. Workflow files won't “Check In”, can't “Undo Checkout”

Notes

• This document folder does not normally appear by default, when viewing a website's Site Contents page.  To make it appear, the document folder's Hide from browser General Setting must be disabled.  To do this:
1. Launch SPD
2. Connect to the target website
3. In the left Navigation panel, scroll down to the Workflows document folder.
4. Right-click on this folder, and then select Properties...
5. In the right Action panel, look for the Settings section.
6. Uncheck the Hide from browser setting.
   
7. Save.
• tbd

SharePoint 2013: How to Connect a Filter to a Chart Web Part

Introduction

In this posting, I will walk you through the process of connecting a Choice Filter web part to a Chart web part so that the range of data shown in the chart depends on a user selection. The chart type will be a pie chart, and the filter type will be the Choice Filter web part. Interestingly, the Choice Filter web part won't be connected to a list that in turn is connected to a chart web part.  Instead, the filter will be connected directly to the chart web part itself.  This can be done because the chart web part has the capability to perform its own filtering on the datasets it consumes.  Furthermore, it can also consume filter values that it will then apply to the datasets it has consumed.  All of the steps for accomplishing this will be discussed here.  Note: these steps require that you have at least Design permission level to the page containing the web parts.

Background

The scenario that will be explored here involves enabling a user to select different sets of data associated with routine monthly SharePoint patching and then see the selected data set displayed in a pie chart. A set of data involves the aggregated times associated with eight patching tasks:

1. Preparation
2. Operating System Update Installation (OSU)
3. SharePoint Update Installation (SPU)
4. Run Get-SPProduct all SharePoint Servers (GSP)
5. Run PSCONFIG all SharePoint Servers (PSC)
6. OWA Update Installation and OWA Reconfiguration (OWA)
7. Miscellaneous Tasks (Misc)
8. Review and Regression Testing (Rev)

These are the general tasks performed every month for SharePoint farm patching.  The aggregate total times captured from such tasks are typically recorded to a list having a normalized transactional schema, where values are in minutes, as shown in Table 1 below.  These are the times associated with patching two SharePoint 2013 farms.  Each row represents a single dataset.

Table 1
Title	Date	Prep	OSU	SPU	GSP	PSC	OWA	Misc	Rev	Total	Include
Patching: production	7/16/2016	0	192	105	139	195	6	0	60	11.52	Yes
Patching: Development	8/10/2016	30	117	124	188	38	9	0	64	9.35	Yes
Patching: Production	8/20/2016	37	144	133	31	35	16	0	36	6.93	Yes
Patching: Development	9/14/2016	10	131	127	120	95	7	0	55	8.97	Yes

The OSU aggregate is the total time involved with patching all farm Windows servers; SPU is the aggregated time associated with updating all farm SharePoint servers; Rev is the aggregated time associated with reviewing and regression testing; and so on. The times associated with these tasks are recorded for process monitoring and improvement purposes.  This sort of data listing follows the standard tabular format for related datasets (having a common X-value):

X-header	YA-Header	YB-Header	YC-Header
X1	YA1	YB1	YC1
X2	YA2	YB2	YC2
X3	YA3	YB3	YC3

The data in Table 1 can be straightforwardly displayed in a chart object.  The Date column provides the X-value and the Prep, OSU, SPU, PSC, OWA, Misc and Rev columns provide the Y-values. Entering this data into a SharePoint list and connecting a chart object to this data results in a typical line chart.

This approach works fine for charting table data as lines. However, if you want display data in a pie chart, you have to reformat the data.  Pie charts do not display multiple datasets, but only one dataset at a time.  This means that a pie chart can only represent the Y-values of a dataset, and not the X value; in other words, a pie chart displays the values for a single row of Table 1.  The process for transposing data from a line chart to a pie chart runs like so:

1. Choose a particular dataset (set of X,Y values)
2. Remove the X-values, leaving the Y-values (YA1, YB1, YC1...)
3. Identify the column headers and pair them with the Y-values

In other words, create a new table having just two columns and listing the values like so:

Item	Value
YA-Header	YA1
YB-Header	YB1
YC-Header	YC1

The first column does not represent X-values, but contains the column headers from Table 1.  These then become the pie chart labels for the pie slices.  The second displays the Y-values of the dataset.  These values are used to determine the relative sizes of the pie slices.  Therefore, if you wanted to display in a pie chart the task times for a patching session, you do it for one date at a time, building the list like so (Table 2):

Table 2
Task	Duration
Prep	0
OSU	192
SPU	105
GSP	139
PSC	195
OWA	6
Misc	0
Rev	60

where this is the data for the patching session conducted on 7/16/2016, as shown in Table 1. To display multiple patching sessions in a pie chart, requires adding the data from these sessions to Table 2 and also adding some columns to it as well that enable the table to be filtered for a specific dataset.  The general process is:

1. Add an additional column to the table that identifies the patching session for the dataset.  This is effectively the X-value for the dataset Y-values.  Call it the Session column, and it will be used to filter for a specific dataset.
2. Add an additional filter column to identify whether a data item should be included in the chart.  This is useful when, perhaps, a particular update session only need to engage in some tasks or was a one-off that you don't want to include in your general process improvement data capture.
3. Also add a column that provides additional explanation or definition of the task, calling it the Definition column.
4. Lastly, reformat the Y-value headers to make them more readable and so that they can be conveniently sorted.

Making these modifications results in Table 3, below.

Table 3
Session	Task	Duration	Include	Definition
7/16/2016	1) Preparation	0	Yes	Review all updates
7/16/2016	2) OS Updates	192	Yes	Install Operating System Updates
7/16/2016	3) SP Updates	105	Yes	Install SharePoint Patches
7/16/2016	4) Get-SPProduct	139	Yes	Run Get-SPProduct
7/16/2016	5) PSCONFIG	195	Yes	Run PSCONFIG
7/16/2016	6) OWA Updates	6	Yes	Install OWA updates
7/16/2016	7) Miscellaneous	0	Yes	Miscellaneous tasks
7/16/2016	8) Review	60	Yes	Testing and verification
8/10/2016	1) Preparation	0	Yes	Review all updates
8/10/2016	2) OS Updates	192	Yes	Install Operating System Updates
8/10/2016	3) SP Updates	105	Yes	Install SharePoint Patches
8/10/2016	4) Get-SPProduct	139	Yes	Run Get-SPProduct
8/10/2016	5) PSCONFIG	195	Yes	Run PSCONFIG
8/10/2016	6) OWA Updates	6	Yes	Install OWA updates
8/10/2016	7) Miscellaneous	0	Yes	Miscellaneous tasks
8/10/2016	8) Review	60	Yes	Testing and verification
8/20/2016	1) Preparation	0	Yes	Review all updates
8/20/2016	2) OS Updates	192	Yes	Install Operating System Updates
8/20/2016	3) SP Updates	105	Yes	Install SharePoint Patches
8/20/2016	4) Get-SPProduct	139	Yes	Run Get-SPProduct
8/20/2016	5) PSCONFIG	195	Yes	Run PSCONFIG
8/20/2016	6) OWA Updates	6	Yes	Install OWA updates
8/20/2016	7) Miscellaneous	0	Yes	Miscellaneous tasks
8/20/2016	8) Review	60	Yes	Testing and verification
9/14/2016	1) Preparation	0	Yes	Review all updates
9/14/2016	2) OS Updates	192	Yes	Install Operating System Updates
9/14/2016	3) SP Updates	105	Yes	Install SharePoint Patches
9/14/2016	4) Get-SPProduct	139	Yes	Run Get-SPProduct
9/14/2016	5) PSCONFIG	195	Yes	Run PSCONFIG
9/14/2016	6) OWA Updates	6	Yes	Install OWA updates
9/14/2016	7) Miscellaneous	0	Yes	Miscellaneous tasks
9/14/2016	8) Review	60	Yes	Testing and verification

Note that the Session column lists the denormalized X-values associated with dataset Y-values.  By listing the X-values this way, this column can be used for filtering purposes.  By filtering for a specific date in this column, it's possible to extract a set of Y-values associated with a specific patching session.  In other words, if Table 3 is filtered by a particular date, one effectively gets back a table like Table 2.

In summary, this is the process you need to work through in order to get the data prepared. Once you have a list like Table 3 created, you're ready to configure a chart to use that data.  In the next section, you'll walk through the steps for accomplishing this.

Procedure

Step 1: Define Chart web part Filter Parameters

1. Drop the Chart web part onto a page.
2. Click Data & Appearance.
3. Click Connect Chart to Data.
4. Select Connect to a List, and then click the Next button.
5. Select the website in the site collection containing the denormalized list, select the list, and then click the Next button. You'll now see your list displayed.
6. Look up at the top of this list: do you see Filter Data? Click the arrow to expand it. This will reveal filters that you can define. Assuming that you have created a list having column names as shown in Table 3, configure the first parameter like so:
   1. Parameter Name: Session
   2. Type: DateTime
   3. Default value: 7/16/2016
7. Now let's also implement the Include parameter. One thing: when you create this column, you selected the Yes/No type. Though it doesn't actually indicate this, it's implemented as a Boolean. When used in a list, and when you access the list in SharePoint, the value that you see for this column is Yes or No. But it is implemented as Boolean, but is not surfaced in that way. However, the Chart web part recognizes that column as in fact Boolean, and the values that it will show for that column are True and False. You don't need to change your list values, but you do need to account for this when specifying default or filter values.
1. Parameter Name: Include
2. Type: Boolean
3. Default value: True
8. Click the Preview Data button. This filters the list based upon the filter parameters you configured.
   
9. Click the Next button. This page helps you configure a range of different chart aspects, including the data series' you want to present. For our needs, all you need to do is configure the Series Type, which should be Pie. Select that.
   
10. Now click the Finish button. The pie chart will then be displayed. It needs some cleaning up, so let's do that next.
    

Step 2: Clean up the Pie Chart Display

1. Click Advanced Properties. The first thing to do is configure a "collected slice," or a slice that contains other pie slices having less than some amount. Doing this helps clear up the clutter associated with having a number of very thin slices and their annotations all crammed together.
2. From the Select an Element panel, select Series, and then scroll down to the bottom, to the Misc section. The configure as follows:
   1. CollectedThreshold: 10
   2. CollectedThresholdUsePercent: False
   3. CollectedThresholdExploded: True
   Like so:
   
3. Now, from the Select an Element panel, select Chart (root element), and then scroll down to the bottom to the Image section. Then configure as follows:
1. Height: 450
2. Width: 650
4. Now, from the Select an Element panel, select Series again, and then scroll down to the bottom, to the Misc section. The configure as follows:
1. PieLabelStyle: Outside
2. LabelsHorizontalLineSize: 0
5. Staying on the Series element, scroll up until you see the MapArea section. Configure as follows (include the "#"):
1. ToolTip: #VALY/#TOTAL (#PERCENT)
6. This completes chart cleanup. You can certainly do far more here, but this is enough for our purposes. In the next step, you will add and configure a Choice Filter web part.

Step 3: Add and Configure a Choice Filter

1. Put the page back in Edit mode.
2. Drop a Choice Filter web part onto the page.
3. Select Edit Web Part from the Choice Filter dropdown menu (hover the cursor over the web bar to see the dropdown appear).
4. In the Filter section, enter a name for the filter and then enter a list of dates. These dates should be exactly the same as what you entered into the SharePoint list. Also enter a date that will be the default date.
   
   The default date is pushed into the Chart web part, when the page is instantiated and streamed to the user's browser. Having a default value ensures that the chart web part will display a chart when the user first connects to the page.
5. Click OK. Now let's connect this filter web part to the chart web part.

Step 4: Connect the Choice Filter to the Chart

1. Open the Choice Filter dropdown menu again, and then this time point to Connections, then point to Send Filter Values To, and then select the name of your chart web part.
   
   A dialog will appear. Note that the names of the parameters that appear in the dropdown on this dialog. Our Session parameter appears first.
   
2. Select the Session parameter, and then click OK. Note the date that appears now in the Choice Filter web part.
   
   This is the default you entered previously.
3. Click the small filter icon to the right of the Choice Filter web part. The Select Filter Value(s) dialog appears.
   
4. Select another date, and then click OK. The dialog closes, and the page is refreshed, now displaying the data associated with that session date!
   
5. At this point, you're set: you don't need any further significant configuration. The rest is customization.
6. Here's a more cleaned up version:
   
   Note that to remove the toolbar, you'll need to edit the web page markup and set the Toolbar parameter of the Chart web part to False.  See the references for additional detail on this. Unfortunately, I don't know how to make the chart Title also update per the Choice filter - the Title text doesn't accept keywords.  If you know of a simple way, add your comment!  For additional hints and guidance on customization, see 

References

• AlsTechTips
• Using the Chart Web Part: Tips and Procedures
• How to create a no-code drill-down chart in SharePoint 2010
• Tips and Tricks with SharePoint and the Chart web part
• SharePoint 2013: Creating Chart Areas using the Chart Webpart
• MSDN Blogs
• Microsoft Chart Control How-to: Add Rich Content Using Keywords: this posting actually pertains to the .NET chart control, but much of its discussion also applies to the SharePoint Chart web part.

Notes

• If you should subsequently edit the Choice Filter web part again - maybe changing its title or some such - don't be surprised that this seems to break the connection between this web part and the Chart web part.  I find this occurs almost every time.  Even if I'm in SharePoint Designer and make a single change to a parameter (e.g., changing True to False), and carefully save the file so that nothing else is changed - even this causes the connection to break.  The fix is simple: just rebuild the connection in the usual way.
• You can also implement a similar capability using the List Filter instead.  This takes a list of values from a column in a SharePoint list that you specify.  This approach enables you to update the filter parameter list by just editing a list rather than having to edit a web page (which requires Design level permission).

SharePoint 2013 TIP: how to easily rename and retitle a website

You can easily rename and re-title a website by getting an instance of the website object and setting its Name and Title properties, like so:

$web=Get-SPWeb -Identity "http://MyFarm.com/MyRootWebsite/MyWebsite"
$web.Title="My New Website Title"
$web.name="MyNewWebsiteName"
$web.Update()

which gives

http://MyFarm.com/MyRootWebsite/MyNewWebsiteName

References

• Rename a web
• Get-SPWeb
• SPWeb class
• SPWeb.Name property
• Rename a site collection
• Get-SPSite
• SPSite.Rename method
• Customer Question: Renaming Site Collections in SharePoint 2013
• How to Rename SharePoint 2013 Site Collections Without Prayer or Sobbing
• Rename a web application
• Get-SPWebApplication
• SPWebApplication members
• How to Rename SharePoint Web Application Name and URL
• General
• Use Windows PowerShell cmdlets to manage sites in SharePoint 2013

Notes

• This works for subwebsites off the root.
• To rename the site collection, see the references above.