adostream flag and KB918899

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Filenet application requires a flag to be unset (value 0) on the ADODB.stream
activex object. However the critical security patch 918899 resets this value
to 1024.
If the value is set back to 0 the patch tries to reinstall from WSUS, if it
is set to 1024 the application doesn't work. Is there a resolution from
Microsoft for this problem (I do not wish to decline the patch in WSUS as not
all users use filenet).
 
Hello,

Thanks for posting.

Since this issue may relate to third-party, I'd like to recommend you work
with the manufacture for assistance with this. Please understand that we
don¡¯t have environment to reproduce and troubleshoot your issue, but
please feel free to involve me during the process of contacting the
manufacture support, I am glad to provide any information.

Thanks for understanding that I don't mean to bounce you between support
professionals as I am fully aware how time consuming this can be. However,
they really are in a better position to be able to assist you with this
issue as they may have experienced similar issues.

Have a good day!

Best regards,

Vincent Xu
Microsoft Online Partner Support

======================================================
Get Secure! - www.microsoft.com/security
======================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others
may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties,and confers no rights.
======================================================



--------------------
 
GeoffWatson said:
Filenet application requires a flag to be unset (value 0) on the
ADODB.stream
activex object. However the critical security patch 918899 resets this
value
to 1024.
If the value is set back to 0 the patch tries to reinstall from WSUS, if
it
is set to 1024 the application doesn't work. Is there a resolution from
Microsoft for this problem (I do not wish to decline the patch in WSUS as
not
all users use filenet).
Click to expand...

With WSUS Server, you can set up groups and put workstations into groups.
You can use this feature to exclude Filenet applications from requiring the
patch. As long as the patch was installed at least once on all
workstations, the workstations are still pretty much "patched," with the
exception that you have changed that value.

I have a feeling that value is important to your security, and the makers of
Filenet should probably consider changing their application to work with the
Microsoft patch. If they disagree, then they [the makers of Filenet] should
put in a free call to Microsoft.
 
Thanks for the replies so far.

I quote from the MS article 870669...
"....If you are running an application in a corporate intranet environment,
and the corporate intranet environment currently uses the ADODB.Stream object
with Internet Explorer, applying this update may cause the application to
break. To restore application functionality, Microsoft recommends that you
first set your Internet Explorer browser security level to High, and then you
must clear the compatibility flag of the ADODB.Stream object...."

I have followed that recommendation, but within a short time the automatic
update seems to offer the patch 918889 again, which resets the flag and
around we go again...

Vincent, I do not see why you expect the application supplier to offer a
resolution to this when it is the behaviour of a MS patch that has altered.
There is clearly a lot of change in this area when there have been so many
re-issues of the patch affecting this object namely 870699, 912812, 916812
and now 918889, which has been reissued again this week...the documentation
in these patches is not very forthcoming in explaining whether one of these
supercedes the other etc. I am hoping that someone who knows what is going
on with these updates will be able to assist with some positive action,
rather than passing the buck to a third party who are probably just as
baffled by this changing behaviour.

Karl, thanks for the suggestion, but I think that if I had done this from
the beginning I would have had to repeat the procedure for each occasion that
the patch was superceded or revised, I am hoping for a resolution from
microsoft, maybe if the detection of the patch was not set to include the
value of the flag...seems reasonable when their own advice was to amend the
flag manually..
 
Karl, thanks for the suggestion, but I think that if I had done this from
the beginning I would have had to repeat the procedure for each occasion
that
the patch was superceded or revised,
Click to expand...

You might be correct, I don't know.
I am hoping for a resolution from
microsoft, maybe if the detection of the patch was not set to include the
value of the flag...seems reasonable when their own advice was to amend
the
flag manually..
Click to expand...

I understand. You'll want to be sure to make a free phone call to Microsoft
support and open a free ticket. Posting here is unlikely to get the
necessary level of attention from Microsoft. They might first suggest the
same workaround I did, so you may want to confirm that that workaround is
not acceptable just in case. [It's also possible they could consider this
not an issue with the patch but a case where WSUS is working as designed,
but I hope not.]
 
Back
Top