Questions

MSXML Broken after MS security update

+
0 Votes
Locked

MSXML Broken after MS security update

billmez
After installing the xml update of 11-14 I can no longer access XMLHTTP through IIS. Any attempts come up with Server.CreateObject Failed Invalid class string error.

This is happening on XP pro, 2000 Advanced Server, 2000 pro, and server 2003, and it is even affecting MSXML3, which should have not been altered by the update. Please note that MSXML DOMDocument does not appear to be affected by this, only XML HTTP.

The dll's are properly registered, and the xmlhttp works using vbscript and WSH command line. I know it is a permission issue, and have had this happen before with scripting permission access after an update, but I am lost at where to look or what changes to make.

In past problems there were registry keys that needed to have permissions
modified, and I tried to add both everyone and IUSR to the xml and xmlhttp registry class entries, but it hasn't worked.

I installed the latest MSXML3 service pack and that didn't solve the problem.

I added NTFS permissions to the DLLs in system32 for everyone and IUSR and that didn't work.

Any help is appreciated as this is affecting 2 commercial web servers plus my development systems. I've also posted to MS newsgroups with no help,but have heard of other problems with this issue.

Thanks,
Bill
  • +
    0 Votes
    abelenky

    I have the same problem, and have not yet found a resolution. If you come up with anything new, please let me know. If I find a solution, it'll get posted here.

    +
    0 Votes
    abelenky

    After lots of poking around, I determined that i can no longer do a Server.CreateObject("MSXML2.XMLHTTP"). Instead, the class-string must now be "MSXML2.XMLHTTP.4.0" (I found a suggestion that .5.0 may also work in some cases).

    I can't explain it, but it seems to work for me. Good luck!

    +
    0 Votes
    billmez

    It took a while to trace since it happened on several systems but here goes...

    The main problem was the permissions on the registry keys for all versions of xmlhttp since it appears that the update affected all of them. Adding the IUSR and IWAM anonymous users to the registry keys with read and execute access worked. It also had to be done with serverxml http.

    On one machine the update just didn't register properly and unregistering and re registering it with regsvr32 handled that problem.

    I have had permission issues on registry keys with selected com components in the past also for the anonymous web users and had to manually add them to the reg keys also.

    The system has had the IIS lockdown tool run on it which creates a new user group and places IUSR and IWAM into it to restrict access rights. We think this may be the reason for improper key security on these installation.

    Just a passing mention, that issues like this that result from an MS security update qualify for free MS support. The Regmon tool available on the MS web site was also instrumental in finding the keys that were being denied access. I hope this helps.

    Bill

  • +
    0 Votes
    abelenky

    I have the same problem, and have not yet found a resolution. If you come up with anything new, please let me know. If I find a solution, it'll get posted here.

    +
    0 Votes
    abelenky

    After lots of poking around, I determined that i can no longer do a Server.CreateObject("MSXML2.XMLHTTP"). Instead, the class-string must now be "MSXML2.XMLHTTP.4.0" (I found a suggestion that .5.0 may also work in some cases).

    I can't explain it, but it seems to work for me. Good luck!

    +
    0 Votes
    billmez

    It took a while to trace since it happened on several systems but here goes...

    The main problem was the permissions on the registry keys for all versions of xmlhttp since it appears that the update affected all of them. Adding the IUSR and IWAM anonymous users to the registry keys with read and execute access worked. It also had to be done with serverxml http.

    On one machine the update just didn't register properly and unregistering and re registering it with regsvr32 handled that problem.

    I have had permission issues on registry keys with selected com components in the past also for the anonymous web users and had to manually add them to the reg keys also.

    The system has had the IIS lockdown tool run on it which creates a new user group and places IUSR and IWAM into it to restrict access rights. We think this may be the reason for improper key security on these installation.

    Just a passing mention, that issues like this that result from an MS security update qualify for free MS support. The Regmon tool available on the MS web site was also instrumental in finding the keys that were being denied access. I hope this helps.

    Bill