This solution converts end-user userinput from Service Manager Portal into a clean formated string table and commits it to a new Action Log entry in top. The script can be modified for other purposes: e.g. used in Orchestrator or appended to the description field.

I made this powershell workflow script because of different wishes from customers all related to complains about the user input on the Service Manager Portal:

Problem:

End-Users can’t see what they typed on a request offering in the service manager portal.

Even if the formular only contains limited questions (e.g. Title and Description) the description field on the portal can only show 3 rows (yes, it’s true ).

The User Input on a Service Request can be hard to read for the analysts as it is printed out in XML (the below happens if you want to display Config Items on the portal via Query Result option):

The User Input on a Incident is not shown at all! The inputs are mapped to the incident form, but could be mapped to different places and might be hard to find. Although Anders Bengtsson made a solution to come to grips with this(http://contoso.se/blog/?p=3121). it doesn’t account for the xml printout and the End-user still can’t see his/her user input. Allthough, you could probably use a combination of this and my solution here.

Solution:

So, to solve this for both end-users and analysts I decided to commit the user input to the action log instead. And at the same time clean the user input to handle config items and enumerations. This way the end-user are able to read all his/her previous answers and the Analyst can also view the user input on the General panel in the top of the Action Log.

Scenario:

Ok so here is what happens:

1) The end-user makes a new Request from the Service Manager Portal (either Incident or Service Request):

2) A workflow with a powershell script runs that triggers on Work Item created where User Input is not empty (this way we can get both Incidents and Service Requests and reasure it’s coming from the portal). The script then cleans the user input into a formated string table and commits it as a new actionlog entry.

3) How the Analysts see it:

Service Request:

Incident:

4) How the End-User see it:

As a bonus you can also see the related request offering which makes it a little easier for analysts to quickly recognize the type of request.

Requirements:

Service Manager 2012 SP1 with UR2 or later (version numbers in references could be modified to support older versions, but it’s not tested on these. Just write to me if you want a version compatible with older versions)

Good question. I’ve not done any stress testing yet, but I will do so when I can and report back. The script itself is measured to complete the first time in 13 seconds and subsequent times for 300ms. I’m not sure if the procedures are cached when it runs the script through a workflow though, but I’ll investigate further when I got time.

I’ve done some stress testing now and observed the running time and if any workflows falling behind (Travis’ sql query)

Making 20 incident and service requests within 5 minutes on the portal did not seem like a problem. The only workflows falling a little behind (5-7minutes) were the notification workflows sent to affected user. But it did that as well without this script.

But there is an error logging to the Operations Manager event log on the server if something goes wrong (eventid 912). I’ll be happy to get the output from that if errors occurs.

Well the script only takes care of userinput, so you’d have to modify it to grab the description property instead and commit that to the action log description. The rule could then be set to Incident Created where source = E-mail.

As I wrote in the top, you are welcome to use the script within a runbook. Not all people have Orchestrator though. I’m not sure why it would be bad practice to use the workflow engine, it’s there to be used. I suppose you might as well “outsource” all your workflows (notifications, group changes etc.) if that were true.

Thanks for using the MP, I have not seen that before. But it looks like the workflow times out for some reason. It has a timeout set to 600 = 10 minutes. You can change this in the MP, but it should be more than enough though. So I need some more info to help:

Does it do it for all kinds of Request Offerings?
Can you show / describe the request offering(s) it does the error for?
Is there any errors created in the event log? Search in the Operations Manager log after eventID 912. If the script made an error it should be there.

Hi Morten, the user input entry is immediately created in the action log, but somehow it hangs somewhere and times out. the MP fails for both IR and SR. No event ID 912 in the event viewer.
In the workflow status, I can see:
– Event 3: PSWorkflow_SetUserInputToActionLog is executing
– Event 4: windowsPowerShellScript1_SetUserInputToActionLog is executing
– Event 9: windowsPowerShellScript1_SetUserInputToActionLog.runTaskActivity1 is executing
– Event 12: windowsPowerShellScript1_SetUserInputToActionLog.runTaskActivity1 is faulting
Thanks for your help.

Could you send your request offering in the management pack, then I can try to troubleshoot further. Just send it to: mme at coretech dk. Screenshots/descriptions of your request offering is also ok, but the mp is most optimal. Also what language is your management server set to?

Hi Tom, we concluded it was some form of security issue. Try unblocking the dll file in the install folder (if it’s blocked). I got vincents RO and it worked on my setup. So I couldnt replicate the error. I recall it was no issue anyway as it ran fine, so the workflows error could be ignored, but not optimal of course.

Please let me know if the dll thing works, if not Ill try to see if I can provoke the error in some way.

That security problem appears to have been resolved by unblocking the DLL. The workflow still says it’s failing but runs mostly fine. I say mostly because it looks like only the first of how ever many fields is being grabbed and then the User Input item in the action log only says “Undefined.”

We are trying to set this up with Incidents and I have extended the class to add extra text fields to map the user inputs to.

Hey..
Iam getting this error. do you have any idear?
System.Exception: Loading managed module type in assembly “Microsoft.EnterpriseManagement.Modules.PowerShell, Culture=””, PublicKeyToken=31bf3856ad364e35, Version=6.0.4900.0″ with type name “Microsoft.EnterpriseManagement.Modules.PowerShell.PowerShellProbeActionModule” failed with error “The module assembly “Microsoft.EnterpriseManagement.Modules.PowerShell, Culture=””, PublicKeyToken=31bf3856ad364e35, Version=6.0.4900.0″ could not be loaded. The exception was: \nCould not load file or assembly ‘Microsoft.EnterpriseManagement.Modules.PowerShell, Version=6.0.4900.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040).”.

This may be because the type or assembly could not be found or the type does not have the MonitoringModuleAttribute.

Some troubleshoot steps/information gathering:
1) What version of SCSM are you using ? I’m asking because the error resembles the issues fixed in SCSM 2012 SP1 UR2 and SCSM R2 with powershell workflows not working. I have not tested the solution with the latest Update rollup (Released last week).
2) What operating system is it?
3) Is the dll file put in the SCSM primary workflow server – installation folder and unblocked?
4) Check the eventlog on the server, under Operations Manager – eventid 912. (But seems like the error happens before execution of script).
5) Does the script work fine if you test it seperately in ISE with a test case and request offering?

Hello,
seems like it is not working with SCSM 2012 R2 UR4. I get the error message that Microsoft.ServiceManager.WorkflowAuthoring.Common Version=7.0.5000.0 could not be found. The dll is available in the Service Manager installation folder but with a higher version number. Could this be an issue?

Thanks for alerting this. I will need to look into that, but then it might be a problem with all powershell workflows as it’s dependent on that file. However a new version should be back-compatible with older versions, so it would be odd if that is the case. Have you restarted the system center services after upgrade? The monitoring agent and configuration service. This ensures the loaded dlls is ajour.

Hello!
Thank you for solution – it’s help me very well
There are some features in solutions work:
1) If you use two or more questions with identical name in request offering, an error occurs. The error reason is in using ordered dictionary for question table. The workaround is using array than ordered dictionary.
2) If user input formatted table size is larger than 4000 symbols, there is exceeding error. The workaround is taking only first 4000 symbols with substring function

1) I’m aware of the issue, as far as I remember it was a tradeoff because ordered dictionary had the advantage that the order of question/answer followed the same order of the request offering and I couldn’t get this to work with an array. But with that being said it is probably doable in some way, it’s over a year ago so I will look into that when I get time :). I found it unlikely that you had the same question twice, but I realize now that if you have a long Offering, a question like: “Other” or something generic is needed.

2) Thanks for this, I will put it on the fixlist also. As a best practice you normally also constrain the size of each string input in the Request Offering to the size of the string property size on the class (e.g. 256 or 4000). Otherwise you can’t submit the ticket. But this must an issue related to comitting the actionlog entry. It’s funny, because making a new actionlog via SDK will automatically trim the last symbols above 4000, but maybe it’s different with powershell

I just tested the 2) regarding above 4000 symbols, and I am able to commit a text above 4000 characters to the actionlog though the last symbols will get trimmed (just like in the sdk). So I’m wondering where you are getting the error, can you paste the error message? I suspect that the error is from the SMportal, which then makes sense cf. my answer above regarding constraining the user input text fields.

Hello Morten,
I’m not sure about second issue (with 4000 symbols), because not tested it specially. May be the error reason was different. I change the script and add UserInput copying to workitem description field and related activity notes field, so I cannot test only action log adding.

Alright I’ll leave it for now then, if you encounter the error in the future then please post here. I believe the problem is due to submitting the ticket via portal and not due to the script, but if you find something then please post

Regarding the array thing it is not something I have time for right now as it would require some structural changes to the code and needs some testing as it could have a counter-effect on other stuff. But if you have made a workaround for the duplicate issue already I’ll be happy to take a look

Oh yeah I just re-read your reply. If you commit something to a string property like the description field it is true that you need to substring the remaining words, that is not the case with the actionlog. But in any case I could make it do so anyway in the GetQA function so it’s ready to be applied on other properties. Thanks

I’m not sure I understand you, what do you mean with it’s cleaning? I know the title is a little twisty as ‘clean’ could mean delete (bad danish translation I know), it really just formats the input into a table-like structure. The only part that is being removed is the xml-metadata coming from a Query Result input, which makes sure it only output the DisplayName. If you want to remove or change the formatting you can comment out or edit that part in the code within the powershell function.