Windows Defender Update Error 0x8024402c

I've been using Windows Defender (beta 2) for a while now, and haven't really had any complaints. Just recently, however, I've been getting message balloons from Defender saying that it hasn't been able to update itself for 14 days, etc. When I manually triggered it to check for updates, it would fail with error code 0x8024402c ( WU_E_PT_WINHTTP_NAME_NOT_RESOLVED).
Searching for info on this lead me to instructions on using msiexec to uninstall the existing virus signatures, etc., but none of this worked.

Then I realized that I had recently switched to using my own Windows Update Server (WSUS). WD must have been seeking the updates from my WSUS rather than windowsupdate.com.

Resolution: Use WSUS Admin to turn on "Definition Updates" and set them to install automatically.

Using Enterprise Library Logging Securely with ASP.NET Applications

Using the EL Logging Application Block with ASP.NET is a little tricky -- primarily due to the fact that, in a well secured ASPX app, the logging code will fail due to a lack of write permissions.

First, let's consider the security aspects. In order to keep ASPX apps locked down, I don't allow any users to write to the ASPX app's v-root hierarchy (except Admins & VS Devs groups of course). For example, an ASPX app may map to:

c:\inetpub\wwwroot\WebApp1

with directory hierarchy (under WebApp1 dir) containing folders such as:

bin
SubFolder1
SubFolder1

The WebApp1, WebApp1/SubFolder1 and WebApp1/SubFolder2 dirs may all contain .aspx or other script/executable files. I want the absolute minimum number of users to be able to write to this dir. Otherwise, the more people who have access (even via hacking), the more risk exposure to script injections, etc.

I frequently find that a developer's "solution" is to enable Write permissions on the v-root. This is a horrible mistake and practically unsecures the ASPX app. The correct (and secure) approach is to:

1. Create a separate directory to store the log files
2. Grant the (IIS 6.0) App Pool's Identity write permission to the new directory
3. Configure the logging distributor to point to target the new directory

Create a Directory for Log Files
Simply use Windows Explorer, the Command Prompt or the Installer to create a dir for the log files. I typically create this as a sub-dir of the v-root (e.g., c:\inetpub\wwwroot\WebApp1\Logs)

Grant Write Permission
Again, use Windows Explorer, an Installer Custom Action, or other method to grant Write permission to the appropriate identity. I typically grant Write permission to IIS_WPG since all App Pool Identities must belong to this group. However, if you use multiple app pools with differing identities, then you should grant permission to that specific identity -- this will protect against other App Pool Identities from writing to the Log dir. (If your ASPX app uses end-user impersonation, see the Impersonation Issues section below)

Configure the Logging Distributor
Now that you have created the log dir and given the App Pool's Identity permission to Write to the dir, you need to instruct the Logging Application Block to use this dir for the output log files. Where the output file (typically "trace.log") is stored is controlled by fileName attribute of the sink element in the logging distributor configuration file (typically "loggingDistributorConfiguration.config"). Simply change the fileName attribute by prepending the relative path information.

<loggingDistributorConfiguration>
<xmlSerializerSection Â… >
<enterpriseLibrary.loggingDistributorSettings
defaultCategory="General" defaultFormatter="Text Formatter" ... >
<sinks>
<sink xsi:type="FlatFileSinkData" name="Flat File Sink" fileName=".\Logs\trace.log" ... />
</sinks>

...

</enterpriseLibrary.loggingDistributorSettings>
</xmlSerializerSection>
</loggingDistributorConfiguration>

Impersonation Issues
If your ASPX app employs end-user impersonation, then you'll need to make a choice.

1. Unimpersonate -- more secure, but a little more difficult to get right
   
2. Use custom group which holds Write Permission; add end-users to this group
3. Stop using end-user impersonation (don't impersonate or impersonate specific identity rather than end-user)
   

I prefer #1 when #3 is not an option. To implement #1, google for info on System.Security.Principal.WindowsIdentity.Impersonate(IntPtr.Zero). This call has the effect of causing the thread to go back to its original identity. Be sure to use catch/finally with Revert in the Finally block. Otherwise, you'll create a large security hole.