I attended a pretty sweet SQL 2000 Reporting Services presentation today by my good friend Scott Golightly.  I was inspired, following the presentation, to install it on my local development machine today - I have immediate need for it and some future needs as well.

One thing the installer does is read the <processModel /> key from the machine.config in order to acquire the credentials (user name and password) of the user under which the Report Server web service will run.  Usually, this would probably be fine - in a production environment - but not in my development environment.  Because I don't run as a local administrator, I've changed the userName and password attributes from their default values of 'machine' and 'AutoGenerate' respectively to another value so that I can effectively debug ASP.NET applications, among other things.

There's a pretty slick utility (aspnet_setreg) that will encrypt a set of credentials and store them in the registry.  Then you simply update the userName and password attributes to resemble 'registry:HKLM\Software\...\ASPNET_SETREG,userName' and 'registry:HKLM\Software\...\ASPNET_SETREG,password' respectively and the ASP.NET runtime will read the encrypted values from the registry and impersonate that user in order to execute the code...pretty slick.

However, it appears that the Reporting Services installer will simply read the values from the <processModel> attributes and use the strings straight from the file.  Well, unfortunately (or perhaps, fortunately) there is no user 'registry:HKLM\Software\...\ASPNET_SETREG,userName' on my system so the installer fails when attempting to grant that user access to the %WINDIR%\Framework\Microsoft.NET\v1.1.4322\Temporary ASP.NET Files\ folder.

The trick is to temporarily change the attribute values to the same user whose credentials are encrypted for the duration of the install, then change them back.

I hope Microsoft fixes this bug, because it's pretty annoying, not to mention insecure.