Best Of
Re: Quick assign to analyst, SMLets?
I saw this the other day on the main/larger thread but saw a couple of responses that kinda covered things. But I'll cover them here as well:
- Custom Events are really only documented in so far as name and the descriptions contained therein for those functions. The repo has a handful of very direct examples. Some functions contained in the custom events script also feature verbose explanations of variables such as when using Custom Rules
- Per my cited comment above, while powerful. Custom Events create the opportunity to bring the connector to a grinding halt if written incorrectly. All in all, its a fine line of - yes these exist and you can use them, but its undertaken entirely at your own risk as everyone's custom events could be different and I/others would have no way of quick and easily troubleshooting.
- When it comes to debugging Custom Events. You'll need to open the SCSM Console, head over to Adminstration → Settings → SMlets Exchange Connector settings. In there, you'll go the workflow tab and disable the workflow then save. The connector is now no longer running. On the SCSM server, or using a run as account - you'll need to open PowerShell ISE or VSCode. Then open up the smletsExchangeConnector.ps1 script. Run it. This now gives you a first hand experience of the connector running and you can watch what errors (if any) arise. More importantly, you can breakpoint the Invoke-AfterCreateIR function and step line by line through it to verify your logic. You don't have to do this and should be a last resort if your custom log events aren't telling you what you're expecting
Now with all of that said. Your function at a high level makes sense for what you want to do. What's worth calling out here is when you're in a Custom Event. Log where at all possible for your own troubleshooting. Second, make sure to include a default case in your switch statement so when things don't go to plan you have a path AND event as to why. Take the following example:
$email = "problem on four, attn: user1"
switch -wildcard ($email) { "*user1" { write-output "The assignee is user1. Log info event." } "*user2" { write-output "The assignee is user2. Log info event." } default { write-output "Not sure who the assignee should be. Log warning event." }}
But a couple of things worth pointing out in the context of the function you are in:
$ID = $NewWorkItem.ID ### I am guessing here based off custom events examples $SRClass = Get-SCSMClass -name System.WorkItem.ServiceRequest$ $UserClass = Get-SCSMClass -name System.Domain.User$ $AssignedToUserRelClass = Get-SCSMRelationshipClass -Name System.WorkItemAssignedToUser$ $ServiceRequest = Get-SCSMObject -Class $SRClass -Filter "ID -eq $ID" #Maybe I could use $newWorkItem instead of doing the $serviceRequest lookup on the ID?
Your guesses are correct but $ID, $SRClass, $UserClass $AssignedToUserRelClass, and even $ServiceRequest are all already known when you are in the function
- Your function can simply make use of the $newWorkItem variable as you commented
- The classes $SRClass, $UserClass ($domainUserClass in the case of the connector), and $AssignedToUserRelClass are set by the connector. Check out things in the primary script starting around line 800. You'll see a host of common variables that you can use if necessary to avoid redeclaring them
- The function is Invoke-AfterCreateIR, but you're using a Service Request based class. Either you're in the wrong function, or this was a copy paste mistake. In any case, it's all the more reason to use the $newWorkItem variable as its Id, Class, etc. are all known, and exist contextually. Which means the nature of your function can not only be trimmed down significantly, but the core logic of what you're trying to do is really just what's in your switch statement
Re: An SMlets based Exchange Connector
You should be able to use Custom Events to apply additional processing based on CC or BCC:
Re: An SMlets based Exchange Connector
I should also add that if you are delivering to one mailbox, then using Exchange rules to forward to another mailbox, then there is a ReceivedBy property in the message header that should contain the original mailbox name. If you combine that with the custom events you should be able to pull out the original mailbox and perform some processing logic. The issue thread linked below has quite a bit of detail about this (though the issue listed there is different) and maps out the conditions where that field is used by the connector.
Re: Cireson Portal fields mandatory based on other fields value
@Simon_Zeinhofer @Bart_Leving - you guys are correct! The Asset Management forms go through some additional backend validation that the work items don't go through and therefore can't have js statements determine the requirement on the controls. I built a custom task to get around this. It's available here:
https://github.com/justinkwork/SWARequired/blob/main/SWARequired.js
This has the added benefit of listening for changes to the viewModel and therefore the requirement on the contingentProps updates according to the current value of the boolProp.
Re: Activity prefixes for Cloud and Delay Activity
Hy @Bryan_Lalor,
we already use an apply-Template function where all Activity prefixes are applied. But as far as I remember, this function had the problem with non existing prefixes too, as well as activities not going to In Progress. But this error has been fixed long ago :) In case you need a definite working apply-template function, have a look at @Adam_Dzyacky s Smlet Exchange Connector, it has the working function in it :) And the good thing is, you can add every activitiy + prefix to it by just adding it to the if-else clause ;)
So in short, when using the apply-template we already included the cloud,delay and powershell activities and there the prefixes are added. We only have the situation when the work item is created via an RO. But tbh for us it is only visual, as the functionality is given still.
In your case it cannot work, as the top if condition says
if($ClassName.startswith("System.WorkItem.Activity") -or $ClassName -eq "Microsoft.SystemCenter.Orchestrator.RunbookAutomationActivity")
So the other if-else clauses will only trigger, when the Activitiy Classname starts with the standard activity prefix or is an SCO activity. As Cireson activity Classnames start with "Cireson" no prefix will be applied, as the top if condition does not return $true. If you remove that if condition it will work fine ;)
Re: Property Notes exists twice in Standard Class
Hi Simon,
Whilst I agree that the class is a mess (Notes x 2 and Standard Notes) it cannot be changed. It is a supported design within SCSM SDK and I think that whilst a bad design, should work fine. The issue with SMLets, I guess, is technically a bug in SMLets.
You could bypass SMLets for this process and call the SDK directly.
Add-Type -Path "D:\Program Files\Microsoft System Center\Service Manager\SDK Binaries\Microsoft.EnterpriseManagement.Core.dll" Add-Type -Path "D:\Program Files\Microsoft System Center\Service Manager\Microsoft.EnterpriseManagement.Common.dll" $emg = New-Object Microsoft.EnterpriseManagement.EnterpriseManagementGroup "localhost" $StandardClass = Get-SCSMClass Cireson.AssetManagement.Standard $cemoStandard = New-Object -TypeName "Microsoft.EnterpriseManagement.Common.CreatableEnterpriseManagementObject" -ArgumentList $emg, $StandardClass $cemoStandard[$StandardClass, "Id"].Value = (New-Guid) $cemoStandard[$null, "DisplayName"].Value = "My Standard" $cemoStandard[$StandardClass, "Name"].Value = "My Standard" $cemoStandard[$StandardClass, "Notes"].Value = "These are the Notes" $cemoStandard[$StandardClass, "StandardNotes"].Value = "These are the Standard Notes" $cemoStandard.Commit()
Re: GenAI
As a follow-up I found out we also have a pilot going using Power Virtual Agent that will learn from documents on a SharePoint site. So I'm going to talk to the person that put that together and see what we can find out from it. I did learn that for our Github Co Pilot is installed in our tenant and before anything is sent outside any company privy data is scrubbed before it goes out.
Activity Form in Archived WorkItems is mixed up - For Activities inside an SA
Recently we wanted to investigate an archived Service Request, and furthermore, if the activities in it have been running thru.
What we noticed, was, that inside the Activities Tab, the activities inside an SA, have been mixed up a bit - Means that the sequence order was not correct anymore. We inspected different SRs from different templates and all of them had the same "issue". Before being archived the sequence was correct and also in the SCSM console the template is correct. It affects both views in the portal, the template view and the list view.
Anyone else experiences the same? It is not a real problem and only cosmetic, but especially when having a template with lots of activities, it makes keeping track of what happened a bit difficult.
Re: OData Table refresh
@Peter_Miklian The oData widgets take their data from the platform and therefor the cachert.csnCached.... tables from the Servicemanagement Database.
The data from the productive DB gets synced into these cached tables every few minutes, afaik it is 10 minutes out of the box. You can change the sync time under
Admin Settings - Dynamic Data Settings
We have it set to every 3 minutes now, but since 11.8.4 sometimes the performance seems to be impacted by the dynamic data sync. But to your question I guess it is neither possible, nor wanted, that the data in the cached tables reflect changes immediately.
Re: Add Cireson Powershell Activity to Incident templates
@William_Hollins Yes, you can actually run Powershell activities on Incidents using the PowerShell Activity and Cloud Activity apps. You would create a Cloud Activity and set the Automation Type to "Powershell" and select any Powershell scripts that you have created with the PowerShell Activity app. You can read more about Cloud Activity here: https://kb.cireson.com/article/install-cloud-activity/2625