Check out all of the posts tagged with 'TMG' below. If you still can't find what you are looking for, try using the search box.
Do you have the Red X and the error "unable to load data" in certain parts of your LightSwitch application. This problem has plagued lots of people as it's just about the worse, most generic error message. The "Unable to load data" does nothing to point you in the right direction. I followed Michael Washington's post and turned on tracing but that didn't give me any clues. Finally in this post Sheel Shah with Microsoft suggested using Fiddler to see what errors might be coming back. (Notice that the fix to the original issue posted by Mr. Yossu was totally different then my issue though we both had that same generic unable to load data error).
Turns out Fiddler did reveal the following:
Error Code: 500 Internal Server Error. The request was rejected by the HTTP filter.
Suddenly, I had something to search on which led me to this post. As soon as I read it, I knew that was my issue as we are being a TMG firewall. To test, I accessed the deployed app by internal IP through a VPN and guess what?...No Red X's. So, if you have deployed your LS app behind TMG (or ISA), here's what you need to do:
Based on the Stack Overflow post, I thought just unchecking Block High Bit Characters would work but it didn't. Checking TMG logs I found that my actual error was "Blocked by the HTTP Security filter: URL normalization was not complete after one pass". I should have known this as we've been bit by the "Verify Normalization" setting previously when deploying a Silverlight Web app. After making the changes to the HTTP Filter, it took a few minutes to take effect (probably because we have a TMG array) but in just a few minutes, everything was coming up Red X free. I hope this help someone else. It won't fix all the "Unable to Load Data" issues as there are a ton of other scenarios that will give you that error, but it will fix those with the error when TMG is the culprit.
We replaced a single TMG 2010 server with a pair of TMG 2010 servers using NLB for internal and external NIC’s. That process in itself was somewhat of a challenge. Along the way we found a bug that was introduced in TMG 2010 SP1. On the single server (non SP1), we had a HTTP listener using a custom port of 8080 (this was for TFS just so you know). On the new servers, we added SP1 for TMG 2010 before adding any rules and then tried to add the HTTP listener on port 8080. However, in the listener properties, as soon as we change the HTTP port and tried to apply we received this error: “This Web Listener is configured to use SSL. You must specify a certificate for use in this Web Listener.”
You can duplicate this by simply creating a new listener, click on the Connections tab, change HTTP port to anything other than 80 and try to apply as shown below.
After seeing the error you may notice that without SP1, the Certificates tab will have all it’s options disabled if you don’t check Enable SSL on the Connections tab. However, after applying SP1 those options on the Certificates tab are not getting disabled and I guess there’s code that keys off that resulting in the erroneous error message we received.
We opened a case with Microsoft and it was confirmed that this is a issue introduced with TMG 2010 SP1 and they are working on a fix. Currently, I see two workarounds:
So there you have it. Just select any SSL cert to get you going even though you may be adding a non-SSL rule/listener. I hope this saves you some time and headache.
After you install TMG 2010 on a server, you’ll probably notice that Windows Update no longer works giving error 80072EE2.
The fix is to set you Internet Explorer proxy setting to point to TMG on port 8080. You probably know the steps but just in case, here’s what you need to do:
You should be able to run Windows Updates now without any problem. Not sure I totally understand why that’s required for Windows Update since if you allow Localhost to External, you can browse the Internet just fine without adding TMG as your proxy server. If anyone knows why it effects Windows Update, let me know.
One of the issues with the "cloud" world is most apps are hosted using SSL for security. This means your URL is their URL. For instance, Microsoft Online (BPOS) will use https://red001.mail.microsoftonline.com for OWA for North America. If you just add a CNAME entry in DNS, that will redirect traffic but you'll get an SSL error since the names don't match. For instance, redirecting .com">.com">https://owa.<yourdomain>.com to https://red001.mail.microsoftonline.com will sort of work but with the SSL error so it's ugly.
In the past I'd setup IIS pages that would just redirect http traffic to the https URL I wanted but that's a pain to setup each time. With TMG 2010 (and really ISA 2006 also I believe), you can just deny that traffic and then redirect it to any URL you'd like. Here's the steps to redirect in TMG 2010.
Here’s a screen shot of how I redirect OWA to BPOS.
Now when you browse to http://<initialURL> that traffic will be redirected to https://<targetURL>. That'll at least give your users an easy initial URL to remember. It won't hide that target URL which can be a shame in certain scenarios. If the site just users HTTP, then CNAME records work great for that but as I mentioned before that'll give ugly verification errors for HTTPS.