MSDE 2.0 Install Fails - Unable to disable network access

I have one super stubborn machine that I am about ready to give up and redo Windows on in order to get MSDE to install.
I am trying to install MSDE 2000 Rel A on a DELL Latitude C840 Laptop. This laptop has all Windows Updates as of 5/20/04. It has MDAC v2.8 prior to install. Virus scan and spyware scan are both clean. I am installing under local Administrator account. I also close all background processes and apps prior to install. Machine name is all caps.
Here are my execution parms: (both have same results)
setup.exe SAPWD=@.@.@.@.@.@.@.
setup.exe INSTANCENAME=@.@.@.@.@.@.@. DISABLENETWORKPROTOCOLS=1 SAPWD=@.@.@.@.@.@.@.
Installation fails and then performs a rollback. I logged the install and here is what it is reporting:
================================================== =======
.
.
MSI (s) (8C:48): Creating MSIHANDLE (239) of type 790536 for thread 1096
SOFTWARE\Microsoft\Microsoft SQL Server Setup.{E09B48B5-E141-427A-AB0C-D3605127224A}
TempFolder is C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{E09B48B5-E141-427A-AB0C-D3605127224A}\
Loading extended custom action library C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{E09B48B5-E141-427A-AB0C-D3605127224A}\sqlcax.dll
SOFTWARE\Microsoft\Microsoft SQL Server Setup.{E09B48B5-E141-427A-AB0C-D3605127224A}
Starting custom action DisableNetAccess()
Error : unable to disable network access to MSDE.
Ending custom action DisableNetAccess()
Action ended 14:53:45: InstallFinalize. Return value 3.
MSI (s) (8C:48): User policy value 'DisableRollback' is 0
MSI (s) (8C:48): Machine policy value 'DisableRollback' is 0
.
.
================================================== =======
It is failing to disable network access to MSDE. I verified that all prereqs for installation (file sharing, and policy settings) are correct. I think I even tried holding my breath and standing on my head while installing with no success.
Any ideas, sympathy, or support? I have searched and searched on the net but apparantly I'm the only one with this particular installation error. Lucky Me.Ok - so I learned some more information about this machine. Apparantly it has had a lot of virus problems in the past with multiple instances of the W32.Netsky.P@.mm virus that were all "removed" with the installation of Norton Anti-Virus.
One thing I decided to try was to check the registry permissions that MSDE is trying to write as it installs. Specifically I checked the permissions on the key HKLM\Software\Microsoft\MSSQLServer and I found that no read or write permissions were set for any user. I set full control to SYTEM and Administrators using RegEdt32.
Upon another logged reinstall of MSDE I recieved a different error:
================================================== ======
SOFTWARE\Microsoft\Microsoft SQL Server Setup.{E09B48B5-E141-427A-AB0C-D3605127224A}
TempFolder is C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{E09B48B5-E141-427A-AB0C-D3605127224A}\
Loading extended custom action library C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\{E09B48B5-E141-427A-AB0C-D3605127224A}\sqlcax.dll
SOFTWARE\Microsoft\Microsoft SQL Server Setup.{E09B48B5-E141-427A-AB0C-D3605127224A}
Starting custom action SetFileAndRegACLs()
Installation drive does not support NTFS security.
Failed to set registry security.
Ending custom action SetFileAndRegACLs().
Action ended 9:27:12: InstallFinalize. Return value 3.
MSI (s) (E4:6C): User policy value 'DisableRollback' is 0
MSI (s) (E4:6C): Machine policy value 'DisableRollback' is 0
================================================== ======
This confirms that I am on the right path, but that this registry permission problem is bigger than I thought. I am wondering if there is some default registry permission that is out of whack that affect new entries being set to no read/write permissions for all users - most likely thanks to those friendly viruses that were running rampant before I came along.
Any thoughts or ideas?|||After more investigation into this registry permission problem I discovered that the registry permissions on this computer have been severely altered. (Problably by one of the many viruses that had been present and since removed)
Permissions on the top level keys, like HKEY_LOCAL_MACHINE, were set to to "Full Control for user Everyone" with no other users defined. No wonder when the MSSQLServer key was added under Software\Microsoft the Administrator and System users were denied permissions. These keys are created to inherit permissions - and with no Administrator or SYSTEM permissions set on top level nodes it just causes havok.
I also installed Norton Anti-Virus 2004 in replace of the "other" virus scanner and it had several problems during install that were related to registry permission failures.
I am offically giving up and re-installing Windows. There is no way I will ever hope to restore the correct permissions throughout the registry.