2

Event with ID 7042 gets logged in the Event Log when two particular services (custom apps) stop on Windows Server 2022. The problem: one Windows Server is not logging those events. Is there an option or policy to enable logging of the 7042 event?

Maris B.
  • 182
  • 3
  • 12
  • Are both processes actually configured as a Windows service? Your "custom apps" comment makes me wonder if it's just an executable that is launched manually or at startup, but not actually as a service. – SamErde Dec 15 '22 at 19:02
  • Yes, both are Windows Services – Maris B. Dec 16 '22 at 07:27
  • To clarify, both services log 7042 on server A, and neither service is logging 7042 on server B? Are there any 7042 log entries on server B from any source? Were the servers built the same way or is one an upgraded older OS? – Maurkov Dec 16 '22 at 16:15
  • Yes, the same services log 7042 on A, and not on B. And on B there are log entries with other IDs, but not 7042. Not sure how the servers were built, I just want to enable event logging for 7042, because I am suspecting that it is disabled by some Group Policy option. – Maris B. Dec 16 '22 at 18:36

1 Answers1

0

I am not a Windows expert, but maybe I could suggest two things to check, since there are no other answers.

First of all, please check if Windows 2022 follows the approach similar to service monitoring as Windows 2008, like described here (or here, or here - these sources are almost same). I think that audit configuration principle is highly likely to remain unchanged, so you can try to run a command from the mentioned articles on both servers and check the output:

SC SDSHOW <service_name>

Command documentation is here.

If the output differs, you might consider taking the string from server A and applying the same DACL/SACL to service on server B using SC SDSET command, as described in article 1 or 2. Please make sure you understand what you are doing, and make sure you check DACL first using ConvertFrom-SddlString, for example, as wrong DACL might cause service outage! Plan & execute with caution, back the old DACL up before overwriting it.

If that is not working (outputs are same), check maybe the global audit options on both servers. From error message, it is possible that this event is classified as Success, and success events auditing might not be enabled on server B. So, check these options as well on both servers by running

auditpol /get /subcategory:"Other Object Access Events"
auditpol /get /subcategory:"Handle Manipulation"

You should see Success (or whatever) audit configured on both servers in the same way. If not, you can try to apply same settings for server B that you have on A using the auditpol /set command - once again, in the same way it was described in article 1 or 2. Please note that enabling the audit of successful events might cause considerable log count increase, so monitor server status closely after changing audit options.

Also, it might be worth checking GPO GUI, as mentioned here and here:

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> System Services

Never tried it myself, but maybe this section is still in place, and something interesting is there.

Alex
  • 186
  • 9