Symantec Management Platform (Notification Server)

Hi,

From time to time we notice that certain event status data is not updated for any computers. Like it is described in TECH40691. The article points obviously also to the solution and this is to change the value of EnableNSEventLog from false to true in the coresettings.config file.

So far so good I can change the value but apparently after a while it is magically set to false again.

Has anyone seen a similiar problem?

Infrastructure contains 1 parent ns and 4 child ns. It has only been seen on child ns. Version on SMP 7.1 SP2 MP1.1 + Rollup v3.

Stefan

Yes we are seeing the same, though it hasn't done it now for a few days. Are you bouncing the Altiris services after resetting the value?

Maybe the first couple of times it happened we did not pay attention about restarting the Altiris service but now I am certain that we restart the service every time after changing the value.

Because it has happened now a couple of times I have also raised a case with support. But I am not sure I will come far with the case and that's why I have started this discussion to hear if anyone else has the same problem and maybe a permanent solution.

I had previously contacted our RPS on this issue, and pinged him again with a link to this thread.

I think it is possible that others are having this issue, but aren't necessarily looking at the type of data that would be impacted by this not being "true", i.e. Last Configuration Request and other event-type data (Inventory seems to be processed fine, and Patch Management deployments, etc).

Now over the last 3 weeks it happens on all the 4 child servers. None of the servers show any "clue" in the log files which means soon my support case will be closed (but not solved) because support cannot find anything....

Anyhow it seems strange to me that there are 2 tech articles out there how to "correct" this setting even though there is no clue which process changes the setting. I don't think it is that many users would go in and change it manually and later on discover there is problem...

@Kyle: Have you heard anything back?

I have been looking into this issue and It seems to be related to the import of items during a replication from the parent to the child. You will not find anything in the logs which reports that the setting has been changed to false, because it is a normal part of the import process. Before at least certain items are imported into the database, the EnableNSEventLog flag is set to false, the item is imported and then the flag is enabled again.

It seems to me that the issue is occuring during the item import step. If an unhandled error were to occur at this stage, the flag would never be reset to true. I have yet to identify what situations could cause this to happen.

Stefan, do your 4 child servers switch from true to false on a predictable basis and do you have any errors reported from replication (particularly relating to the import of items) in the hours preceding the change?

We have only recently started to investigate little bit further in this matter. Actually I was hoping this would be fixed in one of the many updates I have applied in the last 6 months....

However, if I think back it kind of happens on a monthly basis. So I could imagine it could come from the patch management. We have had several cases already opened regarding PM and Replication. For example just now we have opened a case that the "Import Patch Data for Windows" task cannot be started on a child server. But it could also be a false track....

The report "Server Hierarchy Replication" shows many objets failed to replicate and here we have another issue if we want to do "drilldown" to see further details the report times out....and we are told this is a performance issue.

I guess the errors reported from replication I would see in the Altiris logs but I would have to know exactly when it happened and this exact time we always seem to miss with 2 - 3 days and then log files are already gone.

Is there any other source where I could find errors relatintg to the import of items?

I have also been experiencing this over the last 5-6 months.

Like Stefan also noticed.  It appears to happen to my Parent and 6 Child servers around the first week or so of the month.

I usually do not notice it until  a day or so after it happens so hard to see what ran around the time it occured.  I have even ran every scheduled task manually in hope one of them was causing it to revert to false.

 

What I want to do is , since my site servers report in every 1 hour, setup an automation policy email to where if one of them have their configuration request date/time not be within the past 1.5 hours to trigger the email.

I might then be able to see what task, policy, replication rule, etc.. might be causing it.

 

Clay

 

ITMS,CMS,SMS 7.1 SP1 MP1.1 v3

You can increase your log file size and number of log files to help capture more history of replication. Update the settings at HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\eXpress\Event Logging\LogFile\MaxFiles.

 

Or, verify that the setting is correct, then force a replication to the server in question (either partial or complete; unknown which one actually triggers the problem, and could be sporadic: maybe only certain items cause replication to fail?).  Once the replication completes, check/verify the setting is still True.

I think I have identified the root cause behind this. Can some of you experiencing this error search for the term 'CoreSolutionInstallation' in the error logs on an affected child? It will probably be related to an error saying that it failed to import an item because it was on the replication blacklist. Does the item referred to in the error message have the guid: {a18da391-b2dc-4bbd-83a9-84b2fdfd6f9f} ?

Now I just need to figure out how to exclude this item from the replication manifest. It clearly shouldn't be replicating anyway. On the server I am looking at, it is the attempt to replicate the security on this item which is causing the problems.

In the absence of a codefix, the most immediate resolution to this issue would be to schedule a script to run on the child servers after a replication job is run which would set this parameter to true. If you can identify the entries in the log files where an import failed to import item with the guid {A18DA391-B2DC-4BBD-83A9-84B2FDFD6F9F}, and timing of this error is reasonably consistent, you could set the script to run shortly after this error is logged.

I have found the same issue also in our test environment and there I found the mentioned error in the log on the child server:

 

Actually it recorded many "failed to import" errors but that's maybe normal...

So how could I create a workaround? Is there a way to trigger an action on this error within the Altiris Log Viewer?

 

Hi Stefan,

You could save this as a file called EnableEventLog.cs

using System;
using Altiris.NS.Utilities;

class EnableEventLogging
{
    static void Main(string[] args)
    {
        using (ImpersonationContext ic = Impersonate.ImpersonateAsSvc())
        {
            Altiris.NS.Configuration.Core.Settings["EnableNSEventLog"] = "true";
        } 
    }
}

You can run this using the NScript.exe tool under C:\Program Files\Altiris\Notification Server\Bin

The command line would be: NScript.exe EnableEventLog.cs

You could schedule this with Task Server to run after replication or just run it on a regular basis. I can't think of a simple way to get this to trigger on the error in the log files.

An alternative solution would be to exclude the guid from the results of the spSecurityItemFilter stored procedure when @isHierarchyRule = 1 and @isSecurityOnly bit = 1. I have not tested a solution like that however and I do not know if excluding the guid from this list would have undesireable consequences.

Thanks for the hint with the .cs file. It is good to know for another time ;-) For the time being I went with a vbscript which is running as a scheduled task and when finding the value has changed is backing up the log files to a save place.

While I was testing my script in the test environment I have found out that the value has changed again and this was only last week I have changed it to true. This being said now I know what is causing the change to happen. It is the "Full Replication". This runs once a week in our test environment and once a month in the production environement. So this matches the pattern of the changes....

Now I have only the part left to fix the "item" which is causing the full replication to fail...

Hi Stefan,

It is indeed the Full Replication which causes the failure. In particular, it is attempt to replicate the security on the core solution. I have raised this as an issue internally and, as the fix is very simple, it should make it into a point-fix release very soon.

Thanks again with your help I could guide the support the right way and indeed I received the fix which is just an update on a stored procedure.

I was also told that it will make it in the next rollup 7.1 SP2 MP1.1 v5 for all others who might expirience the same issue.