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.

SocketException on host over SmartPass VPN

I have ASP.NET code that attempts to access a particular database over a SmartPass VPN connection. After trying several different ways to avoid the "host not found" SocketException, I copied the ASPX page to a server inside the VPN -- the page worked with no problems. Then I copied the same code into a simple exe (console app); again, it worked fine. I'm at a loss of what the problem is. I know that the ASPX code has DnsPermission, etc., but I haven't been able to find any other clues via google, etc. If you have any ideas, please send them my way.

SQL 2K: User Defined Types are such a pain!

The promise of User Defined Types is huge, but the headaches may not be worth the effort. With one of my clients we need to be able to easily change UDT definitions and get It Just Works (IJW). For example, we create a StringType_50 that can either be varchar(50) or nvarchar(50). Works fine for table definitions and for sproc params. But if you need to create a temp table in a sproc, you can't use the UDTs. Well, you can create the UDT in the tempdb. We have very restrictive production security issues, and I don't know what the issues are re: ability to create types in tempdb. I will probably mess around with that option later. For now, however, IJW just isn't there w/UDTs.

Don't use SQL Server 2000 Table Variables

SQL 2k's table variable is handy in some ways -- less locking required during transactions, fewer sproc recompiles than temp tables. However, I don't recommend using table variables because:

• Table variables cannot be defined using User Defined Types. We use UDTs frequently to enforce consistency in even the smallest dbs. Table variables force you to break this best practice and reverse its benefits.
• Unclear that the variable is a table. The # (or ##) prefix of temp tables gives immediate indication that it is a table. Although good naming conventions could be used to reduce this, naming conventions aren't validated by the compiler.

Power Blogger?

Am I a power blogger or what? It's only been 6 MONTHS since my last entry. Oh yeah -- all over this bloggin' thing.

MS Enterprise Library for GAC

Since I need to use E/L for several apps on a current project, I want to GAC the whole thing. I also want to make it easy for all the devs (of course). Easy solution, right? Just create an installer to gac the E/L assemblies. Well, I had more trouble than one would expect. One of the major hurdles was fairly obscure, so I want to record it here.

Update App Config After GAC'ing Enterprise Library

The biggest gotcha I ran into is that using the E/L config tool for an application sets PublicKeyToken=null in the reference info. This will cause exceptions similar to "Logging.Configuration.ConfigurationException" to occur. To correct this problem, add the PublicKeyToken from the GAC for each E/L assembly to the appropriate location in the app's config files.