When speaking with customers, we hear a lot of questions around “unexpected” errors like “Failed Connection Error 995 Operation Aborted” and “Failed Connection Error 64 Net name Deleted” in the ISA/TMG logs. The main concern here is always if these errors are real errors and how to prevent them.

These errors occur most of the time when SSL traffic is involved.

First of all, if you see those errors: “Don’t Panic” ;-)

These errors are expected in most scenarios, where you’re using ISA 200x or TMG without SSL Inspection.

In this blog I want to provide some background about these errors, and why they are not an indication for an actual error in most cases.

Another good article about these errors had been published by Thomas Detzner covering the connection of these with RPC/HTTP publishing (http://blogs.technet.com/b/isablog/archive/2007/06/25/rpc-over-http-logging-wildness.aspx )

Why 995 and 64?

You may wonder why we’re not logging any HTTP Error codes but use error numbers like 995 or 64 instead. The answer to this question is quite simple: ISA/TMG are both running on Microsoft Windows, as you might have noticed J, where Error 995 and 64 are both standard error codes of the Win32 API, which are defined in the Winerror.h header file (http://msdn.microsoft.com/en-us/library/ms819773.aspx). This file contains the definitions for the standard error codes for Win32 API functions.

But why doesn’t ISA 200x and TMG log the result codes defined in the HTTP RFC?

This question directly leads to the cause of the failed connection attempt log entries, and is quite simple:

“Because it can’t!”

ISA 200x and TMG without HTTPSi can’t look inside the SSL tunnel in forward proxy scenario, once the tunnel is established. Please keep in mind that the SSL tunnel is established between the client and the SSL server and it is an end to end relation. Therefore ISA/TMG has no clue about the traffic inside of the SSL Tunnel, and can’t make any assumptions on why a connection has been closed by the client or the server on the other end.

For more information about the SSL Tunnel setup over a proxy and how TMG HTTPSi changes this scenario please have a look at this article: http://technet.microsoft.com/en-us/magazine/ff472472.aspx

But how can I troubleshoot SSL connection issues then?

Unfortunately the ISA / TMG live logging is not the best tool to troubleshoot SSL connection issues. If you have to troubleshoot these issues, the first thing to start with is to verify the web server logs. if you can access them, or you will need to analyze the network traces. You want to do this ideally on all participating network devices and try to identify any issues with the SSL Handshake, any kind of packet loss or with delays happening during a SSL session.

If this approach doesn’t show any indications what’s going wrong you have to troubleshoot SSL. Next step should always be to either turn off SSL and verify if there are any issues when using HTTP. Another option is to use tools like STRACE (http://www.microsoft.com/downloads/en/details.aspx?familyid=f5ec767f-27f2-4fb3-90a5-4bf0d5f4810a&displaylang=en ) in combination and HTTPREPLAY (http://www.microsoft.com/downloads/en/details.aspx?familyid=d25ba362-c17b-4d80-a677-1faff862e629&displaylang=en) or different tools which allow you to look inside of the SSL Tunnel.

In summary - SSL Troubleshooting can be one of the most challenging things to troubleshoot. If something is going wrong inside the Tunnel, you have to find a way to look inside the tunnel. As SSL is designed in a way that this shouldn’t be possible, to prevent man in the middle attacks, you’ll most likely have to check the endpoints of the tunnel in most of the cases.

Author

Philipp Sand
Microsoft CSS Forefront Security Edge Team

Technical Reviewer

Thomas Detzner
Escalation Engineer - Microsoft CSS Forefront Security Edge Team

This post is about an issue that might occur after you install Forefront TMG 2010 SP1 and Reports start to show blank result. When this happens, the following Alert appears on TMG console:

In this scenario access to the report links URLs: http://localhost:8008/ReportServer_ISARS or http://127.0.0.:8008/Reports_ISARS will also fail. This issue might happen in some scenarios where there is a ‘database logon failure as showed in the error description (error code 0x80040e4d means DB_SEC_E_AUTH_FAILED). To address this issue run the script fixsqlserverlogin_vbs mentioned in the article: http://technet.microsoft.com/en-us/library/ff717843.aspx.

Note: this resolution is specifically for this scenario, where this alert is logged. Do not run the script for in other scenarios with same symptom (reporting showing blank result) but without this alert.

When you run the script, you have to wait for each node to sync with EMS and then run it on second node in case of TMG 2010 Enterprise Edition and on single TMG 2010 server in case of standard server. This script allows admin to change the password so that connection to the database can be established using new password and reports can be fetched from that.

Authors
Suraj Sigh
Support Engineer
Microsoft CSS Forefront Security Edge Team

Yuri Diogenes
Sr Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Bala Natarajan
Sr Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Last week Tarek Majdalani, a Microsoft Most Valuable Professional, posted an article about identifying which version of TMG 2010 is installed – RTM, Service Pack 1 or Update 1 to Service Pack 1.

The article is available on the TechNet Wiki site here.

If you are wondering what version you have installed on your server, this article has all the information you need.

Background:

I recently dealt with a support case exhibiting the below issue.

My customer was publishing an Exchange CAS server with Forefront TMG, and Kerberos Constrained Delegation (KCD) was used in the publishing rule as the authentication delegation method to the web server.

Symptom:

The web publishing was working just fine (including KCD) but surprisingly the “test rule” button was returning the error “Failed to get domain controller name for this published server” when validating the rule.

Here is a screenshot of the test rule button results:

Resolution:

Based on this error details, I led some investigations using both Repro mode data collected with the useful TMG Data Packager (that comes with the TMG BPA) and source code analysis in order to understand the root cause of this.

I found out that one of the checks done by the “test rule” code for the KCD scenario is to check if the published web server is member of a domain and which domain it belongs to.

To do this, the code makes a call the public Windows API DsRoleGetPrimaryDomainInformation which is described in MSDN at http://msdn.microsoft.com/en-us/library/ms676042.aspx).

I found that the call to DsRoleGetPrimaryDomainInformation was failing with an error code of 0x800706ba (which translates to RPC_S_SERVER_UNAVAILABLE).

Reviewing the Network Monitor capture taken on the internal network interface of TMG I spotted that the RPC calls, initiated by DsRoleGetPrimaryDomainInformation, to the published server were failing.

The capture was showing unsuccessful TCP connection attempts from the TMG machine to the published on destination ports 445 and 139:

After further discussion with the customer, I discover that a network filtering device (firewall) located in between TMG and the published server was dropping this connection attempts, explaining the error.

After opening these ports on this filtering device, the “test rule” button returned no error!

Author

Eric Detoc

Escalation Engineer - Microsoft CSS Forefront Security Edge Team

Technical Reviewer

Franck Heilmann

Escalation Engineer - Microsoft CSS Forefront Security Edge Team

Scenario

You have installed Forefront TMG 2010, Exchange 2010 Edge role and Forefront Protection for Exchange (FPE) 2010 on the same machine. You do not want to use the Email policy configuration integration feature of Forefront TMG (in this case TMG won’t manage the Exchange Edge and FPE settings), in other words you have not executed the “Configure Email Policy” wizard in the TMG Management console. In this situation the E-Mail Policy settings appears like the figure below:

On Exchange Edge console you notice that the default Receive Connector of Exchange Edge gets disabled:

Cause

Forefront TMG is responsible for this behavior and the reason is that the property IntegrationEnabled of the SmtpProtectionConfiguration COM object is wrongly set to TRUE by default during TMG setup. See http://msdn.microsoft.com/en-us/library/ff826540(v=VS.85).aspx

Note: This behavior should be fixed in a future update of TMG.

Current Resolution

The recommendation is to use the integration mode so that TMG manages Exchange Edge and FPE settings automatically for you (at least the settings exposed in the TMG management console). If you choose to use the integration mode you won’t run into this issue as TMG will automatically manage the SMTP connectors defined in Exchange Edge.

However if you don’t want to use this integration mode for some reasons, the current workaround to this problem is to set the Email Policy Integration mode to Disabled (as indicated in the screenshot below) and apply the change. This will set the COM property IntegrationEnabled to False.

Author
Eric Detoc
Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Yuri Diogenes
Senior Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Introduction
Consider the scenario where a TMG 2010 Server is installed as Hyper-V guest on a Windows 2008 Server. You publish a website on port 80 or enable HTTP to HTTPS redirection on a Web Listener for an existing SSL publishing rule. When you try to access the published website you get an error: 10060 Connection Refused.

Troubleshooting
A quick look at the TMG Live Logging reveals the following:

Netstat output indicates that Process ID 4 (System) is listening on port TCP 80 as shown below:

This explains why Firewall Service was not able to bind itself to TCP port 80.In scenarios where IIS is installed on the same machine as the ISA/TMG Servers and IIS binds itself to port 80, it is common to such output. As part of the troubleshooting for issues of this nature, we checked and found that IIS was not installed on the TMG Server. We then used Process Explorer to check if any other process which hooks into System process was causing this behaviour and found that it was not the case.

We then used the netsh command line interface to check the state of HTTP Service with the following command:

Based on the above output, we can see that WSMAN is listening on port 80. WSMAN (Web Services-Management) is an open standard for SOAP based protocol management of servers, application and web services. WinRM (Windows Remote Management) is Microsoft’s implementation of WS-Management standard.

In this particular case the Windows Remote Management service was grabbing port 80 on the TMG guest machine which is why the Web Proxy service was not able to bind itself to port 80 and therefore, requests from external clients were failing. Disabling the Windows Remote Management service or changing the WinRM listener to listen on a port other than 80 resolved this issue.

Conclusion
This post explains a scenario where a service other than IIS grabs web ports used by TMG causing publishing rules to fail. In case connection to a particular port on TMG is failing, always check if TMG is listening on that port.

Authors
Junaid Ahmad Jan
Security Support Engineer
Microsoft CSS Forefront Security Edge Team

Mohit Kumar
Senior Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Yuri Diogenes
Senior Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Introduction

When the EMP feature is enabled, TMG will accumulate data downloaded by the client and scan all the content for malware before transferring it to the client. Accumulating the entire file and scanning it, may take a significant time. During this period of time, the client doesn't receive any data and as a result a software timeout can occur or the user can even cancel the download. Therefore, actions need to be taken to avoid this. There are number of ways to deal with this problem which are collectively called “client comforting”. When downloading a file from the Internet through TMG a user can experience different comforting methods. For more information on Forefront TMG comforting method read Configuring malware inspection content delivery at Microsoft TechNet. This post describes potential performance impact by changing the default content delivery method from Standard Trickling to Fast Trickling.

Trickling

Trickling is based on sending successive small portions of the response data to the client before completing the final scan (inspection of the whole response). This mechanism guaranties that the underlying connection is kept alive with the client until the final scan of the whole file.

These portions are scanned in order to reduce the risk of passing malicious code to the client. Standard trickling minimizes the performance overhead of the additional scanning by sending small portions of the response to keep the connection alive. Once the entire response has been accumulated, TMG will perform the final scan and send the remaining data at the maximum possible speed to the client, if content is safe.

Performance

In some scenarios, such as media streaming, throttling down the download speed has adverse effect to the user experience as the downloaded content is used even before it has completed (e.g. playing a movie as it is being downloaded). When using fast trickling option for the Content Delivery method in Malware Inspection, Forefront TMG sends the data as fast as possible to the user, by scanning scan every chunk before sending it. This method requires more resources from the Forefront TMG server, but provides a better experience for the user.

Because of the performance impact, it is recommended to use fast trickling only when important for the user experience (e.g. for media files which are played by online players like YouTube. This is different for non-HTTP audio or video streaming which is exempted from inspection). The requirement to scan every sent portion still applies, so the filter performs O (size) scans. Since every scan starts from the beginning (the entire available prefix is submitted) depending on the file type the overall complexity may become X (where X is size ^ 2). To reduce the number of scans the filter applies some level of buffering. The parameter for the fast trickling is the tradeoff between the user experience (less buffering on TMG, more scans) and performance (more buffering on TMG, less scans).

Changing all downloads to Fast Tricking (as shown below) may cause a rise in CPU utilization when the server is too busy performing malware inspection operation. It is recommended to use this setting only when most of the traffic is streamed. In other scenarios it is recommended to use Standard trickling by default and set fast trickling for the content types only.

Troubleshooting

When Fast Trickling is used as default method, you will notice that standard tricking is never used by monitoring the following counters (for complete lists of Malware Inspection Counters see this article) on perfmon:

Conclusion

To balance performance and user’s experience we recommend using Standard Tricking as default method and Fast Trickling for content types which are streamed by the clients. This way you better balance performance with better user’s experience.

Authors
Yuri Diogenes
Senior Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Ori Yosefi
Senior Program Manager
Forefront TMG Team

Technical Reviewer
Lars Bentzen
Escalation Engineer
Microsoft CSS Forefront Edge Team

Eric Detoc
Escalation Engineer
Microsoft CSS Forefront Edge Team

Here are the ISA Server/Forefront TMG HTTP Policy settings I use for ECP, OAB and Autodiscover. These settings were tested with Outlook 2007/2010 and Exchange 2007.

Author: Jan Tiedemann, Senior Premier Field Engineer

Introduction

This post is about a scenario where TMG Administrator was trying to simulate a failover before put the environment in production. TMG nodes were installed in a third party virtual environment. TMG was using integrated NLB with Unicast, the External TMG adapter was connected to a layer 2 switch. To attempt to simulate failover, TMG Admin was disabling the NICs of one of the nodes, the unexpected result was that the other node suddenly stopped accept connections from External users.

Troubleshooting

When dealing with NLB always remember to start from the basic and here are some good references on that:

• Binding order - http://support.microsoft.com/kb/894564
• VLAN Tagging Issues http://support.microsoft.com/kb/2286940
• Connectivity Issues - http://technet.microsoft.com/en-us/library/cc783135(WS.10).aspx
• General Windows NLB Troubleshooting - http://download.microsoft.com/download/3/2/3/32386822-8fc5-4cf1-b81d-4ee136cca2c5/NLB_Troubleshooting_Guide.htm

For this particular scenario data was collected on the server whose NIC was not disabled and in the traces found something very interesting:

Until frame number 1072 as shown above traffic was normal after that we start seeing huge RARP traffic and this RARP traffic was little weird as we can see below target and source MAC address are same and Target IP address is 0.0.0.0.

As per definition in: //www.ietf.org/rfc/rfc903.txt we have:

Since the Target IP as seen above is 0.0.0.0, this looks strange as why would we start seeing this kind of RARP traffic the moment we disable NLB NIC of the other node.

Resolution

To fix this issue the action from the virtualization vendor below was applied:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1556

This link explains how to disable the RARP traffic and after we disabled the RARP, NLB worked fine even if we disable the NLB NIC of the other node.

Author
Suraj Singh
Support Engineer
Forefront Edge Team

Technical Reviewer
Yuri Diogenes
Sr Support Escalation Engineer
Forefront Edge Team

Scenario

From time to time we come across cases where customers complain that the proxy exception list does not work for certain URLs and (Winhttp) clients still try to connect to the destination server using the proxy instead of going directly.

Affected applications vary, we have seen issues with outlook 2007, SCCM, but the list might not be limited to those two – any Winhttp application might show the same symptoms.

Upon investigating these issues we found that the problem is a case-sensitivity issue – applications might provide an uppercase (or mixed-case) name as URL, whereas the ISA generated pac file works with lowercase exception names (no matter how you entered them in the UI) and case sensitive comparison.

The behavior of TMG is by default the same as that of ISA – however, we now have an option to influence whether we perform case sensitive comparison.

ISA behavior for generating the pac file

Looking at the relevant parts of an ISA generated script we see:

…

function MakeNames(){

this[0]="*.domain.tld";

}

DirectNames=new MakeNames();

cDirectNames=1;

….

function FindProxyForURL(url, host){

…

for(i=0; i<cDirectNames; i++){

  if(shExpMatch(host, DirectNames[i])){

   fIp = true;

   break;}

  if(shExpMatch(url, DirectNames[i]))

   return "DIRECT";

}

You might notice two things: “DirectNames”, our exception list contains lowercase names (as mentioned earlier, no matter how you enter it in the UI), and we do not convert the input to lowercase in FindProxyForUrl before making a comparison.

Because shExpMatch() performs a case sensitive comparison, here is what happens:

1. The Winhttp Client obtains the wpad script (AKA proxy.pac) from ISA.  This script contains code and data to assist the client with determining which proxy to use (if at all).

2. The Winhttp client passes each request to the wpad script for processing

3. The script relies on text matching functionality provided by the client in the form of shExpMatch(); shExpMatch is case-sensitive (by design)

4. if the URL being requested has an FQDN of HOST.DOMAIN.TLD and the wpad script includes *.domain.tld in the “direct access” list, shExpMatch() will return “false”

5. if the shExpMatch returns false for this comparison, the wpad script will return to the web client with a list of proxies to use for this request

Therefore, the client will not try to connect directly to the destination but will use a proxy instead.

TMG behavior for generating pac files

Although by default TMG behaves the same way as ISA, if you look at the generated pac file, you can notice the following differences (showing only the relevant parts):

…

ConvertUrlToLowerCase=false;

...

function MakeNames(){

this[0]="*.domain.tld";

}

DirectNames=new MakeNames();

cDirectNames=1;

....

function ImplementFindProxyForURL(url, host){

…

for(i=0; i<cDirectNames; i++){

if(ExpMatch(host, DirectNames[i])){

   fIp = true;

   break;}

  if(ExpMatch(url, DirectNames[i]))

   return "DIRECT";

}

...

function ExpMatch(str, exp){

if (ConvertUrlToLowerCase)

{

  str = str.toLowerCase();

}

return shExpMatch(str, exp);

}

The key difference is that for the comparison we first call a wrapper ExpMatch, which depending on the value of ConvertUrlToLowerCase converts the input string to lowercase before calling shExpMatch.

If we could manage to set ConvertUrlToLowercase to true, we could circumvent the problem described at the beginning.

Luckily, a new property ConvertUrlToLowerCase was added to the IFPCClientAutoScript3 interface (see http://msdn.microsoft.com/en-us/library/ff824480(VS.85).aspx) to allow lower-casing the URLs passed to the routing script before performing comparison, thus making the routing script case-insensitive.
This behavior is OFF by default. You can however enable this with the following script, provided here as an example.

'
' set wpad script to lowercase its input url – for Internal network
'
set fpc = CreateObject("FPC.ROOT")
set net_internal = fpc.GetContainingArray().NetworkConfiguration.Networks("Internal")
set wpad = net_internal.ClientConfig.Browser.AutoScript
wpad.ConvertUrlToLowerCase = -1
wpad.save

Authors
Balint Toth
Support Escalation Engineer
Microsoft CSS Forefront Edge Team

Technical Reviewer
Eric Detoc
Escalation Engineer
Microsoft CSS Forefront Edge Team

URL filtering is one of Forefront TMG’s most popular features. The feature makes use of a cloud service, also known as Microsoft Reputation Services (MRS) for URL categorization purposes. In this post we’d like to address some of the more frequent questions we’ve received regarding the URL filtering database and the cloud service.

What is the URL categorization cloud service?

MRS can be thought of as a web service, providing secure access to a huge, cloud-based dynamic repository of URLs and their respective categories. The database features over 70 categories ranging from security-oriented selections like Malicious sites, through productivity-oriented categories such as Online Communities, and ending with liability-oriented categories like Pornography. The database spans tens of millions of unique URLs and their respective categories. Whenever a user behind TMG tries to access a URL, TMG can look up its category by issuing an online query to the cloud service. If you’d like to learn more about URL filtering and the cloud service, check out this post.

What are the sources of the URL filtering database?

The database merges data from several providers. The data providers include internal Microsoft sources as well as 3rd party sources. Microsoft signed agreements with BrightCloud (a Webroot subsidiary) and with M86 Security to consume URL categorization data. Those sources are now integrated into the database. It is important to note different providers employ different URL categorization techniques. Some employ manual classification while others rely heavily on web crawlers performing automated classification. The highly advanced automated classification techniques ensure TMG URL filtering is as competitive as it gets when it comes to the coverage of the web and reaction speed.

How frequently is the URL filtering database updated?

The database is constantly updated in order to cope with the dynamic nature of the web. New URLs are added, obsolete ones are removed and categories can change based on the page’s content. The update frequency varies per data provider and per URL category. For example, with security-oriented categories such as Phishing or Malicious sites, the database receives updates every 20 minutes. These highly frequent updates are required to protect customers from dynamic, emerging threats. With some other URL categories, the database updates are less frequent.

How good is the coverage for URLs outside the US?

The The URL filtering database ensures a global coverage, and is meant to serve TMG customers all over the world. The coverage is regularly monitored against indicators such as Alexa's top Million URL list. In addition, telemetry data gathered from TMG deployments around the world is used to refine the database and improve the coverage for URLs that are popular with our customers. There is also a constant dialogue between Microsoft and the other data providers to ensure a focus on geographies with heavy TMG customer presence.

Is URL categorization performed based on the top level domain only or based on the full URL?

The categorization is based on the full path. This means http://www.contoso.com and http://www.contoso.com/sports could be assigned with different categories in the database.

Can a URL have more than a single category?

Yes. You can learn more about TMG’s support for multiple URL categories in this post.

Can TMG block adult text, images and videos from search results by web search engines?

Yes. You can learn more about TMG’s safe search enforcement support in this post.

What else is Microsoft doing to improve the URL categorization service?

Microsoft is constantly seeking customer feedback about MRS and working to address our customers’ concerns. For instance one thing we are working to improve is shortening the total time it takes for a customer to report a mistake in URL categorization on the MRS feedback portal to be corrected in the database.

Author:

Dotan Elharrar, Senior Program Manager, Forefront TMG

Reviewers:

David Strausberg, Technical Writer, Forefront TMG

Zakie Mashiah, Group Manager, Forefront TMG

Introduction

Consider a scenario where TMG Admin reinstalled TMG Enterprise Edition after a hardware failure and decided to rejoin the array member to the EMS. However, when TMG Admin tried to rejoin it the following error occurred:

Troubleshooting

The first basic step in this type of scenario is to review the event view, since it can give you some clues about what is going on. Most of TMG events will be found on Application Event log. So, on Event View we found the following error:

Since we are joining to an EMS all setting including log configuration will be retrieved now from it. So, after checking the Log configuration on EMS for that particular Array where TMG Server was trying to get joined, we found that setting:

The EMS had a configuration for all logs should get stored on volume L:\. We investigates that the target server trying to rejoin did have a volume dedicated for log but it had the letter D: assigned to it. After getting the volume changed to letter L: the joining process worked fine. This change on the drive letter happened while TMG Admin was rebuilding the server after the hardware failure.

Conclusion

This post showed how TMG administrators need to be aware that EMS configuration will try to enforce the settings, in this particular scenario for a logging path that did not exist in the joining array member. It is a good practice to always have the core settings matching in between the EMS and the array members. Additionally document your recovery process making sure that all the requirements are in place to not get surprises down the road.

Author
Daniel Mauser
Sr. Support Escalation Engineer
LATAM Team

Technical Reviewer
Yuri Diogenes
Sr. Support Escalation Engineer
Forefront Edge Team

Introduction
Some of our customers have experienced the problem described below when doing the initial network configuration of a fresh TMG installation. I wanted to share here the cause and solution to this issue.

Consider the following scenario
You have installed Forefront TMG 2010, but when running the Getting Started wizard, you get the error “No network adapters could be identified. The wizard cannot continue” when choosing the Network Template, see screenshot below:

Cause
We’ve seen this issue on servers where Operating System hardening has been applied prior to TMG installation. As a result, some services required by TMG to operate properly have been wrongly disabled causing the problem described above.

Solution
The solution and only supported way to perform hardening of a TMG machine is to execute the Security Configuration Wizard (SCW) tool and use the TMG security configuration template (XML file) matching your deployment in order to harden properly the server.

Note: By default, the SCW does not include support for the TMG 2010 role nor TMG Enterprise Management Server (EMS) role. To support these roles, download and install TMGRolesForSCW.exe included in the TMG 2010 Tools and Software Development Kit (SDK), available here.

Author
Eric Detoc
Escalation Engineer - Microsoft CSS Forefront Security Edge Team

Technical Reviewer
Franck Heilmann
Escalation Engineer - Microsoft CSS Forefront Security Edge Team

Consider the following scenario:

You have configured reporting with TMG, and you have published the generated reports content on an IIS 7.5 Server (Windows 2008 R2) so that TMG administrators in your organization can access these reports from their workstation using a standard browser like Internet Explorer.

Problem:

The Reports are not displayed correctly in the browser. You notice that images are missing, hence the “red cross” error as we can see in the below screenshot.

Cause:

As you know TMG is using SQL Server Reporting Services to generate reports based on the TMG activity logs.

The root cause of the problem here is that no file extension (such as .png) is given to the image files returned as a stream of data by Reporting Services.

In addition, IIS 7.5 won’t serve by default, files that don’t have any known MIME type. Instead IIS will respond with a 404.3 error (see http://technet.microsoft.com/en-us/library/cc753281(WS.10).aspx)

As a result, when the browser sends the requests for the images included in the report, IIS will respond with 404.3 for all them as they are not mapped to a known MIME type.

This error can be easily seen in the IIS log when the client browser is accessing the report.

Workaround:

While this issue is currently investigated by the TMG and Reporting Service product groups there’s an easy workaround that can be implemented on IIS to solve it.

This workaround consists in adding a “.” file name extension mapped to the application/octet-stream MIME type to the MIME types list known by IIS. By doing this, we instruct IIS to serve files that don’t have any extension.

The screenshots below summarized the steps to be done in IIS.

As a result, IIS will respond to such requests (without file extension) with 200 OK with a MIME type of application/octet-stream.

Then the client browser will manage how to render the response. In this case, IE detects that it is an image and will render it as such.

Note: I recommend hosting the reports inside a dedicated virtual directory and adding the above mentioned setting at this virtual directory level.

Author

Eric Detoc

Escalation Engineer - Microsoft CSS Forefront Security Edge Team

Technical Reviewer

Franck Heilmann

Escalation Engineer - Microsoft CSS Forefront Security Edge Team

NIS Signature set released last month (8.32) contained 4 signatures that were disabled by default:

• Plcy:Win/Sharepoint.SafeHTML1.XSS!2010-3243
• Plcy:Win/Sharepoint.SafeHTML2.XSS!2010-3243
• Plcy:Win/HTTP.SafeHTML1.XSS!2010-3324
• Plcy:Win/HTTP.SafeHTML2.XSS!2010-3324

We’ve received a number of questions about why these signatures were off by default and thought it may be worthwhile to write about the NIS signature types again.

As explained in the NIS in TMG whitepaper, there are three different NIS signature types:

1. Vulnerability-based: These signatures will detect most variants of exploits against a given vulnerability.

2. Exploit-based: These signatures will detect a specific exploit of a given vulnerability.

3. Policy-based: These signatures that are generally used for auditing purposes and are developed when neither vulnerability nor an exploit-based signature can be written.

Whenever possible, we write vulnerability based or exploit based signatures. These are accurate signatures which have a very low rate of false positives or false negatives.

However, in some cases we aren’t able to write a vulnerability/exploit signature so we write a policy based signature. These are less accurate and can cause some false alarms so it is up to the administrator to make a conscious decision to enable them despite the risk of false positives.

This is why we make policy based signatures available in a “disabled by default” mode.

Author:

Ori Yosefi, Senior Program Manager, Forefront TMG

Reviewer:

Dror Zelber, Senior Program Manager Lead, Forefront TMG

One of the most common questions we get is about TMG’s support for NIC Teaming and VLAN tagging with NLB enabled.

We have recently released Software Update 2 for Forefront Threat Management Gateway (TMG) 2010 Service Pack 1. This is a regular rollup of hotfixes which is available through Microsoft Customer Service and Support.

One of the issues fixed in this update is TMG’s support for NLB on VLAN Tagged or Teamed network adapters (See KB article 2449122).

With this update installed, Teamed and VLAN tagged NICs become supported scenarios (see NLB’s support statement for VLAN Tagging and teaming adapters for details)

This fix will also be included in future service packs released for TMG.

Author:

Ori Yosefi, Senior Program Manager, Forefront TMG.

Reviewer:

Jonathan Barner, Software Design Engineer, Forefront TMG

Introduction
This post is about a recent scenario where TMG Administrator was receiving complains that some workstations that were using TMG as proxy were failing to run Windows Update. The interesting part of this issue was that only some workstations were having such problem and only if they were using “Automatic Detection” settings (which use WPAD). But all other workstations were using the same setting and were working just fine.

Data Gathering
In order to troubleshoot this I started TMG Data Packager in repro mode using Web Proxy and Web Publishing template and performed the following steps in the client workstation that was having the issue:

1. Clear the wpad cache by executing the following command in an elevated command window: del \wpad*.dat /s
2. Restart Windows Update service
3. Wait for the error to happen on Windows Update.

Data Analysis
I started the data review by looking to the TMG Logging and notice that when it failed the following URL was sent it back to the client:

http://www.update.microsoft.com/microsoftupdate/v6/errorinformation.aspx?error=-2145107946&ln=en-us&IsMu=true&wgaerrorcode=0&wgaend=http://www.update.microsoft.com/microsoftupdate/v6/default.aspx

Notice that this URL returns the error -2145107946 (in decimal), which corresponds to 0x80244016 (in Hex), which means the following:

WU_E_PT_HTTP_STATUS_BAD_REQUEST wuerror.h
# Same as HTTP status 400 - the server could not process the
# request due to invalid syntax.

Having that info, it was time to review the netmon trace to understand why the request was invalid and after reading the trace, it was possible to understand why it was invalid.

Conclusion
By using Netmon it was possible to see the moment that client downloads the WPAD file and tries to access the TMG. But, in it can’t access for some reason (in this case it was a networking routing issue) and switches to another TMG. I wasn’t aware that this environment had another TMG, so I opened the WPAD file and found the following entry called BackupRoute:

BackupRoute="FFTMGEEN2.contoso.com";
UseDirectForLocal=true;
ConvertUrlToLowerCase=false;

This was a backup TMG that was supposed to be used only if the main one was down. So the problem here was:

1. Both TMG servers were listening for CERN proxy requests on the default port 8080.
2. They were also listening for WPAD requests on port 80.
3. The CONNECT requests sent from the client to the FFTMGEEN2.contoso.com was done on port 80 (wpad listener).This caused the failure (error 0x80244016) since the only valid request to this listener is GET /wpad.dat or GET /array.dll?GetRouting.Script.

Solution
In order to fix this it was necessary to change the entry on the Alternate Forefront TMG field within TMG console to be as shown below:

Once this change was done, the WPAD file changed to have the following entry on the backup route:

Have a happy Windows Update process behind TMG !!

Author
Yuri Diogenes
Senior Support Escalation Engineer
Microsoft CSS Forefront (ISA/TMG) Team

Scenario

When configuring site-to-site (S2S) VPN networks, you may notice that the VPN tunnel doesn't connect.

On the dialing TMG server, you'll see the following event logs:

Log Name:      Application

Source:        RasClient

Event ID:      20227

Description: CoId={A56F6195-18BB-44ED-AE45-34B70D127A2C}: The user SYSTEM dialed a connection named Net2 which has failed. The error code returned on failure is 913.

Log Name:      System

Source:        RemoteAccess

Event ID:      20111

Description: A Demand Dial connection to the remote interface Net2 on port VPN2-4 was successfully initiated but failed to complete successfully because of the  following error: A Remote Access Client attempted to connect over a port that was reserved for Routers only.

And on the other TMG server, you'll see this event log:

Log Name:      System

Source:        RemoteAccess

Event ID:      20270

Description: CoID={31A76222-6269-4085-95E5-B3DAC64F69FD}: The user Net2, attempting to connect on VPN2-100, was disconnected because of the following  reason: A Remote Access Client attempted to connect over a port that was reserved for Routers only.

Solution

In order to accept any VPN connections, you must enable VPN client access, even if you only expect site-to-site VPN connections.

-Jonathan Barner, TMG product team

Introduction

UI Search is a TMG feature designed to help administrators instantly filter Firewall Policy rules according to a search criteria string. This feature resembles the "Search Inbox" in Microsoft Outlook and is generally designed to deliver similar functionality.

Usage – visual filtering

UI search can be used to filter rules according to the attributes shown in the management console as column names. All these attributes are supported for localized version of TMG in the very same form as they're shown in UI.

A simple example would be finding all deny rules (Search for “Action:Deny”). For an empty user policy combined with a default system policy, the resulting set of rules will look the following way:

Now, if we'd like to see only those rules that deny access to HTTP protocol, search for: “Action:deny protocol:http”. The query and result would look like this:

We get a single rule which is a subset of the previous query. Here we can see some potential ambiguity: when filtering on “HTTP” both “HTTP” and “HTTPS” will be found since the value is matched as a substring.

Another nice example would be searching for rules governing traffic from external network to local host (search for ‘from:external to:”local host”’):

Usage – search in depth

The same search can be used to find rules where any of their sub-properties fit the search criteria. A good example of that would be searching for rules according to a protocol description:

Consider the following protocol:

This protocol got a twin brother: “System Center Operation Manager Agent Installation”. If we search for 'Description:"Microsoft System Center Operation Manager 2007 Agent"' or just "Microsoft System Center Operation Manager 2007 Agent", we get the two rules referring these protocols:

Another example is filtering rules that deal with download.windowsupdate.com URL. In the example below the URL is part of the “Microsoft Update Sites” Domain name set.

And another one:

Here we note that all rules except the last one were matched according to their description, while the last one is matched according to its users. We can differentiate the result by more precise queries (‘user:”network service”’):

and (‘description:”network service”’)

Queries syntax

Warning: The following sections contains technical mambo jambo. Use at your own risk!

Documentation of the syntax the query follows is available in http://technet.microsoft.com/en-us/library/dd897127.aspx

The search string uses the following grammar:

S -> CriterionList

CriterionList -> CriterionList Criterion | Criterion

Criterion -> Token CLN Token | Token

Token -> TokenType1| DBQ TokenType2 DBQ | SLQ TokenType3 SLQ

Tokens:

CLN -> :

DBQ -> “  //double quote

SLQ -> ‘  //single quote

TokenType1 -> [^ \t\n:\"\']* //sequence of characters NOT containing spaces, tabs, caret returns, colons, double and single quotes

TokenType2 -> [^\"]  //sequence of characters NOT containing double quotes

TokenType3 -> [^\’]  //sequence of characters NOT containing single quotes

Please note that double or single quotes must be used when the search string contains spaces, otherwise it will be processed as two separate search strings.

Implementation details

There are situations in which a search executed from the UI will return more matches, than the exact same search executed using the COM interface. This happens because the UI initializes the full COM sub-tree for rule objects, creating all underlying children (including those that are implicitly set to defaults and are created by demand), while direct search through the COM interface won't see the default children and won't perform lookup on them. However, this will never happen for the matching object that were created or modified by a user.

Written by: Dima Datsenko, Software Design Engineer, Forefront Threat Management Gateway

Reviewed by: Ori Yosefi, Senior Program Manager, Forefront Threat Management Gateway

We know there are many customers who are extremely happy with ISA Server 2006 and have been putting off migration to Forefront TMG 2010. As 2010 is coming to an end, we think you should include migration to TMG 2010 as one of your new year resolutions.

This post will focus on showing you why and help you learn more about Forefront TMG 2010.

Value Proposition: Microsoft Secure Web Gateway with Forefront TMG 2010

Forefront Threat Management Gateway allows employees to safely and productively use the Internet without worrying about malware and other threats. It provides multiple layers of continuously updated protections against the latest Web-based threats, including URL filtering, antimalware inspection, and intrusion prevention.

Microsoft Forefront TMG Core Capabilities

Microsoft Forefront TMG 2010 is positioned as a Secure Web Gateway. The core new features of this product are:

• URL filtering: improves blocking of malicious or inappropriate sites using aggregated data from multiple URL filtering vendors and the anti-phishing and malware technologies that also protect Internet Explorer 8 users.
• HTTPS Inspection: inspect outbound HTTPS traffic in order to protect your organization from security risks inherent to Secure Sockets Layer (SSL) tunnels, such as viruses and other malicious content that could infiltrate the organization undetected.
• Intrusion Prevention (NIS): Protects against browser-based and other Microsoft vulnerabilities.
• Web anti-malware: Provides highly accurate malware detection with the same world-class engine that is used by Microsoft Security Essentials and Microsoft Forefront products.
• Support for Windows Server 2008 R2 (x64): first Microsoft Edge protection product that leverages the scalability and increased memory space improvements of the Windows 64 bit platform.

ISA Server 200X Capabilities

ISA Server 200x doesn’t offer the same Secure Web Gateway capabilities that Forefront TMG offers. ISA Server 200x is commonly used in a Proxy (forward and reverse) type of scenario. Forefront TMG inherits all the ISA Server 2006 capabilities and adds new features to provide more comprehensive protection, while providing a seamless migration path.

Side by Side Comparison

Use the table below to compare ISA 2006 to TMG 2010 feature wise:

What you can do on TMG that you cannot do on ISA

Back in May 2010 I wrote a post on my personal blog where I covered some common scenarios where customers commonly ask if they can use ISA. I selected the top 5 scenarios where there is a real need in the environment, however such a need cannot be answered by ISA Server. The good news is that it can be definitely be answered with TMG. Check the full article at http://blogs.technet.com/b/yuridiogenes/archive/2010/05/28/can-i-do-this-on-isa-server-no-but-you-can-with-tmg.aspx

Learn more about Forefront TMG 2010

Below are some resources that are available for learning about and trying Forefront TMG 2010:

• Forefront TMG Virtual Lab – excellent resource for trying out TMG without having to install it first.
• Forefront TMG Trial version – 120 day, fully functional, trial version to install and test in your own labs.
• Microsoft Business Ready Security Lab - The Microsoft Business Ready Security trial environment provides an end to end trial experience across all of the Business Ready Security solutions. The environment provides an opportunity to evaluate protection, access, management and identity technologies as a pre-configured set of VHDs
• Case Studies Site
• Using Forefront TMG 2010 as a Secure Web Gateway solution – TechNet Magazine article.
• Forefront TMG Pricing and Licensing.
• MS Tech Edge Video about TMG migration from ISA.
• MS Tech Edge Video about TMG Web Access Protection.
• Forefront TMG Web Casts:
  • Forefront Threat Management Gateway 2010: Protection Features and Underlying Technologies
  • Forefront Threat Management Gateway: Deployment, Migration, and Licensing
• TMG Team Blog
• Forefront Edge Community Site
• Microsoft Press Forefront TMG 2010 Administrator’s Companion Book

Author

Yuri Diogenes

Sr Security Support Escalation Engineer

Microsoft CSS Forefront Security Edge Team

Reviewer

Ori Yosefi

Senior Program Manager

Microsoft Forefront Threat Management Gateway Team