Remote Server calls failing since recent Windows update

  • Has anyone else had issues with linked servers, remote calls, double-hops, etc, since the July, August, or September 2019 Windows updates? We know the cause is in there somewhere, as we have re-imaged a PC to pre-July updates and everything works. As soon as the updates are applied, ka-blooey. We can't control the updates (and there can be quite a few in each monthly package).

    We were able to log into a TheTrustedDomain, run our apps OurTrustingDomain\WebServer1 calling procedures on OurTrustingDomain\SQLServer2, which would in turn call procs on OurTrustingDomain\SQLServer3 without a hitch until "something changed".

    Things mostly work when we log into OurTrustingDomain, or RunAs OurTrustingDomain\UserName, but the organization doesn't want us doing that, and for a couple of weeks even that didn't work.

    Anyone have any thoughts / leads / solutions?

    Thanks,

    P

  • sounds like the service pack might have shut down a sql protocol that you use in your linked servers

    can you post the error message?

    failing that, drop and re-screate the linked server using sql server native client protocol (I assume your linked servers are just using"sql server" as a connection type

    also try switching the security context to sql authentication (not ideal, but it will tell you if it's an old fashioned Kerberos double hop issue)

    MVDBA

  • In fact, we've pretty much narrowed it down to this one:

    https://support.microsoft.com/en-ca/help/4490425/updates-to-tgt-delegation-across-incoming-trusts-in-windows-server

    Attempting to digest it, but I'm a DBA, and this stuff quite beyond me :-

     

  • ok - fairly simple,in the article the 2 domains have been told not to trust each other

    the workaround should work, but let your network team handle it - as a short term workaround, switch your linked server to sql authentication... might possibly work

    MVDBA

  • OurDomain definitely trusts TheTrustedDomain. And TheTrustedDomain has never trusted ours.

    Our workaround is having users start the apps using Run As with their OurDomain creds. But this is not ideal...

     

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply