There are several years already the one issue of SCSM make developers of forms customization really crazy: mixing form customization and preview form is really pain in the ass. There was bug opened in Microsoft, but it was closed without real issue. So I decide to close this question once and for all.
Since SCSM 2012 SP1, any component of SMSM self-service portal can’t be located on management server (technically, this will work, but not supported any more). But if you using SCSM since 2010 or 2012, you can have SMPortal installed on management server. In this case you need to remove SMPortal.
The only-supported way is to uninstall management server together with self-service portal and reinstall management server. This is dangerous operation (you just need to save all your custom assemblies from SCSM directory and install management server, target installation to same database). But sometime, especially in lab environment, you need to remove self-service with some “fast” way. This article describe how to do this, but please keep in mind: this is unsupported.
To remove portal you can simple remove Sharepoint and remove all IIS sites. But if you try to update management server after this, you will get “Microsoft System Center 2012 Service Manager is not in a valid state.”. This is because installer “know” that SMPortal was installed before. To clean-up this, you must change registry. Please open the key: HKEY_CLASSES_ROOT\Installer\Features\5BA67A970AE3F4C4989BC10A4083CEE2 and remove next values:
After this you can safely update your management server.
If you often using the XML criteria in SCSM (with SDK or in view with Advanced View Editor) then you can faced with two different notation used as value for properties of enumeration type (like Status, Category, Area and so on): $MPElement[Name=’’]$ and Guid format (xxxxxxxx-xxxx-xxx-xxxx-xxxxxxxxxxxx, or uniqueidentifier in T-SQL). In this article I will describe the deference and will explain why XML validation can fail when $MPElement$ notation used.
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?
In last two articles of SLA series I was wrote about storing of the SLA objects and describe how it’s works.Today it’s time to talk about some “hidden” features of the SLA management system in SCSM 2012. Most of this features are available out-of-box and supported by Microsoft but some of them are not.
In Part 1 of this series I described objects model required for SLA management system in SCSM 2012. Now it’s time to figured out how all this things works.
SLA management system in SCSM 2012 is one of the most powerful feature in contrast with SCSM 2010 where we can use only 24/7 SLA. But in this cycle of articles I don’t want to show you to setup SLA management in click-click-next guide. My goal is to show you how SLA management settings are stored, handled and worked. I hope what this will allow you to use all feature of the SLA management system in SCSM 2012.
SCSM 2012 use the Kerberos protocol to authenticate clients and servers and encrypt data inside of communication channel. The of main concept of the Kerberos protocol regarding Windows services is a Service Principal Names (SPN) records. If your SPN records absent or configured for wrong account\service name then you can except what some function will be work with issues or doesn’t work at all.
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.
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.