This blog post was written up by one of the senior developers on our team - Martha Amirzadeh. Thanks Martha!
One of the common customer requests that we come across is for the ability to add a specific Service Manager Webpart to an existing SharePoint site. That is the focus of this blog.
The Service Manager SharePoint site ships these Webparts:
In order to access these Webparts and their related components, you will need to install a Service Manager SharePoint Site on a machine that your SharePoint site is hosted. You don't have to use this Service Manager SharePoint site later, it is just needed so you could access required files in the next steps.
After you are done with installation of the sample Service Manager SharePoint site, here are the steps to add a Service Manager Webpart to your SharePoint site:
1) Make sure the below assemblies are GAC’ed on the machine that your SharePoint site is hosted on:
Note: These assemblies should already be GAC’ed as part of the sample Service Manager Site installation.
2) Upload the specific Webpart you need to the Webpart gallery of your SharePoint site's parent site.
There are few ways to find the specific Service Manager Webpart you need to upload:
· Browse to “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\SMPortalSharePointSiteFeatures\” where all the Service Manager specific SharePoint files are copied when you installed the sample Service Manager SharePoint site.
For example, copy the specific Service Manager Webpart file called KnowledgeArticleWebPart.webpart from the KnowledgeArticleWebPart folder.
· Navigate to the Webpart gallery of the sample Service Manager Sharepoint site’s parent site and download specific Service Manager Webpart from there.
To navigate to the Webpart Gallery of Service Manager SharePoint site’s parent site, first select Site Actions -> Site Settings of the parent site and then navigate to “Galleries/Web parts”, it should take you here:
· Create a custom Service Manager Webpart as below.
<?xml version="1.0" encoding="utf-8"?>
Version=7.0.5000.0, Culture=neutral, PublicKeyToken=9396306c2be7fcc4" />
<property name="Title" type="string">My Activities Webpart</property>
<property name="Description" type="string">My Activities Webpart Description</property>
Note: make sure the assembly version and publicKeyToken match the assembly that is GAC’ed on the machine already.
3) Add the specific Service Manager Webpart to the SafeControl list in the web.config of the parent site of your SharePoint site.
Keep in mind that you need to add this line for each Webpart separately.
<SafeControl Assembly="Microsoft.EnterpriseManagement.ServiceManager.Portal.SharePointSite, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=9396306c2be7fcc4"
Namespace="Microsoft.EnterpriseManagement.ServiceManager.Portal.SharePointSite.Webparts" TypeName="KnowledgeArticleWebpart" Safe="True" SafeAgainstScript="True" />
Note: Make sure the assembly version and PublicKeyToken match the assembly that is GAC’ed on the machine already.
You can also copy this line from the web.config file of the sample site's parent site if easier.
4) Add this line to the web.config of your SharePoint site's parent site to specify Web content server URL.
<add key="SMPortal_WebContentServer_URL" value="http://SM11023:8080/ContentHost/ClientBin/" />
You can also copy this line from the web.config of the sample Service Manager SharePoint site's parent site.
5) Copy Webpart string resources in to the GlobalResources folder of your SharePoint site's parent site.
To find the specific Service Manager Webpart string resources files, you have two options:
· Copy the files from the App_GlobalResources folder of the Service Manager SharePoint site's parent site. App_GlobalResources folder is located
(Note: the (number) in the path above is a random number generated for the Sharepoint site.)
· Browse to “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\SMPortalSharePointSiteFeatures” where all Service Manager specific SharePoint files are copied when you installed sample Service Manager SharePoint site.
To find GlobalResources location of your SharePoint site’s parent site, explore the parent site in IIS and it should take you to a path like this: “C:\inetpub\wwwroot\wss\VirtualDirectories\(number)\App_GlobalResources”
6) Add the specific Service Manager Webpart to your SharePoint site by editing any page and selecting Insert a new Webpart, then select the specific Service Manager Webpart and Add it to your page.
Ouh... this is hard way... Same can be done much easily:
1. Add new property in IIS (step 4 from this post), this can be done via IIS snap-in.
2. Find the "Microsoft.EnterpriseManagement.ServiceManager.Portal.SharePointSite.wsp" at existing installation and add it to target Sharepoint:
3. Activate solution for site collection (Site Settings -> Site Collection Features)
Step 2 avoid as to manually copy files, adding to GAC and etc.
When do the step 6 from this blog post.
Hi Anton, Thanks for the feedback!
The solution you mentioned is valid if you don’t mind deploying all the features shipped as part of “Microsoft.EnterpriseManagement.ServiceManager.Portal.SharePointSite.wsp” to your SharePoint site/site collection.
However this blog is focusing on a clean way of deploying a specific SM Webpart (not all) to your SharePoint site without deploying any other feature to your site. That’s the common customer request as mentioned in the first line of this blog!
To clarify: SM SharePoint Site Package “Microsoft.EnterpriseManagement.ServiceManager.Portal.SharePointSite.wsp” includes not only SM Webparts but also other features like SM SharePoint SiteTemplate, SM Sharepoint Site Master Page, SM Sharepoint Site CSS, SM Sharepoint site Theme, etc… as a result when you deploy this package to your SharePoint site, all these features will get deployed to your site! Depending on your site requirement, this could cause other issues and you may want to clean up these features from your site.
Thanks Martha to respond. You right about additional features but I can't see any potential issues with that. Even if all that themes, styles and etc will be deployed - they just added to collections and will not be used until someone create new site based on this templates\thems. Or I miss something?
Anyway, here is step-by-step guid to deploy Microsoft.EnterpriseManagement.ServiceManager.Portal.SharePointSite.wsp. __blog.scsmsolutions.com/.../install-scsm12-web-parts-to-existing-sharepoint
If I alreay have a Sharepoint server in production, running other websites, can´t I just install the SCSM SSP direct on that server?
What will happen then?
Will it affect the other systems?
Yes, you can install the SCSM SPP on an existing SP server/farm. It will add a new site and shouldn't affect any other sites already on the SP server.
What if you are moving from 2010 using the portal on IIS to 2012 and you don't have Sharepoint?
@Rob - You can use SharePoint 2010 Foundation Edition which doesnt cost anything.
I would REALLY like to be able to install the web parts on our Sharepoint Online (Office365) site. I would be ok installing the whole WSP as Anton suggests however I do not think it is possible for me to set the Application property SMPortal_WebContentServer_URL in a shared environment. And, as a side note, it would be most helpful if the WSP file could be accessed without doing a local install.
I agree with Anton, it would easier to jsut deploy the WSP, if you dont want the master page, and other webparts available, just remove them after deployment. That is a much more supportable senario.
Done the way this blog discribes, can become a disaster recovery nightmare, if the person that originally set it up is no longer available, and didnt document thier steps.
My personaly approach has always been to avoid manual web.config edits when at all possible. And in this situation it seems very possible to avoid it.
Yeah I have to agree with Anton. Much better to just install the product and remove parts you don't want later. For most System Center professionals there is limited access to SharePoint development anyway, and all of this just seems like a pain in the neck. Cool stuff, but I for sure would not implement the Service Catalog this way.