Hi, Axel from the IE Escalation team again with a quick note on how to use a Microsoft Fix IT to remove IE 8 silently.

First, I would like to thank the “Fix IT” team for quickly answering my questions about the tools functionality!

When I first learned of the Microsoft Fix ITs being available, I wondered if they could be run silently.  The ability to use the tool silently can be a great advantage and appeals to a large IT community allowing these fixes to run without requiring user intervention - in other words, no prompts.  Luckily for us, Fix ITs are .MSI packages and so we can take advantage of the command line arguments available to accomplish our task!

I tested my theory using the IE Fix IT package that uninstalls IE8, and it works just fine!

You can download the IE 8 Uninstall Fix IT tool from KB957700!

Steps:

1. Open a cmd and change directory to %windir%\system32
2. Then type “msiexec /i uninstallie8.msi /quiet”

Note:  Please remember to remove the quotes from the command line above.  When executing from Vista, you should open the cmd window using elevated privileges! 

MSIEXEC Switches

  NOTE:  You can get the list by typing msiexec /? from command window!

More MSIEXEC Documentation:

Standard Installer Command-Line Options

• http://msdn.microsoft.com/en-us/library/aa372024(VS.85).aspx

Related Article:

• How to solve Internet Explorer 8 installation problems

Enjoy!

The IE Support Team

Hi Folks!

Here’s another IE behavior that we thought you might find interesting…

Scenario:

IE makes a request and receives an HTTP response with the "Content-Disposition: attachment" header specifying a filename that includes non-ascii characters. For example, using %XX to encode UTF-8 representations of a Japanese filename. The client has checked "Always send URLs in UTF-8," so the filename is displayed properly, and properly saved if you choose to save it. However, If you choose to Open the file (for example, opening a .csv file in Excel), the filename that Excel uses contains the garbled (%XX) representation of the characters. 

But why?!

In this scenario, the application IE uses to Open the file (in this case, Excel) actually opens the cached file that IE creates when downloading the HTTP response. When IE creates the cached file, if there is a Content-Disposition header and the filename parameter is used, IE simply uses the text from the HTTP header to set the cache filename.  So while it may seem like bad behavior, it’s actually by design!

Regards,

The IE Support Team

Hi everyone!

As many of you know, with the release of Internet Explorer 7, Microsoft made some changes to how IE7 uses FTP.  It’s outlined in this KB article, Separation of Internet Explorer 7 from the Windows shell (KB928675).  Since then, I’ve seen “mixed results” about the changes. 

Recently, an IE Support Engineer was helping a customer with an issue resulting from these changes.  In the end, a solution was provided to the customer forcing Windows Explorer to be the default handler for FTP.  Some subtle manipulation of the registry was all it took and it seems to have satisfied the customer:

BEFORE (32bit)

[HKEY_CLASSES_ROOT\IE.FTP\shell\open\command]

@="\"C:\\Program Files\\Internet Explorer\\iexplore.exe\" %1"

[HKEY_CLASSES_ROOT\IE.FTP\shell\open\ddeexec\Application]

@="IExplore"

AFTER (32bit)

[HKEY_CLASSES_ROOT\IE.FTP\shell\open\command]

@="C:\\Windows\\explorer.exe %1"

[HKEY_CLASSES_ROOT\IE.FTP\shell\open\ddeexec\Application]

@="Explorer"

With these changes in place, Windows Explorer is set as the default handler for FTP, removing the need to go through IE7 for FTP requests.  Now, we haven’t run this through any kind of regression testing.  We are simply offering this as an alternate solution if you are seeing issue when using FTP with IE7 or later.

If you plan to cut/paste FTP URL strings into IE7 (or later) address bar, you may still need to have this registry key set to enabled:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_INTERNET_SHELL_FOLDERS]
"iexplore.exe"=dword:00000001

Regards,

The IE Support Team

Hi everyone!

Veena again, back with a discussion on session management in IE8. Many application developers expect that they lose their session when they close the IE window. So when the user launches a new instance of IE, they expect that the user is shown the login screen. However, to their surprise, this doesn’t happen automatically with IE8. IE8 is actually behaving as expected and I will attempt to explain why.

Relying on closing the window to clear the session is not a recommended way to implement proper logoff for an application. Because this clearly will not work if there is another window that is sharing the session. This has been the behavior always although our mechanics for which windows share a session has changed in IE8. For example, in IE6 and IE7, there were several ways to launch new windows, some of which gave you a new session, others of which did not.

Click IE shortcut from desktop, start->run -> New Session

• Run iexplore.exe -> New Session
• Click File->New Window -> Same session
• Click “Open link in new tab” (IE7) -> Same session
• Click “Open link in new window” ->  Same session
• Window.open() ->  Same session

As you can see, even in IE7, closing the browser window does not guarantee that your session and credentials would be destroyed.  As you may already be aware, many architectural changes were put into IE8. One such change, was to unify the session model and improve performance.  For More information please review MSDN IE Blog Title: IE8 and Reliability - http://blogs.msdn.com/b/ie/archive/2008/07/28/ie8-and-reliability.aspx.

So what if I want the old behavior back?  Well, there are three ways available:

• Registry key
  HKCU\Software\Microsoft\Internet Explorer\Main\FrameMerging
  0 - disable frame merging
• Command-line switch : If the application is being launched via a desktop shortcut, the command line switch “-noframemerging” could be added to that to get the desired effect.
• Example: "C:\Program Files (x86)\Internet Explorer\iexplore.exe" -noframemerging
• Menu item (“File->New Session”)

In summary, having the user close the browser window has never been sufficient to ensure that the session is destroyed. If the user had another window open in the same session, then that window would still effectively be logged in. However, if the user clicks “Log off” in the application before closing the window, the application CAN clear any credentials in the session, either by deleting session cookies (if that’s the authentication mechanism), or by deleting all of the credentials in the session via document.execCommand(ClearAuthenticationCache, false). If the application code does this, the user will not need to close the window to complete the logging out process. So next time they browse to it in another window that’s sharing the session, they should see the login screen as expected.

For more information on Frame Merging, click here.

Regards,

The IE Support Team

Hello there!

My name is Joel Baxter.  I am Senior Support Escalation Engineer on the IE Support Team.  Today I’d like to discuss a recent issue that affects both Internet Explorer 7 and Internet Explorer 8 was uncovered during a recent support call.  The behavior manifests itself as a misleading information bar (aka 'gold-bar') notification which infers a problem with security settings:

IE7

Your security settings do not allow websites to use ActiveX controls installed on your computer.

This page may not display correctly.  Click here for options...

IE8

An add-on for this website failed to run.  Check the security settings in Internet Options for potential conflicts.

There are other causes for this dialog to appear but the one that very few will associate with it has to do with the way the control was signed.  No amount of security zone setting configuration will prevent this dialog from appearing, while still loading the control.   To make matters more confusing, you may have Windows XP clients running IE7 or IE8 that do not display this message when working with the very same cab files!

When the control fails, a log is generated in the Temporary Internet Files folder, named ?CodeDownloadErrorLog!name={the_failing_object_clsid}.htm    The log, when opened, will identify the class ID associated with the failure as well as the HResult error returned:

*** Code Download Log entry (19 May 2009 @ 11:21:00) ***

Code Download Error: (hr = 800b010b) Generic trust failure.

Operation failed. Detailed Information:

     CodeBase: http://mysite/myIE.cab

     CLSID: {12345678-ABCD-12AB-34CD-123456789ABC}

     Extension:

     Type:

LOG: Reporting Code Download Completion: (hr:800b010b (FAILED), CLASSID: 12345678..., szCODE:(http://mysite/myIE.cab), MainType:(null), MainExt:(null))

--- Detailed Error Log Follows ---

LOG: Download OnStopBinding called (hrStatus = 0 / hrResponseHdr = 0).

LOG: URL Download Complete: hrStatus:0, hrOSB:800b010b, hrResponseHdr:0, URL:(http://mysite/myIE.cab)

LOG: Reporting Code Download Completion: (hr:800b010b (FAILED), CLASSID: 12345678..., szCODE:(http://mysite/myIE.cab), MainType:(null), MainExt:(null))

In the log sample above, the cab package myIE.cab failed due to a failure logged as HResult 800b010b, which translates to TRUST_E_FAIL.  When Internet Explorer encounters the TRUST_E_FAIL condition during the download and initialization of ActiveX objects, the information bar message mentioned earlier is displayed.  

You can obtain more information about code download failures from the following Microsoft Knowledge Base article: 

252937  How to find more information about why code download failed

http://support.microsoft.com/default.aspx?scid=kb;EN-US;252937

The problem stems from an attempt by Internet Explorer to validate the trust of an ActiveX cab package that contains Java permissions assigned to it.  These permissions are added during the application of the digital signature through the use of an additional signer library.  The Microsoft signing tools included one such signer named javasign.dll

These attributes are plainly visible on the 'Advanced' tab in the Digital Signature,  Details properties.  In the screenshot provided below, you will notice two attributes included by javasign.dll:  1.3.6.1.4.1.311.15.1 and 1.3.6.1.4.1.311.15.2.   If you are familiar with the object IDs related to Microsoft cryptography, you'd recognize that these are implemented by Microsoft Java.

For those not familiar, you can find them in the Microsoft Knowledge Base:

287547  Object IDs associated with Microsoft cryptography

http://support.microsoft.com/default.aspx?scid=kb;EN-US;287547

The purpose of these attributes is to assign a level of permissions to the Java classes within the package.  When the package was signed, individual properties were assigned by the javasign.dll signer.  The command-line options for Microsoft's signcode.exe utility supported -j to specify an additional signer resource.  In this case, it would have been -j javasign.dll and the -jpswitch allowed the user to assign specific parameters to be used with the DLL referenced with the -j switch, such as LOW, the Java security level associated with the package.

When these attributes are present on a CAB file, Internet Explorer identifies that the OID refers to a Microsoft Java object.  Even though the contents are an ActiveX component, Internet Explorer follows the OIDs and expects the Microsoft JVM to handle the trust checking.  With no Microsoft JVM installed to validate the digital signature on the CAB, the component fails to initialize and run.  Clients with non-Microsoft Java runtime environments installed cannot complete this validation task.   This is why any machine that still has the Microsoft JVM installed can get the control initialized.

Ultimately, the solution to this problem is to resign the ActiveX packages that were signed in this manner.  Javasign is used for Microsoft JVM components, not ActiveX controls.  Simply omit the "-j javasign.dll -jp <parameter>" from your signing process and you should be able to install and run your objects without this error appearing, provided that the client security settings permit them!

Well that’s all for now.  I hope this information was informative and useful.

Regards,

The IE Support Team

Hello There!

Veena here to discuss an important change made in Internet Explorer 8 that could impact you. With Internet Explorer 8 it is no longer possible to load .NET controls in Internet zone under the default(medium-high) security setting.

In Internet Explorer 8, we have added a new UI-less URLAction (0x2005) that we check before loading the .NET MIME Filter, mscorie.dll,  for content from the Internet zone. And by default it is set to DISABLE in Medium-High/High templates which are the default security templates used by Internet Zone and Restricted Sites Zone respectively. This URLAction is enabled by default in the other security zones.

This change prevents the loading of mscorie.dll for a .NET control on a page, if that control's URL has a "DISABLED" policy for the new 0x2005 UrlAction. Please note that this URLAction cannot be configured via the Internet options control panel. This change is further discussed here.

Mscorie.dll, contains a Multipurpose Internet Mail Extensions (MIME) Type Filter. This filter hooks into Internet Explorer and monitors all incoming data streams with the MIME type application/octet-stream. A primary role of this filter is to examine the incoming stream to see whether or not the stream is managed code. If the filter determines that the incoming data is a .NET Framework module, the filter loads a managed assembly named IEHost which then handles loading the .NET control. The following KB article discusses this in more detail:

http://support.microsoft.com/kb/311301

If you want to allow loading .NET controls for any web site that is impacted by this change, you can add it to the trusted sites zone. But please note that the site that needs to be added is that of the control and not that of the page. Alternatively, you can set the above URLAction to enable in the registry but please note that this can compromise the security of your system.

Regards,

The IE Support Team

Hello everyone!

My name is Vinod and I am a Support Engineer on the IE Support Team. I wanted to share with you a very interesting issue I worked on recently.

A user installs an ActiveX control from a web site. The web site is updated with a newer version of the control. When the user navigates to the updated web site, he is prompted to install the updated control as expected.

The user then clicks the "Install" button - installation yields no errors.  The ActiveX control appears to load and work fine. But on every subsequent visit to the web site, user is prompted to install the ActiveX control again.

This can happens if the VerCache registry key fails to be updated during the upgrade of the control:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{D7D5ACA4-4C57-4C75-8D68-BC185E924B4C}] "VerCache"

But how can such a thing happen?

This can happen if the old and new versions of the control have the same “Created” date time stamp, “Modified” date time stamp and the file size, for example:

Here in the above mentioned screenshots they both are having same file date time stamps and that Causes the VerCache registry key to not get updated.

To resolve this , ensure that at least one of these parameters - “Created” date time stamp, “Modified” date time stamp or the file size, on the updated control is different from the old version of the control and you should be GTG!

Regards,

The IE Support Team

Hi Everyone!

Bac again with an interesting issue in IE8.  As everyone is aware, F12 is a keyboard shortcut to bring up the Developer Tools in IE8.  Due to application compatibility reasons, one may want to cancel this default behavior to handle his/her own actions.  The following code snippet has been floating around the Internet showing how to cancel this key:

function CancelF12()

{

     var KeyAscii = window.event.keyCode;

     if (KeyAscii == 123)

    {    

        window.event.returnValue = false;

        window.event.keyCode = 0;

    }

}

The above technique works great most of the time.  Last week, we came across a situation where the above code breaks.  Conditions contributing to the failure include:

1. ShowModalDialog() is involved

2. The code must be run in the Internet zone (or Restricted sites zone)

Note the security zone is important here.  The problem goes away if the code is executed in either the Local Intranet or Trusted sites zones.

Repro Steps:

1) Construct test.html and modal.html pages with the following code:

Test.html:

<html>

<body>

<input type="button" onclick="window.showModalDialog('modal.html');" value= "click me">

</body>

</html>

Modal.html:

<html>

<head>

<title>Modal</title>

</head>

<script>

function CancelF12()

{

                       var KeyAscii = window.event.keyCode;

                       if (KeyAscii == 123)

                       {

                                      window.event.returnValue = false;

                                       window.event.keyCode = 0;

                       }

}

</script>

<body onkeydown="CancelF12()">Try pressing F12</body>

</html>

2) Click the button and press F12

After spending some time debugging, the problem turns out to be this setting in the Internet security zone which causes the code to break:  Allow websites to open windows without address or status bars.  It’s disabled by default in the Internet zone, while enabled in both the Local Intranet and Trusted sites zones.  We don’t recommend customers to change the security setting in the Internet zone as that may compromise the security feature set for the entire Internet URL’s.  A better option would be to add that particular URL to the Trusted Sites zone:

That’s all for now.  Thanks for reading this blog post!

Regards,

The IE Support Team

Hello there!

I recently worked on customer issue in where a behavior change was noted after upgrading to Internet Explorer 8.  The issue deals with clients certificates no longer displaying in the IE client certificate display list dialog when connecting to a Web Server that requires a client certificate for secure communication (connecting over HTTPS using SSL).

The customer noted that using IE6 and IE7, the client certificates would display in the client certificate display list dialog:

Please note:  Client certificates were removed from the above image to protect the innocent and the guilty.  :)

Upon initial view of the behavior, it seemed that Microsoft had regressed a behavior found in IE6 and IE7.  However, upon further review, it was determined that the behavior seen in IE8, is actually a “by design” change for IE8 and Windows 7:

It was determined that expired certificates showing up in the IE client certificate display list dialog was a high pain point for customers. This was due to users picking the wrong certificate and thereby failing to authenticate when the set of certificates a user could select from contained both valid and expired certificates.

Fortunately, you can revert back to the IE6/IE7 behavior by adding the below registry key to IE client machine:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl]

"Feature_ClientAuthCertFilter"=dword:00000002

Please note:  The above Feature control key uses and older method and so you cannot set this FCK, per process.  The registry key needs to be set in the following manner (the above key value should work under HKCU, as well):

With the registry key added, closing and restarting IE should allow the expired client certificates to be displayed when connecting to the Web Server requiring client certificate authentication.

Well, that about wraps it up for this blog.  I hope it was helpful to you!

Kindest Regards,

The IE Support Team

Hey Folks, just a real quick post…

We are seeing some issues coming in with customers wanting to centrally manage the “Safe Search” option that is part of the Microsoft “bing” site:

Unfortunately, this option cannot be managed by IE or via some kind of Group Policy.  The interface is strictly controlled and managed within the site itself.

Please note:  If you are using Bing from India, for example, you are unlikely to see the site’s “Safe Search” setting option. The current work around for this is to click on the country name at the top right and pick choose another nation from the list that is now displayed:

Cheers!

The IE Support Team

Hi everyone!

We’ve got an emerging issue showing up in our support channels in where IE printing functionality (printing, print preview) fails on the Windows XP operating system.  This issue is specific to IE7 and IE8 and we have only reproduced the issue with service pack 3 installed, thus far, but we certainly aren't ruling out other platforms that can install and run either of these revisions of IE.

The behavior is easily recognizable as you will see a blank screen within the print preview dialog instead of the page to print out.  Furthermore, if you try and actually print the page, nothing happens and the page does not print out.

Please note:  Some user have noted seeing this behavior after installing the latest IE cumulative update, KB969897.

In troubleshooting this behavior, we have found that uninstalling the Microsoft Software Inventory Analyzer software, via Add or Remove Programs option in Control panel, resolves these printing functionality issues.  This is our recommendation.

Deeper troubleshooting of this issue indicates a registry key added by the Microsoft Software Inventory Analyzer, may be the root cause of the failure.  The registry key in question is seen below:

[HKEY_CLASSES_ROOT\.dlg]

@="MsiaUtils"
"Content Type"="application/msia-dlg"

Removal of this registry key also seems to resolve the printing functionality issues within Internet Explorer.  However, if you are not proficient at using the registry editor tool, we do not suggest using this method but instead suggest that you simply uninstall the Microsoft Software Inventory Analyzer software.

You can also remove the extension type via Explorer:

1.  From the Windows desktop, double-click on My Computer.
2.  Click on Tools and then Folder Options from the menu.
3.  Click on the File Types tab within the Folder Options dialog.
4.  Within the Registered file types listing, find the DLG extension.
5.  Highlight and then click the Delete button and then choose Yes to remove.

Please note:  This tool is not supported by Product Support Services.

We have some new information coming in that the inclusion of this key seems to be effecting the rendering of text inside CSS styled textboxes.  Applications, for example WordPress, may be negatively affected as well.

UPDATE! 

We’ve been working directly with the MSIA team and they have informed us that they will be making a code change to the product to help resolve this issue.  More detail on the availability of this update can be found here.  The MSIA teams also suggests that instead of just removing the above values from the registry, that users install, use, and then uninstall the MSIA tool to mitigate the app-compat issue with IE.  This is because removal of the registry information can cause certain areas of the MSIA tool to fail, such as the feedback and licensing display forms.

Regards,

The IE Support Team

Hi everyone!

Well, we’ve come across another behavior that some of you are running into so we thought it was time to do a quick write up on the behavior and why it has changed.  The behavior is a little complicated if you are real savvy with how IE makes connections using the HTTP protocol.  Hopefully, we can give you an overview of the behavior that won’t bore you to tears!

:)

Starting with IE7, a behavior change has been made in how IE handles Server certain response codes to web browser connections that originate as a CONNECT request.  Specifically, if a CONNECT request is made by IE to a Web Server and it receives a Server response to that CONNECT request with something other than 200, IE could reject that response as invalid (ERROR_HTTP_INVALID_SERVER_RESPONSE). 

Below is an example of what you might see when connecting to a secure web site with IE using an initial CONNECT with a Proxy Server in between the IE client machine and the Web Server you are connecting to:

CONNECT www.MyTestSSLSite.com:443 HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Proxy-Connection: Keep-Alive
Content-Length: 0
Host: www.MyTestSSLSite.com
Pragma: no-cache

HTTP/1.1 200 Connection established
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Via: 1.1 MyTestProxyServer

This is a working example because the Server response to the CONNECT request is a level 200 response code which means the CONNECT request by the IE client has been honored.

Of course, this isn’t the scenario in where IE fails to honor the Server response.  Failure cases we see are when a Proxy Server returns a Server response code other than the expected 200, as seen above.  This can happen for several reasons and is often done purposely by Proxy Server.  The below response, for example, will indeed be rejected by IE is connecting to a Web Server, through a proxy, where a CONNECT request would be used to make the initial secure HTTP connection:

CONNECT www.MyTestSSLSite.com:443 HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Proxy-Connection: Keep-Alive
Content-Length: 0
Host: www.MyTestSSLSite.com
Pragma: no-cache

HTTP/1.1 302 Redirected
Date: Wed, 17 June 2009 14:21:38 GMT
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Location: http://10.1.0.5/MyTestRedirectPage.html

As you can see in this second example above, the Server response code is now a 302 instead of the 200 expected by IE.  This Server response is telling the IE client to redirect it’s request to a different site than it made the initial CONNECT request to.  Allowing this Server response to be honored by the IE client would be risky because the Proxy Server could return content that IE would interpret as being from the origin server, which Microsoft sees as an unsecure scenario and so honoring the 302 response in this scenario is no longer allowed. This change in behavior doesn’t mean that all Server responses which are not 200 are rejected.  Support for 400-level response codes are still valid and honored in the above scenario.

Please note:  You can see HTTP protocol traffic  using an HTTP tracing tool such as Fiddler or a network analyzer tool such as Microsoft Network Monitor.  Of course the CONNECT request is setting up a secure HTTP connection and so further traffic will be encrypted.  A debug version of wininet.dll can allow you to view encrypted HTTP traffic via the wininet log it can generate.

Well hopefully this blog was more entertaining that fingernail scratches on a chalkboard – until next time!

Regards,

The IE Support Team

Hi everyone!

Axel here from the IE Escalation team with a scenario related to  Security Warning - Unknown Publisher pop-up when executing a file that came from a non trusted source.

I am sharing this out because the immediate assumption is that by just adding the server name to the Local or Trusted Site zone will allow the file to be executed, which is not accurate. Once the file comes down from the untrustedsource and with the Block file stream (see Fig. 1.1), until you remove the attribute you wont be able to run it without first getting the warning mentioned in this blog, see fig. 1.0.

Fig. 1.0 [Screenshot of the Warning with the checkbox “Always ask before opening this file” option]

Fig. 1.1 [Screenshot of the executable properties, showing the Security Unblock option]

Here is what it may look like once you have unchecked the option next to “Always ask before opening this file”.

Fig. 1.2 [Here is what you will still get, even after you have removed the checkbox]

Once you add the unc path to either the Local or Trusted Sites Zone, you will no longer get the warning.

In the above example, we can see that the application did not have a digital signature that verifies its publisher, so we will have to do more work to bypass the warning. You can either have the executable signed using signcode.exe or use the Build in Windows Attachment Manager Policy.

The reason why you get the warning in the first place is because in Windows XP/SP2 and Windows 2003/SP1 we have introduced a new feature called Attachment Manager. This feature was added to help protect your computer from unsafe file attachments. This include accessing files across your network (e.g \\servername\share), files that you might receive with an e-mail message and from unsafe files that you might save from the Internet.

If the Attachment Manager identifies an attachment that might be unsafe, the Attachment Manager prevents you from opening the file, or it warns you before you open the file.

Here are the steps to bypass the warning using Attachment Manager Group Policy. I am also including the registry key modified by the policy.

From Start Run type: gpedit.msc

From User Configuration> Administrative Template> Windows Components> Attachment Manager

Set the following:

Configuration Settings:

> Default risk level for file attachments: Set it to Enabled and Set the default risk level to[Low Risk]

> Inclusion list for low file types: Set it to Enabled and add the file extension [.exe;.vbs;.msi]

> Do not preserve zone information in file attachments: Set it to Enabled.

Close Gpedit.msc and run gpupdate /force

Screenshot of the policy:

Final Step:

> Add the UNC to Local Intranet or Trusted Sites

> Log off and log back in

> Test accessing the UNC share

Registry keys:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Associations]

"LowRiskFileTypes"=".exe;.vbs;.msi"

"DefaultFileTypeRisk"=dword:00001808

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments]

"SaveZoneInformation"=dword:00000001

Article below explains everything about Attachment Management.

• 883260  Description of how the Attachment Manager works in Windows XP Service Pack 2        http://support.microsoft.com/default.aspx?scid=kb;EN-US;883260
• How would you sign your file. You could use signcode.exe from Microsoft. Here is also an article:
• Steps for signing a .cab file: http://support.microsoft.com/default.aspx?scid=kb;en-us;247257

Regards,

The IE Support Team

Hi Everyone!

Axel Rivera again from the IE Escalation team with another IE Enhanced security topic for your viewing pleasure!

UPDATE: I have tested the .exe and .bat file that will disable IE Enhanced Security for both Windows 2003 and Windows 2008 TS Servers. The key is that you have to execute the files while logon with the problem user.  Basically, once your user have these setting on their profile, the only way to remove it is to either Delete the profile and let it re-create again from a fixed profile or execute the fix mention in this article.

In this Blog I would like to share a batch file I use to help disable IE Enhanced Security silently on Windows 2003 servers.  The challenge is that if you have multiple servers, removing it from server console is not practical and can require tremendous administrative overhead.

Please note:  This is the the same task can be achieved from the Windows Add Removed Programs User Interface on Windows 2003 server and From Windows 2008 Server Manager Console!

Cut and paste the lines below into notepad and save the file as "DisableIEES.bat".  This will create a simple batch which can be used to disable IEES (IE Enhanced Security) or download it  here!

Here is where you can set the login script in a policy:

> From Start\run type: gpedit.msc

> From User Configuration

   > Windows Settings

      > Scripts(logon\logoff)

         > Select Logon

            > Click on the Add... btn

            > Click on the Browse... bnt

            > Navigate to the directory where you have the file I sent you (EXE or BAT)

               [You can copy the file to the default Logon script directory: %windir%\system32\grouppolicy\user\scripts\logon]

            > Apply and OK btn to complete

> Close GPEdit.msc

> Start\run type: gpupdate /force to update the policy

> Login with a profile you know have the problem and see if this takes care of the problem.

More information:

There are two parts to turning off IE Enhanced Security.

We need to first identify the registry keys used to change the IE Enhanced Configuration Settings.

Here are the keys as a .reg export format:

Here is the command I use to turn off IE Maintenance using the IEHarden.inf file:

After you execute the batch file from an existing user profile, you should consider logging out and login back in to make sure the changes take effect.  New users should now have IE Enhanced Security disabled.

Disabling IE Enhanced Security from Windows 2008 Server

To enable or disable IE ESC for all users that log on to the computer

• Close Internet Explorer.
• Open Server Manager. Click Start, point to Administrative Tools, and then click Server Manager.
• If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.
• Under Security Information, click Configure IE ESC.

Note: Server Manager opens with the same window that was in use when it was last closed. If you do not see the Security Information section, click Server Manager in the console tree.

• To disable IE ESC, click Off under both Administrators and Users, and then click OK. [ If when you are viewing the Internet Settings you see that the Security Zones are still gray-out enable IE ESC again and Disable it to make sure these settings takes effect. Internet Explorer should be closed When making these changes ]

Note: If Internet Explorer is open when IE ESC is enabled or disabled, you must restart Internet Explorer for the IE ESC changes to become active.

Regards,

The IE Support Team

Hi Everyone!

Axel again, from the IE Escalation team, with another Group Policy pointer.

Recently, I was asked to assist in disabling DEP (Data Execution Prevention) for Internet Explorer. This can be done from Group.  The policy will allow you to turn off the Data Execution Prevention feature that is now on by default when you install Internet Explorer 8. There are good reasons why this is turned on by default and you should read about it here before making a conscious decision to turn it off with this policy.

Policy description:  This policy setting allows you to turn off the Data Execution Prevention feature for Internet Explorer on Windows Server 2008, Windows Vista SP1 and Windows XP SP3.

If you enable this policy setting, Internet Explorer will not opt-in to Data Execution Prevention on platforms that support the SetProcessDEPPolicy API.

If you disable or do not configure this policy, Internet Explorer will use the SetProcessDEPPolicy API to turn on Data Execution Prevention protection on platforms that support the API.

This policy has no effect if Windows has been configured to enable Data Execution Prevention.

Location: Computer Configuration > Internet Explorer > Security Features > Turn off Data Execution Prevention

Screenshot of the policy:

More information:

1. IE8 Security Part I: DEP/NX Memory Protection: http://blogs.msdn.com/ie/archive/2008/04/08/ie8-security-part-I_3A00_-dep-nx-memory-protection.aspx
2. How do I improve my website and add-ons?: http://www.microsoft.com/windows/internet-explorer/readiness/developers-existing.aspx

Regards,

The IE Support Team

Hi Everyone!

Just wanted to let everyone know that a FixIT is currently available to help users protect themselves against this latest ActiveX Control vulnerability outlined here:  http://www.microsoft.com/technet/security/advisory/972890.mspx

The FixIT, when run, will automatically disable the Microsoft Video ActiveX Control.  More information, as well as the FixIT files themselves, can be found here:  http://support.microsoft.com/kb/972890

Related Article:

• Quick and dirty Group Policy ADM template to implement the workaround from KB972890
• How can I run a “Fix IT” silently?

Regards,

The IE Support Team

Hey folks!

We’ve received many many requests asking if the workaround mentioned in KB972890 can be implemented via Group Policy.  To that end, we’ve put together an ADM template to help Domain Admins roll this out through Group Policy.  It’s an “as is” template, so feel free to tweak it as needed.

Important: This policy requires that you disable filtering in the group policy editor. See steps below on how to set this up.

How to load the Custom ADM Template?

1. To start Group Policy, click Start and then click Run. In the Open box, type GPEdit.msc or GPMC.msc if from a Domain policy and then click OK.
2. Select Administrative Templates from the Computer Configuration branch.
3. Right-click the Administrative Templates branch, and then select All Tasks.
4. Select Add/Remove Templates.
5. Click Add.
6. Load the ADM templates.
   

NOTE: Windows 2003, Windows XP will display the policy under: Administrative Templates > New Polcy

Here is how you disable the Group policy filer:

1. Right click on the Policy and select View > detail > Filtering
2. Remove the checkmark from the checkbox next to "Only show policy settings that can be fully managed"
3. You should see the template now.

Please see the attached file below that contains the ADM templates.

Note:

We have updated the template base on some great feedback from our readers. When the policy is enable will set the value to hex 1024  and when disable to 0.

In the Zip file [ADM_KB972890_v_07-09-09.zip], you should find:

1. The IE 32 bit custom adm version: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility]
2. The IE Wow6432Node (x64) custom adm version: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility
3. The registry export (.reg) export for both IE 32 bit and x64 IE version.
4. Readme.txt with our Registry import disclaimer.

Related Article:

• FixIT available for the vulnerability in the Microsoft Video ActiveX Control, Microsoft Security Advisory (972890)

Regards,

The IE Support Team

Hi everyone!

We’ve had some requests come in asking for an ADM template that would give Administrators the option to Enable or Disable the “Check for publisher's certificate revocation” Internet Explorer option.  In any event, here it is.  Simply cut/paste the content below into a file with .ADM extension and then add custom template manually:

CLASS USER
CATEGORY "Windows Components"
CATEGORY "Internet Explorer"
CATEGORY "Internet Control Panel"
CATEGORY "Advanced Page"
POLICY "Check for publisher's certificate revocation"
KEYNAME "Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing"
EXPLAIN "Custom ADM template to Enable/Disable the IE advanced option, “Check for publisher's certificate revocation”"
PART State DROPDOWNLIST REQUIRED
VALUENAME "State"
ITEMLIST
NAME Enabled VALUE NUMERIC 146432
NAME Disabled VALUE NUMERIC 146944
END ITEMLIST
END PART
END POLICY
END CATEGORY
END CATEGORY
END CATEGORY
END CATEGORY

Please note:  You will need to disable the Group Policy filter option, “Only show policy settings that can be fully managed”, before the custom ADM template policy will be displayed:

Well, that’s all for now!

Regards,

The IE Support Team

Hi everyone!

Here’s a quick blog to help users and administrators by-pass that initial web page asking you to save your settings after IE7 is installed…

After installing Internet Explorer 7 all users are supposed to save their settings, the IE automatically redirects the page to "http://go.microsoft.com/fwlink/?LinkId=74005" which redirects to "http://runonce.msn.com/runonce2.aspx" till the user saves the settings to set their preferences such as the default search engine, whether turn on automatic Phishing Filter, language settings and so on.

If the customer does not want to be auto-directed to this web page, then they need to follow the below steps.  Two values should be added/modified in the registry, so that IE 7 will go to the home page instead of the external link above:

1. Open the regedit.exe applet.
2. Go to registry key:
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
3. Right-click this key and select New -> DWORD Value.
4. On the right pane, create the new value to RunOnceComplete.
5. Right-click RunOnceComplete and click “Modify” and set the value data to 1.
6. Repeat Step 3 to Step 5 to create/modify the value name RunOnceHasShown and set the value data to 1.
7. Restart the IE 7 to see if it still visits the Save settings web site.

If you are familiar with using .REG files, then you can use what’s below to create one and use:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
"RunOnceComplete"=dword:00000001
"RunOnceHasShown"=dword:00000001

Please note: IE7 will query the two values RunOnceComplete and RunOnceHasShown every time it starts. If these values have been set as depicted above, IE will visit the home page set in the IE control panel.

For terminal server, you can set a log-on script, so that these two values will be added and set automatically when users connect to the server.

Regards,

The IE Support Team

Hi everyone!

Veena here to discuss an issue that might affect developers using Visual Studio 2005 to perform client side script debugging.

After you install Internet Explorer 8, you may no longer be able to perform client side script debugging using Visual Studio 2005. This issue is discussed in http://blogs.msdn.com/greggm/archive/2009/04/01/script-debugging-broken-in-vs-2005-after-installing-ie8.aspx.

Typically, setting the registry value : TabProcGrowth to a DWORD value of 0 is sufficient to resolve this problem.  However, if you are using Windows Vista, you need to follow ALL of the steps below to resolve this issue:

1) Install VS 2005 update for Vista from http://www.microsoft.com/downloads/details.aspx?FamilyID=90e2942d-3ad1-4873-a2ee-4acc0aace5b6&displaylang=en.

2) Install Visual Web Developer express from http://www.microsoft.com/express/vwd/Default.aspx.  This is to update PDM.DLL to the required version.

Please note:  You don't need to actually use it and can remove it after it is installed. Visual Web Developer express is the free Express SKU for VS2008.

3) Set the registry value : TabProcGrowth to a DWORD value of 0 under HKCU\Software\Microsoft\Internet Explorer\Main.

4) Run Visual Studio 2005 with elevated permissions.

Please note: This is a problem in Visual Studio 2005 and doesn’t happen with Visual Studio 2008.

Regards,

The IE Support Team