SharePoint 2013: working with managed metadata open term sets

Introduction

This posting walks through the process of creating a managed metadata open term set, that is, a term set to which users can add terms.  This posting starts out by creating a new term set group, adding a new term set to this group and then adding a few terms.  Next, the posting walks through adding a new managed metadata column to the list and configuring it for the new term set you created and also configuring it as an open term set.  Lastly, the posting walks through editing this column for a list item and adding a new term to the term set.  This posting assumes that a list has already been created.

Procedure

1. Create a new "open" term set
1. Launch Central Administration.
2. Navigate to: Application Management > Manage service applications.
3. Click on Managed Metadata Service.
4. In the Taxonomy Term Store at right, hover the cursor over Managed Metadata Service, and then click the down arrow that appears.
5. Select New Group.
6. Enter a name for the new group.  For this posting, this will be TEST.
7. Hover the cursor over the name of the new group, and then select New Term Set.
8. Enter a name for the new term set.  For this posting, this will be MyTermSet.
9. Select the new term set.
10. On the General tab at right, look for the Submission Policy setting and then select the Open option:
    
    
11. At the bottom of this page, click the Save button.
12. Hover the cursor over the new term set name, and then select Create Term.
13. Enter a name for this term.
14. Create additional terms as needed.
2. Add metadata column to list
1. Navigate to the target list.
2. Select the LIST ribbon at top.
3. On the LIST ribbon, in the Settings group, click the List Settings button.
4. Scroll down to the Columns section, and then click on the Create column link.
5. In the Name and Type group, select the Managed Metadata option:
   
   .
6. Scroll down to the Term Set Settings group, and then select the Use a managed term set option (this is selected by default).
7. In the term set box, expand: Managed Metadata Service > [Your new term group] > [your new term set].
8. Select your new term set.
9. Scroll a little further down to the Allow Fill-in group, and then select the Yes option:
   
   
10. Click on the OK button at bottom.
3. Add a new term
1. Navigate to the target list.
2. Select an item.
3. On the ITEM ribbon, in the Manage group, click on the Edit Item button.
4. Look for the managed metadata column, and then click on the tag icon.
5. Select the term set name, and then click on the Add New Item link at top:
   
6. Enter a name for the new term.  For this posting, this will be MyNewTerm.
7. Click to the left of the term.
8. Click OK.
4. Verify new term
1. Launch Central Administration.
2. Navigate to: Application Management > Manage service applications.
3. Click on Managed Metadata Service.
4. Expand: Managed Metadata Service > [your new term group] > [your new term set] > [your new term].

References

• Plan terms and term sets in SharePoint Server 2013
• Plan to share term sets and content types in SharePoint Server 2013
• Open and Closed Term Sets Inside SharePoint 2013
• SharePoint 2013- Create term set, terms, Assign managed metadata to a list/library column 
• Create and manage terms in a term set
• Open and Closed Term Sets
• How to set a Managed Metadata Open Term Set in SharePoint 2013

SharePoint 2013: How to configure SSL for SharePoint 2013 for development or testing purposes

Introduction

This posting walks through the process of configuring SSL for SharePoint 2013 for development or testing purposes using the SelfSSL tool available with the IIS6 Resource Kit.  It isn't necessary to build the web application from the start as SSL: you can implement this procedure for a non-SSL web application to which you want to also implement SSL.  This procedure assumes that: a non-SSL web application has been created and implements NTLM, claims-based authentication; and a root site collection has been created.  It assumes a small, two-tier topology, consisting of a SQL Server database on one server and the SharePoint application on the other.  Hyper V 2012 is the infrastructure platform, employing Windows Server 2012 as the server platform.

Procedure

1. Edit the HOSTS file, on the SharePoint server to include the new domain name.
2. Identify the web application name for which you want to implement SSL.  For this posting, the web application is Contoso.com80.  This is the name seen in Central Administration > Application Management > Web Applications > Manage web applications.
3. Download and install the IIS 6.0 Resource Kit Tools package.  Install this as Administrator (right-click).  Installing this will add a number of new options:
   
4. Look for the SelfSSL option, and then right-click this to open it in elevated mode:
   
   This needs to be opened as Administrator in order for SelfSSL to be able to successfully create the certificate and store it in the Certificate Store.
5. Change the shell directory to the location of the SelfSSL.exe tool, at C:\Program Files (x86)\IIS Resources\SelfSSL:
   
6. Launch a new elevated command shell.
7. Execute the following:

   %systemroot%\system32\inetsrv\APPCMD list site "contoso.com80"

   
   This returns the web application ID in IIS.  You need the web application ID in order to successfully create the SSL certificate for this web application.  This returns an ID of 512363676.
8. Back in the SelfSSL command shell, execute the following:

   selfssl.exe /s:512363676 /t /v:7 /n:cn=contoso.com

   This creates the new certificate, 
   
   associating it with the web application, and storing it in the Personal certificate store:
   
   Double-clicking on the entry in the Personal certificate store, you can see the certificate:
   
   .
9. Launch IIS, and then select the Sites node to view the list of sites.  Looking in the Binding column, note that SelfSSL has already added an SSL binding for the Contoso.com80 web application:
   
   .
10. In IIS, double-click on the target site.  This opens the Site Bindings dialog for the site:
    
    Though SelfSSL added the new binding, it did not configure it.  For example, as you can see, it did not configure the Host Name for the binding.  Nor did it select the certificate for this binding.  This you need to do yourself.
11. On the Site Bindings dialog, click the Edit button.  This opens the Edit Site Bindings dialog.
12. In this dialog, enter the Host name Contoso.com, and then select the contoso.com certificate:
    
13. Click OK, and then click Close.
14. On the SharePoint server, open a browser, and then connect to:

    https://contoso.com

    The browser should connect to the domain name without presenting any certificate warning:
    
    If you attempt to connect to this site from another server in the domain (with suitable modification of its HOSTS file), you will experience the certificate warning.
15. This completes this procedure.

References

• Internet Information Services (IIS) 6.0 Resource Kit Tools
• Setting up SSL with a SelfSSL certificate on Windows Server 2003
• How to find IIS7 SiteID using site name on Windows 2008 using appcmd or other util?
• Help needed! SSL certificate replaced, but site delivers old one still?!
• Do It Yourself with SelfSSL
• Setup SSL in SharePoint 2013 using commercial certificates

Notes

• If you previously deployed the web application using a self-signed certificate created using the IIS8 tool, and you then work through this procedure to replace it, you may find that the old certificate continues to be presented to client browsers.  To resolve this, you need to both reset IIS and restart the HTTP web service. Open an elevated command shell, and then execute the following commands in this order
1. iisreset /stop
2. net stop http
3. net start http
4. iisreset /start

SharePoint TIP: [MissingWebPart] WebPart class is referenced [1] times in the database - how to locate the webpart

When performing migrations, whether from 2007 to 2010 or 2010 to 2013, you may see the following warning appear: 1) in response to executing PreUpgradeCheck; 2) in the Missing Server-side Dependencies report; and 3) in other event logs:

[MissingWebPart] WebPart class [Webpart GUID] is referenced [1] times in the database [Content Database Name], but is not installed on the current farm. Please install any feature/solution which contains this web part. One or more web parts are referenced in the database [Content Database Name], but are not installed on the current farm. Please install any feature or solution which contains these web parts.

It is difficult to resolve this migration issue since no page location information is provided.  To find this information, you must search several tables in the content database, including the WebParts, AllDocs and Webs tables.  Using inner joins, you can find this information with a single SQL statement, shown below, executed on the source database.  This statement works in SQL Server 2008:

USE WSS_Content_Database
SELECT tp_WebPartTypeID AS 'WebParts.WebPartTypeID(WebPartClassGUID)', 
       tp_PageUrlID AS 'Webparts.tp_PageUrlID', 
       AllDocs.Id AS 'AllDocs.Id', 
       AllDocs.WebId  AS 'AllDocs.WebId', 
       LeafName  AS 'AllDocs.LeafName', 
       DirName  AS 'AllDocs.DirName', 
       ListId AS 'AllDocs.ListID', 
       Webs.Id AS 'Webs.ID', 
       Webs.Title AS 'Webs.Title', 
       FullUrl AS 'Webs.FullURL'
FROM WebParts 
INNER JOIN AllDocs 
ON tp_PageUrlID = AllDocs.Id
INNER JOIN Webs ON AllDocs.WebId = Webs.Id
WHERE tp_WebPartTypeID = '[Webpart GUID]'

Executing this script returns a table containing the above fields, specifically, the page (leaf) and directory (DirName) names, as well as the site title (Webs.Title) and URL (Webs.FullURL) to help you locate the problematic web part:

Executing this SQL script returned the site, SS, containing the problematic web parts.  This script was useful in that it brought to attention a site that had been overlooked in migration preparation and was no longer being used.  As a result, though problematic web parts were seen in the migration report, it was not known where these were.  Navigating to the site, the problematic web parts were immediately identified:

Then, appending ?Contents=1 to the page URL, I viewed the web part maintenance page:

Using the page features, I was able to remove the problematic web parts.  Re-executing stsadm.exe -o PreUpgradeCheck,

and then viewing the SharePoint Products and technologies Pre-Upgrade Check Report, specifically, the Feature Information section, found no more [Missing] feature items.


References

• Test-SPContentDatabase
• How to Remove Missing WebPart during SharePoint Upgrade
• TechNet: Using Inner Joins
• Preupgradecheck: Stsadm operation (Office SharePoint Server)
• SharePoint 2010 Upgrade: Test-SPContentDatabase – Key to Successful Upgrade

Notes

• Thanks to Claus with BoostSolutions for publishing the article on this.  I've made some minor tweaks to his original script.  Note that an inner join command is written as two words, "INNER JOIN."

SharePoint 2013: how to restore a managed metadata database

Print this posting

Introduction

This posting walks through the steps for restoring a Managed Metadata Service Application (MMSA) database. I use this process to "refresh" a development farm with the latest MMSA changes. The steps in brief are:

1. Stop service
2. Detach old database
3. Attach backup database
4. Grant farm service accounts access: Admin, farm, AppService
5. Configure MMSA for new database
6. Start MMSA
7. Start MM service
8. Check App pools and IIS web services root
9. Reset IIS

Procedure

1. Log into a farm server using the SharePoint Setup User Administrator account.
2. Launch a SharePoint Management Shell as Administrator (right-click).
3. Execute the following: Get-SPServiceInstance | Where {$_.Name -Like "*Managed*"}. This will return all instances of the service application - one for each SharePoint server in your farm. not all of these instances will be running.
   
4. Copy the GUID for the running instance.
5. Execute the following: Stop-SPServiceInstance -Identity <ServiceGUID>.  This will stop, or unprovision, the MMSA instance.
   
6. Leave the shell and this login session open for the time being (if you can).
7. Log into the farm database server host using a farm administrator account.
8. Copy the backup MMSA database to this server.
9. Launch SQL Server Management Studio (SSMS) as Administrator.
10. In Object Explorer, expand the tree to the farm's Managed Metadata database.
11. Right-click on the database, point to Tasks, and then click Detach...
12. Enable the Drop Connections and Update Statistics options, then click OK.
13. Navigate to the folder containing the MMSA database data file.  By default, it will be: C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA.
14. Rename the MMSA database file to something else.
15. Repeat for the MMSA database log file.

    NOTE: steps 12-14 are performed on the assumption that the restored MMSA database has the same database name and filename as the one that you are removing.  If this is not the case, skip these steps.

16. In SSMS, in Object Explorer, right-click on the Databases node, and then click Restore Database.
17. Perform the usual steps for restoring a database, in this instance, the backup MMSA database.
18. Configure farm service accounts for DBO database access:
    1. SharePoint Setup User Administrator (spAdmin)
    2. SharePoint Farm Service (spFarm)
    3. SharePoint Application Service (spService)
    4. Other farm administrator accounts as needed
    Failure to configure these accounts with their usual access (the access they had before) will manifest as counter-intuitive error messages seen when trying to view the properties of the Management Metadata Service Connection, 
    
    or trying to view the Term Store Management Tool,
    
19. Close SSMS.
20. Return to the SharePoint Server and the open shell session.
21. Execute this script:
    

    $app = Get-SPServiceApplication -Name "<service application name>"
    Set-SPMetadataServiceApplication -Identity $app -DatabaseName "<dbname>"
    Start-SPServiceInstance -Identity 

replacing brackets with appropriate values.

NOTE: the <service application name> above is not the one that you see when you execute Get-SPServiceInstance, but the one you see in Manage service applications and what you see when you execute Get-SPServiceApplication.

22. Navigate to: System Settings > Manage services on server.
23. Verify that the Managed Metadata Web Service is started on the appropriate server.  If it isn't, start it.
24. Launch IIS Manager.
25. In the Connections panel, select Application Pools.
26. Verify that the SharePoint Web Services Root is started.  If it isn't, start it.
27. Now expand Sites, and then select SharePoint Web Services.
28. Verify that it is started.  If it isn't, start it.
29. Open an elevated Command Shell.
30. Execute IISReset.
31. Test by first navigating to: Central Administration > Application Management > Manage Service Applications.
32. Then select Managed Metadata Service, and then select the Manage button.  The Term Store Management Tool should display without issue.  If not review the steps performed here and ensure that you have completed all of them.

References

• SharePoint 2013: How to Restore Content Databases
• Move the Managed Metadata Service service application databases in SharePoint Server 2013
• Start or stop a service (SharePoint 2013)
• There are no addresses available for this application" error in SharePoint managed metadata service

Notes

• Managed Metadata Service Application runs on a single server, in this case a single application server.

SharePoint 2013 Tip: how to list all installed SharePoint products

To quickly report on all installed SharePoint-Related products and export to CSV, run this script:

Get-WmiObject -Class Win32_Product | Where {$_.Name -like “*SharePoint*”} | Sort-Object Name | Select-Object name, Description, InstallDate, InstallDate2, Vendor, Version | Export-CSV D:\Products2.csv

References

• List installed SharePoint products via PowerShell
• SharePoint 2013: The license state for the current server doesn't match the farm's license state
• Get-WmiObject
• Using the Get-WMiObject Cmdlet

Notes

• To find out what other properties are available, just pipe into Get-Member.

SharePoint 2013: Working with Move-SPUser and Set-SPUser when migrating users

Print this posting

Introduction

This posting consolidates my notes with regard to migrating user accounts from old SharePoint instances to new ones. I had the need to cleanup and migrate a subset of users from a legacy, Internet-facing SharePoint 2007 farm, using a dedicated instance of Active Directory Lightweight Directory Services (ADLDS), all co-located on a single server. User account maintenance over the years had not be consistent nor robust and as a result user account formats were inconsistent and also reflected changing domain implementations.  Looking through the site collection's AllUsers list, one would see varying user account userLogin formats, such as:

• i:0#.f|OLDDOMAIN1|First.Last
• i:0#.f|OLDDOMAIN2|First.Last
• i:0#.f|OLDDOMAIN3|First.Last
• [machine name]\First.Last

Even the display names of these user accounts frequently contained varying domain names and other odd formats.  I also found some duplication and special character usage. There was no relationship between the old ADLDS and the new AD authentication services, and so performing a simple user migration was not possible.  Alot of user accounts had never experienced a login event, and many others had not been used in over a year.  Given the formatting of the old user accounts, additional effort was needed to cleanup the user account formatting in SharePoint, and then appropriately map the user accounts to their new implementations in AD.

Migrating Old User Accounts to New Domain

To do this, I first migrated the content DB using the usual pathway of: 2007 --> 2010 --> 2013, where both the intermediary 2010 and final 2013 farm web applications were configured as standard claims-based authentication web applications.  After the content DB was satisfactorily migrated and the site brought up, I reviewed the list of users in the old ADLDS, drafting a list of which ones really needed to be migrated.  To draft this list, I pulled user account information via repadmin, and then I coordinated with legacy site stakeholders, providing them lists of the old accounts for them to review.  I also pulled user account lastlogins to better identify and determine user accounts useful to migrate.  Over the course of several rounds of stakeholder review and comment, a final list was drafted.

Next, I used this basic script to pull the list of users in the migrated site collection.  The migrated content was contained in a single content database, a single web application, containing a single site collection. So, I only needed to look at one AllUsers list, like so:

$web=Get-SPWeb [new web application URL]
$web.AllUsers | Select-Object DisplayName, ID, userLogin  | Sort-Object DisplayName | Format-table -auto

This list revealed the extent of what needed to be done.  About a third of what was listed here needed to be migrated.  Because the usernames were so varied, it wasn't clear to me that writing a loop function would be the most time-effective approach.  Instead, I copied the target user accounts into Excel, and then used standard Excel string manipulation tools to generate the following set of statements for each user account to be migrated:

$User=Get-SPUser -Identity "i:0#.f|OLDDOMAIN|First.Last" -Web "[new web app URL]"
Move-SPUser -Identity $User -NewAlias "NEWDOMAIN\First.Last" -IgnoreSID -confirm:$false

In some cases, users had two accounts, due to what appear to have been misspellings or a customization request by a user, such as to shorten a name to a letter or two.  In such cases, I had to create two sets of user account migration steps, each set moving the legacy user account to the same destination account:

$User=Get-SPUser -Identity "i:0#.f|OLDDOMAIN|First.Last" -Web "[new web app URL]"
Move-SPUser -Identity $User -NewAlias "NEWDOMAIN\First.Last" -IgnoreSID -confirm:$false
$User=Get-SPUser -Identity "i:0#.f|OLDDOMAIN|F.Last" -Web "[new web app URL]"
Move-SPUser -Identity $User -NewAlias "NEWDOMAIN\First.Last" -IgnoreSID -confirm:$false

I then incorporated these statements into PowerShell script and executed.  It was useful to have it as a script because in this way I could re-execute the script over multiple trial migration runs - each fresh content database migration bringing with it the old user accounts untouched, and a portion of these would need to be re-mapped to their counterparts in AD.

Cleaning Up User Account Display Names

Another aspect of migrating the old user accounts involved cleaning up the user account DisplayName.  Here again I found a variety of formats and special characters and here again I used Excel string manipulation tools to quickly draft a set of statements for each user account needing cleanup:

$name=Get-SPUser -Identity "i:0#.f|OLDDOMAIN|First.Last" -Web "[New web app URL]"
Set-SPUser -Identity $name -Web "[new web app URL]" -DisplayName "First Last"

These statements I also placed into a PowerShell script for re-use during subsequent trial migration runs.

References

• Active Directory Lightweight Directory Services
• SharePoint’s hidden user-list – User Information List
• TIP: how to use repadmin to find user info in AD LDS
• SharePoint 2013 - The content processing component failed to process the security descriptor of the item
• Capitalizing First Letter of Every Word with Powershell 2
• Windows PowerShell Tip of the Week: The String’s the Thing
• Make a Choice
• Set-SPUser
• Get-SPUser
• Move-SPUser : The parameterless Read method can only be used when this instance was initialized with an SPUser object.
• How to Customize the "Sorry, this site hasn't been shared with you"

Notes

• Thanks to Trevor Seward for his assistance in this posting that helped me to better understand some aspects of the Move-SPUser command.
• The Move-SPUser NewAlias value must be in Pre-Windows 2000 format.  This means 20 characters or less. Otherwise, you will see errors like, "Move-SPUser : The user does not exist or is not unique."  You can determine the pre-Windows 2000 username currently set for the user by going to the account in Active Directory Users and Computers control panel, and then selecting the Account tab.
• The Move-SPUser NewAlias value must be of a user account that exists within the new AD domain.  For example, if you are moving a user to DOMAIN\First.Last, then DOMAIN\First.Last must be a valid AD account already created in the domain.  If this user account does not exist, you will see an error like, "Move-SPUser : The user does not exist or is not unique." 
• You need to refresh the $web object to see the changes.  This is because executing the Get-SPWeb command effectively takes a snapshot of the site collection and stores it in the $web object (as shown above).  If you want to see your changes reflected in the AllUsers list, you need to re-execute Get-SPWeb.

SharePoint 2013: how to create a custom access denied page

Print

Introduction

Previously, in SharePoint 2010, when modifying the Access Denied page via PowerShell, you used the web application's UpdateMappedPage method.  Now, in SharePoint 2013, you use the Set-SPCustomLayoutsPage command.  The new approach greatly simplifies deploying such custom application pages.  This posting shows how to make an elementary modification to the AccessDenied,ASPX page, and then configure the web application to use that new page.

Procedure

1. Log into one of the farm WFEs as a farm administrator.
2. Open Windows Explorer, and then navigate to this folder:

   C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS\

3. Add a subfolder to this folder, naming it CustomPages.
   
   Note that this is the physical path to the CustomPages folder. The relative path would be:

   [web app URL]/_layouts/15/custompages

4. In the LAYOUTS folder copy the file AccessDenied.ASPX into the CustomPages subfolder, renaming it AccessDeniedNew.ASPX.
   
5. Modify AccessDeniedNew.ASPX as desired.  To add text or other HTML elements to this page, be sure to introduce them within <asp:Content tags. In the example below, formatted text has been added so that it will appear just below the "Sorry, this site..." message.  The intent here is to keep the message simple in order to facilitate rapid comprehension and engagement. Added text is highlighted.
   
6. After completing the modification on this WFE, copy the CustomPages subfolder into the LAYOUTS folder of each of the other WFEs.

   NOTE: if you don't do this, your users will experience inconsistent responses - some getting the default accessdenied page and some the new one, depending on which WFE the farm's NLB service routed the user's request to.

7. Open a SharePoint Management Shell using a farm administrator account having the SharePoint_Shell_Access role for the farm configuration database.  To check for those accounts that do have this role for the farm configuration database, execute Get-SPShellAdmin.
8. Execute Get-SPCustomLayoutsPage to view what custom pages have already been configured. If you haven't configured any custom message pages yet, you will see something like the following:
   
9. Execute the command that will update the farm configuration database to point to the new location of the AccessDenied page:

   Set-SPCustomLayoutsPage -Identity "AccessDenied" -RelativePath "/_layouts/15/custompages/AccessDeniedNew.aspx" -WebApplication "http://MyWebApplication"

   The AccessDenied page path is now updated:
   
10. Open a browser using a standard account, and then navigate to a site or page that your account does not have access to.  The new AccessDenied page is presented.  Note that an IISReset does not need to be performed.  The change takes affect immediately.
    

References

• SharePoint 2013
• How to set custom access denied pages in SharePoint 2013?
• Access Denied on SharePoint Root Site - even though access is given
• How to Customize the "Sorry, this site hasn't been shared with you"
• Set-SPCustomLayoutsPage
• Get-SPShellAdmin
• Add-SPShellAdmin
• SharePoint 2010
• SharePoint 2010: How to Customize Application Pages
• How to Customize Error Page, Page Not Found and Access Denied in SharePoint 2010
• SPWebApplication.UpdateMappedPage method

Notes

• Thanks to KeithTuomi for his response, to this posting, providing the necessary steps.
• This procedure was performed on a small, traditional-topology SharePoint 2013 farm that includes one DB, one App and two WFEs in (Windows) NLB configuration.
• Using the steps shown in this posting, you can also deploy custom Confirmation, Error, Login, RequestAccess, Signout and WebDeleted pages. Just change the value of the Identity parameter appropriately.

SharePoint 2007: How to Migrate to SharePoint 2010

Print this posting

Introduction

This posting consolidates my notes with respect to migrating a SharePoint 2007 farm to SharePoint 2010 using the database attach method.  It focuses only on content migration, not service application migration. The SharePoint 2010 web application is configured to use standard NTLM authentication and non-encrypted (HTTP).  This posting installs SharePoint 2010 onto Windows Server 2012; you'll need the May 1, 2014, SharePoint 2010 SP2 slipstream media for this. It also employs SQL Server 2012.

Procedure

1. Verify/create SharePoint 2010 service accounts.
2. Build SharePoint Server 2010 farm (destination farm) on Windows Server 2012.
3. On destination farm, create new web application NTLM and site collection.
4. On source farm, execute STSADM.exe –o preupgradecheck and resolve any issues that are found.
5. On source farm, set content databases to read-only.
6. On source farm, perform content backup.
7. On source farm, copy SharePoint Server 2007 farm content database backup to 2010 farm.
8. Restore 2007 database to 2010 farm database server.
9. In SSMS, map SharePoint Setup User Admin account as DBO of restored 2007 content database.
10. Verify database read-only property is false.
11. Remove 2010 web application content database.  You will need to rename the content database files (data and log) if the database you are migrating has the same file names.
12. Mount 2007 content database to 2010 web application.
13. Optional: initiate Visual Upgrade on all sites in site collection.

References

1. SharePoint 2010 SP2 and Windows Server 2012 R2
2. SharePoint 2010: How to install onto Windows Server 2012
3. Upgrade from Office SharePoint Server 2007 or Windows SharePoint Services 3.0 to SharePoint Server 2013 or SharePoint Foundation 2013
4. Migrate from classic-mode to claims-based authentication in SharePoint 2013
5. SharePoint 2010 Claims: Migrating Windows users to Claims users on existing sharepoint site
6. Migrate from MOSS 2007 to SharePoint 2010 - Step by Step
7. Perform a database attach upgrade to SharePoint Server 2010
8. Checklist for database attach upgrade (SharePoint Server 2010)
9. Upgrade Worksheet for SharePoint 2010 Products
10. SharePoint 2013: Service Account Configurations and Permissions
11. Error lors de l’installation des Office Web Apps 2010 sur Windows 7
12. SharePoint 2010: Install on Windows Server 8 Beta
13. SharePoint 2010 on Windows Server 2012!
14. Installing SharePoint 2010 and SQL Server 2012 on Windows Server 2012 Release Preview
15. Upgrade and migration: Stsadm operations (Windows SharePoint Services)

Notes

• Where is stsadm.exe?: The stsadm command can be found here (default): C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN.
• 2010 SP2 Slipstream ISO file name: Need to use sw_dvd5_sharepoint_server_2010w_sp2.2_64bit_english_mlf_x19-65035.iso to perform this installation.  This version is available through your Microsoft Volume Licensing or MSDN subscription.
• If the (source) databases you are migrating have the same file names as the ones already in the 2010 farm (destination), detaching the destination databases is not enough in this case.  You must also rename the destination database files.  Otherwise, you will encounter errors like the following during the restore database process:

  TITLE: Microsoft SQL Server Management Studio
  ------------------------------
  Restore of database '[content database name]' failed.
  (Microsoft.SqlServer.Management.RelationalEngineTasks)
  ------------------------------
  ADDITIONAL INFORMATION:
  System.Data.SqlClient.SqlError: File "[source content database file]" cannot 
  be restored over the existing "C:\Program Files\Microsoft SQL 
  Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\[destination content database file].mdf". 
  Reissue the RESTORE statement using WITH REPLACE to overwrite pre-existing 
  files, or WITH MOVE to identify an alternate location. 
  (Microsoft.SqlServer.SmoExtended)
  

SharePoint 2013: How to change the Suite Link Bar

The Suite Link Bar is what you see at the top of the page, just below the browser menu bar:

By default, it displays the simple "SharePoint" text.  What you see displayed here is contained in the web application's SuiteBarBrandingElementHtml property. If you interrogate this property, you will see the following:

PS C:\Users\spAdmin> $wa = Get-SPWebApplication http://App1:5000
PS C:\Users\spAdmin> $wa.SuiteBarBrandingElementHtml
<div class="ms-core-brandingText">SharePoint</div>

You can modify this property at any time using PowerShell.  You can even configure this as a convenient hyperlink.  The next steps show you how.

Procedure

1. Run this script to just change the text:

   $wa = Get-SPWebApplication http://App1:5000
   $SuiteBarText="<div class='ms-core-brandingText'>Central Admin: Corporate Site <font color='red'><b>(Production)</b></font></div>"
   $wa.SuiteBarBrandingElementHtml=$SuiteBarText
   $wa.update()

2. Run this script to change the text and configure it as a hyperlink:

   $wa = Get-SPWebApplication http://App1:5000
   $SuiteBarText="<div class='ms-core-brandingText'><a href='http://App1:5000'>Central Admin: Corporate Site</a> <font color='red'><b>(Production)</b></font></div>"
   $wa.SuiteBarBrandingElementHtml=$SuiteBarText
   $wa.update()

References

• SharePoint 2013 Central Administration Productivity Tip
• SPWebApplication.SuiteBarBrandingElementHtml property
• Change top left text to Hyper Link

SharePoint 2013: [MissingSetupFile] File...is referenced [...] times in the database but is not installed on the current farm

Print this posting

Problem

You are performing a database attach upgrade from some previous version of SharePoint to version 2013.  The upgrade fails or completes with warnings.  Checking the upgrade error log file, you see some warnings like this one:

[powershell] [SPContentDatabaseSequence] [WARNING] [time/date]: File [Features\Bamboo.UserAccount.Setup.WebPart\WebParts\CreateUserWebpart.dwp] is referenced [1] times in the database [content name], but is not installed on the current farm. Please install any feature/solution which contains this file.

Running the Missing server side dependencies rule, you see something similar:

[MissingSetupFile] File [Features\Bamboo.UserAccount.Setup.WebPart\WebParts\CreateUserWebpart.dwp] is referenced [1] times in the database [CS_Content], but is not installed on the current farm.

These messages indicate a problem, but not the location of the problem.  The locations of these missing setup file references are needed in order to remove them.  The solution is to look directly in the database itself for this information; specifically, the AllDocs table.

Solution

1. In the warning or error messages, note down some unique part of the file path.  For example, in the messages above, "Bamboo" is unique.
2. Log into the farm database server.
3. Launch SSMS
4. In Object Explorer, expand: [database server] > Databases > [content database] > Tables > dbo.AllDocs.
5. Right-click the database, and then choose New Query.
6. Enter the following

   USE [content database name]
   SELECT * FROM AllDocs
   WHERE SetupPath LIKE '%Bamboo%'
   

   This returns all instances of the setup file and their usage.
7. Among the returned results, look in the DirName column for each result.  This column provides the location that you need.

References

• Solving [MissingSetupFile] errors from SharePoint Health Analyzer
• Inside a SharePoint Content DB
• [MissingSetupFile] File [Features\ReportServer\ReportViewer.dwp]
• Fixing Test-SPContentDatabase warnings
• Troubleshoot database upgrade issues in SharePoint 2013

Notes

• [MissingWebPart] WebPart class: You'll see this in the ULS upgrade error log file.  An ID will be associated with this.  Note down this ID.  Then open up the content database in SSMS, drill down to the WebParts table.  WebPart class IDs can be found in the tp_WebPartTypeId column of the WebParts table.