We are using the free Comodo antivirus product in our not-for-profit office.? It seems to work pretty well, but the updater is failing on many of our machines.

I think I’ve narrowed the issue down to the fact that we used to have a proxy server.? Even though I removed the group policy that configured Internet settings to look for the proxy, and IE and Firefox can reach the Internet just fine, the “.DEFAULT” user section of the registry is still pointing to the proxy server, and Comodo won’t update.? Nothing that I’ve found will change the .DEFAULT user Internet settings — I edit the registry, and then it reverts back.

I found a registry hack to turn on per-machine proxy settings for XP.? That did the trick!? Here’s what goes in a .reg file that you can double-click to import:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings]
"ProxySettingsPerUser"=dword:00000000

Now I just need to see if a similar fix is available for Vista…

It seems to work for Vista, too!

We’re using mod_auth_cas on a linux reverse proxy to authenticate users to our DotNetNuke (DNN) intranet site.? After dealing with the entropy problem that was really slowing down access, we had just one problem remaining:? files that were attached to DNN pages with the built-in editor were not accessible through the reverse proxy.

It turns out that DNN uses a “fileticket” parameter in the file link URLs, and mod_auth_cas uses a “ticket” parameter.? But mod_auth_cas was mistakenly stripping out DNN’s fileticket parameters.? A DNN URL would look like this: “/LinkClick.aspx?fileticket=DBDQlsksjlefwgb&tabid=70”.? After going through the reverse proxy, mod_auth_cas had mangled it to “/LinkClick.aspx?filetabid=70”.

Someone involved with mod_auth_cas pointed me to the bug tracker, and there was a fix for the URL mangling.? You need to get the latest source files, compile them, and the issue is gone!

We set up a Windows Media Server just like we’ve done many times before, but this time we were not able to connect to the streams from outside the local network.? After spending a lot of time verifying that it wasn’t a firewall problem, I found this article that gave an answer: the media server rejected the requests because it didn’t like the dns name in the URL.? Adding the public dns name to the localhost like of the media server’s hosts file fixed it.

Thanks, David!