ad assignment in scom

Network Pioneers

We Make Technology Accessible

Manage SCOM agent Part II: SCOM Assignment

• July 23, 2020
• maher islaieh

introduction

welcome to second article of SCOM agent series which will discuss SCOm server assignment

agent Deployment vs assignment

We have to differentiate between [deployment Vs assignment ]

• install MOM agent on client computer either using discovery method[AD,SNMP] or even manually [DVD, or file in SCOM server]
• configure agent to send all local information to Specific  SCOM server [if your environment  has many SCOM server ]
• Assignment by default is manual [go to client control panel àMicrosoft monitoring agent à check assignment ]
• If we would like to make assignment as auto à we have to publish it in AD

Publish SCOM in AD

 The whole idea with AD integration is that when an agent is manually installed, for example using GPO or System Center Configuration Manager >> it should automatically find which Management Group it belongs to and what Management Server it should be talking to

 This is possible by creating a container in the AD that contains information about Management Group name and Management Servers that are in the Management Group

 After the container has been created, a rule must be created for the Management Server as well that says which servers should talk to which Management Server.

• We have to publish assignment before start to deploy agent à just to make sure that assignment has been deployed also with agent

On SCOM server  à run CMD as administrator

Cd C:\Program Files\Microsoft System Center  \Operations Manager\Server

On active directory à create new group called [SCOMadmins]

Run command à

Please note that :

• Pioneers_SCOM à SCOM management group name that we have created during SCOM installation but if we are NOT sure of name à we can get from registry à HKEY_LOCAL_MachineàSOFTWAREàMicrosoftàMicrosoft Operations Managerà0àServer Management Groupsà
• SCOMadmins à AD security group that has administrators privileges on SCOM management group [open SCOM console àadministrationàsecurityàuser rolesàadministrators] then add this group to [administrators user role]
• We have to create group before perform command
• SCOMadmin à AD account that will be assigned as member of SCOMadmins group and will have administrators privileges om SCOM management group
• This command also will create container in AD DS console called [ operation manager ] but as hidden [we can show it by select feature advance ] and sub container called [ Pioneers_SCOM ] which is name of management group

After command successfully done >> open active directory advance feature àwe will see there is new container in active directory called [operation manager] that contain management group name

Configure Auto Assignment

to Configure SCOM server to assign mom server automatically >>

• Open SCOM console >> administration >> device management >> management  servers >> properties of SCOM142.pioneers.lab  [SCOM server]>> assignment tab >>  add agent assignment from AD as ANY
• This will make any new agent to auto assign SCOM142.pioneers.lab  as assignment server  

To verify publish auto assignment :

• Open control panel >> Microsoft operation agent >>
• Make sure auto update is selected
• Delete manual entry of management server record
• After afew time of restart >> entry should be updated automatically by AD container [operations manager ]

auto assignment is an optional feature that help to configure SCOM to comment to specific SCOM server  in case you have Many SCOm server in your environment 

Share this post

Our Power in Numbers

And all configurations images are proudly made in pioneers lab, articles by course.

• Active Directory (14)
• Exchange (18)
• Microsoft 365 administration (13)
• Microsoft 365 Security (45)
• Vsphere-ICM (31)
• vSphere-O&S (26)
• Win2019 Infra (1)
• Windows (5)

Recent Articles

• secure RDS portal with Certificate Authority
• 13.4 Project Stakeholder Management : Monitor Stakeholder Engagement
• 13.3 Project Stakeholder Management : Manage Stakeholder Engagement
• 13.2 Project Stakeholder Management : Plan Stakeholder Engagement
• 13.1 Project Stakeholder Management :Identify Stakeholders

have a challenge ? don’t hesitate to contact us

Secure Infrastructure Blog

by the Secure Infrastructure team at Microsoft

Is AD integration or manual SCOM agents installation required to allow Automatic Windows Agent Failover between multiple SCOM 2012 Management Servers?

Introduction:

I observed that some IT professionals confused about System Center Operations Manager (SCOM) 2012 windows agents failover requirements, and the raised question was do I need to configure SCOM Active Directory Integration or do manual agents implementation or use PowerShell to allow windows agents to do automatic failover between multiple SCOM management servers? or should I wait and delay SCOM agents deployment until deploying System Center Configuration Manager to deploy SCOM agents? and the simple answer is “ No ” need, and below you can find more details about from where confusion come and why you do not have to wait until AD integration or Configuration Manager be implemented to push SCOM windows agents, and how to verify that SCOM windows agents failover working properly.

Detailed Description:

First, confusion come because some documentation and blog posts shows how to distribute windows agents through SCOM management servers using AD integration or PowerShell Scripts to automate agents assignment through different SCOM management servers which is very good, however this is not mandatory specially for small environment that includes less than 100 windows agents, and the reason behind is that you can distribute the windows SCOM agents though the SCOM management servers while pushing the agents from SCOM management console, so simply you can select which management server will be the primary management server for agents that you are going to push right now as shown in below diagram that you can scroll down and select which management server will be the primary management server for agents that will be implemented within this wizard:

So the simplest way for small to medium windows servers environment is to push SCOM agents between the available management servers in the same management servers pool, so for example if you have two management servers automatically will be member in the same management servers pool then you can push 50% of agents to have SCOM management server-1 as their primary management server and then push the other 50% of agents to have SCOM management server-2 as their primary management server.

To verify windows agents failover between the different management servers simply you need to stop one of the management servers (disconnect from network or shutdown the management server) and check the Operations Manager event viewer in one of the managed computers by the stopped SCOM management server so you will see event ID 21006 as shown below telling you that there is a problem to connect to his management server.

If heart beat configuration kept with default value which is 60 seconds then another event ID 21015 will be generated as shown below telling you that OpsMgr was unable to set up a communications channel to the agent primary management server.

3 Seconds later you will see a new event ID 21017 will be generated as shown below telling you that OpsMgr has successfully failed over to the secondary management server

The good point here is that when the windows agent primary server come back running agent will fail back automatically to its primary management server.

Conclusion:

As a conclusion, SCOM windows agents automatic failover does not require AD integration or PowerShell scripting or Configuration Manager or manual agents installation specially for small to medium environment and agents distribution between different SCOM management servers can be accomplished through push agents wizard, and windows agents failover can be simply verified from event viewer.

Share this:

• System Center

Leave a Reply Cancel reply

Discover more from secure infrastructure blog.

Subscribe now to keep reading and get access to the full archive.

Type your email…

Continue reading

Update on Active Directory Integration with SCOM

What are ad rules, you ask, can i explain with an example, when was this fixed, what was the impact of this fix.

System Center Operations Manager ( SCOM ) uses scripts in Management Packs as part of discovery process. For example, Discover Windows Computer Properties is a discovery process which triggers a PowerShell script that does the discovery.

Earlier to SCOM 2016, these scripts were based on VB. In SCOM 2016 RTM, we migrated these scripts to PowerShell and with this change, Windows Computer details that were retrieved (as part of Active Directory Integration rules) were displaying incorrect NETBIOS name of a domain.

These rules use Active Directory Domain Services ( AD DS ) to assign computers to a management group and assign the computers' management servers. The AD rules that were configured in SCOM2012 were also not working in SCOM2016.

Sure, Let us look at the format and understand it with an example.

Consider you run a computer that is a member of a domain contoso.com and a rule is configured for this domain as shown below.

Below are the formats configured in AD Rules of SCOM 2012, 2016 and their examples.

Due to the above mismatch (SMX vs smx.net) in rule, computer details were wrongly displayed and not working when upgraded to SCOM 2016.

Simply put, the format should have always been “ NetBIOS Domain Name of MS” i.e., SMX.

This issue was fixed in SCOM2016 Update Rollup 7 (Windows Computer Property “NetbiosDomainName” is not discovered properly), however UR7 was released after SCOM1807.

That meant , this issue was not fixed in SCOM 1807 and older versions i.e., SCOM 2016 RTM, UR1… UR6, 1801.

Below is the updated RULE in SCOM 2016 UR7 and SCOM 2019 (same as that of SCOM 2012).

Anyone upgrading from SCOM 2016, 1801 or 1807 to 2019 RTM will run into the issue of previous AD rules not working in SCOM2019. Additionally, AD rules are not visible in the SCOM console which prevents administrators from editing them.

A fix for this issue will be available in 2019 Update Rollup 2. In the meantime, you can edit the rule manually in default management pack and get it working. The steps to do that are as below.

• After upgrade to 2019, export Default Management Pack into a folder
• Open “Microsoft.SystemCenter.OperationsManager.DefaultUser. xml ” from the exported folder
• Rename all the AD rules to use instead of as shown below.

Note: Please note that the domain name is case sensitive .

• Import the updated Management Pack.
• Now, the rules will work correctly.

This article was originally published by Microsoft's Azure SQL Database Blog . You can find the original article here .

Related Posts

• Using Azure Update Management to Automate On-Premises Server Patching
• The Case of Azure AD Quota Exhaustion
• The care and feeding of Azure Arc for Servers
• Step-by-Step: Managing Users via the Azure Active Directory PowerShell for Graph Module
• Step-by-Step Guide: Active Directory Migration from Windows Server 2008 R2 to Windows Server 2022

Kevin Holman's Blog

SCOM and anything else I find interesting

UR6 for SCOM 2016 – Step by Step

KB Article for OpsMgr:   https://support.microsoft.com/en-us/help/4459897/update-rollup-6-for-system-center-2016-operations-manager

Download catalog site:   http://www.catalog.update.microsoft.com/Search.aspx?q=4459897

Updated UNIX/Linux Management Packs:   https://www.microsoft.com/en-us/download/details.aspx?id=29696

Recommended hotfix page:   https://kevinholman.com/2009/01/27/which-scom-hotfixes-should-i-apply/

NOTE:   I get this question every time we release an update rollup:    ALL SCOM Update Rollups are CUMULATIVE.   This means you do not need to apply them in order, you can always just apply the latest update.  If you have deployed SCOM 2016 and never applied an update rollup – you can go straight to the latest one available.

• AIX 6. x   is not supported.

Lets get started.

From reading the KB article – the order of operations is:

• Reporting Server
• Update Unix/Linux MP’s and Agents

WHOA Nelly.

Before we get started – there are some configuration changes necessary in SQL to support UR6.  UR6 has some fixes for Scheduled Maintenance, and these require some rights configuration FIRST – BEFORE applying UR6.  Otherwise you might run into some trouble.

Essentially, you need to:

• In this user mapping – select   db_owner, public, SQLAgentOperatorRole, SQLAgentReaderRole, SQLAgentUserRole

Note:    If you do not configure these rights, you might see failures in the SCOM logs after applying UR6 about not being able to synchronize scheduled maintenance jobs, or you might see issues with creating new Schedule Maintenance failing, locking up the console, or even creating large numbers of duplicate jobs.

1. Management Servers

It doesn’t matter which management server I start with.  I simply make sure I only patch one management server at a time to allow for agent failover without overloading any single management server.

I can apply this update manually via the MSP files, or I can use Windows Update.  I have 2 management servers, and I always recommend a manual installation on management servers, I don’t recommend using Windows Update.  My first management server holds 3 roles, and each must be patched:  Management Server, Web Console, and Console.

The first thing I do when I download the updates from the catalog, is copy the cab files for my language to a single location, and then extract the contents.

Once I have the MSP files, I am ready to start applying the update to each server by role.

***Note:   You MUST log on to each server role as a Local Administrator, SCOM Admin, AND your account must also have System Administrator role to the SQL database instances that host your OpsMgr databases.

My first server is a Management Server, Web Console server, and has the OpsMgr console installed, so I copy those update files locally, and execute them per the KB, from an   elevated   command prompt:

This launches a quick UI which applies the update.  It will bounce the SCOM services as well.  The update usually does not provide any feedback that it had success or failure….  but you MIGHT see a reboot prompt.  You can choose “No” and then reboot after applying all the SCOM role updates.

You can check the application log for the MsiInstaller events to show completion:

Log Name:      Application Source:        MsiInstaller Event ID:      1036 Description: Windows Installer installed an update. Product Name: System Center Operations Manager 2016 Server. Product Version: 7.2.11719.0. Product Language: 1033. Manufacturer: Microsoft Corporation. Update Name: System Center 2016 Operations Manager Update Rollup 6 Patch. Installation success or error status: 0.

You can also spot check a couple DLL files for the file version attribute:

Next up – run the   Web Console update:

This runs much faster.   A quick file spot check:

Lastly – install the   Console Update   (make sure your console is closed):

A quick file spot check:

Or help/about in the console:

Additional Management Servers:

Apply the UR updates for Server, Web Console, and Console roles as needed for all additional management servers.  You should only patch one management server at a time to allow for graceful failover of agents and to keep resource pools stable.

Updating ACS (Audit Collection Services)

One of my management servers is also my ACS Audit Collection Server role.  I will apply the update for that:

Note the above image states “ Operations Manager 2012 ”.  This is a known issue.   Ignore it .

Updated files:

Updating Gateways:

Generally I can use Windows Update or manual installation.  I will proceed with manual:

The update launches a UI and quickly finishes.

Then I will spot check the DLL’s:

I can also spot-check the \AgentManagement folder, and make sure my agent update files are dropped here correctly:

***NOTE:  You can delete any older UR update files from the \AgentManagement directories.  The UR’s do not clean these up and they provide no purpose for being present any longer.

Updating Reporting:

On your server that hosts the SCOM Reporting role, run the update:

2. Apply the SQL Scripts

In the path on your management servers, where you installed/extracted the update, there is ONE SQL script file:

%SystemDrive%\Program Files\Microsoft System Center 2016\Operations Manager\Server\SQL Script for Update Rollups (note – your path may vary slightly depending on if you have an upgraded environment or clean install)

Next – let’s run the script to update the OperationsManager (Operations) database.  Open a SQL management studio query window, connect it to your Operations Manager database, and then open the script file ( update_rollup_mom_db.sql ).  Make sure it is pointing to your   OperationsManager   database, then execute the script.

You should run this script with each UR, even if you ran this on a previous UR.  The script body can change so as a best practice always re-run this.

Click the “Execute” button in SQL mgmt. studio.  The execution could take a considerable amount of time and you might see a spike in processor utilization on your SQL database server during this operation. 

I have had customers state this takes from a few minutes to as long as an hour.   In MOST cases – you will need to shut down the SDK, Config, and Monitoring Agent (healthservice) on ALL your management servers in order for this to be able to run with success.

IF YOU GET AN ERROR – STOP!   Do not continue.  Try re-running the script several times until it completes without errors.  In a production environment with lots of activity, you will almost certainly have to shut down the services (sdk, config, and healthservice) on your management servers, to break their connection to the databases, to get a successful run.

3. Manually import the management packs

There are   36 management packs   in this update!  Most of these we   don’t   need –   so read carefully.

The path for these is on your management server, after you have installed the “Server” update:

\Program Files\Microsoft System Center 2016\Operations Manager\Server\Management Packs for Update Rollups

However, the majority of them are Advisor/OMS, and language specific.  Only import the ones you need, and that are correct for your language. 

This is the initial import list:

What NOT to import:

The Advisor MP’s are only needed if you are using Microsoft Operations Management Suite cloud service, (Previously known as Advisor, and Operations Insights) and have your on premise SCOM environment connected to the cloud service. DON’T import ALL the languages   – ONLY ENU, or any other languages you might require. The   Alert Attachment MP   update is only needed if you are already using that MP for very specific other MP’s that depend on it (rare) The   IntelliTrace Profiling MP   requires IIS MP’s and is only used if you want this feature in conjunction with APM.

So I remove what I don’t want or need – and I have this:

#Note:   If the “Install” button is greyed out   – this means you might already have one or more of these MP’s with the same version installed.  Find it by scrolling through each one, the console will tell you if you already have the same version.

4.  Update Agents

Agents   should   be placed into pending actions by this update for any agent that was not manually installed (remotely manageable = yes):

If your agents are not placed into pending management – this is generally caused by not running the update from an   elevated   command prompt, or having manually installed agents which will not be placed into pending by design, OR if you use   Windows Update   to apply the update rollup for the Server role patch.

You can approve these – which will result in a success or failure message once complete:

You normally can verify the PatchLevel by going into the console and opening the view at:   Monitoring > Operations Manager > Agent Details > Agents by Version

I * strongly * recommend you take a look at this community MP, which helps see the “REAL” agent number in the   Administration –> Agent Managed   view console:

https://kevinholman.com/2017/02/26/scom-agent-version-addendum-management-pack/

And   my SCOM Management Group Management mp ( updated for UR6 ), which will help show you REAL UR levels based on a better discovery.  This has long been a pain point in SCOM:

https://kevinholman.com/2017/05/09/scom-management-mp-making-a-scom-admins-life-a-little-easier/

5.  Update UNIX/Linux MPs and Agents

The UNIX/Linux MP’s and agents at the time of this article publishing have not changed since SCOM 2016UR3 was released.

You can get the current Unix/Linux MP updates here:   https://www.microsoft.com/en-us/download/details.aspx?id=29696

The current version of these MP’s for SCOM 2016 UR6 is 7.6.1089.0  – and includes agents with version 1.6.2-342

Make sure you download the correct version for your SCOM deployment version:

Download, extract, and import   ONLY   the updated Linux/UNIX MP’s that are relevant to the OS versions that you want to monitor:

In my environment – I only monitor RedHat and Universal Linux distributions, so this is my pared down list of MP’s to update:

This will take a considerable amount of time to import, and consume a lot of CPU on the management servers and SQL server until complete.

Once it has completed,   you will need to restart   the Healthservice ( Microsoft Monitoring Agent ) on each management server, in order to get them to update their agent files at   \Program Files\Microsoft System Center 2016\Operations Manager\Server\AgentManagement\UnixAgents

You should see the new files dropped with new timestamps:

Now you can deploy the Linux agent updates:

Next – you decide if you want to input credentials for the SSH connection and upgrade, or if you have existing RunAs accounts that are set up to do the job (Agent Maintenance/SSH Account)

If you have any issues, make sure your SUDOERS file has the correct information pertaining to agent upgrade:

https://kevinholman.com/2016/11/11/monitoring-unix-linux-with-opsmgr-2016/

6.  Update the remaining deployed consoles

This is an important step.  I have consoles deployed around my infrastructure – on my Orchestrator server, SCVMM server, on my personal workstation, on all the other SCOM admins on my team, on a Terminal Server we use as a tools machine, etc.  These should all get the matching update version.

Now at this point, we would check the OpsMgr event logs on our management servers, check for any new or strange alerts coming in, and ensure that there are no issues after the update.

Known Issues:

1.  After applying UR6 – When a scoped Operator uses the console, it crashes with a specific error:    Incorrect syntax near the keyword ‘CREATE’

You will also see events in the OperationsManager event log on the management servers showing exceptions:

Source:        OpsMgr SDK Service Event ID:      26319 Description: An exception was thrown while processing GetRelatedManagedEntitiesByManagedEntityTypesAndCriteriaWithInstanceQueryOptions for session ID uuid:d35b8bee-4d1f-49ba-aeb3-0f4021d3eda0;id=221. Exception message: The creator of this fault did not specify a Reason. Full Exception: System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.UnknownDatabaseException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to Incorrect syntax near the keyword ‘CREATE’.). Source:        DataAccessLayer Event ID:      33333 Description: Data Access Layer rejected retry on SqlError: Request: MT_Select_Rel_ea99500d-8d52-fc52-b5a5-10dcd1e9d2bd — (ParentIds=457c209e-d14b-0721-be20-c3bf55447dab), (Depth=0), (UserRoleIds=e7cb00d7-9b7e-4657-8a0e-7479a32e1951), (UserScopeIds=S-1-5-21-3626055071-1639654894-2113106914-1112,S-1-5-21-3626055071-1639654894-2113106914-513,S-1-1-0,S-1-5-32-545,S-1-5-2,S-1-5-…), (OperationId=e8b526b8-2404-4b2a-ab56-db3d9c7ef6aa) Class: 15 Number: 156 Message: Incorrect syntax near the keyword ‘CREATE’.

This is a bug, and will be fixed in UR7.  To work around this bug, you need to replace “ Microsoft.EnterpriseManagement.DataAccessService.Core.dll ” with a previous version, on all management servers.  This file is located in your Management Servers, in \Program Files\Microsoft System Center 2016\Operations Manager\Server.  The affected file version is 7.2.12066.0 .  You need to rename this file to something like Microsoft.EnterpriseManagement.DataAccessService.Core.dll.UR6 then copy over the same file from UR5.  The UR5 version is 7.2.12016.0.  Stop the SDK/DAS service, rename the UR6 file, copy over the file from a UR5 system, and start the SDK/DAS service.

You can download UR5 from http://www.catalog.update.microsoft.com/Search.aspx?q=KB4090987

You can extract the KB4090987-AMD64-Server.msp using a unzip utility, and find the file “F_MEM.DAS.Core.dll.62894CB9_4320_40DB_B4E4_C0347FAB97B6”.  Copy this file and rename it to Microsoft.EnterpriseManagement.DataAccessService.Core.dll

2.  The   ACS update shows “Operations Manager 2012”   in the UI but is actually for SCOM 2016.

46 Comments

Kevin are the permission changes supposed to be permanent or can they be removed after UR6 is applied?

Permanent. The permissions changes are to enable scheduled MM to work on an ongoing basis.

Kevin perhaps you know when the Application pool crashes and the Scheduled Maintenance Mode will be fixed in SCOM 1801/1807? With new release or only in SCOM 2019?

I believe those will be fixed by SCOM 2019. In the SAC model, fixes arrived in the next version, which was every 6 months. The SAC model doesn’t have UR’s. Maintaining two branches can be a little confusing to customers, because different fixes will reach different branches at different times.

It is possible to update from 1801 to 2016 UR6, make sense?

It is not possible to “downgrade” from SCOM 1801 to SCOM 2016. 1801 can be upgraded directly to SCOM 1807, or to SCOM 2019 only.

As I know you can’t move from CSB to LTSB but can from LTSB to CSB.

I’d wait until SCOM 2019 releases (soon) before making any decisions on that. There are some changes coming with regard to that.

Is it possible that the SCOM 2016 UR4 to 1807 or something…?

You are going to have to be more clear with your question.

The OM event log on all 5 of my management servers got corrupted after applying this. Had to kill HealthService.exe, clear the event log and restart healthservice. Other than that, it went fine.

This is now interesting to me…. seeing how we reset the event log size in UR7. I wonder if we did this in UR6 and I just didn’t notice it.

Thanks for the detailed article. I have a strange issue here after applying the UR, Total process went without any error (Updated Server, web console, ACS, console and Agents as well. The problem here is that the Agent version is not updating in the console, it is still displaying the older version but under ‘Patch List’ it is correctly mentioned with UR 6 patch. Event in the registry of the Agent, it is showing older version. I tried manual installation also, still it is same. What is the way forward?, please help. Thank you

Regards guru

By design. https://kevinholman.com/2017/02/26/scom-agent-version-addendum-management-pack/

Thanks for the detailed article. Everything went well for me with out errors but the agent version is still not updated. I tried manual update, still same issue. Even in the registry, it is not updated but in the ‘Agents by Version’, it shows UR6 Patch.

what is the way forward, please help. Thank you

Regards/guru

This is by design. Agent version is a “major” version and does not update. This is why I wrote: https://kevinholman.com/2017/02/26/scom-agent-version-addendum-management-pack/

Hi Kevin, Thank you very much for the clarification. Its working 🙂

Thanks for the complete guide, I’ve an issues after applying UR6 on newly installed SCOM 2016 i noticed that there is alert (All Management Servers Pool Unavailable) following by EVENT ID 20022 (All Management Servers Resource Pool) is not heartbeating as well as Notifications Resource Pool

AD Assignment Resource Pool

This Server is newly installed

Also i used your MP to get agent version its show me that the RU is 6 and the version is the latest but the version in managed computers still the old, i tried to repair – uninstall and reinstall same issue, i tried to discover new devices and install the agent on it i got the same issue

appreciate your help

Thanks in advance

After Install SCOM UR6 we have problem with “My Workspace”. Users (Operator Role and Advanced Operator) can’t use saved State views and create worked new. Got Error: ===== Date: 07.02.2019 17:37:02 Application: Operations Manager Application Version: 7.2.12066.0 Severity: Error Message:

Incorrect syntax near the keyword ‘CREATE’. ========== In Operations Manager log: Level: Warning EventID: 33333 Source: DataAccessLayer ==================== Data Access Layer rejected retry on SqlError: Request: MTV_Select_ea99500d-8d52-fc52-b5a5-10dcd1e9d2bd — (UserRoleIds=e94743e9-b72a-41fe-858e-074cf81e2863,b1e29780-16dd-483d-84df-0ca8680caef6,2de7d87c-7ca7-4051-892f-1f7ffa43e8c2,9c886019-f9b8-47e…), (UserScopeIds=xxxSIDS_HERExxx…), (OperationId=e8b526b8-2404-4b2a-ab56-db3d9c7ef6aa), (NetbiosComputerName0=%%%) Class: 15 Number: 156 Message: Incorrect syntax near the keyword ‘CREATE’. ========== and Level: Error EventID: 26319 Source: OpsMgr SDK Service ========== An exception was thrown while processing GetManagedEntitiesByManagedEntityTypesAndCriteriaWithInstanceQueryOptions for session ID uuid:8c32d870-9e7f-4e5d-817e-df2d361bb78e;id=17738. Exception message: The creator of this fault did not specify a Reason. Full Exception: System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.UnknownDatabaseException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to Incorrect syntax near the keyword ‘CREATE’.). ========== Uninstalling console patch not helping. Administrators not affected.

Possible this is a bug. Any help will be appreciated. Thanks in advance!

This is a known bug in UR6 for operators with scoped views. You need to back date one of the files from a UR5 install. I will edit the post to cover this in the known issues section

Hi Kevin, we are really interested in the back dating the file you mentioned (UR5 Install), because we have face an issue with almost all scoped views – the console crashes with “Incorrect syntax near the keyword ‘CREATE’.” I found your comment yesterday and already opened a case to get the update, but I would be also interested in the possible workaround (or solution). Many thanks in advance!

Thanks Kevin. We had the same issue using Squared Up with scoped views. And this solved the issue.

Pingback: SCOM 2016 UR6 console crashes with “Incorrect syntax near the keyword ‘CREATE’.” | POHN IT Blog

Kevin, do you know why I can’t find this update rollup anymore? It looks like it was removed from MS Catalog.

I don’t know why, but I can confirm. I have escalated this internally to try and get it restored ASAP.

How soon until UR7?

I assume soon, but I don’t know.

Kevin, running into an issue where jobs are now failing with this error

Alert: MSSQL 2016: A SQL job failed to complete successfully Source: SQLSERVERAGENT Path: SQLSERVER50.hq.first.int;MSSQLSERVER Last modified by: System Last modified time: 3/14/2019 11:30:16 PM Alert description: Event ID: 208. SQL Server Scheduled Job ‘BAE833BF-7318-E911-A2F4-005056923776’ (0x6EEC45C75FB68A40AC327423C9925DDF) – Status: Failed – Invoked on: 2019-03-14 23:30:15 – Message: The job failed. The Job was invoked by Schedule 21 (BAE833BF-7318-E911-A2F4-005056923776). The last step to run was step 1 (Maintenance Schedule Process Step).

Alert view link: “?DisplayMode=Pivot&AlertID=%7b859aad82-8347-4f18-b56f-0504d39f162e%7d” Notification subscription ID generating this message: {7EE83EF8-D787-375F-786C-5797872B23FA}

Just an update. I noticed that the agents never checked in for an update. I got to looking and UR 6 was attempted to be installed via SCCM and it failed (Could not stop services: Access Denied). I logged in to each MS and stopped the services. The update ran fine. All the agents started checking in for updated agent, but it didnt fix the maintenance schedule issues on a SQL AG. Still cant open them

And another update on this for anyone else having issues. The SQL scripts runs when executing as a whole. It creates the new Stored Procs, but they do not get executed as I thought. According to this https://support.microsoft.com/en-us/help/4459897/update-rollup-6-for-system-center-2016-operations-manager#verify you need to manually run the stored proc (if you are impatient like me).

After manually running the SP, the maintenance schedules were immediately available.

I am getting the same error you mentioned here with scoped users in SCOM 2019, but it only happens with a scoped user in the Web console. They also get an error 500. I replaced Microsoft.EnterpriseManagement.DataAccessService.Core.dll with the 1807 version and it seems to have fixed this. Have you seen this on other SCOM 2019 installs?

I have a repro of this and will report it.

Thanks for the info on this, this also worked as a workaround for me.

This is being fixed for SCOM 2016 in UR7. For SCOM 2019, it will likely be fixed in UR1, or by requesting a private fix from opening a support case.

Where can I find roll back option for this UR6?

Uninstall information is included in the KB article: https://support.microsoft.com/en-us/help/4459897/update-rollup-6-for-system-center-2016-operations-manager

Hi Kevin, Our previous team member has set password for service and sdk account but we dint knew the password now. I want to perform UR6 on 16 management servers. Do I need to login using service account to perform the activity or local SCOM admin access is enough? Please help on this request.

You NEVER need to log on as a service account, and I consider that a worst practice. You should always log on using an account with the rights specified in the article.

WE have successfully completed UR6 using your steps. Thanks for the same. I would like to know whether Unix and Linux agent update is mandatory? We have version 7.6.1064 and 7.6.1076 installed. Please guide. Also, in SCOM management -> SCOM Agents I’m not able to see 2016 UR6 anywhere mentioned. What could be the reason.

If you use Unix/Linux monitoring, then yes – you need to update everything. If you don’t use SCOM to monitor UNIX/Linux systems, then no.

I don’t know why your SCOM management view doesn’t show UR6. Either you are not keeping that MP up to date, or your agents didn’t get updated. You need to troubleshoot this.

Concerning the: Incorrect syntax near the keyword ‘CREATE’, it’s still occurring on SCOM 2019, is there anything i can do to fix it?

Contact Microsoft support. There is a private hotfix.

Official link for the download to the public fix for SCOM 2019 : https://support.microsoft.com/en-my/help/4506518/system-center-operations-manager-hotfix-for-scoped-group-users

Pingback: OpsMgr 2016 – QuickStart Deployment Guide - Kevin Holman's Blog

bumped into one issue after doing management pack cleanup and was wondering that you have seen this before. Using SCOM 2019 UR1. After cleanup I’m no longer able to reset monitors health from health explorer. Mangement server reports event ID 26319 “An exception was thrown while processing SubmitTasks for session ID uuid:e992410a-9875-4643-9d5f-1f9629d5831a;id=20653. Exception message: The creator of this fault did not specify a Reason. Full Exception: System.ServiceModel.FaultException`1[Microsoft.EnterpriseManagement.Common.UnauthorizedAccessEnterpriseManagementException]: The creator of this fault did not specify a Reason. (Fault Detail is equal to Microsoft.EnterpriseManagement.Common.UnauthorizedAccessEnterpriseManagementException: The overrides provided for the task with id 4737ca24-843e-03bb-5c26-7c5336851d07 were invalid.).”

maybe you have some ideas?

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

The Monitoring Guys

A fine site for discussions about monitoring and related technology, automated linux agent deployment for scom - the monitoring guys, automated linux agent deployment for scom.

I wrote this script some years back so forgive me if I’m a little hazy on the details. I believe this was tested with SCOM 2016. It was originally designed to be used with System Center Orchestrator (SCORCH) however you can run it directly on the SCOM management server as well. The script is commented quite a bit but you really should know your way around PowerShell a little bit before using this.

Download “SignCertManageNixAgent”

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

3 Replies to “Automated Linux Agent Deployment for SCOM”

This is terrific! Thank you!

I wrote this years ago. I’m sorry I didn’t post it earlier. It always comes down to finding the time.

• Pingback: Microsoft Cloud ve Datacenter Management Ağustos 2020 Bülten – Sertaç Topal

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Terms and Conditions

Tell a friend!

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Events 20012 and 2000 when you use Active Directory integration for agent assignment in Operations Manager

• 2 contributors

This article helps you fix an issue where Operations Manager agents can't find the primary management server, and events 20012 and 2000 are logged.

Original product version:   System Center Operations Manager, version 1807, System Center Operations Manager, version 1801, System Center 2016 Operations Manager, System Center 2012 R2 Operations Manager, Microsoft System Center 2012 Operations Manager Original KB number:   4503903

You use Active Directory integration to make agent assignments in Microsoft System Center Operations Manager. However, Operations Manager agents can't find the primary management server through the Active Directory policy.

When this issue occurs, the following events are logged in the Operations Manager event log:

Log Name: Operations Manager Source: OpsMgr Connector Date: <Date> <Time> Event ID: 20012 Task Category: None Level: Information Keywords: Classic User: N/A Computer: scomagent.contoso.com Description: The OpsMgr Connector did not find any connection policy in Active Directory for management group <Management_Group>

Log Name: Operations Manager Source: HealthService Date: <Date> <Time> Event ID: 2000 Task Category: Health Service Level: Error Keywords: Classic User: N/A Computer: scomagent.contoso.com Description: The Management Group <Management_Group> failed to start. The error message is the environment is incorrect.(0x8007000A). A previous message with more detail may have been logged.

When diagnostic tracing is enabled, the following error messages are logged in the TracingGuidsNative.log file:

948 [3]6532.7764::03/27/2019-15:36:12.285 [Common] [] [Information] :Common::ADGetSCPInfo{scputil_cpp633} SCP Not found for primary ManagementServer 949 [3]6532.7764::03/27/2019-15:36:12.285 [Common] [] [Verbose] :Common::EventLogUtil::LogEvent{eventlogutil_cpp388}Logging informational event 20012 with args "<Management_Group>", "NULL","NULL", "NULL", "NULL", "NULL", "NULL", "NULL", "NULL" 950 [3]6532.7764::03/27/2019-15:36:12.285 [Common] [] [Information] :Common::EventLogUtil::GetEventCommonFuncAddresses{eventlogutil_cpp164}LoadLibrary("EventCommon.dll") module not found, will continue. 951 [3]6532.7764::03/27/2019-15:36:12.285 [Common] [] [Information] :Common::EventLogUtil::LogEvent{eventlogutil_cpp468}At least one of GetFormattedMessage and FreeMOMMessage function pointers is NULL. 952 [3]6532.7764::03/27/2019-15:36:12.285 [Common] [] [Information] :Common::EventLogUtil::LogEvent{eventlogutil_cpp475}Logging event 20012 from source "OpsMgr Connector" with severity 0x4 and description "NULL". 953 [3]6532.7764::03/27/2019-15:36:12.285 [MOMConnector] [] [Information] :getADManagementGroupsFromEnvironment{momconnectormg_cpp3942} No SCP was found 954 [3]6532.7764::03/27/2019-15:36:12.285 [MOMConnector] [] [Error] :CConnectorManagementGroup::UpdateConfigurationFromEnvironment{momconnectormg_cpp4171}AD integration is enabled but primary info was not located. Ignore this MG 955 [3]6532.7764::03/27/2019-15:36:12.285 [MOMConnector] [] [Error] :CConnectorManagementGroup::LoadConfiguration{momconnectormg_cpp1548}To update configuration from environment failed with code 10( ERROR_BAD_ENVIRONMENT )

Operations Manager agents cannot parse more than 10 service connection points (SCPs). This issue occurs if your management group has more than 10 management servers and the Automatically manage failover option is selected in the agent assignment rule.

To fix the issue, follow these steps to limit the number of SCPs:

• Log on to the computer by using an account that's a member of the Operations Manager Administrators role.
• In the Operations console, select Administration .
• In the Administration workspace, select Management Servers .
• Right-click the primary management server, and then select Properties .
• In the Management Server Properties dialog box, select the Auto Agent Assignment tab, select the existing agent assignment setting, and then select Edit to open the Agent Assignment and Failover Wizard.
• On the Inclusion Criteria page, copy the LDAP query, and paste it to a Notepad file.
• Select Cancel to close the Agent Assignment and Failover Wizard.
• Select Delete to delete the agent assignment setting.
• Select Add to open the Agent Assignment and Failover Wizard.
• On the Domain page, select the domain of the computers, and then select Next .
• On the Inclusion Criteria page, enter the LDAP query that you copied in step 6, and then select Next .
• On the Exclusion Criteria page, type the FQDN of computers that you explicitly want to prevent from being managed by this management server, and then select Next .
• On the Agent Failover page, select Manually configure failover , select no more than nine (9) management servers, and then select Create .
• In the Management Server Properties dialog box, click OK .
• Wait for one hour for the agent assignment setting to propagate in AD DS, and then check whether the issue is fixed.

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources