Hi everyone!

Axel here from the IE Team with a quick Group Policy ADM template to help implement workaround described in security advisory 973472. I am also including the .reg file and .adm templates for both x86 and x64 versions.

Please note:  This is 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.

Please note: Windows 2003, Windows XP will display the policy under: Administrative Templates > New Policy

Here is how you disable the Group policy filer:

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

x86 ADM Template

x64 ADM Template

x64 Registry key

x86 Registry key

We also have the above samples available to download here.

Regards,

The IE Support Team

Hi everyone!

IE Support is seeing a huge influx of issues with weird IE behaviors and failures coming in over the last two days.  We are seeing IE crashes, IE simply unloading from memory, and even script errors on web application that have been working in the past without issue.  Currently, we are only seeing these errors with Internet Explorer 7 and 8.

The issue appears to be related to a recent signature update to McAfee’s Host Intrusion Prevention software that was released on July 14, 2009.

If you are seeing these kinds of behaviors with Internet Explorer since in or around the July 14th, 2009, we recommend that you review the details outlined in this McAfee KB article:

https://kc.mcafee.com/corporate/index?page=content&id=KB66316

Our understanding is that a signature update has already been released to resolve this issue.  However, if you need further assistance from McAfee technical support in getting the signature update, you can contact them using the information located here:

http://www.mcafee.com/us/about/contact/index.html

More information:  You can continue to browse in a limited capacity by starting Internet Explorer in No Add Ons mode by using the shortcut located under All Programs | Accessories | System Tools until you update the affected signature file:

There is also a command line option you can use as well.  From a command line window you can using the below option:

Once you hit enter, IE will load with no Add Ons within the IE process:

Regards,

The IE Support Team

Hi everyone!

We’re seeing another emerging issue around Internet Explorer that we wanted to make you aware of…

If you are seeing slow performance within Internet Explorer 8 (opening new tabs, for example), after just recently installing the latest version of the Skype application (v4.1), this could be the cause.  We believe the reason behind this performance issue is an IE add-on that gets installed by the latest revision of the Skype software.

To resolve this issue quickly, please open Managed Add-Ons and disable the installed Skype IE add-on:

Please note:  So far, we are only seeing this issue with this specific version of Skype in conjunction with Internet Explorer 8.

Regards,

The IE Support Team

Hi everyone!

Gary Ranne here from the IE Team with a quick tip on how to use Fiddler to identify codebase objects on a webpage.

With the inception of the ActiveX installer service it is even more important to be aware of the location that ActiveX controls are being installed from. Frequently, this can be done simply by viewing the source of the Web page that is loading the control. All we need to do is to look for an Object tag that contains a “codebase” attribute. This “codebase” attribute points to the location that the control will be downloaded from. This works great when the Object is being loaded from the page itself, but it is not uncommon for a control to be loaded from a .js file or a .css file. How can we locate the codebase in these cercumstances?

• Install Fiddler from www.fiddler2.com.
• With Fiddler capturing, navigate to the page that is trying to load the control.
• Once the page has tried to load the control, select all the sessions in Fiddler like so:

• Decode all the selected sessions by right-clicking on the sessions and selecting Decode selected sessions
• Next select the Edit menu / find sessions…
• In the find dialog enter “codebase” and click find sessions.
• This should highlight any sessions that have a codebase attribute within it.
• Select the highlighted session and display the raw tab in the response inspector

• Click “View in Notepad” and then search in Notepad for the codebase.

 Enjoy!

Regards,

The IE Support Team

In this post, I like to share a scenario that you may find when trying to open a procmon pml file that was captured on a 32bit operating system and trying to open it from a 64bit client machine.
 
If you find your self asking someone to gather some process monitor from a 32-bit client machine and once you received it and try to open it on a 64-bit client machine you may experience a little message.

The message may read like this:

This is because, in order for you to open the 32bit procmon capture you need to be using the same version or use the /run32 switch which will allows you to Run the 32-bit version on a 64-bit client machine.
 
NOTE: This process was tested using the Process Monitor V 3.01

How to get to the command Line Options…?

From Process Monitor, select the help menu and click on the Command Line options… submenu

Here are the command line arguments:

Creating a shortcut

You can create a shortcut on your desktop for the next time you may have to review a 32-bit procmon log from a x64-bit client machine.
 
The easiest way is to right click on the Procmon.exe process and select Create Shortcut

Then from the properties of the Procmon.exe – shortcut (right click and select properties) the /Run32 at the end of the target entry.

Now, you can put this Procmon.exe – shortcut wherever you like, to make it easier next time you have to review 32-bit procmon logs from a 64-bit client machine.
 

Hope you enjoy this little trick to help those that may have encounter this scenario before!

This blog has been provided to you by another one of our Escalation Engineers for Internet Explorer, Louis Shanks.

If you are wondering how your local system account is getting proxy settings even though you have applied proxy settings only for users, this post will help you. 

Here you will see the proxy settings set in Local system account:

HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections

The applications which run in system context might stop working if the Local system account contains proxy settings or any undesired settings which are not set by system administrator.

Here is how the user base settings can get written to Local system account registry key.

• IE maintenance GPO
• IEAK also has the same ability to import connection settings and deploy to a client PC.  Once established, the SYSTEM registry profile will be tattooed. 

Here I will discuss about the IE maintenance GPO which causes this behavior.

When you use Internet Explorer Maintenance Group Policy to set user based connections settings, it provides you with two options:

If you choose Connection Settings options to set connection settings for the user, it causes this behavior.

To test it yourself, try setting this GPO in your local computer using Local group policy editor.

• (Run gpedit.msc command to open Local GPO editor)
• User Configuration - Windows Settings - Internet Explorer Maintenance   - Connection    - Connection Settings - choose [Import the current Connection Settings from this machine] and click [Modify Settings]

• Once GPO is applied to the user, check this registry:
  
  HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections

Expected Results:
"Proxy Server" settings of connection should not apply to HKEY_USERS\.DEFAULT. \Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections key.

Actual Result:

 “Proxy Server" settings of connection gets added here: HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections key.

What we recommend:

The respective proxy settings part of IEMaintenance should be used. User Configuration - WindowsSettings - Internet Explorer Maintenance- Connection-Proxy Settings

 NOTE: If you have configured connection settings and then try to click on proxy settings, you are presented with following warning by the policy editor:

It tells you that proxy settings will overwrite the imported connection settings. 

This warning applies to the user scope only.

It is of no use to profiles that are not in scope to receive user-based Internet Explorer policy settings (such as the SYSTEM registry profile). So remember that the system base settings added by connection settings will still exist and user based proxy settings will be overridden.

Once you click on OK, you are presented with the following dialog box:

You can then use following articles to configure proxy settings.

• Configure Proxy Settings, using below TechNet article:
• http://technet.microsoft.com/en-us/library/cc754834(v=WS.10).aspx

If this is proxy settings for a specific dial-up connection:

If it needs to have the same proxy settings as LAN, then DialUpUseLanSettings is the best approach as mentioned in http://support.microsoft.com/kb/839571

• If not, maybe CMAK would be a better approach to deploy that connection

Connection Manager Administration Kit

• http://technet.microsoft.com/library/4a602fd8-0e94-45eb-9b8c-4e674187cf70.aspx

 You can also use PowerShell and GPO.

•  Deploying VPN Connections by Using PowerShell and Group Policy 
• http://technet.microsoft.com/en-us/library/ee431700(WS.10).aspx 
• Provisioning VPN client settings using Group Policy
• http://blogs.technet.com/b/rrasblog/archive/2009/08/31/provisioning-vpn-client-settings-using-group-policy.aspx

I hope this helps and solve the mysterious question of why your local system account gets user based proxy settings.

This blog has been provided to you by Anshu Vashishta, IE Support Engineer.

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 .bat file that will disable IE Enhanced Security for both Windows 2003 / Windows 2008  and 2012 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 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.

Other Related Blog Post:

• How to troubleshoot IE Enhanced Security warning "Content from the website listed below is being blocked by the Internet Explorer Enhanced Security Configuration" ?
• http://blogs.msdn.com/b/askie/archive/2012/09/11/disable-ie-enhanced-security-does-not-work-in-windows-2003-and-2008-remote-desktop-services-terminal-services-host.aspx

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

In this blog, I am sharing the commands available to uninstall Internet Explorer.

Examples covered in this blog are for:

Example for uninstalling Internet explorer 9

• Log on to the computer by using an administrator account or an account that has administrative rights.
• Close all Internet Explorer browser windows.
• Click Start, type cmd in the Search box, and then click cmd under Programs.
• Right click and select Run as administrator
• Copy the following command:

FORFILES /P %WINDIR%\servicing\Packages /M Microsoft-Windows-InternetExplorer-*9.*.mum /c "cmd /c echo Uninstalling package @fname&& start /w pkgmgr /up:@fname /quiet /norestart

• Paste the command into the Command Prompt window, and then press Enter.
• Restart the computer.

Example for uninstalling Internet explorer 10

• Log on to the computer by using an administrator account or an account that has administrative rights.
• Close all Internet Explorer browser windows.
• Click Start, type cmd in the Search box, and then click cmd under Programs.
• Right click and select Run as administrator
• Copy the following command:

FORFILES /P %WINDIR%\servicing\Packages /M Microsoft-Windows-InternetExplorer-*10.*.mum /c "cmd /c echo Uninstalling package @fname&& start /w pkgmgr /up:@fname /quiet /norestart

• Paste the command into the Command Prompt window, and then press Enter.
• Restart the computer.

Example for uninstalling Internet explorer 11

• Log on to the computer by using an administrator account or an account that has administrative rights.
• Close all Internet Explorer browser windows.
• Click Start, type cmd in the Search box, and then click cmd under Programs.
• Right click and select Run as administrator
• Copy the following command:

FORFILES /P %WINDIR%\servicing\Packages /M Microsoft-Windows-InternetExplorer-*11.*.mum /c "cmd /c echo Uninstalling package @fname&& start /w pkgmgr /up:@fname /quiet /norestart

• Paste the command into the Command Prompt window, and then press Enter.
• Restart the computer.

MORE INFORMATION

Articles:

What to do if you can’t uninstall Internet Explorer 9

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

Manual Process:

Install or uninstall Internet Explorer

http://windows.microsoft.com/en-us/internet-explorer/install-ie#ie=ie-11

Want to share a scenario I worked on recently that may help others understand what could cause Enterprise Mode not show in GPMC.

Condition:

• You want to manage IE11 Enterprise Mode GPO from a Central location using your Central Store Group Policies configuration
• You have already installed IE11 on the machine you are using to manage these group policies
• You have already install the require IE Cumulative update that introduces Enterprise Mode MS14-018

When you open GPMC on your Domain controller you do not see the 2 new Enterprise Mode Group Policy entries:

• Let Users turn on and use Enterprise Mode from the Tools menu
• Use the Enterprise Mode IE website list

Reason:

• You have not copied the new IE11 Enterprise Mode ADMX templates on your Sysvol Policies PolicyDefinitions  directory
• You had GPMC opened when copying the files

Actions taken to get your IE 11 Enterprise Mode GPO settings show in GPMC when using Central Store Group Policy Configuration

• Make sure GPMC is close!
• Copy both the new IE11 Templates into its respective policy folders.
• Copy inetres.admx from C:\Windows\PolicyDefinitions  to  the Domain Sysvol\Domain\policies\PolicyDefinitions folder.
• Copy inetres.adml  from C:\Windows\PolicyDefinitions\en-US to the Domain Sysvol\Domain\policies\PolicyDefinitions\en-US policy folder.

NOTE: Verify, the new files have the new EMIE entries present.

• Open GPMC to confirm the new IE11 Enterprise Mode GPOs are present

The key to this scenario was to make sure that GPMC console was closed and validate the new files were copied successfully to the Central Store!

Here are the EMIE entries we need to have in the templates. You can search for it.

Inetres.adm entries:EnterpriseModeEnable and EnterpriseModeSiteList

 <policy name="EnterpriseModeEnable" class="Both" displayName="$(string.EnterpriseModeEnable)" explainText="$(string.IE_ExplainEnterpriseModeEnable)" presentation="$(presentation.EnterpriseModeEnable_1)" key="Software\Policies\Microsoft\Internet Explorer\Main\EnterpriseMode">
      <parentCategory ref="InternetExplorer" />
      <supportedOn ref="SUPPORTED_IE11" />
      <elements>
        <text id="EnterReportBackPrompt" valueName="Enable" />
      </elements>
    </policy>

<policy name="EnterpriseModeSiteList" class="Both" displayName="$(string.EnterpriseModeSiteList)" explainText="$(string.IE_ExplainEnterpriseModeSiteList)" presentation="$(presentation.EnterpriseModeSiteList_1)" key="Software\Policies\Microsoft\Internet Explorer\Main\EnterpriseMode">
      <parentCategory ref="InternetExplorer" />
      <supportedOn ref="SUPPORTED_IE11" />
      <elements>
        <text id="EnterSiteListPrompt" valueName="SiteList" required="true" />
      </elements>
    </policy> 

Inetres.adml entries: EnterpriseModeEnable and EnterpriseModeSiteList

If you disable or do not configure this policy setting, users can pin sites.</string>
      <string id="EnterpriseModeEnable">Let users turn on and use Enterprise Mode from the Tools menu</string>
      <string id="IE_ExplainEnterpriseModeEnable">This policy setting lets you decide whether users can turn on Enterprise Mode for websites with compatibility issues. Optionally, this policy also lets you specify where to get reports (through post messages) about the websites for which users turn on Enterprise Mode using the Tools menu.

If you turn this setting on, users can see and use the Enterprise Mode option from the Tools menu. If you turn this setting on, but don't specify a report location, Enterprise Mode will still be available to your users, but you won't get any reports.

If you disable or don't configure this policy setting, the menu option won't appear and users won't be able to run websites in Enterprise Mode.</string>
      <string id="EnterpriseModeSiteList">Use the Enterprise Mode IE website list</string>
      <string id="IE_ExplainEnterpriseModeSiteList">This policy setting lets you specify where to find the list of websites you want opened using Enterprise Mode IE, instead of Standard mode, because of compatibility issues. Users can't edit this list.

If you enable this policy setting, Internet Explorer downloads the website list from your location (HKCU or HKLM\Software\policies\Microsoft\Internet Explorer\Main\EnterpriseMode), opening all listed websites using Enterprise Mode IE.

<presentation id="EnterpriseModeEnable_1">
        <textBox refId="EnterReportBackPrompt">
          <label>Type the location (URL) of where to receive reports about the websites for which users turn on and use Enterprise Mode</label>
        </textBox>
      </presentation>
      <presentation id="EnterpriseModeSiteList_1">
        <textBox refId="EnterSiteListPrompt">
          <label>Type the location (URL) of your Enterprise Mode IE website list</label>
        </textBox>
      </presentation>

This blog has been provided to you by the IE Support Team.