0 Replies Latest reply on Nov 16, 2016 9:35 AM by David Miller

    November 2016 Security Monthly Quality Rollup for Windows Server 2012 r2

    David Miller

      On our test system for Responder 10.2.1c (which we have running on Windows Server 2012 r2), we applied the "November 2016 Security Monthly Quality Rollup for Windows Server 2012 r2".  It was a biggie at 155.5mb in size.

       

      After restarting the server, we attempted to restart Responder and it did, but Line Display and Prediction services both spit out tons of errors about MSMQ timeouts.  We were also blowing .NET runtime errors for 2.0.50727 with anything Responder tried to do.  Eventually, the Responder Windows service crashed out.

       

      After doing some triage and work, we discovered through using “netstat –abno |findstr 1801” that the IP address that we had set in the registry for MSMQ to use the parameters “BindInterfaceIP" value was being ignored and the MSMQ service had defaulted to using the IP address of 127.0.0.1 post MS patch.  Noticing that Windows “WinRM” authentication event errors were present in the system events at the same time the timeout errors were occurring for Responder started pointing towards authentication issues related to MS DTC related to MSMQ coordination of services.  Then we go through this process:

       

      1. Stop Responder applications on affect server
      2. Stop MSMQ Services and then stop MS DTC service
      3. In services select the Distributed Transaction Coordinator properties and select Log On
      4. In the Log On properties select the “This account:  “ browse button and Enter the object name to select as “Network Service”
        1. If Network Service is the account selected and used, do this step anyway to re-associate the service level account.
      5. On the Log On tab select OK to apply “This account” changes. 
      6. Open a command prompt as an administrator
      7. At the command prompt type msdtc –resetlog and press return/enter key
      8. Start MS DTC service
      9. Start MSMQ service
      10. Restart responder

       

      With the way Microsoft's patches have behaved over the last couple of months, this may be very handy to know in the future.  We don't know if this happens just with our configuration or if this is a global issue with Windows Server 2012r2.

       

      Thank you to my system admin ron whitney for getting this all figured out!