I tried LogOnServer project from mipsdk-samples-component but can’t make it write audit logs. The method AuditEntry is called but nothing happens, no exception is raised, no logs are written.
However, audit logs can be read when using the LogClient.Instance.ReadLog method in the project.
XProtect version is 2021R2 and the MIP SDK version is 21.2.0.
Please try the latest version of the MIP SDK. This might be easier if you use the newest version of the sample.
https://github.com/milestonesys
You can use the newest version of the MIP SDK even if your XProtect VMS isn’t the newest version.
Thanks for the answer but unfortunately, the newest version of the MIP SDK produces the same behavior. It doesn’t write audit logs.
I tried on a 2020 R3 installation and it’s the same issue.
I have no clue why it’s not working, Could it be related to the XProtect VMS installation ?
Yes, we must suspect that something is special and causing the issue as it does not fit a known issue. That you see the issue in two different installations with different versions does however make it even more of a mystery.
Please allow me first to ask whether the logging functionality in general works as intended?
Please test; if you make a rule to log something does it work as expected?
And first step troubleshooting, do you see any error in the MIP SDK logs?
The logging functionality seems to work as expected.
I made a rule and a log was written.
There is no error in the MIP SDK logs.
Neverthless, while doing my tests and not defining the LogMessageDictionary correctly, I could see error logs in the MIP SDK logs : “Error LogClient Unable to find log message with id=MyMessageId”.
If you look in the sample you have this line of code:
LogMessageDictionary lmd1 = new LogMessageDictionary("en-US", "3.9", _myApplication, _myComponent, BuildDictionary("en-US"), "AccessControl");
One thing is important here. Every time you use this to register a message you must bump the version: If the version has been used before and is reused the registration is ignored!
Might that be it? Please retest making sure you use a new “version” string.
I have an idea that I should add a comment in the sample so that this information is there for future versions of the sample. Let me know if it solves the issue for you.
I bumped the version but it’s the same result, no audit log was added.
It does not seem to be the issue here.
I finally made it work. I tried it on other milestone installations and it works as expected 
But, it doesn’t work on one of our installation, I can’t figure out why. I might be related to the many tests I did on this one. Is there any way I can reset the dictionnaries ? Is it stored in files or in the database ?
Thanks for your help 
Hi Julien,
The Log Server message types are stored in the database. The recommended way of doing a cleanup is to re-install the Log Server.
When doing the reinstall, make sure you select the “Overwrite” option for the database.
Alternatively, you can manually delete the “SurveillanceLogServerV2” database, and re-install the Log Server. Then select to create a brand new DB. It’s what the “Overwrite” option does anyway.
Please be aware that both options outlined above will delete ALL log messages on that server. So make sure there isn’t anything there that you intend to keep.
In relation to why that particular machine doesn’t write logs, looking into some debug logging might be useful. The usual suspects would be the Log Server debug logs (“[C:\ProgramData\Milestone\XProtect](file:C:/ProgramData/Milestone/XProtect) Log Server”) and the MIPSDK logs (“[C:\ProgramData\Milestone\MIPSDK](file:C:/ProgramData/Milestone/MIPSDK)”)