Adding a cross-post.

"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!

"Eric" wrote in message
...
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!

What is really strange is that the output of "ftype mailto" gives
me Outlook.exe, while Default Programs says Mailto is handled
by Windows Mail. How can there be a conflict like that?

Gary VanderMolen

"Robert Aldwinckle" wrote in message ...
"Eric" wrote in message
...
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.

"Gary VanderMolen" wrote in message
...
What is really strange is that the output of "ftype mailto" gives
me Outlook.exe, while Default Programs says Mailto is handled
by Windows Mail. How can there be a conflict like that?


I don't know but what I would try is making one show for both.
I don't know how successful just changing it with the ftype command
would be so probably I would try switching the default (just as a repair)
instead.


Good luck

Robert
---



Gary VanderMolen

"Robert Aldwinckle" wrote in message ...
"Eric" wrote in message
...
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.

ftype reports that Outlook.exe is mapped.

I previously tried switching the mapping to WM and experienced the same
problem.


"Robert Aldwinckle" wrote:

"Eric" wrote in message
...
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!

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" wrote in message
...
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!

There is another item I've discovered. The times it does not work, Vista is
using the broker IEUser.exe to execute Outlook.

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" wrote in message
...
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!

"Eric" wrote in message
...
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" wrote in message
...
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!