Deploying the Service Manager Self-Service Portal web parts with SharePoint Services 3.0

Deploying the Service Manager Self-Service Portal web parts with SharePoint Services 3.0

  • Comments 35
  • Likes

System Center Service Manager includes two types of web parts as follows:

1.      End user specific web parts. E.g. Web part for global announcements.

2.      Analyst specific web parts. E.g. Web parts for manual and review activities.

One deployment option is to manually deploy the web parts to SharePoint – this can be cumbersome. This option involves copying all the web part assemblies, modifying the site’s web.config file to register the web parts as safe controls, creating a custom security policy file or adding the assemblies to global assembly cache (GAC) and so on.

The other deployment option is to deploy the web parts using a solution package (WSP). A solution package is a cabinet file containing all the web part assemblies, solution, and feature manifests, required web part resources, etc.


  1. Web Parts solution file is attached. For System Center Service Manager 2010 RTM version use this file    For SP1 use this file 
  2. SP1 solution file contains both end user and analyst portal web parts.
  3. An advantage of using solution deployment is that all the changes made to web.config file, and the web application are atomic and can be easily undone by retracting the solution using the WSS solution management.

Steps for deploying SM web parts solution to a SharePoint web application:

  1. Install SM portal using the Setup on the SharePoint server. This is required for v1 even if you don’t intend to use the out of the box Service Manager Portal.  After you have installed the SM portal and WSS 3.0 it should look like this in IIS -



2.  Add the solution package to the solution store. Go to the SharePoint central administration site->Operations->Solution Management. Since there is no way to do this from the UI you need to use  the command-line stsadm tool. You can copy the WSP file to where stsadm is installed for convenience. stsadm ships with WSS 3.0 or Microsoft SharePoint Server 2007 and can be found at “%COMMONPROGRAMFILES%\Microsoft shared\web server extensions\12\bin”. Remember to use the correct WSP file either RTM or SP1 based on your installation. Adjust the stsadm command line to reflect the correct file name.

          stsadm -o addsolution -filename ServiceManager.Webparts.SP1.wsp


3.  Then deploy the solution to the site from the central administration solution management website or by using stsadm tool. To deploy using the UI go to the SharePoint Site Solution Management UI and click the web parts WSP that we added to the solution store in the last step. Then deploy it by clicking Deploy Solution as shown in the picture below.



This will deploy the required web part binaries to the web application bin folder along with their resources. It will also mark the web parts as safe controls by adding the following two SafeControl elements to the SafeControls element web.config file -

<SafeControl Assembly="Microsoft.EnterpriseManagement.ServiceManager.WebParts,   Version=7.0.5000.0, Culture=neutral, PublicKeyToken=9396306c2be7fcc4" Namespace="Microsoft.EnterpriseManagement.ServiceManager.WebParts" TypeName="*" Safe="True" /> 

<SafeControl Assembly="Microsoft.EnterpriseManagement.ServiceManager.Portal.Common, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=9396306c2be7fcc4" Namespace="Microsoft.EnterpriseManagement.ServiceManager.Portal.Common" TypeName="*" Safe="True" />

Note:  Advantage of using solution deployment is that all the changes made to web.config file, and the web application are atomic and can be easily undone by retracting the solution using the WSS solution management.

4.    There is one thing you still need to change in the site’s web.config file. Open the site’s web.config and comment out the trust element. If you don’t want to remove the trust element the recommended option is to define a new CAS policy file and use it. I will provide more details on that in another blog. Another option is to add the web part binaries to GAC.

<trust level="WSS_Minimal" originUrl="" />

5. Go to Site Settings->Site Features and activate the Service Manager web parts feature. This will populate the web part gallery of the site with the SM web parts.


6.   Go to IIS and change the application pool identity of the SharePoint services site (where you want to deploy the solution package) to SM SDK service account.

7. In the Features view of the SharePoint site make sure that only windows authentication is enabled.


8. Change the session state mode of the SharePoint Site to “Use Device Profile”.

9. Create the web part pages using the web parts populated to the web part gallery in the last step.






Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Service Manager 2001 and Sharepoint really sucks if I need to do all these hack to make it work.

    Bot products are made by Microsoft, so go and make them work together by default.

    I am a system engineer and I don't want to edit manually web.config files, or mess with GAC, and DLL's just to get the product installed. This is supposed to be a basic function of the setup.exe and not hacking.

    Of course I have tried to follow these steps, and also consulted with the deployment guide, now I got a Sharepoint site which won't even load.

    Either provide a full step by step guide, or let the setup.exe deploy the Sharepoint integration.

    Im really pissed off now, whith this amateur approach. Half a day of mine is gone hacking DLL's into GAC, and tweeking Sharepoint without any success.

  • Dan_MS,

    With the steps outlined in this blog you don't need to

    add any DLL's to GAC and the steps are pretty much a standard way to deploy web part features to SharePoint.

    What error are you getting while loading your SharePoint site I can help you fix it.

  • So then if I'm understanding the steps correctly above, you're basically saying if we want to deploy this in a production environment we should create a new SharePoint web application entirely as the SM SDK account is required to be used as the app pool account.

    As we aren't going to change our "main" web app's application pool account to the SM account, does that mean we're basically stuck unless we do the new web app?

    Also, how come we need to define a new CAS policy?  I've never had to do that manually for any other web parts before...

  • Seanny,

    Yes for the first question - if you cannot change existing web app's application pool account to SM Service account w/o any side effects then you will have to create a new web application.

    No to the second question about CAS file. I will provide a CAS policy file in another blog soon. In SM SP1 there is a plan to ship a web part WSP file which will inlcude the CAS policy as well. Please note that that is just a plan as of now.

  • What a disappointment

    The portal can't be install on a 32Bit system.

  • @Pedro901:

    Welcome to the 21st century. Hey, SCSM is a brand new product launched in 2010 and you want to have 32-bit compatibility? Why? Do you really have hardware that do not support 64-bit?

    Peter Forster, MVP Virtual Machine, Austria

  • Hi Paresh,

    A good article here, i'm not the sharepoint admin but following this guide has been helpful however i have some questions to ask;

    1. when installing the sm web portal do i have to be logged on to the moss server as sm admin?

    2. how exactly do i comment out the trust element functions and do i also have to do it for the medium or just the minimal?

    thanks, i would really appreciate your response.

  • Hi. Is is possible to use the web portal such that we as a service provider can use it to ask customers for more information; and for our customers to provide updates to us?


  • I cannot seem to find the following file anywhere:


    Needed to add and deploy


  • Euh, forget my question. Looks like it wahe bottom of the procedure.

  • Everything works up until I try to add a webpart (eg. 'Create Request'), then remote connections to this site (from within the same subnet) don't work anymore (mind you, the site was easily reached a second before I added the webpart). If I connect to the site through IIS locally, I have no problem and can even see the newly added webpart. What could be wrong?

  • Extra on these web parts: I am able to see the newly added web part locally on the IIS server, but I also see an error on the page: Automation server can't create object. default.aspx, line 697, Char 26.

    This error dissapears when I remove the web part.

  • I got rid of the 'Automation server' eroor by installing the portalclient on that webserver, but still no luck with the remote connections to it. I get a chance to login, but then progressbar stays forever. When I shut down the application on the webserver, the client does react by saying 'service unavailable' so it knows where to look.

  • Hm, am I really the onlyone where this doesn't work?

    Anyway, extra question on the procedure, point 7, described above:

    'Make sure that ONLY Windows Authentication is enabled.'

    Does this mean that I have to disable the ASP.NET Impersonation (which is enabled by default)?

    I get an error (locally and remotely): 'Cannot complete this action. Please try again' when I try to connect to the site.

  • @Gertjan Maeckelbergh

    Yes should have only the windows authentication enabled.

    For accessing the page containing create request webpart make sure you install the portalclient control on the remote clients accessing it.