Solution to clean User Input from Service Manager Portal and commit it to the Action Log

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 Smile).
  • 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):

image

  • 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):

portal

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:

console

Incident:

UserInput_console3

4) How the End-User see it:

portal1

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:

  • SMlets installed on the SCSM Management Server (workflow server) : http://smlets.codeplex.com
  • 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)

Download

Download from techned gallery here:

http://gallery.technet.microsoft.com/Commit-User-Input-from-a47d7afe

The zip file contains the following:

  1. Coretech.PSWorkflow.SetUserInputToActionLog.xml : The unsealed Management Pack that contains the workflow (feel free to seal it if you want)
  2. PSWorkflow_SetUserInputToActionLog.dll  : Assembly dll file
  3. SetUserInputToActionLog.ps1 : Script file if you want to check it out or reuse elsewhere.

Installation instructions:

  1. Copy PSWorkflow_SetUserInputToActionLog.dll  to your Service Manager install folder, e.g. C:\Program Files\Microsoft System Center 2012\Service Manager
  2. Import the Management Pack Coretech.PSWorkflow.SetUserInputToActionLog.xml
  3. Enjoy!

If you have any feedback on this, just throw a comment or write me an email.

The solution is provided “as-is.” You bear the risk of using it.

By | 2013-09-20T16:32:33+00:00 September 20th, 2013|Service Manager (SCSM)|32 Comments

About the Author:

Morten Meisler

Consultant / Developer / Trainer

Key areas / products:

  • System Center Service Manager
  • System Center Operations Manager
  • Automation (System Center Orchestrator / Service Management Automation (SMA))
  • Development: C#.Net, Powershell, SQL, Web development / HTML5 (Javascript,jQuery,CSS,HTML, Wordpress etc.)

32 Comments

  1. Anders October 4, 2013 at 10:31 - Reply

    How much of an impact does this additional workflow have on performance? Ie. any experience with deploying this on systems with 100’s of new incident and service requests each day?

  2. Morten October 4, 2013 at 11:32 - Reply

    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.

    • Morten October 4, 2013 at 11:39 - Reply

      The measure was tested on a VM test-server with Win2008R2, 8gb ram, 4 cores, non-ssd. So it’ll probably run faster in a prod environment. But will report back asap

  3. Morten October 7, 2013 at 13:34 - Reply

    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.

  4. Kenneth Andersen October 30, 2013 at 20:25 - Reply

    Hello, I like the “workaround” 🙂

    But can I get the workflow to run then iam using the Exchange Connector ? So that the first e-mail description is loaded to the action log?

  5. Morten October 30, 2013 at 21:51 - Reply

    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.

  6. […] blog: Solution to clean User Input from Service Manager Portal and commit it to the Action Log @ Coretech […]

  7. Anders Spælling January 24, 2014 at 10:59 - Reply

    Isn’t it best practice to do workflows in Orchestrator (or SMA), and not in the builtin workflow engine?

    og nu 😉

  8. Morten January 24, 2014 at 11:49 - Reply

    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.

  9. Vincent February 10, 2014 at 14:09 - Reply

    Thanks for this MP. The action is log created, but the MP status still shows that it fails in the last activity:

    System.TimeoutException: The operation has timed out.
    at Microsoft.EnterpriseManagement.TaskRuntimeManagement.ExecuteTaskInternal[T](IEnumerable1 targets, Guid taskId, TaskConfiguration configuration)
    at Microsoft.EnterpriseManagement.TaskRuntimeManagement.ExecuteTask[T](IEnumerable
    1 targets, ManagementPackTask task, TaskConfiguration configuration)
    at Microsoft.ServiceManager.WorkflowAuthoring.ActivityLibrary.TaskExecutor.RunTask(String sdkServerName, Guid taskId, IList1 taskTargetIds, Dictionary2 taskArguments, Int32 taskTimeout)
    at Microsoft.ServiceManager.WorkflowAuthoring.ActivityLibrary.RunTaskActivity.Execute(ActivityExecutionContext executionContext)
    at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity, ActivityExecutionContext executionContext)
    at System.Workflow.ComponentModel.ActivityExecutorOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime)
    at System.Workflow.Runtime.Scheduler.Run()

    Would you please have any idea? NB: I am using SCSM 2012 R2.
    Thanks. Vincent.

    • Morten February 10, 2014 at 14:34 - Reply

      Hi Vincent,

      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.

  10. Vincent February 11, 2014 at 9:33 - Reply

    Hi Morten, could you please drop me an email, so that I can reply to you with screenshots? Thanks. Vincent.

  11. Vincent February 11, 2014 at 12:17 - Reply

    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.

  12. Morten February 11, 2014 at 22:59 - Reply

    Hi Vincent,

    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?

  13. Tom April 17, 2014 at 21:53 - Reply

    Was a solution ever found for Vincent’s problem? It appears I am having the same one.

    Thanks,

  14. Morten April 17, 2014 at 23:34 - Reply

    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.

  15. Tom April 21, 2014 at 17:39 - Reply

    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.

    Thanks,

  16. Kenneth Andersen May 1, 2014 at 21:41 - Reply

    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.

    Workflow: PSWorkflow_SetUserInputToActionLog.WindowsPowerShellScript.d6d319c2_71e5_49c2_b756_e5aee5a96685

    Instance: CT-SCSM02.egdk.it-corp.net

    Instance ID: {FAE59522-8AE1-FC63-7EDB-2DBDD94E29AA}

    Management Group: EG_TESTENV

    Full Exception Text:

    Microsoft.EnterpriseManagement.HealthService.HealthServiceException: 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). —> System.IO.FileLoadException: Could 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)
    File name: ‘Microsoft.EnterpriseManagement.Modules.PowerShell, Version=6.0.4900.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’
    at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)
    at System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
    at System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
    at System.Reflection.Assembly.Load(String assemblyString)
    at Microsoft.EnterpriseManagement.HealthService.Internal.ManagedHostHelper.LoadModuleType(String moduleAssemblyName, String moduleTypeName)

    WRN: Assembly binding logging is turned OFF.
    To enable assembly bind failure logging, set the registry value [HKLMSoftwareMicrosoftFusion!EnableLog] (DWORD) to 1.
    Note: There is some performance penalty associated with assembly bind failure logging.
    To turn this feature off, remove the registry value [HKLMSoftwareMicrosoftFusion!EnableLog].

    — End of inner exception stack trace —
    at Microsoft.EnterpriseManagement.HealthService.Internal.ManagedHostHelper.LoadModuleType(String moduleAssemblyName, String moduleTypeName)
    at Microsoft.EnterpriseManagement.HealthService.Internal.ManagedHostHelper.Microsoft.EnterpriseManagement.HealthService.Internal.IManagedHostHelper.LoadAndInitializeModule(String moduleAssemblyName, String moduleTypeName, UInt32 countInputPorts, Boolean doesModuleHaveOutput, String configuration, Byte[] stateBlock, UInt32 stateBlockLength, Object& moduleReference, Object& moduleInputReference, Object& moduleInputBatchedReference)

    at Microsoft.ServiceManager.WorkflowAuthoring.ActivityLibrary.WindowsPowerShellScript.Activity_Closed(Object sender, ActivityExecutionStatusChangedEventArgs e)
    at System.Workflow.ComponentModel.ActivityExecutorDelegateInfo`1.ActivityExecutorDelegateOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime)
    at System.Workflow.Runtime.Scheduler.Run()

  17. Kenneth Andersen May 1, 2014 at 21:44 - Reply

    – Event 3: PSWorkflow_SetUserInputToActionLog is executing
    – Event 4: windowsPowerShellScript1_SetUserInputToActionLog is executing
    – Event 9: windowsPowerShellScript1_SetUserInputToActionLog.runTaskActivity1 is executing
    – Event 14: windowsPowerShellScript1_SetUserInputToActionLog.runTaskActivity1 is Closed
    – Event 17: windowsPowerShellScript1_SetUserInputToActionLog is Faulting
    – Event 18: windowsPowerShellScript1_SetUserInputToActionLog is Closed
    – Event 20: PSWorkflow_SetUserInputToActionLog is Faulting
    – Event 21: PSWorkflow_SetUserInputToActionLog is Closed

  18. Morten May 2, 2014 at 10:39 - Reply

    Hi Kenneth,

    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?

  19. Michael November 4, 2014 at 21:05 - Reply

    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?

    Regards
    Michael

  20. Morten November 5, 2014 at 10:58 - Reply

    Hi Michael,

    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.

    I’ll try it out in my test env soon enough.

  21. Morten November 5, 2014 at 10:59 - Reply

    Well the services stops during upgrade, but a new restart never hurts 🙂

  22. Nataly November 13, 2014 at 11:03 - Reply

    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

  23. Morten November 17, 2014 at 13:56 - Reply

    Hi Nataly,

    Thanks for the feedback.

    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

  24. Morten November 17, 2014 at 16:50 - Reply

    Hi Nataly,

    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.

  25. Nataly November 18, 2014 at 8:39 - Reply

    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.

  26. Morten November 18, 2014 at 9:41 - Reply

    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

  27. Morten November 18, 2014 at 9:45 - Reply

    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

  28. Martin January 21, 2015 at 10:56 - Reply

    Hello,

    thanks for MP. It is working on SCCM 2012 R2 UR4, but I have another problem. Your script will clean user input information. Is there any option how to change script in MP to not clean user input?

    Thanks

  29. Morten January 21, 2015 at 11:04 - Reply

    Hi Martin,

    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.

  30. Miro January 21, 2015 at 21:24 - Reply

    Hi,

    is it possible to change the MP to store data into Comment log instead of Action log?

    Thanks
    Miro

Leave A Comment