Change Site Definition

When an upgrade is performed on a SharePoint environment chances are some items will get lost in the upgrade.  This is especially true if your 2007 environment took advantage of the FAB40 template set or someone went crazy downloading free site templates from the internet.  These items do not block a successful upgrade and sites may even continue to work as expected after the upgrade has been performed.  However these do leave your content databases in a weird state and central administration does warn about these missing items so it is best to cleanup your content databases to remove these broken references.  There are a number of possible errors that can be presented and for most of them the way to resolve the problem is straight forward.  For reference I have included these here.

MissingWebPart and Missing Assembly
MissingFeature
MissingSetupFile

However there is no well known process for dealing with MissingSiteDefinition references which look like this message:

[MissingSiteDefinition] 1 Sites in database [] has reference(s) to a missing site definition, Id = [75820], Lcid = [1033].  The site definitions with Id 75820 is referenced in the database [], but is not installed on the current farm. The missing site definition may cause upgrade to fail. Please install any solution which contains the site definition and restart upgrade if necessary.

The site definition does not seem to be used or depended on anywhere inside of SharePoint, it only seems to be used for loading resources from the 14 hive.  However there is no way through stsadm or powershell to change the site definition for an existing site which means once a site is created there is no way to change the site definition.  This can be very troublesome because a lot of backup / restore and import / export commands require an existing site with the same site definition as the original, making these processes impossible to execute on sites with a missing site definition.  If you find yourself in this situation I have developed this process for changing the site definition of a site back to a blank site.

NOTE: This process involves editing files that Microsoft does not support editing for, so this process is use at your own risk.  Make sure to implementing extensive testing before deleting the original content.

1. Create a new blank site that will be used for testing. 
2. In powershell export original site: Export-SPWeb http://site.url/ -IncludeVersions 4 -IncludeUserSecurity -path \\put\files\here -NoFileCompression (Exporting with no file compression is the key make sure to include it)
3. Edit Manifest.xml change the Configuration attribute to 1 if it is another number. 
4. In the Manifest.xml file change the attribute WebTemplate to "STS" 
5. Edit Requirements.xml change the attribute WebTemplate ID to STS#1 
6. In powershell import into the previously created blank site: Import-SPWeb https://blank.url/ -path \\put\files\here -NoFileCompression -IncludeUserSecurity 
7. Verify test site! 
8. Delete original site 
9. Create new blank site with original site's url and site collection administrators
10. Import into the just created blank site using same command and files as in step #5 
11. Verify new site
12. Empty recycle bins

Refreshing Email Enabled Lists after Migration

Anytime you move your content databases to a farm using the database attach method in SharePoint 2010 (and i'm guessing SharePoint 2013) you need will need to refresh all of your email enabled lists.  The reason for this is because SharePoint stores the email enabled lists inside of the Farm Configuration Database and since the Farm Configuration database doesn't move during a database attach migration you need to refresh all of your email enabled lists back into the Farm Configuration Database.  The best way to do this is with a short script that will iterate through all sites and perform this function.  Here is the code to perform this action:

Add-PSSnapin Microsoft.SharePoint.PowerShell -ea 0

 

$sites = Get-SPSite -LIMIT all

 

foreach ($site in $sites) {

  $site.RefreshEmailEnabledObjects()

  $site.Dispose()

}

I found this code on this blog and he has a very good write on this issue: http://get-spchopps.com/post/2012/08/23/Fixing-Incoming-Email-after-Migration-to-SharePoint-2010.aspx.

I made a slight modification to the script that enables it to enurmate all sites in your farm and not just using a limited result set. 

Setting a Custom Color Palette on Chart Web Parts

The Chart Web Part is a SharePoint 2010 component that lets users generate charts from SharePoint lists or from BDC data.  This chart is great for providing simple data visualization that is embedded in SharePoint web part pages.  I had to do a project using this web part so I had to dig a little deeper into how to use the web part effectively.

The chart web part seems to just be an extension of the Microsoft .NET Chart class that allows you to specify the properties of the class via XML that is embedded in your SharePoint Web Part Page.  There are wizards and an advanced interface available on the web part pages to configure this underlying XML, but there are more options available to  you if you are willing to dig in and edit your page via SharePoint Designer.  Using SharePoint designer I was able to overcome what seems like a simple problem, how do I use a custom color palette on my chart?

I am going to outline the steps you need to take in order to add custom colors to a chart.  You can skip some of these steps and go straight to editing the XML, but I find that by completing my charts first and then editing the XML there is a lower chance of me accidentally blowing away my custom settings by going through a wizard.

1. Add a chart web part to your page.
2. Connect the chart to your data source using the data connection wizard. 
3. Start the chart customization wizard to format  your chart.
4. Select your chart type (type doesn't matter for custom palettes)
5. On the Appearance Themes tab:
1. Set the Theme to "Custom"
2. Set the Transparency to "Custom"
6. Finish the wizard setting any values other than the two above.
7.  Launch SharePoint Designer and open the source of your page.
8. Search for the String "PaletteCustomColors" this will take you to the embedded XML element for the custom palette.
9. The palette is ten semicolon(;) delimited values that you can set to whatever colors you want.  For how to specify color values in this section see the paragraph below. 
10. Save your page source and refresh the page, you should now see your custom colors!

There is a little trick to defining custom colors through this method and it will become appearant as soon as you open the file.  All colors have a four number format ex. (204, 255, 227, 130) this really threw me for a loop at first because everyone knows that colors are usually specified with three numbers in an RGB format.  It seems that Microsoft is starting to encourage the use of a four digit color specification where the extra number (the first in this case) is the transparency of the object.  Transparency is based on the percentage equal to the first number divided by 255, so 0 would be transparent and 255 would be solid.  In this situation a solid red would be 255, 255, 0, 0 and a half transparent blue would be 127, 0, 0 255.

Now that you know how to define colors you can go in and set your own palette of ten colors for use on your chart!  The chart web part will assign colors to your series based on when the values occur so the first series value will map to the first color and the next to the second, etc...

You must be careful when you use this editing XML method for changing charts because if you later use the wizards to edit your charts they may remove your customized values.  I have found that color is pretty stable and your settings will not be deleted unless you go into the wizard and change the color palette, transparency, or chart type.  But if you use this method to edit other values they may be wiped out by using the wizard.

For reference you can find the documentation for the chart class here:  http://technet.microsoft.com/en-us/system.web.ui.datavisualization.charting this documentation will show you the properties that are available on the chart class and that may be usable via the editing XML method. 

Good luck and happy charting!

Long time no post, hopefully things coming soon

Sorry for no posts in a while but work has been a little crazy over the past year and I haven't had a lot of time to focus on SharePoint and CRM.  On a good note we have now finished our upgrade from SharePoint 2007 to SharePoint 2010 successfully.  Some items have crept up lately that I think need to be documented to help others overcome the problems we have encountered.  Here is a list of things you will hopefully see from me over the next couple weeks.

• How to successfully send out an email merge campaign from word as an email address other than the one that owns the primary outlook profile on a machine.  
• How to create a custom color palette for use with SharePoint charts.  
• Problems with re-provisioning the User Profile Synchronization Service
• Refreshing email enabled lists after performing an upgrade.  
• Possibly a post about migration from 2007 to 2010 if I think I can add more value outside of what is already documented on the internet.  

If there is anything in this list people would like to hear first let me know!

Testing Access Services

This is part of my series on testing SharePoint service applications: http://matthewchurilla.blogspot.com/2012/02/testing-service-applications-in.html

There is a good article on MSDN for setting up a basic web database using Microsoft Access: http://msdn.microsoft.com/en-us/library/ff402351.aspx.  This article will walk you through the basics of creating a few access tables, publishing your database to SharePoint and then adding data into the database.  The site even has a sample database you can use to do your testing(http://archive.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=odcac2010h2&ReleaseId=3921).  I like to use this sample database as a starting point for my testing once I have started with this database I like to perform the following actions on the stock database just to get a better test of the available functionality.

1. Use web form to add a supplier: Microsoft
2. Use web form to add a supplier: Apple
3. Use web form to add a supplier: Google
4. Use web form to add a part for supplier: SharePoint, Microsoft
5. Use web form to add a part for supplier: Office, Microsoft
6. Use web form to add a part for supplier: Windows, Microsoft
7. Use web form to add a part for supplier: iPhone, Apple
8. Use web form to add a part for supplier: iPad, Apple
9. Use web form to add a part for supplier: GSA, Google
10. Use web form to add a part for supplier: AdSense, Google
11. Use web form to add a part for supplier: Blogger, Google
12. Switch back to Access and ensure that data is populated back into the database.
13. Create a new report to test reporting.

1. Show all fields from all tables
2. Add "Supplier Name" to the report
3. Remove Column "Supplier"
4. Remove Column "ID"
5. Add a Group on "Supplier Name"
6. Your final report should look like this.
7. Synchronize the report back to the web
14. View the report in SharePoint

At this point you have performed a basic test of Access Services.  If everything outlined here worked you can be fairly confident your service is installed and working properly.  We will keep the database site published for now we might use it in future articles.  

Document Management with SharePoint and CRM

Microsoft Dynamics CRM is a great application for managing customer, sales, and marketing data but it is not a very good document management system.  Fortunately Microsoft has another product named SharePoint that is a great document management and storage system and now with the new version of CRM you can link entities to SharePoint so you can store related documents in SharePoint and utilize the great document management features provided by that software platform.  In this blog posting I am going to give an overview of the integration possibilities between Microsoft Dynamics CRM and Microsoft SharePoint.

First off let us take a brief look at the Document Management section of the Microsoft Dynamics CRM Settings to see what is available to us. 

1. Document Management Settings – This option allows you to do the base configuration for Document Management.  This is where you go to configure which entities in the system document management is enabled for and where you can specify the primary document management location if you choose to have one. 
2. Install List Component – This option points you to instructions for downloading and installing the SharePoint list component that you can install as a sandboxed solution for sites that you wish to enable enhanced document management on.
3. SharePoint Sites – This section lists all of the sites that are linked to CRM but unfortunately it is only useful for sites that have the SharePoint List Component installed on them.   If you are not using the list component adding sites to this section will not have any effect in other parts of the system.
4. SharePoint Document Locations – This choice is a great place for administrators to reference.  Listed in this section you will find every location that is linked to from CRM.

Starting at the top let’s examine the document management settings section.   The primary listing on this page allows you specify which entities you would like to enable document management on.  A number of these are enabled by default however you can enable document management for any stock or custom entity that exists in the system.  There is a second option present on this screen and that is an option that lets you specify a SharePoint 2010 site URL to enable automatic folder creation; this provides you the capability to automate your document management with a SharePoint 2010 site that has the List Component installed on it.  We will re-visit this later when we review the 2010 only features. 

Next we are going to take a quick look at how things look once you have document management enabled so you have a good feel for how linked document libraries will behave.  So without further ado...

Here is a sample view of how a site will look when linked via an absolute URL.  Notice how this is just an embedded view of the SharePoint Document Library, because of this, you are capable of doing anything in this embedded view you could do normally in SharePoint.  The downside is it makes for a busy screen because there is a lot going on visually and the two different UI styles clash a little bit.

And here is a sample screenshot of how linked document libraries look for sites that have the SharePoint List Component installed on them, notice how the document library has a more integrated look and feel to it this exposes all of the document management capabilities of SharePoint to the user through a more seamless CRM user interface.

The last thing I want to point out is that you are able to link more than one document location to each entity.  You are capable of having many locations which will allows you to separate documents into different locations based on similar properties.

Next let’s move on to linking CRM entities to SharePoint document libraries.  For those of you with SharePoint 2007 this will be the only integration option available to you.  However this functionality is not only available to just 2007 users; if you are operating in an environment where you cannot install the SharePoint 2010 List Component you can still use Document Locations to connect SharePoint 2010 and CRM.  Document Locations are rather primitive because they just embed an HTML viewer in the CRM page that simulates browsing the linked document library in a web browser.

When you add a Document Location and don’t have any Site Locations defined that have the SharePoint 2010 List Component installed you will be presented with an “Add Document Location” dialog box that will only be capable of linked via an absolute URL to a target document location.  In order to do these just give your document location a name and enter the full SharePoint URL you wish to link as a document location. 

Now let’s look at the SharePoint 2010 List Component; this item allows you to directly link document libraries from SharePoint 2010 into CRM.  I will not go over installing this component on a SharePoint site because this process is well documented elsewhere (http://www.microsoft.com/download/en/details.aspx?id=5283).  Once you have installed the list component on a site you will have a few new capabilities available to you. 

First you will now be able to set an automatic folder creation site.  When you enable this feature you will be prompted on whether you want to structure your folders by accounts or contacts.  Whenever you enable this feature entities that are related to the based on entity will have all of their documentation consolidated in the same folder structure within SharePoint.  For example if you had an account named Account 1 that had an opportunity named Opportunity 1 then you would end up with a folder structure that was something like “Account 1\opportunity\Opportunity 1” similarly if there was a quote named Quote 1 the folder would be named “Account 1\quote\Quote 1”.  If you don’t select to group items based on entity it will group everything within a new document library named after the entities that are contained within it.  Once you have enabled automatic folder creation the first time someone visits the document section of an entity they will be prompted to create a new folder in the appropriate location.  Personally I don't like to enable automatic document library creation, I feel that this removes some of the flexability of the system but this could be very convient for some organizations.  Below are some screen shots of how this appears in the CRM interface.

The second thing you will now be able to do is add sites into the SharePoint sites list.  Adding sites here is a good way to allow users to create folders.  When you have sites listed in the SharePoint Sites list users will now have a second option when adding a new document location.  This option allows the user creating a new document location to specifiy a new folder under an existing site that you have added to the SharePoint Sites List. 

The last section we need to visit is Document Locations and it is a very good section.  The Document Locations option enables you to view every link between CRM and SharePoint so it is a great place to review for duplicate connections and to ensure that the integration is being used properly.  You will notice in this final screen shot the difference between how absolute URL links are displayed compared to Document Locations that are setup based on a base SharePoint Site and relative references from there.

And that completes this posting on Document Management for Microsoft Dynamics CRM.  I hope you are a little more informed now. 

Configuring Secure Store

This is part of my series on testing service applications: http://matthewchurilla.blogspot.com/2012/02/testing-service-applications-in.html

We will be working on testing service applications and in order to do this properly we will need to configure the secure store service.  We are configuring this service to test the ability of service applications to access external data sources.  If you don't care about accessing external data sources from your service applications then you can skip configuring the secure store service and any future tests that involve it.

In order to not reinvent the wheel Microsoft already has some documentation on configuring most service applications and I will link to it when possible.  Here is the document for configuring the secure store service application: http://technet.microsoft.com/en-us/library/ee806866.aspx.  The steps you will want to perform in order to have a properly configured service application.

1. Generate a New Key
2. Create a new Target Application.  I used the parameters to the right.  Be aware setting the members to All Authenticated Users is not recommended this will allow any user to authenticate to external data sources that use the target application ID.  But since this is for testing purposes we are going to use it to make things easy.
3. Set credentials on the target application.

Once you have a target application setup you will be able to use this application in other service applications to test data access to external data sources.