When attempting to load the ACS forwarders on systems not attached to the domain, it seems to go ok, but then, no data ever seems to make it to the server for auditing.
I started troubleshooting by enabling extended logging for the agent.
Dipesh’s blog explains some common issues associated with the agent. The following shows how to enable extended logging.
1. Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AdtAgent\Parameters
2. Create DWORD value = TraceFlags and set it to a decimal value of 524420.
3. Restart AdtAgent service.
After following the procedures, I ended up seeing the following error frequently in the logfile:
[20100816 122255,058][Info ]LookupServersReg(): Found HQSCOM01.DirectApps.int:51909.
[20100816 122255,065][Error ]IoContext(0xC5C630)::OnRecvComplete(): Disconnecting: dwIo = 0, dwError = 0x00000040.
[20100816 122255,065][Warning]IoContext(0xC5C630)::OnRecvComplete(): Disconnecting.
[20100816 122255,065][Error ]AgentClient::Connect(): Connection status 0x00000040.
[20100816 122255,065][Warning]ConnectToServer(): Calling Disconnect() with error 0x00000040.
There are a variety of parts associated with this. Some of which I’ll cover here, some of which I presume have already been completed. Keep in-mind, these errors were encountered on a non-trusted host, meaning the forwarding server was not listed in Active Directory. If you are getting the same errors on a host that is trusted (e.g. joined to the domain) then you are likely facing a different problem.
We had already completed the steps of registering a non-trusted computer using certificates. However, the computer was not sending the security auditing information back to ACS and the agent was generating the 0x00000040 errors in the agent log. All other aspects of the agent were working correctly, such as performance monitoring, pings, health reports, etc.
The following steps were performed (as outlined in System Center Operations Manager 2007 Unleashed, p 782):
1. On the ACS collector, perform the following task once –
a. Stop the AdtServer service (net stop adtserver at a command prompt with admin privileges)
b. Change directory to %WinDir%\System32\Security\adtserver (not in the book)
c. Type “adtserver -c” at the command prompt
d. You’ll be prompted to pick a certificate that was registered to the ACS collector host and generated by the domain certificate authority
e. Start the Adtserver service (net start adtserver)
2. For each certificate-based, ACS forwarder, use the certificates mmc on the forwarder to export the certificate (cer) file for the local computer (when you bring up the mmc, it wants to default to user level, so make sure to change to computer)
3. On a domain controller for the ACS collector domain, open up active directory users and computers (ADUC). In one of the OUs, create a computer account (using the defaults) with the same name as the forwarder that you exported the certificate from. (to keep management under control, we created a “foreign computers” OU and then made an OU for each client site or grouping of computers.
4. Right-click on the computer and select the “Name mapping” option. Add the exported certificate.
5. In the operations manager console, enable the audit health collection option.
6. On the forwarder, stop the adtagent servers and run adtagent -c at the admin command prompt. Select an existing certificate to import associated with the name of the forwarding computer. Start the adtagent service again.
Once these steps were completed, a review of the adtagent logs showed no further errors and ACS events were now showing up in the audit reports.