ERROR SolarWinds.InformationService.Core.CrudProcessor - Create operation failed.

Create/Update/Delete is not supported for Orion.NPM.CustomPollerAssignment. This is enforced through the access control mechanisms, so that's why you're getting an access denied message.

I'll bring this to the attention of the product manager for NPM, because what you are trying to do is a very logical way to automate things.

Got it, thanks Tim (99351)

kbyrne@maximumasp.com, can you elaborate on your use case a bit more?

What type of pollers, how many, deployed against what type of node...

That wil help us treating this enhancement request with the appropriate priority

My developer has this working on our production box, but this is not working on our lab box.  we have 6 custom pollers that we are trying to assign to a node once it is added to the database.  We can figure out why this is failing, when it works on the prod box.  The nodes we are adding are Juniper Netscreen firewalls and we are adding session, cpu, memory type of pollers.

Are the two servers running the same version of NPM?

Can you use a stored procedure instead?

CREATE PROCEDURE [dbo].[sp_addCustomPollers]
 @NodeID int,
 @FQDN nvarchar(255),
 @PollerGroup nvarchar(255)
AS
BEGIN
 INSERT INTO CustomPollerAssignment (CustomPollerAssignmentID, AssignmentName, CustomPollerID, NodeID, InterfaceID)
  SELECT NEWID(), UniqueName + ' on ' + @FQDN, CAST(SUBSTRING(cast(CustomPollerID as nvarchar(255)), 1, 36) as UNIQUEIDENTIFIER),
  @NodeID, 0 AS InterfaceID FROM CustomPollers
  WHERE GroupName=@PollerGroup and Enabled=1;
END

Both Servers are running 10.2,  one server is running NCM 6.1 and the other 7.0,  But that shouldn't matter since this wasn't working before I upgraded it to 7.0 either.

The trouble with just updating the database (with or without a stored procedure) is that the new custom poller assignments may not be scheduled for polling right away. A restart of the Orion Module Engine service would cause the new assignments to get scheduled for polling.

I can't explain why it would have worked on one 10.2 server but not the other. That's strange.

I talked to our developer and he said that is not really an option moving forward, because we run the risk of corrupting the entire database.

I have ran the permission checker and the configuration manager to see if there was a fix that needed ran. 

Just curious, would the fact that our lab environment is a virtual machine running the software and database be a factor?