Normally when one creates a group which will be dynamically populated and this group is being saved, all is well. So it was until I moved the OpsMgr-database to another SQL-server. When I made a new group and configured this group to be dynamically populated and tried to save this group, I got this error message:

I was a bit suprised at first but since I had created many dynamically populated groups already without any error I knew the error had to be related with the move of the OpsMgr-database. More over since that was the only change in the SCOM-environment.
The OpsMgr eventlog showed this event:

How nice! This event told me what was wrong: The execution of usercode in the .NET Framework is disabled. And that is default on a freshly installed SQL 2005 server. When one installs OpsMgr this feature is enabled. But in this case that is a different SQL-server now.
Cause
By default SQL accepts only Stored Procedures based on T-SQL. But when one creates a group which is to e bdynamically populated, certain Stored Procedures are used which are based on any language but T-SQL.
Solution
In order to resolve this issue, Common Language Runtime has to be enabled on the SQL instance where the OpsMgr database resides. Look here how to enable it. (Also a good source for any other programming and/or SQL related information)
See screendump below how the CLR must be set on the SQL-server:

No comments:
Post a Comment
Note: Only a member of this blog may post a comment.