3 ms·
My work Windows server VM boxen started off life largely as 2008 R2, one was 2008. They are all now mostly 2022 and converted to EFI with secure boot - some of
by gerdesj 3y ago
My work Windows server VM boxen started off life largely as 2008 R2, one was 2008. They are all now mostly 2022 and converted to EFI with secure boot - some of them put up quite a fight. Not a large setup - three DCs - one in my home attic for DR, a File n Print n NPS n CA box, a Trellix (Nee McAfee) ePO and a few more bits n pieces.
sfc /scannow can fix issues but it is not a panacea and certainly not the first thing you should reach for. It sorts some aspects of .dll hell but that is an app thing and a complex one.
As you say, get the logs out and your stethoscope. Sadly most of us don't have access to source with Windows, so we rely on intuition, 30 years of experience and some really cunning search queries. Even though Google search is largely wank, a decent and carefully curated ublocklist can winnow out the worst rubbish.
Having said that, Outlook is totally damned when it comes to logs. Outlook trace logging is an Outlook programmers debugging tool only and of absolutely no use for a sysadmin. You literally fly blind with Outlook and are best off looking at Exchange logs instead. The Outlook devs are only interested in themselves and no one else. You do get CTRL - r click on Outlook icon to unlock the connectivity checker to give you absolutely no help apart from showing how bad things are. The autodiscovery checker is handy and I have fixed configuration issues with it.
- nullindividual 3y agoFiddler w/ SSL decryption is the way to go to help diagnose connectivity issues with Exchange.
- gerdesj 3y agoI use wireshark instead - https://wiki.wireshark.org/TLS https://wiki.wireshark.org/TLS
- nullindividual 3y agoThey're not comparable tools. I wouldn't use Wireshark to debug HTTP. And Fiddler simply can't intercept other protocols.
- gerdesj 3y agoFiddler is a MitM proxy with knobs on. I don't deny it is rather handy. I use a lot of tools. Wireshark simply listens. If you give it the private key for a TLS exchange it is able to decrypt the stream. Fiddler makes changes to the stream - it turns a single stream into two streams with the Fiddler in the middle, Wireshark does not - per se - it just listens but because it will be a tap in a stream it will slightly affect that stream, unless you use a switch that can mirror ports - and that's what I do. When it is your web server (int al) then you have access to the private key and then Wireshark's minimal touch is indicated. Otherwise Fiddler or similar (Squid and others for me) is indicated instead.
- nullindividual 3y ago(I've used Fiddler for... ever, so I'm familiar with it) The GP likely doesn't have the private key if they're using Outlook. As if they're using Outlook it is most likely with Exchange. And if they're using Exchange, it is most likely EXO. Hence, Fiddler as the appropriate recommendation for this portion of the thread.
- gerdesj 3y agoIf you have to resort to a proxy (fiddler) then you are making changes. You do not get to sample unblemished data. Perhaps that is OK for the snag/issue in question but may not be. Port mirroring/SPAN/RSPAN is the only way to be an observer without affecting the traffic you are inspecting. Fiddler literally does a man in the middle attack. If you don't have access to a private key for a TLS exchange and stream, then you cannot do quite a lot of diags. In the end, Fiddler and the like might do the job but to really get close to the wire requires full knowledge and a much lighter touch. That will be a port SPAN/mirror and Wireshark and a private key.
- nullindividual 3y agoAgain, irrelevant for the discussion at hand.