Error Communication WebClient

Copper Contributor

We are deploying Azure ATP Sensor on a DC and are getting the following error:


2019-12-04 15:06:10.3678 Error CommunicationWebClient+<SendWithRetryAsync>d__8`1 Microsoft.Tri.Infrastructure.ExtendedException: Sanitized exception: [Type=System.Net.Http.HttpRequestExceptionMessage=7INzM3PVZQKggOiiHcWjqw==StackTrace


We are using a proxy to connect to the Internet. As a troubleshooting step, we have got the IP address for the DC is whitelisted on our proxy to allow connections through to the Internet. The error still continues.


On the ATP portal, we see the Service Status changing from "Starting" to "Stopped" status as the service keeps on retrying to connect. However, the Health status shows as "Syncing". I have attached a screenshot as well showing the status. Ignore the ones that are masked out in BLACK, the one that is causing us issues is the one masked out in YELLOW.


Has anyone come across this issue yet and is there is a known fix for it?

8 Replies


This error means there is still a networking issue which blocks the sensor from contacting the AATP Azure backend via HTTPS/443.

Although  white listed, it might still be blocked int he proxy or somewhere else.

Note: If you install the sensor in silent mode, you have an option to install it with proxy support, including a proxy that requires an authentication, so instead of trying to bypass the proxy, maybe try to work with it...

@Eli Ofek 

Thanks for the quick turnaround! Very much appreciated!


We did start off with setting the proxy authentication and attempting connection via that route by using the silent mode install method. Gradually we then started troubleshooting and reached a point where we had to whitelist the server IP on the proxy without any success.


We are going to check our perimeter firewall to validate if any traffic is being dropped there.


In the meanwhile, does anyone know if there are any specific ports that need to be opened up for traffic related to ATP sensor communication?


Just 443, both to azure, and to localhost.

(The sensor service is communicating with the updater service via localhsot 443 as well).

@Eli Ofek 

Thanks for your assistance so far! We had traffic on 443 getting dropped on our Perimeter Firewall. Once the DC IP was allowed to communicate over that port, we saw a new set of errors.


These errors have been discussed in the Tech Community


In our case, we have a forest where the root domain is with two child domains, and (I have used example names). We are testing ATP sensor install on We are using an account which is created in as that is our user domain. Questions I had were, under Directory Services config on the portal:


- In the user name do I put just the SAM account or the UPN excluding the domain name

- In the domain, do I put or or


Any help on this matter would be greatly appreciated!

best response confirmed by tanves (Copper Contributor)
Both SamName and full UPN formats should work. Set the dc domain of the account. This is if all domains have full 2 way trust.

@Eli Ofek 


Thanks a bunch for all your guidance! We entered the UPN as per your advice along with the DC Domain and all communications started working!

@Eli Ofek 


I tried the silent installation but it doesnt install or give any error.

Tried UPN in the silent installation as below:



.\"Azure ATP sensor Setup.exe" /quiet NetFrameworkCommandLineArguments="/q" AccessKey="xxxxxxxxxxxxxxxxxxxxxxxxx==" ProxyUrl="" ProxyUserName="" ProxyUserPassword="xxxxxxxxx"


Is it correct?



@Amin7RDR The format is correct, I can only guess that the values are correct as well :)

In order to sww what went wrong you need the deployment logs,  the interactive console/ UI won't tell you much without the logs.

1 best response

Accepted Solutions
best response confirmed by tanves (Copper Contributor)
Both SamName and full UPN formats should work. Set the dc domain of the account. This is if all domains have full 2 way trust.

View solution in original post