Incidentally, the reason why I’ve only just installed the patch, several days after it was made available is because last week I cleaned up the disk space used on our SUS server and one of the things I (mistakenly) did was to select what I thought was all the urlscan log files, but actually included urlscan.ini. This didn’t stop urlscan working – it just blocked practically every request as GET was not on the list of allowed verbs (as this list didn’t exist). It was only when I realised that the patch hadn’t been installed yet that I realised this was the culprit.
Comments
I think what you are trying to say is that when you deleted the urlscan.ini, rebooted (or at least restarted the IIS services), that all of the incoming GET requests were blocked! (which is behavior by design)
Do I understand you correctly in saying you might have suspected that just the patch being installed was the reason IIS was blocking all incoming GET requests?
Yes the behaviour was by design and it was because the patch was the last thing to be installed that I suspected it *might* have been the problem – but it wasn’t.