Map of Renewable Water

Here's the map!

PowerShell 1.0 / WMI / IIS 6.0

Here are a few simple PowerShell 1.0 scripts for collecting info from IIS (6.0 on Windows Server 2003 in my case). I'm putting here primarily for my own reference, but hopefulle someone else will find them useful.

write-host "### -----"
$t = get-wmiobject IISWebVirtualDir -namespace "root\MicrosoftIISv2"
$t | ft AppPackageID, AppPackageName, AppRoot, Name
# $t | ft AppIsolated, AppPackageID, AppPackageName, AppRoot, Caption, ' Description, InstallDate, Name, Status

renders

$t = get-wmiobject IISWebVirtualDirSetting -namespace "root\MicrosoftIISv2"
$t | ft AppFriendlyName, Name, Path, Realm
# $t | ft AppIsolated, AppPackageID, AppPackageName, AppRoot, Caption, ' Description, InstallDate, Name, Status

renders

Windows Update for Home Network

If you have a home network of Windows PCs, wouldn't it be nice to download the monthly updates once (rather than to each PC independently)? Sure, you could manually copy the files to a network share and manually execute them from each PC. But believe me, that gets to be a hassle! You have to take lots of issues into consideration: 32- or 64-bit; WinXP, Vista, Server 2000, 2003, 2008; Office XP, 2003, 2007; etc.


If you're using some version of Windows Server, it's pretty easy to set up your own Windows Server Update Service (WSUS). Visit http://technet.microsoft.com/en-us/wsus/ to download, install and configure WSUS.


Now, in order to have your PCs reference your WSUS rather than Windows Update, you need to change a couple of policy objects. Since I'm using a domain for my home network, I use the Group Policy Object Editor once and all the PCs pick it up. I believe the same changes will work by applying them to a PC's Local Policies.


Open the Policy Object Editor and navigate to Administrative Templates / Windows Components / Windows Update.







The pane to the right will show the applicable settings for Windows Update.


Now you need to open the policy for Specify intranet Microsoft update service location Properties and provide the URL to your WSUS machine. You may have to check in IIS Manager to determine the correct port.




Your domain-connected PCs will pick up the change on their next policy load. You'll know that the client PCs are using your home WSUS when they appear in the Computers list of the WSUS admin application (Administrative Tools / Microsoft Windows Server Update Services 3.0)

Windows Policies and Settings for Virtual Machines

Here are a few useful configuration settings for Windows when installing as virtual machines (VMWare, Virtual PC, Virtual Server, etc.) Some of these settings are inappropriate for production systems; I'll try to clarify in those cases.

Clear Pagefile on Shutdown

This will help reduce the VM's disk space demands. Although many VM hosts may take of this directly, to make sure it's cleared out set the following Group Policy Object (GPO)

Local Computer Policy\Computer Configuration\Windows Settings\Security
Settings\Local Policies\Security Options\Shutdown: Clear virtual memory
pagefile

Allow Shutdown Prior to Logon (Non-Production)

It's valuable for personnel who can't log on to a VM (no access, forgot password, etc.) to be able to shutdown the OS w/o logging in. Enable the following GPO:

Local Computer Policy\Computer Configuration\Windows Settings\Security
Settings\Local Policies\Security Options\Shutdown: Allow system to be shutdown without having to log on

Allow Power Users to Shutdown the OS (Non-Production)

Add the local Power Users group to the following GPO:

Local Computer Policy\Computer Configuration\Windows Settings\Security
Settings\Local Policies\User Rights Assignment\Shutdown the system

Visual Studio 2008 Unattended Setup Fails on Longhorn

Problem: Visual Studio 2008 unattended setup from DVD fails on Windows Server 2008 (Longhorn) RC0
Root Cause: Unattended setup is not supported from DVD
Work-Around: Run unattended setup from a network share.

We had the bright idea for unattended Visual Studio 2008 setup. The theory was that we would create the unattend file using setup's CreateUnattend switch, copy it to the DVD and update autorun to trigger the unattended installation. All our devs would need to do is load the DVD, go get a cup of coffee and voilà! VS 2008 would be ready for action.

Unfortunately, it didn't work as expected. After several attempts with minor changes (full path, quoted path, etc.), I finally dug into the log files (in \Users\AppData\Local on Longhorn). Setup creates at least 3 log files in this folder - dd_depcheck_VS_PRO_90.txt, dd_error_vs_procore_90.txt and dd_install_vs_procore_90.txt. The error file was sufficiently helpful. The first 2 lines show:

[11/26/07,15:45:23] vs70uimgr: [2] Admin deployment is not allowed from a
CD/DVD.

[11/26/07,15:45:23] setup.exe: [0] InitializeUIManager(), Start
failure

That's pretty clear and straight-forward.

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.

ASP.NET Apps within SharePoint

While designing a digital asset management system for one of my clients, I considered running the ASP.NET app within SharePoint by simply instructing SharePoint to exclude the path. This is a pretty good idea, if the app can live within the confines SharePoint imposes. Authentication & Session, for example, can't be controlled at the this level.

If your app needs to impersonate, the capabilities are limited. Setting impersonation in the identity element causes the Windows Identity to be IUSR_. Leaving impersonation off causes the Windows Identity to be that of the App Pool (NETWORK SERVICE in my case). In either case, the Page and Thread Principals are empty since the Directory Security setting in IIS allows anonymous. Changing the Dir Sec setting does as you'd expect -- the Page and Thread Principals are set appropriately, impersonation is set, etc. But, now the entire top-level SharePoint site requires authorization (no anonymous access).

ASP.NET Impersonation and Principals

Every now and then I write a simple app to remind myself of what the principals are for the various impersonate config options. Maybe in the future I'll remember to look here.

Assumptions:

• VRoot requires authentication (anonymous disabled)
• VRoot's App Pool identity using NETWORK SERVICE
• "IEUser" is the end user
• "ImpersonatedUser" is the user config'd in the identity element

Scenario	Page User	Thread CurrentPrincipal	WindowsIdentity
impersonate=false	IEUser	IEUser	NETWORK SERVICE
impersonate=true; userName not set	IEUser	IEUser	IEUser
impersonate=true; userName set	IEUser	IEUser	ImpersonatedUser

So, the identity of System.Security.Principal.WindowsIdentity is the only one that changes. Page.User should typically be used for IsInRole checks.

SharePoint & WSS_Medium

As I mentioned in an earlier post, I've been trying to determine the overhead involved with updating data via SharePoint WebParts vs. ASP.NET WebForms. To get started, I created a simple WebPart to render the request's query params to a HTML table. So, the first problem I ran into is that a WebParts do not have access to the params collection due to CAS. When I exec'd the page, an error regarding "LinkDemand for AspNetHostingPermission failed" (or similar). So, my WebPart didn't have this permission. I added it to GAC, but elevating it to Full trust probably isn't a good idea. Thanks to several blog posts (Debugging Web Parts - a full explanation of the requirements in particular) I changed the system.web/trust config from level='WSS_Minimal' to 'WSS_Medium' This brought my WebPart back to life, and I believe I'm operating in a least required security mode now.

Applications in SharePoint

I'm architecting a solution for a customer which would benefit from several features in SharePoint 2003 (Tasks, Alerts, doc repository, etc.) The solution will need several of these concepts, and I hope SharePoint's features will be a good match. However, I'm concerned that data entry pages will be complicated by the fact that SharePoint uses WebParts in zones on the page. This is similar to other frameworks I've used, yet so far I have not been able to determine the amount of additional overhead required to do data entry in SP.

WebParts are very similar to Server Controls in ASP.NET -- code in an assembly writes HTML to the output stream. No big deal from the output standpoint, but you don't get as much of the input benefits from ASP.NET controls (DataGrid is a good example).

Big Gaps

Wow! It's amazing how long the "dry spells" are between my blogging activities. Too busy!

XSLT, XPath and GUID's

Ahh, GUIDs. We love 'em; we hate 'em. Actually I usually love them, but querying for GUIDs in XML is fraught with peril. Consider a simple case of seaching for a Person node by the value of an attribute:

<xsl:template match="//Person[@PersonID='3'] >
...
</xsl:template>

But what if the unique identifier for Person nodes is a GUID?

<xsl:template match="//Person[@PersonID='
{4C22F4FA-0C4A-4FCF-85DF-F9B7A902244E}'] >
...
</xsl:template>

• What GUID format is used in the XML?
• Bracket notation?
• Hyphenated?
• Mixtures?
• With which casing are the alphabetic portion of the hex values stored in the XML?
• Upper case?
• Lower case?
• Mixture?

As you can see from just these two items, the matrix of problems expands rapidly. In the particular case I am dealing with, I am able to control format (bracketed, hyphenated), but not case. I have had to assume that case will be either upper or lower, but that mixed case will not occur (a fairly reasonable assumption since the GUIDs are not manually edited; for code to render mixed case it has to do extra work). So, my XSLT file finds the appropriate node by this method:

<xsl:param name='FindThisGuid'>
<xsl:variable name='UCaseGuid' select='translate($FindThisGuid, "abcdef", "ABCDEF")'>
<xsl:variable name='LCaseGuid' select='translate($FindThisGuid, "ABCDEF", "abcdef")'>
<xsl:template match='Person[@PersonID = $UCaseGuid) Person[@PersonID = ($LCaseGuid)]>
...
</xsl:template>

Now the Good News: XSLT 2.0 will hopefully resolve this issue by promoting GUID to a first class citizen (actual type).

IE Gotcha! Do Not Use Self-Closing Script Tag

I recently had the (ahem) pleasure of helping a colleague debug a JavaScript problem. The issue was the he had multiple JavaScript blocks on a page like this:

<script type='text/JavaScript' src='uitools.js' />
<script type='text/JavaScript'>
function DoSomething() {
//...
}
</script>

Seems harmless enough, right? For the longest time we could not determine why DoSomething was not accessible to page elements. We tried all kinds of things until we stumbled upon a surprising resolution. We began to drill in on the issue when I moved the DoSomething function into the upper script block (which required breaking open the self-closing script tag). Suddenly, page elements could use the function successfully. After we moved the function back to its rightful home, everything still worked. Then I realized that the only difference was that the upper script block was no longer self-closing. When I converted it back to self-closing, sure enough the page stopped working again.

For some reason IE (and possibly other browsers) does not handle self-closing script tags in an XML compliant manner. Go figure!

BP: 15 Minutes Isn't Enough

One of the pitfalls of the internet era is that we easily forget that communication takes time. Today's case in point has to do with product build announcements. On my current project, the dev team's "practice" is to send email announcing, "We're going to sync & build in X minutes. Don't check in anything until we send email announcing a successful build." (Formerly X was 5 minutes; recently it has trebled to a whopping 15. The fact that the dev team builds on a random schedule is poor practice in the first place.)

The person who does these builds seems to think that everyone receives the email instantaneously and that they will act on the information immediately. As is predictable, however, the builder frequently sends email along these lines, "Everybody stop checking in! I haven't been able to build." or "We will not have a build today because too many checkins occurred after the cut-off."

The problem is that people are not immediately in tune with email in some Borg-like fashion. We need consistent, dependable builds; but we're trying to deliver randomly.