Forum Discussion
Error installing Azure ATP Sensor on DC
We have the ATP Sensor installed on 2 DCs. Both worked till last week.
Since there just one Sensor is working. On the Other DC it stopped communicating.
When i RDP on the Server i saw the Service was stopped.
Since today i was able restart the service. But today Service restart failed also after server reboot.
I decided to uninstall and reinstall the Sensor but without any lucky.
Always stops with this error:
Attached the Sensor Logs
Server details:
Server 2019 (1809)
Installed on Hyper-V 2016
No Proxy or SSL decryption
Thanks, Philip
JTUKTECH Proxy was the issue.
I followed these steps https://docs.microsoft.com/en-us/azure-advanced-threat-protection/configure-proxy#configure-the-proxy and finally it fixed couple of weeks back.
17 Replies
maple85 I had similar problems. Logs indicated that the updater service wasn't starting. If this is what's happening during your install, open services and keep bashing refresh. If you see the "Azure Advanced Threat Protection Sensor Updater" starting and then stopping repeatedly then it's probably this.
Bear in mind also that this is running as local system, so your proxy settings may not be correct. You can correct/set proxy settings for this user using: bitsadmin /util /setieproxy localsystem - help available under: bitsadmin /util /?
I was able to amend the proxy settings during the service start attempts and the service went on to install. Don't be too surprised if you break windows update if you change this setting if you aren't using WSUS.
JTUKTECH Proxy was the issue.
I followed these steps https://docs.microsoft.com/en-us/azure-advanced-threat-protection/configure-proxy#configure-the-proxy and finally it fixed couple of weeks back.
- bitsadmin isn't available on Server Core so best to use the /ProxyUrl parameter
maple85 Did you manage to fix this issue. We are facing the same issue.
We have 4 DCs on Azure infrastructure . 3 DCs worked successfully but in 1 DC we are facing issues
We have the same network configuration , OS , patches on all DC.
Kindly share suggestionsn pls
- EliOfek
Microsoft
SathishKumarPatchaiappan , are you sure it's the same issue?
the error code in the UI is very basic and can "split" to many root causes.
in order to know for sure you need to collect the deployment logs...
EliOfekbelow is what we see in the log
Property(S): INSTALLLEVEL = 1
MSI (s) (A4:C4) [20:55:25:640]: Note: 1: 1708
MSI (s) (A4:C4) [20:55:25:640]: Note: 1: 2205 2: 3: Error
MSI (s) (A4:C4) [20:55:25:640]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1708
MSI (s) (A4:C4) [20:55:25:640]: Note: 1: 2205 2: 3: Error
MSI (s) (A4:C4) [20:55:25:640]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709
MSI (s) (A4:C4) [20:55:25:640]: Product: Azure Advanced Threat Protection Sensor -- Installation failed.
- EliOfek
maple85 The key error in the log says
"failed two way SSL connection to service. The issue can be caused by a proxy with SSL inspection enabled. [_workspaceApplicationSensorApiEndpoint=Unspecified/constantiaindustriessensorapi.atp.azure.com:443 Thumbprint="
So most likely either you do have ssl inspection you are not aware of, os something else is in the middle breaking the TLS session. Hard to say what without having a stable repro.
- Is SSL Inspection explicitly forbidden?
- EliOfekYes, SSL Inspection is not supported due to mutual authentication.
Hi,
thanks for your answer!
I saw this with SSL inspection but fact is that I installed the sensor with the same setup 2 month ago.
Also on my 2nd Domain Controller on the same Network everything is fine.
That´s why i can´t understand why it is suddenly not working.
Problem began with automatically stopped service. First restart of the service helped but on one point it doesn´t . So i decided to reinstall the sensor but with no luck.edit: also auto update on this DC to new version did not work.
on 2nd DC no problem.
- EliOfek
maple85 try to capture a network trace to see where it fails.
Tip: I saw a case earlier this week where the client had issues with CRL. could it be that this machine does not have updated crl while the other has so it fails ?
If not, a network trace should tell you more, but it has to be something environmental...
