Installing Azure ATP Sensor… failed with 0x80070643

By Tomica Kaniski in Other 0 Comment

Another “short and sweet” one! 😀

I was installing a couple of Microsoft Defender for Identity (a.k.a. Azure Advanced Threat Protection, or Azure ATP) sensors, on Domain Controllers behind corporate proxies.

Everything went well on all of them… but the last one, of course!

Every other picked up the system proxy settings and installation went fine, but the last one failed… with a highly descriptive error saying “Installation failed. Error code: 0x80070643“:

It seems that this installation hasn’t picked up the system’s proxy settings (for whatever reason), and this information needed to be set manually during the installation.

So, after downloading and unpacking the Azure ATP Sensor installation, open Command Prompt (as Administrator, of course) and, from its folder, run this command (make sure you enter your proxy information and the right access key):

Hope it helps (helped me)! If it doesn’t, try reading this thread.

Cheers!

Beware of the proxy!

By Tomica Kaniski in Other 0 Comment

Had a (somewhat) interesting case the other day – after (finally) upgrading my Windows Admin Center (WAC) gateway machine to the new Windows Server 2022, my WAC suddenly stopped working. I couldn’t connect to any of the servers from within the console, couldn’t add new ones, … nothing.

When tried adding new servers, nothing happened – wizard stays at “Searching for…“:

Even PowerShell couldn’t connect anymore (which is actually the root cause of the above).

So, what happened?

Everything worked before and I wasn’t aware of other changes… other than upgrading my OS (in-place upgrade, Windows Server 2019 to Windows Server 2022), that is.

Let’s try and make sense of all this.

Test-NetConnection says everything is fine, Test-WSMan from another machine works:

However, Test-WSMan from this (WAC) machine simply doesn’t work:

Tried checking the logs next – two errors inside Applications and Services Logs -> Microsoft -> Windows Remote Management -> Operational log caught my eye:

  • Error 138: The client got a timeout from the network layer (ERROR_WINHTTP_TIMEOUT)
  • Error 142: WSMan operation Identify failed, error code 2150859046

So, it’s something with the network after all – more specifically, seems like there is some issue on the HTTP/S part!

After some thinking, I remembered that we have a HTTP/S proxy in our network – maybe my PowerShell session actually tries to go through it?! 😀

Checking if proxy is set (with netsh winhttp show proxy) – it is! This could be the issue.

Now I’m resetting the proxy settings (with netsh winhttp reset proxy, of course):

And then trying Test-WSMan again:

It finally works! And WAC works as well! 😀

Hope this helps!

Cheers!

Windows Update, Windows Server 2016 and proxy

By Tomica Kaniski in Other 58 Comments

The dumbest thing… you are installing your brand new Windows Server 2016 machines and then you realize that Windows Update doesn’t work. It just gets stuck on Checking for updates/Downloading updates… for days.

image

Of course, you have some sort of proxy on your network, and you start troubleshooting this issue by testing on a proxy-free network… and without proxy, Windows Update works just as it should!

So, the next logical next step is to blame “those networking guys”, because updating your machine works fine, when not behind their “fancy proxy thing”.

But no.

You will soon realize that you have some “old” Windows Server 2012 R2 (or even Windows 10) machines, which are updating just fine… even through the “fancy proxy thing”.

And then you start asking yourself why.

You are checking the configuration of older machines by opening up Internet Explorer and double-checking proxy settings… and then you make sure that your new machines are having the same configuration – they have. Then you are just confused. It’s not networking, it’s not proxy settings… what could it be???

Still a bit confused, you have a great idea to check system proxy settings by running netsh winhttp show proxy – on older machines you’ll probably see something like this (which is probably OK, because you’ve just seen the Proxy Settings in IE, which are set to correct values):

image

So, you’re (naturally) configuring new machines accordingly. Still doesn’t work.

What next?

You can do further reading & testing, but the thing that helped in our case was setting the system (winhttp) proxy with netsh command, so that it actually imports IE proxy settings.

Basically, you need to run netsh winhttp import proxy source=ie (after you’ve set the right proxy settings through IE dialog, of course) or set your system proxy by using the netsh winhttp set proxy proxy.mydomain.com:8080 command.

After that, Windows Update starts working again!

So, remember – when using Windows Server 2016, set your system proxy settings by using the netsh command and everything will work just fine! Smile

Cheers!

P.S. Of course, if you have another trick to make it work, please comment. Smile