Beware of the proxy!

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!

Capturing network trace in Windows

Do you need to capture some network traffic on a Windows box for further analysis, but don’t want to install additional software just… everywhere?

I usually do.

If you didn’t know, Windows has built-in tool with which you can do just that – (among other things) capture network trace to a file for further analysis. The tool is called netsh.

So, how do you capture traffic with netsh?

It’s fairly easy (for more options, filters and such, you can always check the accompanying help content – netsh trace start ?):

If you look at the location where you’ve saved your trace, you’ll see two files – of those two files, MyTrace.etl is the one you want:

OK, but what do you do with it?

If you try to open it with, for example, WireShark, you’ll see it doesn’t work:

So… we have a trace file with which we can’t really do anything?!?

Not exactly!

If you have Microsoft Network Monitor (now archived, but can be found… on the Internet) or Microsoft Message Analyzer (now retired), you can open up and analyze your trace as you normally would:

If you already have WireShark on, let’s say, your workstation, and want to continue using it for the analysis, this trace needs to be converted to a format which WireShark understands (hope that one day we’ll have WireShark which opens such .etl files natively).

You can convert it by using the free tool called etl2pcapng.

It doesn’t require installation, and if you want to use the pre-compiled binaries, they are available under etl2pcapng releases.

So, convert your (netsh) MyTrace.etl to (WireShark’s) MyTrace.pcapng with this command:

Once converted, you can open the new file (MyTrace.pcapng) in WireShark, and do what you would usually do to analyze it:

Hope this helps!

Cheers!

Windows Update, Windows Server 2016 and proxy

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