"Eric" <(E-Mail Removed)> wrote in message
news:68E24D29-B249-43B9-887A-(E-Mail Removed)...
> There is another item I've discovered. The times it does not work, Vista is
> using the broker IEUser.exe to execute Outlook.
More security/obscurity? Perhaps we should be cross-posting
to Vista Security too? <eg>
What happens if you just Run... mailto:
E.g. that should just be explorer.exe starting Outlook.exe,
no "broker" required?
Good luck
Robert
---
>
> In Vista, if IE requests access to the system that is beyond the current
> level permitted by the protected mode, executing of the requested operation
> is done through a broker. There are two brokers being IEUser.exe and
> IEInstall.exe. As in XP, Vista pretty much requires that applications be
> installed using an admin account so to work around this in a controlled
> manner, it uses IEInstall.exe. The same type of scenario plays out for
> executions but instead uses IEUser.exe.
>
> This still doesn't answer the question. It doesn't make sense that in one
> case the broker must be used but in the other two cases, the broker isn't
> needed and a different path is taken through the registry.
>
>
> "Eric" wrote:
>
>> I've made an interesting discovery while monitoring registry access by IE.
>>
>> Whenever a mailto is clicked on a page that is either NOT part of a trusted
>> site or exists within a frame of a trusted site, the registry entry
>> HKCU\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\MAILTO\UserChoice
>> is read. This entry contains the prog id of the application associated with
>> mailto.
>>
>> But!, when I click a mailto hosted in a non-framed page within a trusted
>> site, the registry key is never checked! This doesn't make sense.
>>
>> "Eric" wrote:
>>
>> > ftype reports that Outlook.exe is mapped.
>> >
>> > I previously tried switching the mapping to WM and experienced the same
>> > problem.
>> >
>> >
>> > "Robert Aldwinckle" wrote:
>> >
>> > > "Eric" <(E-Mail Removed)> wrote in message
>> > > news:301D1D3C-59BF-423D-B25F-(E-Mail Removed)...
>> > > > Adding a cross-post.
>> > >
>> > >
>> > > You're cross-posting to both Outlook and WM NG
>> > > so which one is the default E-mail app?
>> > >
>> > > To help clarify this switch to a cmd window and enter:
>> > >
>> > > ftype mailto
>> > >
>> > > and capture the cmd output.
>> > >
>> > >
>> > > HTH
>> > >
>> > > Robert Aldwinckle
>> > > ---
>> > >
>> > >
>> > > >
>> > > > "Eric" wrote:
>> > > >
>> > > > Here is the scenario:
>> > > >
>> > > > To ensure ActiveX and such all function properly for our extranet users, we
>> > > > have them add our sites to their list of Trusted Sites. IE7 with Vista sets
>> > > > Protected Mode to On for the Internet zone and sets Protected Mode to Off for
>> > > > any sites within the Trusted Sites zone. Just as always, when you click on a
>> > > > mailto link from within the Internet zone, a new email opens just as it
>> > > > should which is how things have always been for Trusted Sites as well. Now
>> > > > with IE7/Vista, if you click on a mailto link posted on a site within Trusted
>> > > > Sites, a NEW window opens with Protected Mode ON treating it as though it
>> > > > were part of the internet zone and not trusted. The new email opens but not
>> > > > without first canceling the navigation of the window and displaying an error.
>> > > >
>> > > > This situation can be confusing for some users. When switching between
>> > > > protection modes, you switch browsers as well. Just as was always the case,
>> > > > a new page shouldn't even open when creating a new email though now does ONLY
>> > > > when clicking a mailto from within a trusted site. So now the user is thrown
>> > > > to a totally different brower and presented with an error stating IE couldn't
>> > > > display the webpage. There is nothing to inform the user that the error
>> > > > should be ignored and that their session is actually in the browser behind
>> > > > the one currently active. They write and send their email and then the
>> > > > typical response to the error would be to just click Back but this is a new
>> > > > browser and has no Back history. Calls then flood our help desk.
>> > > >
>> > > > Frames just make this issue even more screwed up. If the page containing
>> > > > the mailto resides within a frame, there is no problem! The new email opens
>> > > > properly with no second browser or error. If that same page is opened by
>> > > > itself in the browser, the problem comes back.
>> > > >
>> > > > It's easy to try. Just create a page with a mailto, watch the mailto link
>> > > > work, add the site hosting the page to your trusted sites, refresh, and then
>> > > > watch the mailto link produce the second browser with the error.
>> > > >
>> > > > Any ideas?
>> > > >
>> > > > Thanks!
>> > >
>> > >
>> > >
|
Similar Threads
