Showing results for 
Search instead for 
Did you mean: 
Create Post

Object Status is Up, one or more child objects are in Down state.

Jump to solution


Just applied the latest SR 10.2.2, hoping that the bug, where objects in a map have a red dot on them has been addressed but the issue remains...
Any ETA on when this issue would be addressed? The false positives presented in the maps are causing alot of confusion and panic!

Just to confirm, I did already double check that no child objects have any faults either, therefore a status rollup is not the culprit.
The issue is current on any map, in any module. Lastly, creating a quick basic map with the same nodes still shows the nodes/objects as having one or more objects in a down state.


1 Solution

For those of you that don't see the Orion.UDT.Port line in the table after an upgrade to NPM v10.3, you'll have to manually add it.

Here's the SQL query:

insert into NodeChildStatusParticipation (EntityType, ModuleName, Enabled, Installed)
values ('Orion.UDT.Port', 'UDT', 0, 1)

Thanks Jamie

View solution in original post

0 Kudos
25 Replies

fcaron Is there anything we can do to disable the setting from being reverted if or when you ever run configuration wizard?

Is there a database schema that is used to compare settings, which could be modified?


On a test deployment with a fresh database, the setting for childstatusparticipation seems to be disabled by default.

It is only on existing databases, or upgraded installations, that this setting is enabled.

0 Kudos

I've resorted to a post Configuration Wizard clean up SQL script. Right now just removes the virtualization tab on the admin menu bar and sets UDT and sql appinsight child status participation to 0.

0 Kudos
Level 10

In NPM 10.5 and UDT 3.0.0 I Still get into this issue. I 'm trying to follow some direction here to fix this error.

Thanks to Thwack community.

0 Kudos
Level 8

What table are you guys referring to? There are a lot of tables.


Nevermind, NodeChildStatusParticipation is the table.

I don't have this exact issue. My groups are all green, even though there are warning/errors. And I have the rollup set to worst case. Weird.

I'd like to make a correction to my last post. I said that it wasn't resolved in the 10.3 RC3 release, either, but that is not entirely correct.

It seems that it is possible to disable this "feature" in 10.3 and ONLY in 10.3 to show the "correct" status of nodes in maps. I'll elaborate more on why this should be set as the default setting after explaining the feature.

Looking at the table NodeChildStatusParticipation you'll find the following:


As you can see, Orion.UDT.Port status is checked and that means that any status relating to UDT ports - such as 100% used ports on a specific node - will rollup to the overall node status in the map.

You can disable that entity from participating in the child rollup status by removing the check mark or running the following query:

UPDATE NodeChildStatusParticipation SET Enabled=0 WHERE EntityType=’Orion.UDT.Port’

I've tried this myself and can confirm that our maps now show something that is expected, hooray! (Remeber this is only possible in 10.3 RC3)

So, why is it so important that this newly added feature in 10.3 includes disabled rollup setting for UDT by default?

Well to answer this we need to look at UDT and determine what it does really as a module, what is its purpose, what are its functions and what should it alert on by default?

Three things;

1 Is tracking functionality. You can keep an eye on equipment and know where they are located and what they are connected to on your network. Excellent!!!

2 Tracking user activity in your domain by tapping into your ADDSs. Fantastic!!!

3 Inventory for all switches (or anything with a port). This feature allows you to report on port usage; how many ports are used and what are they being used by? You could use UDT to figure out whether you've got more networking equipment that you actually need by connecting nodes from one under utilized network switch to another. In that case, your objective is to use up all the ports on one switch rather than using half of all the ports on two switches. The end result is better use of your equipment and less power consumption. Makes sense, no?

Paying close attention to UDTs third major function, that is - reporting/provisioning of ports, one would expect that if all ports on a switch are being used then that switch is doing what is is supposed to do and everything would be great - for that one switch. Why would that raise an alarm? It makes no sense. And if it does raise an alarm, one would have to ask himself if that is in reality an alarm at all? Do i have to have a minimum of 20% available ports at all times on all monitored nodes? I can't see the logic of alerting on the % used ports in general. It may be relevant and of major importance to someone but then why does that alarm have to create a false positive elsewhere in the system?


This is still the case in NPM 10.7, UDT 3.0.2 and Core 2014.1.0

Unless I am missing a menu option I still had to do the table update to remove UDT status (in my case UDT monitoring ports that are down status) so it doesn't clutter my maps with tiny red pimples.

Hi, we upgraded to 10.7 and notied that the routers showed green status even when one or more interfaces were actually down. Previously on 10.5 version the interface status correctly reflected on the node status; it had green icon with blinking red icon superimposed.

I made the sql update as suggested in this thread but it didnt make any difference.

Any suggestions?


0 Kudos

I am also seeing this issue with: Orion Platform 2014.1.0, NCM 7.2.2, NPM 10.7, NTA 4.0.0, UDT 3.0.2, IVIM 1.9.0

0 Kudos

Hi guys,

For anyone reading this, the quoted workaround is still the only way to display maps without the influence of UDT thresholds in NPM 10.3 GA.

0 Kudos

For those of you that don't see the Orion.UDT.Port line in the table after an upgrade to NPM v10.3, you'll have to manually add it.

Here's the SQL query:

insert into NodeChildStatusParticipation (EntityType, ModuleName, Enabled, Installed)
values ('Orion.UDT.Port', 'UDT', 0, 1)

Thanks Jamie

View solution in original post

0 Kudos

As Deltona mentioned, in 10.3 we have implemented a possibility to turn off UDT ports status calculation into Node's child status.

The query you need to run against your Orion DB to exclude UDT ports status would be

IF NOT EXISTS (SELECT 1 FROM [NodeChildStatusParticipation] WHERE [EntityType]='Orion.UDT.Port')

  INSERT INTO [NodeChildStatusParticipation] ([EntityType], [ModuleName], [Enabled], [Installed]) VALUES ('Orion.UDT.Port', 'UDT', 0, 1)


  UPDATE [NodeChildStatusParticipation] SET [Enabled]=0 WHERE [EntityType]='Orion.UDT.Port'

(which is almost the same as above except the row might not exist in the table yet)

No need to restart any services, just refresh the page with the map,

Thanks to Deltona for cooperation!

Jan Petrzelka

Orion Tech Lead

New catch - this actually helps, but the setting is reset to Enabled=1 on every Orion Business Layer (Module Engine) restart.

We'll trace it as separate issue.

As a workaround, avoid service restarts and disable the "Orion.UDT.Port" setting as needed.

0 Kudos
Level 8

  I am having the same issue except my primary object is greyed out and says a child object status is unknown.  These objects have no child objects configured nor anything within the map that would make it a child for status to flow up to the primary object.  Has this been resolved yet by chance?

Thanks for the help - Mike

Hi Mike,

This hasn't been resolved yet. At least not in the 10.3 RC3 release.


Level 17

I assume you are running UDT or IPSLA?  I am running both and believe both are culprits for this behavior.

I have had to remove those modules from my web server farm to prevent these false positives.

I maintain the modules on the primary engine and I look at that site if needed.

I agree that this needs escalated attention!!!

0 Kudos

Hi Larry,

We have the whole Orion suite running on one box.

0 Kudos

Has any PM had a chance to look at this and escalate?

0 Kudos


0 Kudos

We are going to look

0 Kudos