I recently encountered an issue with NSIS that I believe is related to an interaction with UAC, but I am at a loss to explain it and I do not know how to prevent it in the future.

I have an installer that creates and removes IIS virtual directories using the NsisIIS plugin. The installer appeared worked correctly on my Windows 7 workstation. When the installer was run on a Windows 2008 R2 server it installed properly, but the uninstaller removed all of the virtual directories and put IIS is an unusable state; to the point that I had to remove the Default Web Site and re-add it.

What I eventually found was that all of the IIS configuration files under C:\Windows\System32\inetsrv\config had a lock icon on them.

Some investigation seem to indicate that this means a user account has taken ownership of the file, however all the files listed SYSTEM as the file owner. I did check a different server that I have not run the installer on, and it does not have the lock icon applied to the IIS files.

I have also seen the same lock icon appear on other files that the NSIS installer creates. For instance, I have a Web.Config.tpl file that is processed using the NSIS ReplaceInFile which also appears with the lock icon after the installer finished.

After I explicitly grant another user account access to the file, the lock icon goes away.

I run the installer under the local Administrator account on the 2008 R2 server, so I do not get the UAC prompt. Here is the relevant code from the install.nsi file

RequestExecutionLevel admin

Section "Application" APP_SECTION
   SectionIn RO
   Call InstallApp
SectionEnd

Section "un.Uninstaller Section"
   Delete "$PROGRAMFILES\${PROGRAMFILESDIR}\Uninstall.exe"
   Call un.InstallApp
SectionEnd

Function InstallApp
   File /oname=Web.Config Web.Config.tpl
   !insertmacro ReplaceInFile Web.Config %CONNECTION_STRING% $CONNECTION_STRING
FunctionEnd

Function un.InstallApp
   ReadRegStr $0 HKLM "Software\${REGKEY}" "VirtualDir"    
   NsisIIS::DeleteVDir "$0"
   Pop $0
FunctionEnd

I have three questions stemming from this incident:

1. How did this happen?
2. How can I fix my installer to prevent it from happening again?
3. How can I repair the permissions on the IIS config files.