Windows Internal Database will not start after Install Active Directory

My only problem with this is that on a properly functioning WSUS 3 server,
IIS_WPG has no permissions on %windir%\temp.

But, perhaps, this whole issue has been remediated in WSUS 3.0. I don't even
see that any IIS account has any permissions on the \Program Files\Update
Services tree at all on my current WSUS 3.0 front-end server.

Also, since I don't at the moment have a point of reference on an SP1
server, or a WSUS 2.0 server, we've still left unaddressed the issue of the
IWAM_machinename account in the ACLs of the \Program Files\Update Services
folder tree on a WSUS 2.0 server.

Doh!... WSUS 2.0 -- the one we've been talking about since this thread
started.

And.. if the IWAM or ASPNET accounts don't matter, then we've still not
resolved the question of why IIS needs to be reinstalled on a WSUS 2.0
server.

Nor, why your obviously simple solution doesn't seem to be documented
anywhere in the Microsoft Knowledge Base, including those articles
specifically targeted at this scenario (i.e. running dcpromo on an
IIS-installed system).


I already did. Please reread the thread history -- either this
thread, or our other monolithic thread on this same subject.

There are no out-of-process COM+ applications in WSUS to support. WSUS is,
and always has been, an entirely .NET-based webservices enviroment.

I'm not "suggesting" anything. I'm merely pointing out to you what the facts
are. WSUS 2.0 configures IWAM_machinename in the ACLs for \Program
Files\Update Services, and when you 'dcpromo' a WSUS 2.0 server, it breaks
it to the point that IIS must be reinstalled so that the IWAM_machinename
account is in the correct account domain.

Maybe it did do that to support co-existence on Windows 2000 as well as
Windows Server 2003. Maybe it doesn't do it anymore because it no longer has
to support coexistence on a Win2000/IIS5 environment.

But, either way, it does not discount the (as yet unrefuted) fact that
running 'dcpromo' on a WSUS 2.0 server requires reinstallation of IIS.

Yes.. and a hundred empirical examples of the failure over the past two
years would suggest otherwise.

I don't want to waste time with pointless hypothetical speculation - I'd
just rather look at the issue in question and see if a resolution can be
achieved.

I have a test machine configured. If you can send me a list of functionality
that doesn't work, I will endeavour to find out what IIS reconfiguration is
required so that it's not longer "broken".

hi all , i got the internal error problem and i réinstalled the win server 2003 R2 SP2 than make it a DC and when i tried to install WSUS3.0 SP1 it wont be installed at all i got the message " faild to create local group..."

Domain controllers cannot have a local group.

When you make a server a DC it eliminates any local groups.

Put WSUS on another server.

[XLNNYC]

This is a related issue someone may have a clue about. I am running plain old XP SP3 and Office 2007 Enterprise Edition. The internal SQL server also gives an error message in the event log after I joined a domain (i think, because i noticed that sometime later)

The error message in the event log is

Source MSSQL$MSSMLBIZ event ID 17207
FCB::Open:Operating system error 5(Access is denied) occured while creating or opening file 'c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\master.mdl" Diagnose and correct the operating system error and retry the operation.

Seems like Microsoft has offered same patch but I can't get that to work ..
http://support.microsoft.com/kb/929665

"To work around this issue, repair Windows Internal Database. To do this, run the following command line at a command prompt:
Msiexec /i SSEE_10.msi CALLERID=OCSetup.exe REINSTALL=ALL REINSTALLMODE=omus /qn REBOOT=ReallySupress /l*v <Log_File_Path> "

Trying this return a syntax error. - I can download SSE_10.msi and but it in the directory where i run this command line, but same syntax error.
Where would i find the right program or how do i correct the OS/ SQL config?

[joel84]

"To work around this issue, repair Windows Internal Database. To do this, run the following command line at a command prompt:
Msiexec /i SSEE_10.msi CALLERID=OCSetup.exe REINSTALL=ALL REINSTALLMODE=omus /qn REBOOT=ReallySupress /l*v <Log_File_Path> "

This command is used for repairing the database. But even after doing the repair, if you are getting the same error, that means there are some files that are missing from it. So I would like to suggest you to re-install the SQL. Reinstalling it might resolve the problem.

[BrianFink]

Good Morning

I also have this posted on the Technet forum board:

Good Morning,

I'm the system admin for a small company. We have a dedicated domain controller but it is the only one. To get a second domain controller up and running on our domain, I installed the AD role on our file and in-house testing SQL server. I found the article

http://support.microsoft.com/kb/929665

In the article it reads

To work around this issue, repair Windows Internal Database. To do this, run the following command line at a command prompt:
Msiexec /i SSEE_10.msi CALLERID=OCSetup.exe REINSTALL=ALL REINSTALLMODE=omus /qn REBOOT=ReallySupress /l*v <var><Log_File_Path></var>

My question is what is the Log_File_Path? Is that where I installed the AD log path or is that a SQL log path?

It also appears that we might have to uninstall and then reinstall SQL?

My DBA is also looking into this.

Thanks in advance,
Brian

[Janos™]

Hi BrianFink,

I guess Log_File_Path is used for SQL. You can read more about it here - http://technet.microsoft.com/en-us/l...7(SQL.90).aspx

Apart from the, I also faced similar problems and to solve it I followed the below suggestions:

Check out this KB first 925976 ( http://support.microsoft.com/kb/925976 ) .

This might fix the problem that I saw when I ran KB929665. I did not find this until later and I resolved the problem using the "brut force" method. Not graceful but successful.

Here were my steps:

1. Uninstall WSS 3.0

2. Uninstall .NET 3

3. Uninstall Windows Internal Database: (http://technet2.microsoft.com/window....mspx?mfr=true)

4. Cleaned Registry as per 925976. I only found two keys: SQLGroup and FTSGroup)

5. Install AD

6. Install .NET 3

7. Install WSS 3.0

8. Restored Windows SharePoint Services 3.0 by using Central Administrator. I had previously setup scheduled tasks for Full and differential back-ups with a cmd line script using stsadm.exe

KB 929665 left out some key info. Here are the 2 cmd line that worked for me. I had to cd to the directory first. Putting the full path into the msiexec line did not work for me.

CD C:\Program Files\MSECache\wssv3\database

Msiexec /i SSEE_10.msi CALLERID=OCSetup.exe REINSTALL=ALL REINSTALLMODE=omus /qn REBOOT=ReallySupress /l*v C:\sqlfix.log

[BrianFink]

Thanks for the information.

I've passed it on to my DBA who is reviewing it. What really hurts is that one of our production databases is down, which I only found out recently.

Brian