Windows Internal Database will not start after Install Active Directory

Hello,

I read the KB article below for the fix BUT where is the <MSI_File_Name> the
article is asking for? How can I download the job?

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

Msiexec <MSI_File_Name> CALLERID=OCSetup.exe REINSTALL=ALL
REINSTALLMODE=omus /qn REBOOT=ReallySupress /l*v <Log_File_Path>

That's your installation file either on your server cd or sql cd. So search
on your disks for .msi files.

Well I actually set up wsus3.0 using the WSUS3Setupx86.exe which installed
the Windows Internal Database on it's own so I don't have a Windows Internal
Database.msi. Thats My problem. Where is and which .msi am I looking for?

When you run the setup binary (.exe file), it self-extracts to a temp
folder. The MSI is under wYukon sub folder inside that temp folder.

can you please clarify your subject line...

Windows Internal Database will not start after Install Active Directory

Did you run dcpromo on this system *after* installing IIS/WSUS???

Well I got the .msi and ran it but I kept getting the popup screen with all
the msiexec.exe switches. The following was my command line:
E:\>Msiexec ssee_10.msi CALLERID=OCSetup.exe REINSTALL=ALL
REINSTALLMODE=omus /q
n REBOOT=ReallySupress /l*v E:\log

I also did what Fei Cao (MSFT) <feicao@online.microsoft.com> said in a
related article to unistall wsus3.0 which was successful:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup], change
the value for "wYukonInstalled" from 1 to 0, then run the unstall --you need
to choose to leave Database behind on the first page of uninstall wizard.

Problem: The Windows Internal Database is still in the add/remove programs
and will not allow me to remove it with a fatal error and when I reinstall
wsus3 it tries to connect to the Windows Internal Database but fails.

Any other ideas? I really dont want to flatten the box and start over. It is
in production because it was working fine untill I promoted it to a DC..

Oh by the way I ran also:
"msiexec /x {CEB5780F-1A70-44A9-850F-DE6C4F6AA8FB} CALLERID=ocsetup.exe" and
this uninstall operation failed with a fatal error.

Well after all the mombo jumbo typed below. I changed the service startup
for WID from network service to local system account and the WID started. I
was now able to reinstall WSUS3 and it connected to the database.

Well.. that's the FIRST thing that broke the box.

You *cannot* dcpromo an IIS server. Period.

Uninstall WSUS. Uninstall IIS. Reinstall IIS. Reinstall WSUS.

Of course you can dcpromo an IIS box

Only if you friggin want to break IIS!

Trust me, Ken.. I've seen several *hundred* attempts of people running
dcpromo on an IIS-installed box, and every one of them *breaks* IIS.

Here's exactly what happens:

When you install IIS on a non-DC server, it creates LOCAL accounts:
IUSR_machinename and IWAM_machinename, which are stored in the local SAM.
Everything that accesses IIS anonymously goes through the IUSR_machinename
account.

When you run dcpromo on such a system, it wipes out the SAM. Anonymous users
then try to find the IUSR_machinename account and it doesn't exist. Nothing
will work.

That's just the *basic* stuff! The complex stuff is even more complicated.

A similar problem occurs if you run dcpromo on a Domain Controller with IIS
installed. In this case the IUSR_machinename and IWAM_machinename accounts
are stored in Active Directory. Demoting the machine then makes all IIS
requests try to find the IUSR_machinename and IWAM_machinename accounts in
the local SAM -- but they don't exist.

Can you "fix" the scenario without uninstalling IIS. Sure you can. Microsoft
documented it a KB article for all those people who tried to dcpromo their
IIS box.

First option is to manually recreate the accounts in the domain, and
properly reassign *ALL* necessary permissions across the web server to those
domain accounts. This is not as simple as it might seem.

http://support.microsoft.com/kb/300432/en-us

This article used to be much more complicated that it is now (the article
used to explain how to 'reassign' all of the necessary permissions), and
really only applies to IIS5 on Windows 2000 -- which is a much less
complicated beast than IIS6 on Windows Server 2003.

But the problem also is that the local SAM is not the only thing dcpromo
messes with on an IIS-installed system:

http://support.microsoft.com/kb/332097/en-us

The *BEST* solution is to not run IIS on a Domain Controller at all.

The next *best* solution, if it becomes necessary to run dcpromo on a
machine with IIS installed is to:
[a] Uninstall all web applications.
[b] Uninstall IIS.
[c] Run dcpromo.
[d] Install IIS.
[e] Reinstall all web applications.

I've been doing this for a long time [1]. I can assure that there is no
issue running dcpromo to make the machine a Domain Controller. It certainly
doesn't break IIS per se

Running dcpromo does change a few things:
a) local account become domain accounts
b) a different security template is applied
So, if you app depends on any of these things you may have some issue that
you need to work around.

But IIS itself does not break just because you run dcpromo.

I would suggest you try this again. Install IIS on a vanilla Windows server
box, then dcpromo it.

"Trust me" is all well and good, but being an IIS MVP, I'm sure I have
looked at more IIS scenarios than you have :-)


IIS will logon the new domain IUSR_<servername> account instead.

There can be issues running DCPromo to remove AD on a machine that is
running IIS (I didn't consider this scenario in my original statement).
Effects vary depending on whether this is last DC in the domain or not.

I'm happy to discuss these as well, depending on the scenario that is being
faced.

I may concede this semantical argument, but a very simple application, like
WSUS, which pretty much runs as a anonymous access resource, gets totally
broken.

Riddle me this, then. :-)

If IIS wasn't broken in such a scenario, then one should only need to
uninstall the =APP=, and reinstall the =APP, and no changes on IIS would be
required at all. But several dozens of peoples, perhaps a hundred or more,
have personally observed the ramifications of running dcpromo on a WSUS
Server, and the *only* functional fix requires the uninstallation of IIS.

You know.. I'll concede *this* scenario doesn't break anything.

But IIS is merely a *platform*. Now put an application on top of that
platform -- something simple like WSUS. Run dcpromo on a WSUS server. WSUS
breaks. Uninstall WSUS. Reinstall WSUS. WSUS is still broken? Why? Because
IIS needs to be reinstalled. Why does IIS need to be reinstalled if it's not
broken?

Which is a *real* problem when all of the NTFS ACLs have the
MACHINE\IUSR_<servername> SIDs in them!

Well, I have not run into this scenario. What the specific fix is will
depend on what the specific error is. I will give this a go and see what
shakes loose.

Which resource's access control lists (ACL)s have the SID for
machine\iusr_<machinename>?

All critical resources that IIS needs have ACEs for either the IIS_WPG or
the Users group, or are never touched by IUSR_<machinename> in the first
place (e.g. IUSR_<machinename> is not used by .NET applications). That is
why IIS continues to work even after DCPromo and making the box a DC.

Actually, I misspoke, it's the IWAM_<machinename> account, and it's in the
ACL for the following WSUS resources:
\Program Files\Update Services - Read/Read&Execute/List Folder Contents
inherited to all child objects
\Program Files\Update Services\Logfiles - Full Control

And.. now that I think about this, it may be that the reinstall of WSUS
doesn't 'fix' anything, because these two root folders never get removed
during the uninstall, thus the ACLs do not get updated. Maybe this *is* a
WSUS problem.. and if so... it's been around, and unreported for a very long
time.

I'll do some investigation of my own along these lines. I must admit, I've
never dug deeply into this issue, as I've taken the simple advice of not
installing IIS on a DC, but, sadly, many others have done so -- and our only
observation here (in this newsgroup) was that fixing the problem required
reinstalling IIS.

Thank you for the constructive feedback.

IWAM_<machinename> isn't used by IIS6.0 unless you are running it in IIS 5.0
Compatibility Mode.

It might be used by other things (but it shouldn't - it's not supposed to
be).

In IIS 5.0, IWAM_<machinename> was used as the process identity to host the
IIS out-of-process applications in COM+. These apps were what you saw
running in dllhost.exe

But that's not used in IIS 6.0 (at least not in IIS 6.0 native mode)

I have posted the steps I took to get WSUS working again after doing a
DCPromo under the thread titled "WSUS 3 stops working after DC Promo"

If you have the time to validate those findings, that would be great.

A simpler solution for this oft-encountered
issue will be appreciated by many, I'm sure.

I'll definitely check them out.

As noted in an earlier thread, this problem may have been mitigated somewhat
by the apparent switch to using the ASPNET account, rather than IWAM_, in
the ACLs on Win2003 Service Pack 2 systems.

Just to clarify -- did you run this test on an SP1/R2 machine, or on a SP2
machine?

I did this test on a Windows Server 2003 R2 box with SP2 installed.

It should not make any difference whether directories are ACLed with either
IWAM or ASPNET user accounts, as neither is used by IIS 6.0 (or ASP.NET)
natively on Windows Server 2003. Those accounts are there for legacy support
(e.g. if you run IIS 6.0 in IIS 5.0 Compatibility Mode)

Given that very few WSUS installations have been made to SP2, and the
majority of the past two years were all on SP1, that's probably the more
appropriate platform to address this issue in.

It doesn't matter whether =IIS6= uses the accounts... it matters that the
=APPLICATION= uses the accounts!

The *facts* of the ACLs on the \Program Files\Update Services folder seem to
contradict your statement, Ken.

Furthermore, the previously mentioned failures of WSUS on a
Win2003SP1/IIS6/WSUS2 machine also contradict the statement.

Or if any application chooses to use them!

Just for you, I repeated the test on Windows Server 2003 R2 box (no SP2)

- Change logon account for Windows Internal Database to Local System
- Give IIS_WPG group Modify permissions to
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
- Give IIS_WPG group Modify permissions to C:\Windows\temp

and WSUS v3 seems to work just fine.

What application are you talking about? There are arbitrary accounts that
may, or may not exist, and may or may not have the actual names that are the
defaults.

Can you give me an example of such an application?

Well, I don't have a WSUS v2 application handy, so I will have to take your
word for it. Perhaps that ACL was there to support Windows 2000
installations (where IWAM_<machinename> is the default account for
out-of-process COM+ applications).

In any case, I don't see why WSUS v2 would be using that account *unless* it
was running on Windows 2000. Are you suggesting that WSUS v2 does
impersonation under the covers by creating a new WindowsIdentity and
impersonating IWAM even on IIS6? That sounds like crazy architecture to me.
Occam's Razor would suggest that something else is causing your issues.