4 ms·

That's not just plausible but probably needs a CVE and then MS will have to act. I can feel an experiment coming on: Mint an OpenSSL based CA and use it to ge

That's not just plausible but probably needs a CVE and then MS will have to act. I can feel an experiment coming on: Mint an OpenSSL based CA and use it to generate 200 certs for randomly generated CNs. The script could write out a zone file and web server vhost configs. Pop the CA cert in a Win PC/Server trust store. "Fix" the time on the web server. AutoIT could be used to poke a browser at each vhost or an iframe monstrosity. I have yet to see this snag myself but it sounds like an MS style screw up. Excellent engineering fucked up by one wrong assumption which leads to a huge towering monstrosity. Sheer arrogance precludes a back down, MS ploughs on and then after a year or two, a fix is silently released and the victim shaming carries on for a little while longer. Meanwhile social.ms carries on advising sfc /scannow and then reinstalling the OS.

londons_explore 3y ago
> advising sfc /scannow and then reinstalling the OS. I really hate that. If there is some problem, properly diagnose it, figure out how it happened, and figure out how to change things so it can never happen to you or anyone else again. Or you could just wipe all config and reinstall everything and hope it doesn't happen again!
- 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 ago
    Fiddler w/ SSL decryption is the way to go to help diagnose connectivity issues with Exchange.
    - gerdesj 3y ago
      I use wireshark instead - https://wiki.wireshark.org/TLS https://wiki.wireshark.org/TLS
      - nullindividual 3y ago
        They're not comparable tools. I wouldn't use Wireshark to debug HTTP. And Fiddler simply can't intercept other protocols.
        gerdesj 3y ago
        Fiddler 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.

londons_explore 3y ago

> advising sfc /scannow and then reinstalling the OS. I really hate that. If there is some problem, properly diagnose it, figure out how it happened, and figure out how to change things so it can never happen to you or anyone else again. Or you could just wipe all config and reinstall everything and hope it doesn't happen again!

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 ago
  Fiddler w/ SSL decryption is the way to go to help diagnose connectivity issues with Exchange.
  - gerdesj 3y ago
    I use wireshark instead - https://wiki.wireshark.org/TLS https://wiki.wireshark.org/TLS
    - nullindividual 3y ago
      They're not comparable tools. I wouldn't use Wireshark to debug HTTP. And Fiddler simply can't intercept other protocols.
      - gerdesj 3y ago
        Fiddler 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.