Make SCOM all functionnalities working in a full Kerberos environment

We have implemented NTML restriction in our AD envionment because of a prioritized recommendation in the Azure AD Security assessment : Place privileged users in the Protected Users Group. The protected users groups provides additional security, because users can only authenticate using Kerberos (everything else is blocked) and hardenning is applied to the Kerberos authentication used by enforcing AES encryption.
BUT placing privileged users in Protected Users Group or implementing authentication policy to restrict usage of NTLM on admin accounts make SCOM loosing some functionalities.

Approving installation on agent in pending required update after having applied KB4601269 on Management Servers is failing with an access denied message. I need here to add that the SCOM environment is dedicated to AD servers so given credentials on the task are Domain Admin credentials.
This error generate an error event 10607, source Health Service Modules in the Operations Manager Event Log:
The Operations Manager Server cannot process the install/uninstall request for computer <Computer Name> due to failure of operating system version verification.
Operation: Agent Install
Install account: <Admin Account>
Error Code: 80070005
Error Description: Access is denied.

And in the same time, an event 4625 is raised with status "0xc000006e" for the account used in the deployment task on the domain controller that has been used for authentication. It indicates that the account is trying a network logon (type 3) with authentication Package NTLM, authentication information is valid but some user account restriction has prevented successful authentication.
The Event description adds that ‘NTLM authentication failed because access control restrictions are required.’ and it gives the name of our Authentication Policy we have implmented in the AD environment.
NTLM usage block is a known consequence of the Authentication Polices configuration and reverting the Authentication Policy from ‘Enforce Policy Restriction’ to ‘Only audit policy restriction’ for the account use in the deployment task is solving the issue. In audit mode, we always see event in AD for NTLM usage but NTLM authentication stay allowed.

I was thinking that SCOM uses whatever mechanism is available to open a RPC connection at start the installation and then open an SMB connection to copy updates but this shows that without NTLM V2, (NTLMV1 was disabled since year now in our environment), the deployment cannot be successful.
A Microsoft case has been open for this specified issue and analysing network traces confirms that
1. The deployement start by creating an RPC connection and this connection is well using Kerberos authentication.
2. Then it uses an SMB session by using IP address and since IP address alway use NTLM, kerberos is not used at this step.

At this step, Microsoft support indicates that no configuration can be done in SCOM as it is by design, however, we can configure the operating System to use Kerberos even for IP adresses by following this article: https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip
After applying the change, new traces have been analysed by Microsoft and the SMB session is well initiated using Kerberos ! However, we can see later in the trace that we have another RPC session, starts with authentication using Kerberos, but later in the same session, it reverts to NTLM, even though the session was successfully running on Kerberos.

So it appears that in all cases, SCOM will always use NTLM authentication (because using IP adresses) and this doesn't follow the AD Security assessment recommendation for privileged users.
In order to be able to deploy agent update, we need to manage an exception in our Domain Admin account to allow NTLM authentication, even temporarly, or to think about an other way to deploy and also loose the SCOM functionality.

I think that the majority of Microsoft customers have disabled NTLM and kept NTLM V2 and maybe we are the first to implement NTLM restriction but the recommendations of the Azure AD security assessment are clear, it is necessary to force privileged accounts to use Kerberos.
SCOM Product used for AD monitoring is using privileged accounts and should follow the Azure AD security recommendations.

Modify the RegEx engine leveraged by the expression filters (& possibly elsewhere in SCOM) from the .NET Framework RegEx engine, to the Perl engine that is leveraged by the group calculator module. Doing so would bring the following benefits:

1 - Consistency in the interpretation of regular expressions throughout SCOM;
2 - A more flexible experience using regular expressions in the context of expression filters, as the Perl engine offers support for RegEx functionality that is not available with the .NET Framework engine, such as the support for certain "Character Classes" (ex.: \d for digit) & "Assertions" (i.e. [Negative] Look(ahead|behind)).

See https://docs.microsoft.com/en-us/troubleshoot/system-center/scom/regular-expression-support for details.

Thanks,

Larry

SCOM as a product can be somewhat difficult to learn, mostly because of insufficient learning material or courses for existing/new users/customers. I have personally received many comments and questions about SCOM being a difficult and complex product.

Although there are a lot of great community blogs and materials out there, it may still be spread out abit everywhere and difficult to come by.
So I thought of a Microsoft Learn, which is a free, interactive, hands-on training platform that helps people develop in-demand technical skills related to widely used Microsoft products.

I think Microsoft Learn modules for SCOM could be a very good idea for both existing and new people that want to learn more about SCOM, or even starting fresh.

To start off there I would suggest a fundamentals learning module, for example:
• System Center Operations Manager fundamentals

The first module could go through some of the following SCOM concepts:
• SCOM Roles
• SCOM Management Packs
• SCOM Classes and Objects
• SCOM Models
....

Any thoughts / suggestions? Leave a comment below!

All - This poll is from SCOM Product Group. As a SCOM user, you would be using a lot of MPs and some of them could be outdated in terms version, monitors, rules and features. We are looking to revive Management Pack as a whole and we want to hear your feedback on the below topics.

1. What are top 5 MPs (in terms of usage) used at your SCOM infra?


2. Which top 5 MPs critically need version update (agnostic)?


3. What are the top 3 issues that arise on MPs (in general)?


4. What are top 3 workloads for which MPs are missing/unavailable?

Please do not forget to upvote this!

When an SCOM Agent's Operations System undergoes In-place upgrade, Post upgrade duplicate objects are seen in SCOM related to the Agent

In this example Duplicate Disks, Network adapters can been seen. Kevin Holman has blogged about this topic as well - https://kevinholman.com/2019/07/01/do-you-have-duplicate-logical-disks-in-scom/#:~:text=It%20isn't%20terribly%20harmful,in%20SCOM%20as%20a%20whole.

It would be great to have a design change to handle this internally within SCOM rather than Administrators deleting and re-approving the same in the SCOM console.

Lot of manual validation needs to be done as follows:

1. Once the Agent is deleted, We have to wait to a day for the Agent to be groomed automatically to purge its old object which takes a day.




2. Verify if the Agent is a part of the right groups post approval.




3. In rare cases we may have objects not re-discovering (This might be a genuine issue if some components broke during OS upgrade.)