The feedback on the self-service portal has consistently been that it needs to be more customizable. That is by far the #1 feedback item on SCSM 2010. The types of desired customizations typically fall into these categories:
Most of these things ideally would be configurable options on the web parts and there would be some sort of administrative UI which allowed you to change these things. Making things like that configurable via an admin experience requires significant development and test time which unfortunately we didn’t have in the 2010 product development cycle. That is what we are shooting for in the vNext version (currently code named “R2”) of the SCSM portal that we are super excited to show you at the Microsoft Management Summit for the first time. The vNext portal will be based on SharePoint 2010 (any version including Foundation). It will be made up of web parts. You can change the text shown on labels, change fonts, change the style, change the layout, etc. using standard SharePoint administrative experiences and tools. It will be relatively easy to add new content to the portal by creating web parts that use the SDK and plugging them into the SharePoint site. You will also be able to add languages or change display strings by modifying the string resource files. We will let the user choose which language they want to display the console in. The portal will be a single SharePoint site instead of an analyst portal and an end user portal, but the user experience will be role based so people only see what they need to see. In short, it will be what we all wished the SCSM 2010 portal could have been.
In the meantime, we know that the lack of customizability of the portal is a pain point for customers right now. Many of the modifications that customers want to be able to do are relatively trivial to make if you had the source code and a little bit of know how. To help customers achieve their goals for a customized self-service portal in the near term, we are releasing the source code to the portal today. Not everybody has Visual Studio and a developer on hand to make these customizations, but a lot of our customers do. Some of our SCSM administrators, consultants, and SI partners are even developers at heart and are excited about the possibility of making the self-service portal do what they want it to do. We realize this isn’t ideal to have to modify code to get what you want, but it is better than not being able to modify it all! Hopefully this will suffice while we are busy building the new portal.
But we also have another fun surprise! We are also including a newly styled portal in this download that you can deploy with copy/paste of some files. The new site looks like this:
It is styled to look similar to the SharePoint 2010 default site template:
Looks a lot better huh?!
This updated version of the portal is also intended to show you some of the possibilities for customizing the portal. The updated version of the portal has the following modifications:
(new) vs. (old)
Results in a new change request being created with an automated activity that looks like this:
When the automated activity kicks in it will create a new user in Active Directory using PowerShell:
I’ve commented most of the code where I have made modifications with “PORTALMOD” so you can search through the code base and easily see all of the modifications that I made.
So – to recap, this new release includes:
I’ve also attached the MP to this blog post that is need to make the new user provisioning scenario go. Please don’t use this in production though! I have spent minimal time testing it as it is just an example of what you could do. To deploy it you just need to import the MP .xml file and put the workflow .dll file in the C:\Program Files\Microsoft System Center\Service Manager 2010 directory.
I also want to discuss what the roadmap is for the portal. The SCSM 2010 SP1 portal is an ASP.Net web site that hosts web parts. Those web parts can be put on a SharePoint site. The results are not great but you can do it and it can be made to look good now that you have the source code. So, in that sense what we have done for the SCSM 2010 and what we are doing for the SCSM vNext portal are similar, the only difference being that in vNext we will require SharePoint as the hosting framework for the web parts. So – in theory you could port your web parts that you develop today to run on the vNext portal since it is all just SharePoint and web parts. The only little detail there is that the web parts you create today using the source code provided will use a different way of accessing the data than the vNext portal will. We are still sorting out the details of that and whether or not you could mix/match 2010 web parts with vNext web parts on the same SharePoint server, but I think we’ll be able to make it work.
Lastly, I just want to make sure that everyone is clear on what this release is. Think of it as a shortcut to developing your own custom portal using the Service Manager SDK. We have effectively shown you how to do it and provided some sample code . Whatever you create is like you created it from scratch. If there is a bug in a modified portal then you won’t be able to call Microsoft support about it. I hope that makes sense and seems fair. If there is a bug in the SDK somewhere then of course you can call Microsoft support about it. Of course we are here to help you on the forums and blog if you need some help getting started, have questions, or want to discuss a bug.
I’m really looking forward to seeing what people do with this. We have had some internal groups here at Microsoft take this source code and do this already and it has worked out great.
Download the files from the Microsoft Download site here:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=65fbe0a3-1928-469f-b941-146d27aa6bac&displaylang=en
You can also download this from MSDN or TechNet if you are a subscriber - the release there is called the 'Service Manager Portal SDK'.
Big THANKS to Paresh (the Microsoft developer on the original portall that helped pull this together), the marketing team for funding the portal style update, and all the community beta testers that validated this release for us!
Enjoy!
@Torben - yeah, try copying over all the .config files.
@Travis.
I have tryed copy all the files, still the same problem..
I think, I have to wait until vNext is Releast .. ;-)
Give Erling a copy if you see him at MMS2011 ;-)
Can someone please confirm that this only modifies the ENDUSER, my ANALYST has remained the SAME
@Fletcher -
Confirmed, only the EndUser portal style is updated.
@Travis -
Thanks, btw, the look is great, can't wait for vnext :)
Thanks Travis, finally got around to implement this, works great!
Travis, still loving the portal, but the new update incident function for end users, can you think of a quick solution to make this generate a notification to the analyst, or at a minimum change the incident status when an update is made by the end user?
@Trana010 -
Can you write code? Or are you looking for a codeless solution?
@Travis
Looking for the same solution as Trana010. Our app guys have had a look at te source code but are still scratching their heads about how to make the incident status change when it is updated from the portal.
Any help would be greatly appreciated.
@Bren & @Trana010
Assuming you are using the new version of the portal your developers will need to update the UpdateIncidentInternal method in RequestDetails.cs.
Steps:
1) Create a new status enumeration for 'Updated by end user on portal' or something like that (if you want to ; or you can use an existing status)
2) Get the GUID of the status using a query like this replacing 'Other problems' with whatever the display name was that you chose):
SELECT
EnumType.EnumTypeId, LocalizedText.LTValue, EnumType.EnumTypeName, LocalizedText.LTStringType
FROM ServiceManager.dbo.EnumType INNER JOIN
ServiceManager.dbo.LocalizedText ON EnumType.EnumTypeName = LocalizedText.ElementName
WHERE (LocalizedText.LTValue LIKE 'Other Problems')
3) See how I changed the status to active in that method as an example of what you need to do. Instead of passing the active GUID, pass your GUID.
A bit over my head unfortunately and I am a one man shop when it comes to this stuff. Is the code supposed to go in the internal static bool "updateincidentinternal" of helper.cs?
Couldnt I just change the status in 1 line on the else statement of the updateincidentinternal to whatever I added to the incident status lists in helper.cs?
@Trana101 -
Yes - you've got it. You just need to update the else block to look like this:
else
{
//Since it is not currently resolved just add an end user comment
IDataItem updateCommentLogItem = (IDataItem)sdkQueryUtility.CreateEmoFromClass(WebpartsConstants.CommentLogTypeId);
updateCommentLogItem[DataItemConstants.Id] = Guid.NewGuid().ToString();
updateCommentLogItem[WebpartsConstants.EnteredDate] = DateTime.Now;
updateCommentLogItem[WebpartsConstants.EnteredBy] = HttpContext.Current.User.Identity.Name;
updateCommentLogItem[WebpartsConstants.CommentLogComment] = strLogComment;
requestDataItem[WebpartsConstants.UserCommentsComponent] = updateCommentLogItem;
IDataItem updatedByUserStatusEnumeration = sdkQueryUtility.GetEnumeration(new Guid("your GUID here"));
requestDataItem[WebpartsConstants.IncidentPropertyStatus] = updatedByUserStatusEnumeration;
}
Notice the two new lines at the end of it.
Thanks Travis, works great!
Travis,
According to the Doc I should have just been done with step 6. After building the solution, what do I do with the modified files? Do I need to create a class, form and workflow as stated in the doc at step 7? Thanks in advance.
Nevermind, I complicated things, what I needed to do was just copy the files to the inetpub folder. Problem resolved :)