Re: In regards to MS IE 6.0 Critical update 834489 - Workarounds do not work.
From: Wes (wcarberry_at_sensecorp.com)
Date: 02/09/04
- Next message: Wes: "Re: Security Update 832894 causing 'this page cannot be displayed'"
- Previous message: T: "Microsoft Internet Explorer 6 reboots Itself"
- In reply to: Robert Aldwinckle: "Re: In regards to MS IE 6.0 Critical update 834489 - Workarounds do not work."
- Messages sorted by: [ date ] [ thread ]
Date: 9 Feb 2004 11:23:29 -0800
I actually had a problem where they weren't very descriptive in that
they didn't explicitly state that you have to add two subkeys
(FeatureControl AND FEATURE_HTTP_USERNAME_PASSWORD_DISABLE under
FeatureControl) under the last subkey (all caps one) - there's where
you create the DWORD value "iexplore.exe" with a value of 0.
The following in a .reg file fixed the problem for us where we were
passing login credentials via the intranet:
<start fix_834489.reg file>
REGEDIT4
[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet
Explorer\Main\FeatureControl]
[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE]
[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE]
"iexplore.exe"=dword:00000000
<end fix_834489.reg file>
I believe what Robert is alluding to in his post is that if your
application is the one passing the credentials instead of a linked URL
(as in our case) - you may want to try adding an additional DWORD
value entry with your exe name. So if your program were called
"casino_cams.exe" - add this to the above .reg file:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME_PASSWORD_DISABLE]
"casino_cams.exe"=dword:00000000
Hope it helps. Was in Vegas this weekend and most of your clients
were operating well enough to beat me up a bit ;).
Wes
"Robert Aldwinckle" <robald@techemail.com> wrote in message news:<uNqzk2y6DHA.2404@TK2MSFTNGP12.phx.gbl>...
> > We have attempted to make the Registry entry, and it did
> > not fix our problems at all.
>
> Travis,
>
> It may help if you describe in more detail what you did in the registry.
> For example, is it being done for compatibility for iexplore.exe
> or some other application? Could character case be a factor?
>
>
> > How does Microsoft propose that we fix this problem
> > without using elevated windows login permissions?
>
> Can you give an example of what you are thinking of here?
> The only thing that comes to mind is using RegMon to verify
> that the compatibility switch is being checked. Are you saying
> that the check does work for Administrators and Power Users
> but not normal users?
>
>
> HTH
>
> Robert Aldwinckle
> ---
>
>
> "Travis Whidden" <twhidden_at_smartconnect_dot_net@smartconnect.net> wrote in message
> news:99a201c3ea8b$107d0b90$a401280a@phx.gbl...
> > In regards to: http://support.microsoft.com/default.aspx?
> > scid=kb;en-us;834489
> >
> > This caused us HUGE problems with our systems. We are a
> > Microsoft partner, and we depend FULLY on IE. With this
> > change, it fully took our software to a halt.
> >
> > Let me explain.
> >
> > We have a little over 100,000 IP video servers deployed
> > over some 800 networks around the world. Our clients,
> > some major companies such as HMS Host, Wal-Mart, Target,
> > Sephora, Las Vegas Class-A Casinos (MGM, Mirage, Poker
> > Palace, Treasure Island, etc), and many more now no
> > longer can view their cameras (after an update. Here is
> > how our software works:
> >
> > A user will log into our Digital Surveillance Center
> > software that is ran via IIS and our clients using IE
> > 6.0. Our datacenter generates URLs to point to each IP
> > video server. The images and video feeds are then
> > integrated into our interface, where you can navigate
> > though their security cameras.
> >
> > Each IP video server has HTTP authentication to protect
> > the video feeds in the event that someone was just
> > randomly choosing IPs, etc. The IP video servers are
> > produced 3rd party, and they ALL require HTTP
> > authentication.
> >
> > With this patch basically renders our ENTIRE software
> > USELESS. Our software has worked for years, and it
> > seems that the reason this patch was released for
> > basically a COSMETIC fix because people though they saw a
> > different URL on their status bar of all things.
> >
> > We have attempted to make the Registry entry, and it did
> > not fix our problems at all. We tried on several
> > different machines using both types.. HKEY_CURRENT_USER
> > and HKEY_LOCAL_MACHINE
> >
> > Here are some of the questions I have:
> >
> > How does Microsoft propose that we fix this problem
> > without using elevated windows login permissions?
> >
> > If this problem causes way too many headaches, would this
> > patch ever be revoked and a different patch issued?
> >
> > If the problem was that Microsoft was making a cosmetic
> > fix to the status/address bar, why don't they just show
> > the entire href instead of completely disabling something
> > that has been working for years and years. Why does this
> > new patch also affect image url sources??
> >
> > This is an extremely extremely high priority for our
> > company, and I am sure thousands of other companies. We
> > need a response ASAP.
> >
> > Please feel to e-mail me directly. I will write back
> > with a phone number to call.
> >
- Next message: Wes: "Re: Security Update 832894 causing 'this page cannot be displayed'"
- Previous message: T: "Microsoft Internet Explorer 6 reboots Itself"
- In reply to: Robert Aldwinckle: "Re: In regards to MS IE 6.0 Critical update 834489 - Workarounds do not work."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
