When you want to apply template on work item it’s extremely easy: you need to call ApplyTemplate method of the EnterpriseManagementObject or EnterpriseManagementObjectProjection class instance (with one exception – template shouldn’t contains activity for Service Requests, Change Requests or Release Records). But what if you want to create new object based on template? From first view it’s look not very hard – just call appropriated constructor. But in fact this is just first step of list of required steps: required or optional.
As you know when you deleted connector in SCSM all configuration items discovered (or imported) by this connector will also be deleted. But good question is how determinate which CIs will be deleted? This can be done using some SQL queries but this is complex, unsupported way and you must have SQL Management Studio installed. But we have a power of PowerShell and can use it to get this information.
UPDATED: Thanks to Aaron to pointing me to the right direction. Approach below allows you get CIs updated by specified connector. But SCSM stores all connectors for CI object and even if no properties was updated during connector’s sync process, this connector will be added to object. In other words, if you have object that discovered by more than one connector then this object will be removed only if all connectors will be removed.
How often are you faced with problem when your PowerShell script working fine when running under your account but doesn’t work in SCSM workflow? It can be dozens reasons why it’s doesn’t work: permission issue, workflow account’s settings is wrong and so on. Even debugging the native workflow (WPF created with Visual Studio) is not easy. But what about PowerShell?
This article describe how to generate link to specified request offering or to Generic Request on the Self-Service Portal. This can be helpful in email massages or on the custom portals\external systems. To do that you should complete two steps: get IDs of the Service Request and Request offering and generate link.
Today is XXI century and time of x64 systems. But not all of products ready to this. As example – System Center 2012 Orchestrator. If someone miss last few month and didn’t know that I’m talking about then it will be surprise: all process inside System Center 2012 Orchestrator running as x86 process. And this is can be really the problem because registry and file paths for x64 and x86 are different.
You’ve created a new class based on any existing class and have added existing form (with or without modifications) for it. Then you was imported management pack to SCSM and have tried to use that form but console was crashed with exception. Error “System.ArgumentException: propertyName” was recorded in “Operations Manager” event log. Why this happened?
Unfortunately, AD connect doesn’t have a ability to change it schedule. For SCSM 2010 AD connector runs one per hour, for SCSM 2012 it run once per 24 hours. For small domain this is acceptable schedule but for large domains with many users it can be potential risk of overload of the SQL or SCSM servers. AD connector get from AD only objects changes since last run but even this amount of data can be large and reduce workload to SCSM management server and even more to SQL server.
As you all know (or will know after reading of this post )) ) the SCSM 2012 have a native cmdlets which has installed during setup process of SCSM console. Some of native SCSM2012 cmdlets use different from SMLets names of the cmdlets.
Sometimes you need to know which objects contain the queue. This can be done easy with PowerShell.