none
IE8 + Protected Mode + Outlook (2003 or 2007) + mailto link + Vista 32-Bit SP2 = Unable to launch outlook... IE7 Works Fine...

    Question

  • I have just started testing IE8 with our environment - and have the exact problem described in another thread for Internet Explorer with the mailto: behavior and etc.  I was directed here to ask the same question, again.

    We are a Vista shop w/SP2 (32-bit) and have continued to run IE7 due to compatibility issues with various partner web apps - but now really is the time for an IE8 upgrade for us.  Everything fully patched up through last week when I started testing.  Office 2003 SP3 (deployed via Group Policy from a network location if that matters, and it has a minor transform created by the customization thing as part of the push and SP3 is slipstreamed into the network source (yes it was like that before it was deployed to these workstations)) and yes we get the same error message on mailto links:

    "Cannot start Microsoft Office Outlook.  Cannot initialize Microsoft Office shared utilities.  Please restart your computer or reinstall Microsoft Office Outlook."

    If Outlook isn't already running, you get a different (similar) error when clicking a mailto link:

    "Cannot start Microsoft Office Outlook."

    Restarting, repairing, reinstalling, doesn't matter.  Same problem persists.  Remove IE8 and everything works fine with IE7.  Reinstall IE8 and the problem returns.

    A bit about what I've checked:  I'm extremely familiar with the google chrome and registry stuff surrounding htmlfile and etc.  I've checked all that.  The issue we have is not related to a missing or invalid key of that type.  This problem has also happened on 4 seperate (identical, managed corporate machines) machines.  It isn't a corrupt file or user profile, etc.  All 4 work fine with IE7 all 4 exhibit the same problem with IE8...  I've checked for the case, apparently early IE8 installers changed iexplore.exe to IEXPLORE.EXE (or something like that) in a registry location, and caused similar symptoms.  We do not have that issue on these machines. 

    One thing from the IE thread, that I've confirmed - is that IE8 is able to launch Outlook for mailto links when Protected Mode = Off.  IE7 can launch Outlook for mailto links when Protected Mode = On or Off.  FWIW.

    At this point, I really believe that this is a Vista, with UAC enabled, with IE8 with Protected Mode enabled "bug" or...  maybe it is not a bug but rather a designed undocumented behavior.  :)

    It's pretty annoying to think that we may burn a support call over this.  :(


    Ethan
    • Edited by nanunanu Wednesday, April 28, 2010 9:16 PM Detail about IE8 Protected Mode...
    • Moved by Maxwell JosephMicrosoft Support Friday, April 30, 2010 10:22 AM moving to right forum (From:Sending and Receiving Mail)
    Wednesday, April 28, 2010 9:09 PM

All replies

  • Anyone?

    Something deep down tells me that it is probably somehow related to changes introduced with LCIE - http://blogs.msdn.com/ie/archive/2008/03/11/ie8-and-loosely-coupled-ie-lcie.aspx

    ...  But that is just a very vague poorly researched guess.

     


    Ethan
    Thursday, April 29, 2010 4:17 PM
  • I have just started testing IE8 with our environment - and have the exact problem described in another thread for Internet Explorer with the mailto: behavior and etc.  I was directed here to ask the same question, again.

    Thanks for setting up this cross-post.

    We are a Vista shop w/SP2 (32-bit) and have continued to run IE7 due to compatibility issues with various partner web apps - but now really is the time for an IE8 upgrade for us.  Everything fully patched up through last week when I started testing.  Office 2003 SP3 (deployed via Group Policy from a network location if that matters, and it has a minor transform created by the customization thing as part of the push and SP3 is slipstreamed into the network source (yes it was like that before it was deployed to these workstations)) and yes we get the same error message on mailto links:

    "Cannot start Microsoft Office Outlook.  Cannot initialize Microsoft Office shared utilities.  Please restart your computer or reinstall Microsoft Office Outlook."

    If Outlook isn't already running, you get a different (similar) error when clicking a mailto link:

    "Cannot start Microsoft Office Outlook."

    Do you ever see the related symptom that I mentioned with  mailto: ?   FWIW I now have W7 X64 and with Outlook 2010 set as the mailto: default I still see that prompt.   However, now I have done the test that that I was previously unwilling to try that I had suggested to Dominik (the OP) using my Guest account and can prove that checking the Don't show... box in conjunction with the Don't allow button has no permanent effect.   So I think you will have to find some other explanation for your problem symptom.   FWIW it looks to me that perhaps Outlook is not fully installed (reminds me of the Outlook 2010 Click-to-run version. <w>)

    Restarting, repairing, reinstalling, doesn't matter.  Same problem persists.  Remove IE8 and everything works fine with IE7.  Reinstall IE8 and the problem returns.

    A bit about what I've checked:  I'm extremely familiar with the google chrome and registry stuff surrounding htmlfile and etc.  I've checked all that.  The issue we have is not related to a missing or invalid key of that type.  This problem has also happened on 4 seperate (identical, managed corporate machines) machines.  It isn't a corrupt file or user profile, etc.  All 4 work fine with IE7 all 4 exhibit the same problem with IE8...  I've checked for the case, apparently early IE8 installers changed iexplore.exe to IEXPLORE.EXE (or something like that) in a registry location, and caused similar symptoms.  We do not have that issue on these machines. 

    One thing from the IE thread, that I've confirmed - is that IE8 is able to launch Outlook for mailto links when Protected Mode = Off.  IE7 can launch Outlook for mailto links when Protected Mode = On or Off.  FWIW.

    At this point, I really believe that this is a Vista, with UAC enabled, with IE8 with Protected Mode enabled "bug" or...  maybe it is not a bug but rather a designed undocumented behavior.  :)

    It's pretty annoying to think that we may burn a support call over this.  :(


     

    It will be even more annoying if the "solution" you are given is to reinstall your OS to get the same resolution that the OP got.   <eg>

     

    Good luck

    Robert Aldwinckle
    ---

    Thursday, April 29, 2010 4:22 PM
  • Do you ever see the related symptom that I mentioned with  mailto: ?   FWIW I now have W7 X64 and with Outlook 2010 set as the mailto: default I still see that prompt.   However, now I have done the test that that I was previously unwilling to try that I had suggested to Dominik (the OP) using my Guest account and can prove that checking the Don't show... box in conjunction with the Don't allow button has no permanent effect.   So I think you will have to find some other explanation for your problem symptom.   FWIW it looks to me that perhaps Outlook is not fully installed (reminds me of the Outlook 2010 Click-to-run version. <w>)


    I have the same behavior when clicking mailto: links as I do entering mailto: into the address bar.  The unable to launch message.  Confirmed this consistent behavior on 4 machines running IE8, confirmed that everything works fine (no error, just a new message) on several machines still running IE7. 

    Mailto links and address bar entry both work fine when I turn protected mode off (I'm taking a shortcut and running it as administrator, which does not have the same zone settings as my "normal" user has)...

    The thing that I've noticed with some testing and watching in process explorer is that OUTLOOK.exe is invoked with iexplore.exe as a parent, when it fails under protected mode, that is that...  when it works (from a command prompt, from IE8 protected mode off, from IE7, etc) the new mail message appears on screen when it hands off to the "global" OUTLOOK.exe that is running under explorer.exe and the instance that was invoked as part of the mailto (or manually from a command prompt) terminates once the "hand off" happens.  It seems like this "hand off" isn't allowed somehow when IE8 is running in protected mode and I'm wondering again if that LCIE change is related.  IE7 allows the "hand off" no matter what state the Protected Mode is in.

    I bet others havn't found this yet because so many businesses are still running XP.  *shrug*


    Ethan
    Thursday, April 29, 2010 4:41 PM

  • I have the same behavior when clicking mailto: links as I do entering mailto: into the address bar.  The unable to launch message.  Confirmed this consistent behavior on 4 machines running IE8, confirmed that everything works fine (no error, just a new message) on several machines still running IE7. 

    Have you ever seen the prompt that I have been referring to instead?  Even with any other client (e.g. with WinMail?)  I still think it would be worthwhile trying to understand why there are two symptoms for (presumably) the same cause (e.g. security/obscurity).

    The thing that I've noticed with some testing and watching in process explorer is that OUTLOOK.exe is invoked with iexplore.exe as a parent, when it fails under protected mode, that is that...  when it works (from a command prompt, from IE8 protected mode off, from IE7, etc) the new mail message appears on screen when it hands off to the "global" OUTLOOK.exe that is running under explorer.exe and the instance that was invoked as part of the mailto (or manually from a command prompt) terminates once the "hand off" happens.  It seems like this "hand off" isn't allowed somehow when IE8 is running in protected mode and I'm wondering again if that LCIE change is related.  IE7 allows the "hand off" no matter what state the Protected Mode is in.

    Sure, that task structure explains the prompt symptom which presumably can be suppressed by using the checkbox*.  I think it's strange that that symptom occurs for both Outlook and WinMail but not WLMail though.

    BTW you could test your LCIE idea by setting  TabProcGrowth = 0.   Apparently that forces Protected Mode off.  I don't know if that was just to generalize the simulation of "IE7 on XP" mode or if there is a better reason for it.   TabProcGrowth = 1  reportedly leaves Protected Mode alone but disables the LCIE enhancement, effectively simulating IE7 on Vista, I suppose.

    * I just realized that I haven't yet completely tested disabling the prompt, e.g. by checking it while allowing the use of the E-mail client.  In case it results in something closer to your symptom I could try that, then also test the KB article's claim that using RIES sets things back to normal, e.g., resulting in seeing the prompt again.   In fact, I had intended on doing that in order to find out what registry value saves that state information.   Getting forgetful and unfocused.   ; )


    HTH

    Robert
    ---

    Thursday, April 29, 2010 11:33 PM
  • Have you ever seen the prompt that I have been referring to instead?  Even with any other client (e.g. with WinMail?)  I still think it would be worthwhile trying to understand why there are two symptoms for (presumably) the same cause (e.g. security/obscurity).

    Yes, I have seen that dialog in the past, but while IE7 was installed the checkbox for don't ask this again was checked, and the action was allowed... So it has been a while... And it isn't prompting now, it is just allowing (OUTLOOK.exe is being invoked, but results in the error message)...

    BTW you could test your LCIE idea by setting  TabProcGrowth = 0.   Apparently that forces Protected Mode off.  I don't know if that was just to generalize the simulation of "IE7 on XP" mode or if there is a better reason for it.   TabProcGrowth = 1  reportedly leaves Protected Mode alone but disables the LCIE enhancement, effectively simulating IE7 on Vista, I suppose

    Setting TabProcGrowth = 0 on the Vista SP2 32-Bit w/Outlook 2003 SP3 w/IE8 machines in our environment allows mailto links to work with out error. The new message pops right up. But it as expected sets Protected mode = off, which isn't the desired result.  I've repeated this result on 2 of the machines, with the same result, so I think I can say that 100% of our machines experienced the problem when testing IE8 and 100% of the machines tested do not experience the problem when TabProcGrowth = 0 limits protected mode (under the same user account, etc) in our testing environment.

    This is a little bit of a tangent, but I tried to repeat this result with a personal laptop running Vista Business 32-Bit SP2 and Office 2007, and was unable to.  But that machine got IE8 as soon as it was released.  So I'm still grasping at straws as to if this is a patch order thing that is caused by us continuing to run IE7 for so long, or perhaps some quirky restriction interaction with IE8 and the group policy in our environment.  Either way, the behavior with our production machines is very very consistent so I think there is _something_ concrete to cause / and resolve / this behavior.  Just need to find it.


    Ethan
    • Edited by nanunanu Friday, April 30, 2010 3:08 PM More detail...
    Friday, April 30, 2010 3:03 PM
  • More testing... 

    If I remove the TabProcGrowth key and go back to normal LCIE functionality, I currently have the following behavior:

    If Protected Mode = On for the "Internet" zone...  mailto links DO NOT WORK for sites in any zone (including Local Intranet with Protected Mode = Off).  If I turn Protected Mode = Off for the "Internet" zone, mailto links WORK for sites in any zone (including Local Intranet with Protected Mode = Off)...

    I havn't tested Protected Mode = Off for "Internet" zone and On for "Local Intranet" to see what happens, but I'm betting that it will work in that scenario.


    Ethan
    Friday, April 30, 2010 4:05 PM
  • Confirmed - Protected Mode = Off for "Internet" zone and Protected Mode = On for "Local Intranet" zone lets mailto links work for sites in both zones.  Protected Mode = On for "Internet" zone and Protected Mode = "Off" for "Local Intranet" zone makes mailto links fail in both zones.

    That is just kcab sdrowssa.


    Ethan
    Friday, April 30, 2010 7:26 PM
  • TabProcGrowth = 1  reportedly leaves Protected Mode alone but disables the LCIE enhancement, effectively simulating IE7 on Vista, I suppose

    Setting TabProcGrowth = 0 on the Vista SP2 32-Bit w/Outlook 2003 SP3 w/IE8 machines in our environment allows mailto links to work with out error. The new message pops right up. But it as expected sets Protected mode = off, which isn't the desired result.  I've repeated this result on 2 of the machines, with the same result, so I think I can say that 100% of our machines experienced the problem when testing IE8 and 100% of the machines tested do not experience the problem when TabProcGrowth = 0 limits protected mode (under the same user account, etc) in our testing environment.

    This is a little bit of a tangent, but I tried to repeat this result with a personal laptop running Vista Business 32-Bit SP2 and Office 2007, and was unable to.  But that machine got IE8 as soon as it was released.  So I'm still grasping at straws as to if this is a patch order thing that is caused by us continuing to run IE7 for so long, or perhaps some quirky restriction interaction with IE8 and the group policy in our environment.  Either way, the behavior with our production machines is very very consistent so I think there is _something_ concrete to cause / and resolve / this behavior.  Just need to find it.

    I was hoping you would find  TabProcGrowth = 1  a possible workaround.   Did you test that case too?

    However, good news.   I have found out how to get the prompt back and I think I may have even simulated one of your error cases.

    I had to use ProcMon to find the right clue but it is documented here:

    <title> Understanding and Working in Protected Mode Internet Explorer</title>
    http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx

    In particular this value for Policy (DWord) is what I got when I accepted the prompt and requested Don't ask...

    3 Protected Mode silently launches the broker as a medium integrity process.

    When I deleted that value name I got the prompt again because (strangely IMO) a new ElevationPolicy GUID was created.   When I tried only to change its value to anything else, at first it didn't seem to matter but when I did a Switch User (e.g. from Guest back to my user) and back and then I tried  mailto:  again, with the Policy value set at 1  (Protected mode silently launches the broker as a low integrity process), I got an error "Outlook can not be started"!

    So, I'll be curious to see if you have a Policy value of 1, for an ElevationPolicy which involves your version of Outlook, as I think that could explain your symptom.

    BTW I think this proves that the information in that "article" (actually a Vista help page) we have been referring to was perhaps wishful thinking because  RIES  didn't touch that branch.   In fact, since the Guest account had never been used before, allowing the prompt created the whole LowRights branch, not just a new policy in it.  I'm surprised that there is no apparent cleanup utility provided for this mechanism.  It seems like a bit of a security exposure not having one.  I may be missing something by only being on W7 Premium (e.g. no GPEdit.msc).

    Finally, I would like to point out that Dominik came so close to figuring this out himself--e.g., he actually posted his Policy value--but unfortunately neither of us was aware of this MSDN document or any of its details.


    Good luck

    Robert
    ---

    Saturday, May 01, 2010 5:26 AM
  • I was hoping you would find  TabProcGrowth = 1  a possible workaround.   Did you test that case too?

    Yes, with it set to 1 or value not present, the error happens. Only with a value of 0 does the behavior change. 

    However, good news.   I have found out how to get the prompt back and I think I may have even simulated one of your error cases.

    When I deleted that value name I got the prompt again because (strangely IMO) a new ElevationPolicy GUID was created.   When I tried only to change its value to anything else, at first it didn't seem to matter but when I did a Switch User (e.g. from Guest back to my user) and back and then I tried  mailto:  again, with the Policy value set at 1  (Protected mode silently launches the broker as a low integrity process), I got an error "Outlook can not be started"!

    So, I'll be curious to see if you have a Policy value of 1, for an ElevationPolicy which involves your version of Outlook, as I think that could explain your symptom.

    Unfortunately, whatever I'm chasing isn't playing nice.  I have a value under HKCU (not HKLM) for the ElevationPolicy GUID for AppName=OUTLOOK.EXE but the Policy DWORD is set to 3 already.  I'm sure this value was created by IE7 BTW...  In an attempt to recreate your results, I tried changing that value or removing it entirely and continue to get the original error with out a change in behavior, with out the prompt.  In other words, IE8 isn't touching or honoring (or re-creating) the values in that HKCU location.

    Might be onto something with the user switching though...  I have a 3rd party tool that can run some tasks with elevated privledges to help with legacy applications that don't have a silent install and insist on self updating even when a non-admin user gets to the desktop.  Effectively every desktop session has already done a fast user switch once by the time the user can run Outlook. 

    More things to make you go hmmmmmm.


    Ethan
    Monday, May 03, 2010 3:13 PM
  • Unfortunately, whatever I'm chasing isn't playing nice.  I have a value under HKCU (not HKLM) for the ElevationPolicy GUID for AppName=OUTLOOK.EXE but the Policy DWORD is set to 3 already.  I'm sure this value was created by IE7 BTW...  In an attempt to recreate your results, I tried changing that value or removing it entirely and continue to get the original error with out a change in behavior, with out the prompt.  In other words, IE8 isn't touching or honoring (or re-creating) the values in that HKCU location.


    Yes.  It was actually  HKU  that  ProcMon  showed me.   It was the  "Low Rights" and ElevationPolicy keys when used as search terms that made me find the above document (which only refers to HKLM).   Sorry for the confusion.

    My only idea for you then at this point would be to try using ProcMon too.   Trace both cases,   the normal case that I'm seeing and your case.   Then try to compare the traces for their essential differences.   E.g. can you do vanilla installs of Vista or W7 and Outlook which won't be affected by your slipstream?  Then recreate my symptom in that and trace it.   Or perhaps you could define a new user who gets to see things more clearly, such as my Guest account did.  Remember, the Low Rights branch didn't even exist until the prompt was allowed.

    BTW since I didn't know what I was looking for I just started filtering for  Operation Is RegSetValue  then exluded things that it obviously wouldn't be and eventually narrowed it down to these Low Rights values.   Now that we have more knowledge about what is causing the related symptom you may have an easier time of constructing filters for yourself.   ; )


    Good luck

    Robert
    ---

    Tuesday, May 04, 2010 6:40 AM
  • An update for those playing along with the home edition - since it looks like the moderators are getting itchy on this one...  Nothing to report.  We still have the issue and we still do not have a resolution.
    Ethan
    Tuesday, May 11, 2010 8:22 PM
  • To be sure: try this!

    HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\{DAF41CF2-D359-44FA-A773-D7F5DE111E75}
    "AppPath"="C:\\Program Files (x86)\\Microsoft Office\\OFFICE11"
    "AppName"="OUTLOOK.EXE"
    "Policy"=dword:00000003

    --------------------------------------

    Create Regkey: "Low Rights" in HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer

    Create Regkey: "ElevationPolicy" in HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Low Rights

    Create Regkey: "{DAF41CF2-D359-44FA-A773-D7F5DE111E75}" in HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy

    in HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\{DAF41CF2-D359-44FA-A773-D7F5DE111E75}
    create a String Value (REG_SZ) with the Name "AppName" and value "OUTLOOK.EXE"
    create a String Value (REG_SZ) with the Name "AppPath" and value "C:\Program Files (x86)\Microsoft Office\OFFICE11"
    create a DWORD (32-bit) Value (REG_DWORD) with the Name "Policy" and value "3"

    You can create these registry keys/values with Group Policy Preferences.

    Goodluck!!

     

     

     

     

     

     

     

    Tuesday, November 08, 2011 4:10 PM
  • To be sure: try this!

    HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\{DAF41CF2-D359-44FA-A773-D7F5DE111E75}
    "AppPath"="C:\\Program Files (x86)\\Microsoft Office\\OFFICE11"
    "AppName"="OUTLOOK.EXE"
    "Policy"=dword:00000003

    As I said...  I have a value under HKCU (not HKLM) for the ElevationPolicy GUID for AppName=OUTLOOK.EXE but the Policy DWORD is set to 3 already.  Still have the issue on all machines in our environment. 

    The GUID is different for us, as is the AppPath, as we are on 32-bit Vista, not a 64-bit OS like you are running...  But the point remains....  With correct values for a Low Rights ElevationPolicy, it still gives us the error.


    Ethan
    Tuesday, November 08, 2011 4:34 PM