I get this error when I try to close the Exchange mangement console on my laptop: "You must close all dialog boxes before you can close exchange managment console" Just recently started. Any idea what is going on? Josh

Please check this article at http://technet.microsoft.com/en-us/library/bb851503(EXCHG.80).aspx Hope it can help you.Nile Jiang- Please mark the post as answer if it answers your question. http://www.usefulshare.com

Hi Josh, Before you close Exchange Management Console, please make sure you have closed all the dialog boxes you opened from Exchange Management Console (e.g. dialog box for mailbox properties etc.). Best Regards, Evan Liu TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

I've started getting this as well on Windows 7 x64 SP1. I definitely do not have any windows open and this has happened enough times for me not to be willing to write it off. I'm going to put money on a recent OS level patch changing the behaviour. EDIT: IE9 to be precise http://social.technet.microsoft.com/Forums/en-US/w7itproSP/thread/a5ac4fc6-1a98-4215-90e4-d084843bbb9a/

Running Windows 7 and just installed IE9. Getting the same error now: You must close all dialog boxes before you can close EMC. Seems to be related to IE9. Brian

I have the exchange 2007 management tools (SP3) loaded on my windows 7 desktop. Whenever I try to exit the console, I get the error "you must close all dialog boxes before you can close exchange" and it will not let me close the console. Any ideas what is going on?

Normally, of course, this means that you were looking at the properties of something, but then tried to close the app before you clicked OK, or Cancel, or Apply. But are you saying that you get this message without even opening the properties of something in the GUI?Outlook Web Access For PDA , OWA For WAP www.owa-pda.com email a@t leederbyshire d.0.t c.0.m

correct. I have closed out the one diaglog box I had opened and then when I try to close the console, I get this error message. I thought I saw someone say this was related to IE9, but I have not seen anything concrete about it, especailly from Microsoft.

Does it do this every time, or are you keeping the MMC running because you don't want to do any damage by killing it off in task manager?Outlook Web Access For PDA , OWA For WAP www.owa-pda.com email a@t leederbyshire d.0.t c.0.m

I thought I saw someone say this was related to IE9, but I have not seen anything concrete about it, especailly from Microsoft. I'm getting the same issue after Automatic Updates installed IE9 on a Server 2008R2 Std box that I just loaded Exchange 2010 management tools on.

Does it do this every time, or are you keeping the MMC running because you don't want to do any damage by killing it off in task manager? Outlook Web Access For PDA , OWA For WAP www.owa-pda.com email a@t leederbyshire d.0.t c.0.m Does it everytime and the only way to close the MMC is to kill it in task manager.

Uninstalled IE9 and now the MMC works as it's supposed to. Looks like a bug.

I have the exact same thing with IE9, Exchange 2010 SP1 and the management tools installed on my win 7 64 Pro machine. Haven't tried uninstalling IE9 though.

Appears to be a known bug with IE9 and MMC, not just Exchange; any snap-in you open with MMC.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

I've only noticed it with exchange. I run a lot of administrative tools that use MMC from my machine but Exchange seems to be the only one causing the issue.

I also have an issue with ADUC on my Win7Pro64bit box and IE9. I thought it was originally from SP1 but now I'm assuming it's IE9.

Hi jgoodin, As far as I know, there is a known issue with IE9 and MMC, I suggest you follow these steps to troubleshoot the problem: 1. Please install all the latest updates to have a try. 2. If the issue persists, uninstall IE9 to check whether this issue will occur not. 3. please check the event log and paste the related information in your next post. Thanks, Evan Liu TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

With IE9, Win7 Pro 64 bit, fully patched. It did it again this morning. I couldn't find any related errors in event viewer on my machine or the exchange server. I'll go back to IE 8 and see if it happens again.

I have successfully reproduced this error on our test Exchange 2010 server (Server 2008 R2) after installing IE9. I removed IE9 and no longer have the issue. This is definately an issue with IE9 and MMC. There were no errors in the event log of the server related to this issue.

Same here. With all updates installed I receive the same message. After uninstalling IE9 the issue is fixed.

Hi jgoodin, Any updates on this issue? Thanks, Evan Liu TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

I too am having the same issues, I have this on every server I have installed IE 9 on. I have uninstalled on a few and everything is back to normal. But IE9 is a update on all 2008 and windows 7 machines ? How can we get this fixed quickly ?? I think IE 9 needs to be pulled from the microsoft updates until this issue is fixed since it does effect everyone so badly..Kelly Sietmann

Dear All I to had the same problem i have updated the server and re-strated at that time i have seen some other dialog boxes were opened it was hidden and can not be seen after re-starting EMC is closed i try several times its opening and closing with out any hurdles RegardsRaSa

I cannot find any hidden dialog boxes, and this doesn't change the fact that when I open Active Directory Users & Computers and click on an item's properties, I get "MMC has detected an error in ta snap-in and will unload it". There's still something wrong with MMC and IE9.

Same Here, Exchange 2007 EMC, Windows 7 Ent x32 SP1, Installed IE 9 and EMC gives me "you must close dialog boxes ..." whether or not you ever opened any properties. So far EMC is the only MMC giving me this issue. ADUC, Server Manager, PerfMon all work fine. I uninstalled EMC and reinstalled, no joy. I attempted uninstall of IE9 but have no option to revert back to 8. My choice is live with it and wait for the fix or uninstall IE9 and run Chrome or Firefox to browse with.

I am getting the same results with Exchange 2007 MMC on SBS 2008 with IE9 Installed. I however noticed that it only occurs is after I goto "Recipient Configuration -> Mailbox -> TheUser -> E-Mail Addresses tab" and begin adding aliases.This is very annoying. The only way I found to close it is to kill it in the Task Manager. Which takes serveral attempts. The Exact Dialog box that pops up is: Microsoft Management Console You must close all dialog boxes before you can close Exchange Management Console.

Same issue with me. Windows 7 Professional x64, IE9, & Exchange Management Console with all the latest updates in every regard.

Thank you, we are looking into this.

For some strange reason I'm having issues closing EMC. It tells me all windows must be closed before closing the console, yet all other dialog boxes do appear to be closed. The only way to exit the console is a force close.

known issue MS is aware of it. you must close all dialog boxes before you can close exchange http://social.technet.microsoft.com/Forums/en/exchangesvradmin/thread/ea4e1ffe-472e-4508-9a14-0735ac6322caJames Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Known issue with IE9 on the same machine. If you go in to the Mailbox tab in Org Config then you get this error. Remove IE9 from the machine and the problem goes away. No news on when a proper fix is due. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Add me to the list of people experiencing the same issues.

I removed IE9 and I no longer receive the error message.

i have the same issue with exchange 2010 and WS 2008 R2 thanks

Hi, Our product team is working on this issue, I suggest you wait for the updates. If I get any new information, I will update the thread. Thanks for understanding. Evan Liu TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi, Was experiencing same problem just browsing around in MMC (Event Logs, Services, Device Manager, etc.). Definitely opened dialog boxes (e.g. service properties). Consistently got this error (close all dialog boxes). After reading this post I did two things (so can't say for sure which may have caused a change in behaviour)... 1. Clicked OK on the Close all Dialog Boxes dialog box), closed IE9 which was open, tried to close MMC again. Same error. 2. Back in MMC (with IE9 now closed), I right clicked on Computer Management (top of navigation tree on the left) and selected Connect to another computer... Selected "Local Computer" and then OK. I could then close MMC without any issue and I now can't reproduce the problem doing the same things in MMC that I was doing before. Haven't been through a restart (yet) but this may help. Win 7 Ultimate 64-bit, IE9 Mark

Dear ALL Just uninstall IE9 as IE9 has Know Issues once uninstalled the Problem will be eliminated as i have practically un-install IE9 from my servers Regards RaSa

I use EMC and EMS from my workstation. Uninstalling IE9 is an easy fix for servers, especially since you don't use the internet on a server. But when it's on a workstation from which I use the internet constantly, uninstalling IE9 is a work around, not a solution.

I use EMC and EMS from my workstation. Uninstalling IE9 is an easy fix for servers, especially since you don't use the internet on a server. But when it's on a workstation from which I use the internet constantly, uninstalling IE9 is a work around, not a solution. I agree 100%. It's a workaround, not a solution. A solution would be a fix for either IE9 or EMC/EMS/MMC.

Hi folks Can you confirm the full version number of IE9 in the situations this is occuring. Thanks! Mark Feetham Senior Program Manager Internet Explorer Product Quality

Mine is version 9.0.8112.16421 Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Mine, too, is 9.0.8112.16421

Same Problem, Same IE9 Version Number. Additionally Windows Update (WUA Scan directly on the host; not by WSUS) wants me to install IE9. Any ideas?

Same isue here, same version number, WindowsSBS2008 R2.

Same for me, 9.0.8112.16421 and so far, I will not install on any of my servers.Rick Vachon

9.0.8112.16421

I am also using IE 9.0.8112.16421 on SBS 2008

If you are experiencing this problem - can you just clarify the following, please: Does the problem stay once you reboot the machine that has the problem? If you have a problem in more than just Exchange Management Console - does it go away after reboot there? (It is not just a "please reboot" blind suggestion; we are seeing some repros go away once the machine is rebooted) Thank you!

Does the problem stay once you reboot the machine that has the problem? - YES. Doesn't matter how many times I reboot the issue remains. If you have a problem in more than just Exchange Management Console - does it go away after reboot there? - No, the problem remains no matter how many times I reboot. What seems really bizarre is that it only happens occssionaly in EMC after I open the details to an item, say a mailbox or a Transport Rule, and then modify the details or create a new entry, and then close the item. In MMC (with the ADUC snap-in) I will get an error everytime I open the details of a user. The error is "MMC has detected an error in a snap-in and will unload it." This error is more consistent than the EMC issue.

Same results for me, too. I have found that if I open the EMC and immediatley close it, I do not have the problem. It seems to happen if I open the properties of an object, say an Address List or a Send Connector. Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

I have rebooted several times since the IE 9 install and it behaves that way consistently. Only with the EMC and even if I just open EMC and then imediately attempt to close. I have restarted the machine, and then opened EMC, attempted to close and I get the Error.Rick Vachon

Jeff/ChowHound, Do either (or both) of you have the problem with ADUC that I'm experiencing?

Negative. I only see it on EMC, I've tested every mmc I could thing of, perf mon, aduc, several of the built in admin tools, and naked mmc.exe. I tried reloading EMC, no joy.Rick Vachon

Negative. I only see it on EMC, I've tested every mmc I could thing of, perf mon, aduc, several of the built in admin tools, and naked mmc.exe. I tried reloading EMC, no joy. Rick Vachon Interesting.... I started getting the MMC errors after installing IE9, and I was receiving those errors before I installed EMC.

I'm only having trouble with EMC, no other MMC consoles. It may be interesting to note that I have another Exchange server that is using the same IE9 build and has no problem whatsoever. Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Negative. I only see it on EMC, I've tested every mmc I could thing of, perf mon, aduc, several of the built in admin tools, and naked mmc.exe. I tried reloading EMC, no joy. Rick Vachon Interesting.... I started getting the MMC errors after installing IE9, and I was receiving those errors before I installed EMC. I've had the EMC installed on my workstation for some time ( more than a year) and only started getting the error after I installed IE9 last week (except of course, the once or twice I actually did try to close EMC and still had a property box open :-).Rick Vachon

I had an answer to this suggested as a comment to my blog: http://mailmaster.se/blog/?p=600Magnus Bjrk www.mailmaster.se/blog

Magnus Björk, Sir your comment wasn't clear, if you are suggesting that uninstalling IE9 (your comment on your blog) then that is not a fix, it's a work around. The other comment saying adding https://localhost to the trusted sites zone, I can't think why it would have anything to do with it, but I tried it anyway, (I added http://localhost and https://localhost) No joy in muddville. I'm not a big fan of the EMC already. It's an incomplete, half finished, stripped-down management console that MS used to try and force admins who already have way to much to keep up with to learn yet another CLI, E.G. Powershove. Maybe that's why I suspect it [EMC] so strongly. Rick Vachon

I got the same issue after installing IE9. Pleas help us MSFT.

This is a work-around, not a solution. However, it probably will be helpful to finding a correct solution. Thanks.Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Negative. I only see it on EMC, I've tested every mmc I could thing of, perf mon, aduc, several of the built in admin tools, and naked mmc.exe. I tried reloading EMC, no joy. Rick Vachon I have the same exact issues. Win2008R2sp1 Enterprise with Exchange 2010 Std and IE9 (same version as shown above). I have tried the http://localhost and it made no difference. All admin tools work except for EMC. EMC only gives this error after opening the properties of a container like Organization Configuration - Mailbox but it is repeatable. Lastly rebooting changes nothing. @MSFT thank you for working on a fix as I would prefer that to the workaround of uninstalling IE9. -McCue

I have the same issue now with the event viewer

I ran into the same issue with our new Exchange 2010 environment running on Windows Server 2008 R2. IE shouldn't be used on our servers anyway, so the easiest solution was to uninstall IE9 until this bug is resolved by Microsoft. Sounds like lots of folks are having similar issues so hopefully we'll see this fixed soon...May Patch Tuesday??

Dear ALl Un-install IE9 and wait till microsoft release updates i hope MSFT will do it immidiately, yes its a work arround till then wait for updates RaSa

Mark me as one having this same issue. I was going crazy, until I found this blog.

Dear ALl Un-install IE9 and wait till microsoft release updates i hope MSFT will do it immidiately, yes its a work arround till then wait for updates RaSa This is not an answer - removing IE9 is a work-around. Eventually, IE9 will be marked as a critical update in Microsoft Update and it may be pushed down to all computers. We NEED a solution before that happens.Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Dear ALl Un-install IE9 and wait till microsoft release updates i hope MSFT will do it immidiately, yes its a work arround till then wait for updates RaSa This is not an answer - removing IE9 is a work-around. Eventually, IE9 will be marked as a critical update in Microsoft Update and it may be pushed down to all computers. We NEED a solution before that happens. Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Jeff, How many more do you think will suggest that unistalling is a "fix"? Are they that hungry for the points?Rick Vachon

On Wed, 4 May 2011 16:22:17 +0000, Jeff Guillet [MVP, Author, Blogger] wrote: >Un-install IE9 and wait till microsoft release updates i hope MSFT will do it immidiately, yes its a work arround till then wait for updates > > >RaSaThis is not an answer - removing IE9 is a work-around. Eventually, IE9 will be marked as a critical update in Microsoft Update and it may be pushed down to all computers. We NEED a solution before that happens. When this happens, are you always in the same selection in the EMC? E.g., "Recipient configuration -> Mailbox"? If so, does moving to some other selection before you try closing the EMC work any differently? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Having the exact same issue with EMC. IE9 build 9.0.8112.16421, Server 2008 R2 SP1 Enterprise

Same for me. Exact same issue with EMC IE9 Server 2008 R2 SP1 Standard

Another "Me Too" comment. This is occuring on a freshly Re-built Server 2008 R2 Standard x64 w/SP1 and all patches installed. Running Exchange 2010 SP1 (14.1, Build 218.15), IE 9 (9.0.8112.16421) This occurs either connected via RDP or on the systems console. Thought that might help someone out- I'm going to uninstall IE9 and see if that work-around corrects it, at least on a temp basis. EDIT: Did some additional testing in my environment on the server in question before uninstalling IE9. Adding/Moving "https://localhost" has no effect. I can trigger this in my environment by going into "Organization Configuration", and selecting "Mailbox". (edited to remove references to phantom mailstore- more checking removed that variable from the problem.(

I have same issue in my freshly installed test environment. I was definitly able to reproduce the error: 1. Open EMC -> Organisational Config -> Mailbox 1. Open EMC -> Organisational Config -> Unified Messaging 2. Open EMC -> Server Configuration -> Mailbox The error DID NOT appear when I: 1. Open EMC -> Organisational Config -> Client Access 2. Open EMC -> Organisational Config -> Hub Transport 3. Open EMC -> Server Configuration -> Client Access 4. Open EMC -> Server Configuration -> Hub Transport 5. Open EMC -> Server Configuration -> Unified Messaging 6. Open EMC -> Recipient Configuration -> Mailbox 7. Open EMC -> Recipient Configuration -> Mail Contact 8. Open EMC -> Recipient Configuration -> Dist. Group 9. Open EMC -> Recipient Configuration -> Dics. Mailboxes Hope it help. Regards Eduard

Actually with any IE release like this you'll always have the option to not install it. Even in June when it rolls out you'll get the "Do you want to install this yes or no? question before it installs. Given that we shouldn't be surfing from the server this isn't a huge thing but it is a bit tiring that the Exchange team and the IE 9 team didn't get their testing act together and find this ahead of time since this isn't the first time the Exchange management console has barfed on an IE new release. Rich since you have Exchange team contacts, is the Exchange team contacting the IE9 team?

Actually with any IE release like this you'll always have the option to not install it. Even in June when it rolls out you'll get the "Do you want to install this yes or no? question before it installs. Given that we shouldn't be surfing from the server this isn't a huge thing but it is a bit tiring that the Exchange team and the IE 9 team didn't get their testing act together and find this ahead of time since this isn't the first time the Exchange management console has barfed on an IE new release. Rich since you have Exchange team contacts, is the Exchange team contacting the IE9 team? It's true that admins should not be "surfing from the server," but if it were not for some of us who actually installed IE9 on Exchange servers Microsoft would not know of the issue. Eventually, IE9 will become a critical update and I'd hate to find out about it then. I contacted Nino Bilic on the Exchange Team (way above), who told me that the IE9 product group is "looking into it".Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

June is supposedly when it will be more widely pushed out. (Apologies for the attitude) But someone in the Exchange team should have been testing it before this. It shouldn't be community folks that always find out stuff after things have been released. When it occurs with the main console, this is basic testing 101.

No attitude taken. :) Agreed that better testing should take place, especially for something as far reaching as IE or Service Packs. But I also understand that not everything can be tested. While this seems to be a pretty wide-spread issue, I have several servers myself that don't have this problem. This makes it difficult to troubleshoot. I'm thankful when the community posts these issues so they can be addressed. I've shot another email off to the Exchange team to see if there's any progress. I don't have a contact for the IE9 group. Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Yes, you shouldn't be surfing on a server, but what about those of us who have the EMC loaded on their Windows 7 machines so that they don't have to log on to the server console? Don't forget to take that into consideration.

Yes, you shouldn't be surfing on a server, but what about those of us who have the EMC loaded on their Windows 7 machines so that they don't have to log on to the server console? Don't forget to take that into consideration. That's EXACTLY how I found it. I don't normally use the console on my desktop as it has limited functionality, I use it on my windows 7 Desktop for creating new mailboxes/user accounts.Rick Vachon

Even more of a reason that this is basic testing 101 that should have been caught by the Exchange team. Someone in Microsoft admin'ing Exchange servers you would think would have stumbled on this during beta testing themselves.

Agreed.Rick Vachon

No attitude taken. :) Agreed that better testing should take place, especially for something as far reaching as IE or Service Packs. But I also understand that not everything can be tested. While this seems to be a pretty wide-spread issue, I have several servers myself that don't have this problem. This makes it difficult to troubleshoot. I'm thankful when the community posts these issues so they can be addressed. I've shot another email off to the Exchange team to see if there's any progress. I don't have a contact for the IE9 group. Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Thanks for pinging me Jeff... :) Just a quick update - we are still researching this problem. It has turned out to be a bit more complex than originally anticipated. Exchange can not really "fix" this in any way as it is a problem in interaction of IE9 and MMC itself (which Exchange uses as a client). Long story short, right now we do not have any new workarounds (other than what was already discussed in this thread) but the issue has not been forgotten and I am actively tracking it with those other teams.

I am getting the same results with Exchange 2007 MMC on SBS 2008 with IE9 Installed. I however noticed that it only occurs is after I goto "Recipient Configuration -> Mailbox -> TheUser -> E-Mail Addresses tab" and begin adding aliases.This is very annoying. The only way I found to close it is to kill it in the Task Manager. Which takes serveral attempts. The Exact Dialog box that pops up is: Microsoft Management Console You must close all dialog boxes before you can close Exchange Management Console. Noticed the EXACT same thing. Exchange 2007 SP3 on SBS 2008 w/IE9 installed. Never noticed the problem until I added mailboxes and added new primary SMTP addresses for each mailbox, then EMC wouldn't close. Killed the task to get out of it.

FYI - I just built three new Exchange 2010 SP1 UR2 servers on Windows Server 2008 R2 SP1 with IE9 and they all three have the same problem. I fully updated these servers and installed IE9 before installing Exchange 2010. Ugh. Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Another issue that I stumbled accross was after I installed IE9 and rebooted on SBS 2008 I got a corrupted msvcr80.dll which would not allow alot of the services / application to start. Exchange being one of them. I had to restore this dll from a backup. I was then able to reboot normally then remove IE9 from SBS 2008. However now IE9 keeps poping up as an important update. Why is IE9 tied into the EMC in the first place. I would have to agree with Susan above.... TESTING? Although I love the new IE9 on Windows 7; you think they would have tested it on the Server Platforms before releasing it. Thanks for everyones posts....

Um... me too, lot of stuff in this thread about servers and whatnot, I've got it with EMC 2007 SP3 on Windows 7 SP1 x64. Not a server. Touch anything in EMC pretty much and I get this error message when trying to close it.

I too have the same issue... SBS 2008 R2, Exchange 2007 SP3. Installed IE 9, and now get the you must close all dialog boxes error... Is there any way to get notified when this is fixed?

One more here... Actually two... My laptop and desktop both with Win7 x64 get this error when trying to close the mmc. Fortunately, I will primarily be using powershell rather than the mmc most of the time so it doesn't bother me too much. And as a side note, I had IE9 installed before I installed Exchange 2007 MGMT Tools. And as another side note, I have Tivoli Endpoint Manager Console (formerly BigFix) installed and IE9 broke it too. Every time I try to resize the TEM window, the console crashes... I guess that's what I get for trying to stay on the N version of any microsoft product...

Strangely another admin I was working with has the exact same setup as me pretty much, and her PC doesn't have the problem... Is this all on x64 versions, I think her PC might be 32-bit? I've had bugs before on x64 versions of Windows that don't show up on the 32-bit versions, I've got a problem right now with MSRA that only seems to happen on 64-bit clients. Someone above said 32-bit too.... really? What testing was done that it wasn't caught?

I too have this issue. Exchange 2010 SP1 on Standard 2008 R2. All officially released updates are installed. Have to end task or log off to close the GUI. Other than being annoying it doesn't seem to cause any problems and powershell is unaffected.

Me too. Exchange 2010 SP1 on Windows Server 2008 R2 Please Microsoft release a update for IE9 to fix issue.

What worked for me was turning off "Internet Explorer Enhanced Security Configuration" for Administrators and Users and then adding https://localhost to the "trusted sites" in IE Security as well. Close EMC, and all IE windows and reopen EMC and I have not been prompted with "you must close..........." from EMC since. T It only worked temporarily for that logged in sesion. After a reboot of the server the issue came back when trying to close the mmc the next time. Hopefully MS will come out with a fix soon.

What worked for me was turning off "Internet Explorer Enhanced Security Configuration" for Administrators and Users and then addinghttps://localhost to the "trusted sites" in IE Security as well. Close EMC, and all IE windows and reopen EMC and I have not been prompted with "you must close..........." from EMC since. T

Thank you Trevor, Unfortunately turning off Enhanced Security would be a work-around and we would like a fix from Microsoft that doesn't require lowering security on the system. -McCue

Thanks for your idea.

2 months later after the OP and I have a fresh Exchange 2010/Server 2008 R2 install with IE9, same issue. Shall I wait for a fix or uninstall IE9?

I no longer install IE9. I uninstall it on any Exchange 2010 servers I find it on and then hide the update in Windows Update. Come on, Microsoft! Put some effort into this! Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi all I had the same problem. I have resolve this problem by using these steps-- 1. Install latest update. 2. Pls carefully see that anything is not open on your screen from MMC CONSOLE 3.Close mmc by using task manager. 4. restart the server. after all these step your problem would be solve. Thnak & regards AAKASH JAIN Skype;- jain_it Network Administrator

Aakash, This may have worked for you on a server but, my windows 7 box has been updated and restarted many, many times since this problem first manifested. Sorry but it's not a fix for me. As for my servers, I have to keep unchecking the box to not install IE9 from windows update as it comes across as an "Important Update". For my home machine, I uninstalled IE (I do not like it anyway, wish they'd quit moving controls around, and the popup bar at the bottom, what the hey?) and I am using Google Chrome. I would for my machine here at work as well but I have found some sites will not view in chrome, in particular MS sites, which I need for work. Cheers, Rick Vachon Rick Vachon

i have the same issue. answer by aakash does not work for me :(Thanks Uday Kiran, Senior Consultant Cyquent Technology Consultants, Dubai Please Mark as answer if it helps you

Same issue here as well, on all my fresh installed 2010 SP1 RU3 servers (W2k8 R2 SP1). What's interresting, though is that if you just click on around anywhere in Toolbox, Recipient Configuration, Server Configuration and even the UM, HT and CA parts of Organization Configuration - MMC shuts down just fine. As soon as you click the Organization - Mailbox - Database Management and that part is refreshed (still without clicking on anything), MMC hangs with this error and you'll have to kill MMC.Exe... To me, the current EMC seem a bit "unfinished" as well - especially i regards to the refreshing of a DAG and it's database status. Refreshing/waiting/refreshing/waiting doesn't pick up the correct status of all DAG DB-copies in my environment after a DB-move - but if you restart the EMC, all is looking fine immediately!

Same issue here... my current workaround is to just end the mmc.exe process. Not very clean (or ideal), but i'm not going to uninstall IE9.

Same issue here - IE 9.0.8112.16421 Tried closing out of all MMC's, rebooting, still no go. It's weird that it looks like it only happens with the multi-pane portions of EMC. I agree about the 'not browsing around on an exchange server' comments, but isn't IE 9 supposed to be as much a 'security' update to IE 8 as it is an improved user experience? Also, IE 9 is now grouped in the critical/security update section. So unless you uncheck it - you're gettin' it. I will keep IE 9 and wait for a fix...

I also agree that you should not (or limit) browsing from an Exchange server. However, it is important that this is fixed as many companies may setup a Remote Desktop Server and publish the Exchange Management Console to avoid having the install the console on the desktops of anyone that requires access. As they will not be able to close the console, this can pose a challenge as someone will have to manually kill the session.Sean | http://seanv.wordpress.com

I am also experiencing the same problem. Is there not a solution to this yet?

I am also experiencing the same problem. Is there not a solution to this yet? We haven't seen anything from MS here in a while, meanwhile, IE9 keeps showing up as an important update on my servers and I have to uncheck the box an it shows up on MBSA to my InfoSec guys. I wish I had made a restore point so that I could uninstall from my desktop but I don't have the option to revert. I've decided I do not like it, at all. It's almost as slow as Outlook now and the controls have been moved around to strange places. I knew I didn't like EMC the first time I tried to to find out how much space a user was using, I have to search the web to find the "secret squirrel" powershell command. I manage a relatively small network, In addition to Exchange, I manage Sharepoint, Active Directory as well as the entire VM infrastructure. I have enough to do already and now I have to research CLI commands to do anything in exchange like importing a new certificate, it's pedantic and insulting to try and tell me that it's because we designed to be more streamlined for the Help Desk type and a ""True Administrator"" can use the CLI, I throw the BS card on that one. It's either because they want to force everyone to learn their CLI or that they were in a hurry to get it on the street, maybe even some other nefarious reason but defininetlay not for the official kool-aid offering stated. How hard would it be to have an "Admin Mode" switch? Every command in the EMC is based on PS anyway. Apologies to all for the rant, now that I've told MS to "get off my lawn" I'll get off of y'all s. Cheers, Rick :-)Rick Vachon

Hi all. Thank you very much for detailing the issue and we do now understand what's occuring between the EMC, MMC and MSHTML. We have enough information to complete the investigation and have moved to looking at ways to improve this situation. As I understand it, the workaround (albeit clunky) to use Task Manager to end, does work. When we have more to share we will post back. Thanks MarkMark Feetham Senior Program Manager Internet Explorer Product Quality

Mark: Thank you for the update. Is there an associated KB article for this issue, by any chance?

we are still waiting ...Ibro

Besides my exchange servers which had this problem. Subsequently uninstalled ie9 from them, I just had the same occur to a Vista home premium x64 laptop that I am working on for a co-worker. Base install from dell with ie 9.0.8112.16421 update versions 9.0.1.

Same problem here. I have a number of clients with 2010, IE9, 2008 R2 and all experience the same damn issue. And to comment on earlier posts - even though admins don't surf the net from servers - we do use the internet to download fixes and whatnot to servers (especially in a pinch). This isn't a solution, but the only way to exit the EMC console is to either kill the process or logoff. Not the cleanest method but they work. Microsoft -- This wouldn't be so bad except you are pushing IE9 out to servers. QC should have caught this issue

I've been working with Microsoft via some of my contacts and I finally have a little information to share. Officially, the statement is: The IE9 engineering team is aware of the issue and actively triaging it. They are considering a fix to be delivered later this year. Unofficially, the issue has been linked to the Microsoft Management Console (MMC) and Internet Explorer 9. While the issue is primarily in the MMC, the IE9 team can release a fix sooner than the MMC team. They are cautiously optimistic that a fix will be released in a Q4 2011 service update. That's all I've got, folks. Stay tuned. Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Hi all, I posted this clean workaround on another much shorter but similar thread. I couldn't see how to link it so I'm re-posting. I'm getting this error with SBS2011 and IE9 in the EMC. The most convenient workaround for me is to not-Logoff. Press Logoff. This immediately throws up a message box advising you about open dialog boxes and saving changes before pressing OK. Don't be in a hurry to press OK. Just wait a few seconds and you won't actually logoff because you get the opportunity to cancel. Pressing Cancel returns you to the console screen, Now you press OK on the message box and your EMC/MMC will close gracefully without recording an application hang event

This has gone from being a minor annoyance to being a significant problem for me, because IE9 is now an update showing up in WSUS, so short of creating separate groups to exclude anyone with EMC, I can't approve IE9 for deployment. I don't particularly want to do that for just one bug that will eventually be solved. Q4 is a long way off, we're still in Q2.

Scott Schnoll in one of the recent Teched presentations indicated a workaround that you have to just click anyhere other than the mailbox node under server configuuration. So work in emc then to close it click on oraganization node to clsoe it. The issue is with MMC and not Exchange or IE9 it seems.

Brilliant! I've confirmed this workaround.

LMurthy's workaround does not work for me. Server 2008 R2 SP1 IE 9.0.8112.16421 Exchange 2010 Standard (v14.1, Build 218.15) No matter where I go in EMC I end up with the error when I try to close it. I end up having to kill that MMC in task manager.

LMurthy's workaround does not work for me. Server 2008 R2 SP1 IE 9.0.8112.16421 Exchange 2010 Standard (v14.1, Build 218.15) No matter where I go in EMC I end up with the error when I try to close it. I end up having to kill that MMC in task manager. Ditto for me, If I don't click anything in EMC, it will not close properly. Not a work around for me.Rick Vachon

That "workaround" does not work for me either. And I don't consider having to remember where to click to be a workaround anyway. Seriously, this needs to be fixed. Soon.

I ran into this issue recently with Exchange 2010 SP1 or 2008 R2 SP1. As a work around I made an mmc and added the Exchange Management Console snap-in. The newly created mmc closes fine.

Same problem here ! Last workaround is not working...Pensia Ltd - R&D - CTO :: www.pensia.com

I'm in an E2kX class and this error comes up all the time :P. Reason is: "its microsoft"

I ran into this issue recently with Exchange 2010 SP1 or 2008 R2 SP1. As a work around I made an mmc and added the Exchange Management Console snap-in. The newly created mmc closes fine. This is the first work around that has worked for me. Now I just get the "Do you want to save" dialog, but I can live with clicking OK. Thanks Supersonic_Oasis!Rick Vachon

to resolve this issue follow these instructions: What worked for me was turning off “Internet Explorer Enhanced Security Configuration” for Administrators and Users and then adding https://localhost to the “trusted sites” in IE Security as well. for how to turning off “Internet Explorer Enhanced Security Configuration” for Administrators and Users check http://www.techrepublic.com/blog/datacenter/windows-server-2008-manage-internet-explorer-enhanced-security-configuration/255 Close EMC, and all IE windows and reopen EMC and I have not been prompted with “you must close………..” from EMC since.

to resolve this issue follow these instructions: What worked for me was turning off “Internet Explorer Enhanced Security Configuration” for Administrators and Users and then adding https://localhost to the “trusted sites” in IE Security as well. for how to turning off “Internet Explorer Enhanced Security Configuration” for Administrators and Users check http://www.techrepublic.com/blog/datacenter/windows-server-2008-manage-internet-explorer-enhanced-security-configuration/255 Close EMC, and all IE windows and reopen EMC and I have not been prompted with “you must close………..” from EMC since.

Someone posted that earlier, doesn't work. It's happening on clients too, they don't have the enhanced security configuration.

Just my 2 cents on this. I'm using the Exchange MMC (installed from the Exchange 2007 SP3 media) remotely from Win 7 x64 Enterprise SP1 machine (so no IEESC in play). I start mmc.exe from a cmd box that is running as my domain admin account (my local logon is always just a domain user account). I cannot remember if I installed IE9 before or after I had built/saved my mmc for Exchange, but I am(was) definitely experiencing this issue. Following supersonic_oasis's tip, I deleted my saved mmc and built a new one. Having done that, I just now have opened and closed this new mmc twice (including moving focus around the containers and opening some properies boxes) without the nag prompt. We may be on to a half-decent work around here. Cheers

Can be fixed with IE ESC Exchange 2010 - (You must close all dialog boxes before you can close Exchange Management Console) Pete PeteNetLive

Can be fixed with IE ESC Exchange 2010 - (You must close all dialog boxes before you can close Exchange Management Console) Pete PeteNetLive Sorry, but I already had the IE ESC disabled for the Administrator as you suggested and it still happens.

Same thing is happening to all my Exchange boxes. Just started happening and the last thing to get installed on them are updates from WSUS including IE9. Hopefully MS can fix it soon. Until then the only work around for me since I remote into these machines is to simply log off.

Try this! In my cases this only happens when I execute the Exchange Console (2007 & 2010) with another user. I have executed IE9 with this other user and the error go away. I tested it several time open and close the console, and opening and closing different dialogs and do not receive this message when closing anymore .

What seemed to be a workaround for me is similar to the Log Off suggestion. Except on Server 2010, You really do not get an option to cancel Logoff. After you CTRL-Alt-Del, you get one click for a Logoff and it logs you off. No cancel. Anyways, I logged off with the MMC running. Could not close it normally. Server 2010 did not ask me if I wasnted to Close all dialog boxes or save any work, it just logged me off. I then re-logged on and closing all the MMCs seem to be working normally. I tried with the WSUS MMC, ADUC and Exchange Console. Clicked around. Opened property windows, then closed everything down just fine; no errors. Hope this works for others.

Doesn't work for the third time of saying it - it happens on clients that have the tools installed and do not have ESC.

I have a fix. Microsoft, stop trying to make browsers.

Doesn't work for the third time of saying it - it happens on clients that have the tools installed and do not have ESC. EDIT: False, I have had ESC both on and off and it doesn't help.

For those who are too impatient to read through the entire thread to confirm your issue and/or find a workaround, here's a summary: * This occurs on servers (2008/2008R2) and workstations (Vista/W7) alike; If the EMC is installed and IE9 is present, you are probably experiencing this issue. * Merely navigating the EMC's left hand tree without opening any properties or other dialogs is enough to trigger the issue. * Force killing the MMC.EXE process or logging off and letting the OS kill the process is the only way to close the EMC when this occurs; however, this may have an effect on system stability. * MSFT is aware at some level of the issue, but has not released a fix yet. To my knowledge, there's no KB article on the problem as of this writing. (Jeff, Mark, anyone at MSFT: care to chime in with an update?) * The only sure-fire workaround the collective has found is to either not install or uninstall IE9. * Changing the "Enhanced Security Configuration" on the server does not appear to fix the issue on a reliable basis, and some of us refuse to turn it off on our servers for security reasons. (Please direct all flames about not browsing from servers to /dev/null; WE KNOW IT'S A BAD IDEA.) * Same with changing the localhost trust and security settings; I tried it on a fully patched brand new install and it did not work. * Same with making sure all the patches have been installed, etc. ad nauseum: This issue started for me directly after installing all the patches up to current at that date. worked fine until I installed IE9 as an update.

For those who are too impatient to read through the entire thread to confirm your issue and/or find a workaround, here's a summary: * This occurs on servers (2008/2008R2) and workstations (Vista/W7) alike; If the EMC is installed and IE9 is present, you are probably experiencing this issue. * Merely navigating the EMC's left hand tree without opening any properties or other dialogs is enough to trigger the issue. * Force killing the MMC.EXE process or logging off and letting the OS kill the process is the only way to close the EMC when this occurs; however, this may have an effect on system stability. * MSFT is aware at some level of the issue, but has not released a fix yet. To my knowledge, there's no KB article on the problem as of this writing. (Jeff, Mark, anyone at MSFT: care to chime in with an update?) * The only sure-fire workaround the collective has found is to either not install or uninstall IE9. * Changing the "Enhanced Security Configuration" on the server does not appear to fix the issue on a reliable basis, and some of us refuse to turn it off on our servers for security reasons. (Please direct all flames about not browsing from servers to /dev/null; WE KNOW IT'S A BAD IDEA.) * Same with changing the localhost trust and security settings; I tried it on a fully patched brand new install and it did not work. * Same with making sure all the patches have been installed, etc. ad nauseum: This issue started for me directly after installing all the patches up to current at that date. worked fine until I installed IE9 as an update. I agree, the only surefire way of getting this to go away is to uninstall IE9. There was also a suggestion to create an mmc and add the Exchange serevr 2010 snapin however if I then click all nodes under server, org and recipient, it throws the same issue. I realise you would probably not open all areas of exchange but it proves the bug is still there. MSFT what is the latest? Will you bring out an update that stops this browser being incompatible with your own software (MMC and certain versions of sharepoint), Certain java based sites/applets/programs and lots of websites or will this just go on and on until you decide lets make IE10 which in truth will probably not be an improvement. I have always been of the opinion that you should move to latest tech and work out the kinks but IE9 is just way too buggy and I have upgraded to IE8. My org has banned its use and we are a Microsoft partner. Rant over :)

Dear all I agree with williams point we may have to wait till MSFT fixes the issue.un-install IE9 offcourse its a temporary workarround, but you can eliminate the error atleast for time being. regards RaSa

Same issue, same opinion... Wait until MSFT releases a fix. Uninstalling IE9 might be a security risk, also disabling IE ESC... Anyway, my Exch2010 console is open 24/7, no need to close it. Now the dummie question: what is the standard time MSFT takes to release this kind of fixes? godog

Same issue, same opinion... Wait until MSFT releases a fix. Uninstalling IE9 might be a security risk, also disabling IE ESC... Anyway, my Exch2010 console is open 24/7, no need to close it. Now the dummie question: what is the standard time MSFT takes to release this kind of fixes? godog There is no standard time. They have the bug, it has a priority and they'll get to it when they get to it. This bug has been around since IE9 beta if that gives you any indication.

They still can't find the solution?/?/?/?/? .........................................................../...................................................................

I'd also like to know when this is fixed. Also...it once again reminds me of how much (read: little) testing is done by Microsoft before releasing products...

Hi folks. Quick update: The root cause has been established and we are actively working with the teams needed to priortize a fix. We've not released a KB as the current work around of using Task Manager to end the process is (to my mind) clunky. We are continuing to listen and expedite this issue with the necessary teams internally to return the interoperability and behavior you all expect. Thanks and regards. Mark Feetham Senior Program Manager Internet Explorer Product Quality

Nice to see some acknowledgement of the problem once again. But it is a bit has been quite a while without a fix for this issue.... for an issue that is pretty annoying.-Pete

Looking forward for some sort of fix from MS soon. We cannot kill the MMC all the time.

We too have an environment with WSUS and this is becoming more problematic as more admins move to Windows 7 and IE9. The fact that this is known and has taken so long to address is casting a fairly negative image of Microsoft around here. I hope that a true fix comes sooner rather than later.

Exchange 2010 SP1 Management Console + Windows 7 x64 + IE9 + All updates = FAIL :(Alexey Kuznetsov, Relief Software

My solution was, IE 9.0 add in TAB: Security ->Trusted Sites : mmc (only). now work well. Tks and lucky youmigrations

Can you provide exactly what text did you put in? I tried a number of things in Trusted sites and also tried adding into LAN addresses, advanced but couldn't get rid of the issue. Thanks Simon

@ Mark Feetham MSFT Thank you for the update. I'll continue to moniter this thread for future updates about a fix or KB article and would appreciate it if you would post back here when there is news. Regards, Dave

Well I guess it is good to know I'm not the only one having this issue..... :p

http://www.petenetlive.com/KB/Article/0000478.htm Regards, Ahmad

http://www.petenetlive.com/KB/Article/0000478.htm Regards, Ahmad Not working. I already had IE ESC disabled on the server. Definitely related to IE9 - hopefully a patch will be released soon.

Ahmed: This was already suggested back in July. No good.

I'm also facing the same

Amazing that it's been five months and no sign of a fix.Regards, Josh Erquiaga

Come on MS, release a fix, surely you can add it in on "Update Tuesday", with the other 17 security fixes we're getting :)

Just posted this blog http://www.windowsitpro.com/blog/tony-redmonds-exchange-unwashed-50/exchange-server/why-cant-microsoft-ie9-work-exchange-management-console-140165 to see whether it might prompt Microsoft to fix this enormously irritating problem. - Tony

Yes, the problem is irritating, and no we don't need prompting to fix it. We (Exchange) are working to get the appropriate team to fix this issue. We certainly understand the grief it is causing and we would like a permanent fix for this, too. Unfortunately, for the time being, the workarounds of removing IE9 or killing mmc.exe are the only possible solutions. But don't think for a minute we forgot about this, are neglecting it, or are somehow incapable of fixing this because that is simply not the case. Any suggestion otherwise, is simply unfounded.This posting is provided "AS IS" with no warranties, and confers no rights.

I mean no disrespect here but this issue has occurred since March. It's now August. Every two months a new IE update comes out. The perception out here is that this is not a high priority due to the length of time it's taking to fix this. If (heaven forbid) the fix doesn't make it into the next IE update, perhaps someone can proactively post status reports. Past history with Microsoft is that someone has to make it a "bloggy" or "newsworthy" event before someone takes action. Making proactive status reports here would help to reinforce the fact that it is not being forgotten. Out here we don't understand why it's taking this long. Help us to understand.

Thanks, Scott. I know you don't want to throw any team under the bus (I'm looking at you, IE9 team), but I see two problems here. One is the obviously irritating problem itself, and the other is Microsoft's (the company's) lack of response and information about this issue. I almost think the second problem is more important in this case. When so many users are complaining about an issue and there's little or no authoritative response, it's viewed as a failure and customers don't feel the love. It's even more aggrivating when the IE9 train keeps coming down the track - IE9 is now listed as an important update in WSUS and will be installed automatically on WSUS clients, MS is pushing IE9 whenever and wherever it can, more companies are deploying it in managed environments. etc. The fact that most users affected are admins running the Exchange management tools from their Win7 desktops is mainly lost here. Yes, we know we can end task the MMC. Yes, we know that it can be solved by uninstalling IE9 (if possible - it's not in managed environments) and ignore the WSUS update. These do nothing to eliminate the irritation. and having Microsoft seemingly ignore customer complaints does not help. On a side note, it's noteable that Exchange 2010 is useable and stable enough that (relatively) small irritations like this get a lot of comments. Looking forward to a fix in Q4. http://www.expta.com/2011/04/issue-with-ie9-and-exchange-2010.html Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

OK, so let's talk about some more details. Susan mentioned this issue has been around since March. Based on forum threads and emails I have, it looks like late March is when this issue first surfaced. And then in April, the issue started getting reported more frequently (although at this point not an alarming frequency) because IE9 was released to Microsoft Update. As it was reported primarily by Exchange admins on both Exchange 2007 and Exchange 2010 and initially only with the EMC, this was initially thought to be an Exchange bug. But, given the combination of software bits in use (Exchange, MMC, IE and Windows), this could just as easily have been an IE, Windows or MMC bug. We (Exchange) didn't know at this point, but nonetheless our product quality team and others took ownership of this issue and began an investigation in late April. After investigating the matter in Exchange and IE, it was determined in early May that this was actually an MMC bug. However, after discussing the issue with the MMC team, the IE team took ownership of the bug. It turns out that there was a similar bug they (IE) fixed in Windows, but that fix did not resolve this issue because MMC hosts the mshtml component directly instead of using a web browser control. So why did the issue appear with IE9, but not, for example, in IE8? In a nutshell, in IE9, the "Internet Explorer_Hidden" window has a property flag on it that did not exist in IE8 and earlier. MMC checks for this flag in its process and if any remain open, it will prevent the dialog from being closed and report the error message we've all come to hate. In any event, after working with the MMC team throughout May, the IE team retained ownership of this issue. Like all companies, Microsoft has a finite amount of resources (time, money, people, tools, etc.). So, we prioritize the work we do based on a number of criteria. Like all bugs, this one has a specific priority and severity, and like some bugs, it's current status is active, which means the bug is being actively worked on by one or more people. It takes time to work out all of the issues with code bug that can span across multiple products. So, I would say, first, don't bash the IE team. The IE team has graciously stepped up to take ownership of this issue and to provide a fix in IE so that MMC (and any other apps similarly situated) are fixed. I have personally communicated with the PMs and devs that own this issue and I can assure you that they are well aware of your frustration and that they are working on this issue. When we have more information that we can share, we will blog it, tweet it, and post it here in the forums. In the meantime, some other points worth raising: While many of us monitor these forums regularly, these forums are not a substitution for reporting bugs by contacting CSS. If you contact CSS, yes they will ask you for a credit card, but if you are reporting a bug, no charges will be made against your credit card. In other words, calling CSS to report bugs is basically free (except for your time, of course). But it is the proper and official way to notify Microsoft of bugs like this. We still want you to report these issues in the forums because lots of us monitor these forums and can take action based on them. But when it comes down to things like prioritizing bug work and stacking bugs, official customer reports via CSS or another proper escalation path are required. We have been somewhat vocal about this. I spoke about this publicly at TechEd North America in May, and internally in July (at an internal conference) so that the field, PFEs, etc., could spread the word, too. But that said, there really hasn't been much to say about it. We've detailed the workarounds, but we don't have a fix yet. As much as I would like to keep the forums up-to-date on this and every other issue, it simply is not practical to post regular status updates about every single bug. Not only would that not scale, it would be unmanageable, as well. That said, I will post back here when I get more information from the IE team in September. IMHO, this is a very minor issue that, while frustrating, is not pervasive, does not cause any damage or data loss, has viable workarounds and is really inconsequential from a day-to-day perspective (hey, just leave MMC open <g>). These are my own viewpoints and they do not necessarily reflect the viewpoints of Microsoft. Nonetheless, I hope they help. This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks again, Scott! That's MUCH more information than we've gotten previously and is what we are looking for, short of a fix. I kind of expected to see this information from owner of the bug or the MMC team, though. Jeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Scott: Thank you *very much* for taking time to update us. It's greatly appreciated. In the future, I'll also let our premier rep know if I run across something like this, and I'll also give him a heads up so that he's at least aware of the issue for the other accounts that he manages.

To give a bit of communication and hopefully better understanding back - keep in mind that this is not caused by a security update but an IE9. Therefore unless you are a premier customer with incidents, it may not be a free call. To get it into escalation you'd call, have to use a support incident or pay the $250 fee and hope that it would be credited back to your account once they figured out it was a bug. Many times I have to use the MVP cases we get to have people call in because $250 a pop doesn't sit well when they see that it's your problem not theirs. In this bloggy/forum/twitter world people don't call, they go to a forum to report the problem. The earliest reports may not come from enterprises but from smaller firms with tighter budgets. I understand you still prioritize based on esclation paths, but please understand that forums should be weighted with the understanding that people these days use means other than support phone calls to indicate pain. Giving status reports to MVPs and then empowering them to spread the word would work as well if you could. I don't need you personally to do it, but ensuring that some group of plugged in people are in the know so that they can spread the word would be wonderful.

Susan, when you call CSS to report a bug, it is free. It does not matter if it is a security update, an IE update, some new software we just RTM'd, etc. I have yet to hear of a single customer that reported a bug and was charged for it. If you know of any such customer, please have them contact me (scott dot schnoll @ microsoft dot com) and send me the details. You should not be using the MVP cases for anyone other than yourself. They are given to MVPs for that specific MVP's use. Forums have been around for a long time, and I expect and hope people will keep using them. But forums are not an official way to report bugs for a variety of reasons, including the ones I previously mentioned. We value the forums (and more importantly, the forum participants such as yourself) tremendously, but they simply don't work as a scalable, sustainable method for tracking real customer issues. While they are informative and highly useful, their purpose is not a bug collection mechanism, especially given that we have very mature channels and processes available for that. As for status reports, I and others regularly update MVPs and others in regularly scheduled community conference calls, and via private MVP DLs on this issue and others. And as I mentioned I've discussed this publicly at TechEd (and there are forum posts in a different thread on this issue that reflect that, as folks mentioned it), and I plan on discussing it next week publicly at TechEd New Zealand and the week after at TechEd Australia. In fact, given the minor nit that this issue really is, I could argue that I have spent a disproportionately large amount of time discussing this issue. I can assure you that if and when there is something noteworthy to mention, it will be mentioned (blogged, tweeted, posted in forums, mentioned at conferences, discussed in concalls, etc.).This posting is provided "AS IS" with no warranties, and confers no rights.

When I call in, if I don't have a case, I have to provide a credit card to start the call. MVPs can't use cases for our own personal use, the cases are only to be used for community needs.

As I stated earlier, if you contact CSS, yes they will ask you for a credit card, but if you are reporting a bug, no charges will be made against your credit card. In other words, calling CSS to report bugs is basically free (except for your time, of course). But it is the proper and official way to notify Microsoft of bugs like this.This posting is provided "AS IS" with no warranties, and confers no rights.

Now we know it's a bug, initially we may not. At the point in time where they call in, they may not know it's a bug. So the charge to either their technet incidents or to their credit card gets made intially. Telling someone to call and that their credit card will be ultimately refunded, only works with people that trust me personally. The only way I can guarantee that Microsoft will get a call is to set up a case for someone who otherwise would refuse to call in. That's my reality of working with people in the forums.

Susan, you make an excellent point. If you call in, and it is not a bug, you will be charged. Which is one reason I hope folks will continue to report issues here, too. Certainly, you don't want to pick up the phone every time you run into an issue. You definitely want to come to these forums and discuss the issues with others.This posting is provided "AS IS" with no warranties, and confers no rights.

I use the forums as an excellent resource when troubleshooting problems myself- the problems I've run across in my day to day work are generally something that's been encountered before, or at least give me things to try before calling in for support and burning our premier time on what may be a trivial issue to fix.

Scott.. For fairly obvious reasons I've just read this entire thread. I work for a multinational and am in charge of their Email systems covering 40,000 people. I have 3 comments on your comments. First. There is no way I'm going to give over my credit card details for what is basically a Business issue. First I need to know how much it will cost, and second, I need to get the appropriate authoriastion and third, I will need to reclaim that amount. So Bug reporting through the telephone is not going to happen by me or any of my collegues for exactly this reason. Second, in this day and age, we should have an on-line way of "officially" reporting bugs to you. You're MIcrosoft, you make computer operating systems among other things. You DO NOT make telephones. Why are we being asked to use a non-microsoft product to report issues with a microsoft product. Yes, I can imagine there are occasions where you can't get on line, but come one.. This is the 21st Century, start using the products you sell. If you don't, why should we? Third, reporting a bug shouldn't require credit card information EVER.. I don't have to hand over credit card information to anyone else when reporting support issues, and I've paid a licence fee for my server and users, so I should be able to report bugs.. If it's user error, you should simply mark it as such once received, but please.. Let's stop with this "Credit Card" rubbish, it's slowing your whole ability to be responsive..

Jon, Looks like that was your first post in these forums. Thank you for your feedback and welcome to the community! I appreciate what you are saying; and I'll pass on your feedback to folks in our CSS organization. We do in fact have online issue reporting and tracking that comes with certain support agreements. And we have several other online mechanisms, including Web pages and email aliases, that can be used for submitting feedback and reporting bugs. As for credit cards, they actually don't slow down our responsiveness at all. And when a customer calls with a problem our focus is on solving that problem, and not just taking credit card info (our support organization is a cost center, not a profit center). As an aside, can you imagine the furor that would result if we forced you to only use a Microsoft product to report bugs? That would not be cool. Folks would scream at us, and rightly so. No, we have to have other mechanisms, including ones that cover the wide array of customers who for a variety of reasons are on disconnected networks, or networks with no access to the Internet. To address your 3 comments directly: Companies use credit cards all the time to cover business issues. For example, purchasing goods and services, which is what we're talking about here. Second, of course we tell you how much it costs (and we publish that on our support Web pages, too). You cannot provide a service to the public without first informing them of the cost. To carry your example forward, you would basically get approval from your manager for the charge and then proceed with the case. If your support case is not being opened to report a bug, then you probably won't see a refund. If it turns out your support case did result in the reporting of an actual bug, then the charges are immediately reversed and they never appear on your card. We've been operating this way for well over a decade, and the process has worked well for our customer and for us. As I mentioned before, we do have online mechanisms. For example, Premier Support customers have Web portals they can go to for opening issues, tracking issues, etc. And if folks like yourselves prefer to contact us using a Microsoft product, we do in fact make telephones (Windows Phone and Windows Mobile) which can be used to call us. But of course, we're not going to force you to use a Microsoft product to request support, so you can also any other telephone. Your third issue seems to be a repeat of your first issue. And overall the two issues seem to be a complaint about having to pay for support. Again, if you are reporting a bug, you won't be charged in the end. But the fact that a credit card is needed to purchase a service does not slow down our response times at all. I'm not sure on what basis you are claiming this, so if you have any evidence or cases where the processing of a credit card slowed down the response time, please send them to me for investigation ASAP. Again, thanks much for your feedback, and I hope you continue to participate in the technical Q&A portion of these forums. These are my own viewpoints and they do not necessarily reflect the viewpoints of Microsoft. Nonetheless, I hope they help.This posting is provided "AS IS" with no warranties, and confers no rights.

This issue can be fixed by adding mmc.exe to the Trusted Sites list in IE, as stated by Ashley here: http://www.expta.com/2011/04/issue-with-ie9-and-exchange-2010.html ThomasThomas Stensitzki - MCPD, MCITP, MCTS, MCSA, MCSA:Messaging

This solution will not work because it will not work in principles. What does adding the file name in trusted sites? Nothing. If you run mmc.exe in debug mode, you can see that some call from mmc.exe to mshtml.dll involve exception 'AccessViolation'. This is "security improvements in IE 9" :( Any claim to the Exchange Team are not justified, because this happens not only Exchange Management Console, but also with other consoles, i.e. TMG Management Console. This is bug in new IE security model. When IE Team fixed this bug - we must asks IE Team Lead, but not Exchange Team guys. In this time, in my opinion, the best workaround is a uninstall IE 9 (downgrade to IE 8), because this disadvantages exceeds all its benefits. We just have to be patient and wait for the official bugfix from IE Team.MVP Exchange Server from Russia http://msexchangeexpert.ru Please sorry for my English, it's not my native language.

People seem to think this fix will work because they are not performing the correct steps to trigger the problem. Here are EXACTLY the steps to reproduce the problem, 100% of the time: Open Exchange Management Console. Expand Microsoft Exchange On-Premises. Expand Organization Configuration. Select Mailbox. Wait about 2 seconds. The Status Bar should be blank (not "Refreshing..." in the lower left). Make sure you are seeing the Database Management tab. Attempt to close Exchange Management Console. It doesn't matter if you add mmc.exe to Trusted Sites. It doesn't matter if you add about:blank to Trusted Sites. There is nothing you can add to Trusted Sites which will fix the problem when you perform the steps above. People are adding these things to their Trusted Sites, then they are testing by going into Recipient Configuration or Server Configuration or Toolbox. That's not a correct test. You must land on the Database Management tab and allow it to finish refreshing. If you go to any other place, it won't trigger the problem. If you land on the Database Management tab but close EMC quickly before it finishes refreshing, it won't trigger the problem.

I haven't FIXED it, but I have gone around it on 2 different servers now, by adding https://localhost (exactly as written) to trusted sites. Log off + on again...and the Exchange console now works as intended :)

Hi All :-) Tried these work arounds again. Didn't help with our config. As a matter of interest the bug doesn't come up in every section of the EMC for me. I can go into EMC, Recipient Config and change things fine but if I even open EMC, Server Config and just select Mailbox I get the issue. EMC, Server Config Client Access, Hub and Unified work ok. Haven't tried every permutation but find it interesting people are seeing it manifest in different ways. Simon

A little off topic here, but I have noticed the EXACT same bug when trying to close the Failover Cluster Manager in Windows Server 2008 R2. I have been monitoring this problem ever since IE9 came out and it affected EMC, and now to find out its also affecting Failover Cluster Manager and nothing has been resolved but these so called workarounds. Microsoft fix your problems already. It's getting ridiculous. TSK TSK TSK

I uninstalled IE9 and now my server is stuck at "Preparing to configure Windows" screen...

People seem to think this fix will work because they are not performing the correct steps to trigger the problem. Here are EXACTLY the steps to reproduce the problem, 100% of the time: Open Exchange Management Console. Expand Microsoft Exchange On-Premises. Expand Organization Configuration. Select Mailbox. Wait about 2 seconds. The Status Bar should be blank (not "Refreshing..." in the lower left). Make sure you are seeing the Database Management tab. Attempt to close Exchange Management Console. It doesn't matter if you add mmc.exe to Trusted Sites. It doesn't matter if you add about:blank to Trusted Sites. There is nothing you can add to Trusted Sites which will fix the problem when you perform the steps above. People are adding these things to their Trusted Sites, then they are testing by going into Recipient Configuration or Server Configuration or Toolbox. That's not a correct test. You must land on the Database Management tab and allow it to finish refreshing. If you go to any other place, it won't trigger the problem. If you land on the Database Management tab but close EMC quickly before it finishes refreshing, it won't trigger the problem. I can confirm this is still a current issue - been tolerating it for months but as I use RDP it's not really an issue but an irritation... A fix would be nice though

Still looking for a fix...any updates from Microsoft?

5 months down and still no fix for this issue. It's a shame really, because I had high hopes for IE9. Sadly the browser is just too buggy to sustain in our environment; we're looking at moving to Chrome and ditching IE altogether. (9.0.8112.16421)

Adding myself to the list of affected users. I'm running Windows 7 x64 and IE9.0.8112.16421 (bundled, not removable). Anxiously awaiting a fix.

I'm running Windows 7 x64 and IE9.0.8112.16421 (bundled, not removable) You can disable IE9 as Windows Feature from Control Panel - Programs and Features - Turn Windows Features on and off.MVP Exchange Server from Russia http://msexchangeexpert.ru Please sorry for my English, it's not my native language.

Please see this update from the Exchange team. They are very much aware of the issue and working within Microsoft to get it resolved. http://blogs.technet.com/b/exchange/archive/2011/09/09/exchange-2007-or-2010-emc-might-fail-to-close-with-quot-you-must-close-all-dialog-boxes-before-you-can-close-exchange-management-console-quot.aspx Mike Crowley | MVP My Blog -- Planet Technologies

Dear ALL See the Link below for more information MSFT is still looking in the matter http://www.windowsitpro.com/blog/tony-redmonds-exchange-unwashed-50/exchange-server/strange-case-ie9-mmc-exchange-light-appears-tunnel-140523 Special Thanks to MR.Tony Raymond how brought this info to us Regards RASA RaSa

I came here to find a solution to this problem because I got tired of using taskmgr.exe to kill mmc.exe, which is what I've been doing before knowing others were having the same issue. I see that there has been no solution since first discovered in March. Well, guess I'll just have to wait a bit (I hope only a bit) longer. John Babbitt - Systems Administrator - Ashland Support Group

To all on this thread: Not sure when MS will resolve this issue, but this IE9 fix for this was proposed back in June by Trevor on Magnus Bjork's blog page: http://mailmaster.se/blog/?p=600 Basically - add https://localhost to the trusted sites in internet options and that should fix the problem until MS does. Had the same annoying issue with EMC and after adding the above - problem solved.

People seem to think this fix will work because they are not performing the correct steps to trigger the problem. Here are EXACTLY the steps to reproduce the problem, 100% of the time: Open Exchange Management Console. Expand Microsoft Exchange On-Premises. Expand Organization Configuration. Select Mailbox. Wait about 2 seconds. The Status Bar should be blank (not "Refreshing..." in the lower left). Make sure you are seeing the Database Management tab. Attempt to close Exchange Management Console. It doesn't matter if you add mmc.exe to Trusted Sites. It doesn't matter if you add about:blank to Trusted Sites. There is nothing you can add to Trusted Sites which will fix the problem when you perform the steps above. People are adding these things to their Trusted Sites, then they are testing by going into Recipient Configuration or Server Configuration or Toolbox. That's not a correct test. You must land on the Database Management tab and allow it to finish refreshing. If you go to any other place, it won't trigger the problem. If you land on the Database Management tab but close EMC quickly before it finishes refreshing, it won't trigger the problem. The https://localhost 'fix' doesn't work in the above situation

Thank you all so much for the continued community efforts on other workarounds, aside from the known Task Manager route. In terms of an update, a fix has been developed and is undergoing testing and various other processes we have to do prior to releasing updates. The work is being carried out by the IE team and as soon as we can provide information on a release date we are confident with, we'll post again. Regards MarkMark Feetham Senior Program Manager Internet Explorer Product Quality

Thanks for the update Mark. Hope this gets rolled out soon, been 6 months since the original poster.Stew

Which is what I meant - ESC has got nothing to do with it.

I don't think I've ever seen a thread where people have gone around in circles so many times, "it's this", "no it isn't", "it's this", "no it's not". Accept the reality... you cannot fix it without a bug fix from Microsoft... Must be some side effect of us all working as troubleshooters.

I have tested it and it does not close the EMC after you follow the above-cited procedures. I hope to get a fix because I am do not want to uninstall IE9, if indeed it is true that uninstalling it fixes the problem.

Hi Scott, only a reminder. Another 6 weeks without any usefull information or a working bugfix. Regards

I read many persons ask about this issue, i think first times that is a mistake and i leave "some" dialog boxes opened, but i'm tired about this issue, OF COURSE all the dialog boxes are properly closed, but reading about there is a misconfiguration when IE9 is installed NOT JUST the beta or RC all the versions of IE9 causing this conflict, i just solve Loging Out the server and Login In again. This is the better way to prevent damages to the MMC, i repeat is the only way i learn as MSFT not have some Hotfix to solve. Best regards Emilio WildeEmilio I. Wilde

Fix now available: http://blogs.technet.com/b/exchange/archive/2011/10/17/a-fix-for-the-interoperability-issues-between-exchange-2007-and-2010-emc-and-ie9-is-now-available.aspx

One behalf of all of us that have worked on this issue at Microsoft, thank you for bringing this to our attention and for patiently waiting for the hotfix. The above referenced post from my colleague Nino Bilic describes how you can get KB 2624899 if you seek an immediate resolution to this behavior. Regards. Mark Mark Feetham Senior Program Manager Internet Explorer Product Quality

Thank you all at Microsoft for this fix! Here's where you can find a link to page where you can order the hotfix without having to call Microsoft PSS: http://www.expta.com/2011/10/fix-for-you-must-close-all-dialog-boxes.htmlJeff Guillet, MVP, MCITP:Enterprise Messaging Administrator, MCSE, CISSP | http://www.expta.com Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

The only way I have been able to close the EMC is to end the task once, Ignor the message then end the task again. I know it's not the safest thing to do, but I don't always have the option of logging off the PC. I really wish this would get resolved quickly./Mike.Grimmer

Also: If you have a premier support contract (as my company does) or a contract that includes access to a TAM, said TAM can also get you the links for the downloads as well. I'll be setting up some quality time during our next schedule maintenance to install these on our environment along with other patch updates in general for the 4 servers I have that are affected.

I read many persons ask about this issue, i think first times that is a mistake and i leave "some" dialog boxes opened, but i'm tired about this issue, OF COURSE all the dialog boxes are properly closed, but reading about there is a misconfiguration when IE9 is installed NOT JUST the beta or RC all the versions of IE9 causing this conflict, i just solve Loging Out the server and Login In again. This is the better way to prevent damages to the MMC, i repeat is the only way i learn as MSFT not have some Hotfix to solve. Well, I have this issue also, but never posted on this thread. Your suggestions do not work for me as well for some other persons i spoke too. I am sorry. kind regards, dutchfish