yeah, from what I've read online on various places (including technet), they indicate adding 127.0.0.1 crl.microsoft.com to your hosts file should result in a quick-fail response to the site and give much better performance, but it seemed to make no difference on my server. I checked the webpage in IE and it comes back rather promptly (with a 400 error mind you, but it is a fast response), so I am thinking my issues are unrelated to the CRL. Blocking it in the hosts file seemed to make no difference.
The other interesting thing I noticed is that a 1 step SQL job (the step just calls a simple SSIS package) runs slowly. The job step completes in 20 seconds, the job itself completes in 33 seconds. Prior to the updates, the job step would complete in 5 seconds tops.
when I look at the sysjobactivity table, prior to the update, I see data like:
Run_Reuqested_Date - 2018-03-02 20:05:00.000
Start_execution_date - 2018-03-02 20:05:00.000
Last_executed_step_date - 2018-03-02 20:05:00.000
Stop_execution_date - 2018-03-02 20:05:05.000
After the update, it looks more like:
Run_requested_date - 2018-03-13 15:05:00.000
Start_execution_date - 2018-03-13 15:05:00.000
last_executed_step_date - 2018-03-13 15:05:04.000
stop_execution_date - 2018-03-13 15:05:32.000
If I go into the overview of that same SSIS package, I an see the duration of the individual package steps (using today's date) it shows the 3 steps (the whole package, the "clear existing data" step in the package and the "move data" step in the package) is only taking a little over 1 second to complete. BUT the duration of the whole package is 16.067 seconds. The duration of the job though is 32 seconds for the above example.
I can't find anything useful in either the SQL logs or the windows logs either. I did try doing some stuff with netstat, but it didn't tell me anything interesting. I tried turning off the firewall on the server (short term) but it made no difference either.
This one is confusing me as we didn't change the job at all. Just windows updates (including SQL updates). It did result in a .NET update... I wonder if that is being problematic...
As for blocking the CRL, best I could find, it is not a configurable thing as it is baked into .NET.
Forgot to mention - my IT department told me they see nothing bad happening network wise. I imagine this is going to be something simple that I am just not thinking to check (like some service got switched from automatic to manual with the update), but I am just running out of ideas on what to look at or for.
Last edit for this post - I tried running the 64-bit dtexec and it took 17.969 seconds to run the package. The 32-bit dtexec took 20.453 seconds. running it in visual studio takes 5 seconds but that is not a realistic scenario.