Windows Internal Database will not start after Install Active Directory

Hello Jim,

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

Best regards

Myweb
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.

Post by Jim
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>
Thanks,
Jim

Jim

2007-07-12 18:45:10 UTC

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?
Jim

Post by Myweb
Hello Jim,
That's your installation file either on your server cd or sql cd. So
search on your disks for .msi files.
Best regards
Myweb
Disclaimer: This posting is provided "AS IS" with no warranties, and
confers no rights.

Fei Cao (MSFT)

2007-07-12 21:58:59 UTC

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.
--
Fei Cao
Microsoft, WSUS

This posting is provided "As Is" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Post by Jim
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?
Jim

Lawrence Garvin (MVP)

2007-07-13 03:32:00 UTC

Jim, can you please clarify your subject line...

Re: Windows Internal Database will not start after Install Active Directory

Did you run dcpromo on this system *after* installing IIS/WSUS???
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

Jim

2007-07-13 12:37:35 UTC

Lawrence,
It was a WSUS member server. Then I dcpromo it up to a DC.
Jim

Post by Jim
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?

Jim, can you please clarify your subject line...
Re: Windows Internal Database will not start after Install Active Directory
Did you run dcpromo on this system *after* installing IIS/WSUS???
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://www.microsoft.com/wsus
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

Lawrence Garvin (MVP)

2007-07-14 00:33:35 UTC

Post by Jim
Lawrence,
It was a WSUS member server. Then I dcpromo it up to a DC.

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.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

Ken Schaefer

2007-07-14 09:30:32 UTC

Of course you can dcpromo an IIS box

Cheers
Ken

Post by Jim
Lawrence,
It was a WSUS member server. Then I dcpromo it up to a DC.

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.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://www.microsoft.com/wsus
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

Lawrence Garvin (MVP)

2007-07-14 17:53:23 UTC

Post by Ken Schaefer
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.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

Ken Schaefer

2007-07-15 03:44:49 UTC

Post by Ken Schaefer
Of course you can dcpromo an IIS box

Only if you friggin want to break IIS!

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.

Post by Lawrence Garvin (MVP)
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.

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 :-)

Post by Lawrence Garvin (MVP)
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.

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

Post by Lawrence Garvin (MVP)
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.

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.

Cheers
Ken

[1] I've been an IIS MVP for nearly 5 years now, I've written books and MS
TechNet articles on IIS, reviewed IIS MOCs, presented at over half a dozen
TechEds on IIS etc.

Lawrence Garvin (MVP)

2007-07-15 04:38:10 UTC

Post by Ken Schaefer
Of course you can dcpromo an IIS box

Only if you friggin want to break IIS!

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

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.

Post by Ken Schaefer
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.

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.

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

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?

Post by Ken Schaefer
IIS will logon the new domain IUSR_<servername> account instead.

Which is a *real* problem when all of the NTFS ACLs have the
MACHINE\IUSR_<servername> SIDs in them!
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

Ken Schaefer

2007-07-15 04:59:03 UTC

Post by Ken Schaefer
Of course you can dcpromo an IIS box

Only if you friggin want to break IIS!

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

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.

Post by Ken Schaefer
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.

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.

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

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?

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.

Post by Ken Schaefer
IIS will logon the new domain IUSR_<servername> account instead.

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

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.

Cheers
Ken

Lawrence Garvin (MVP)

2007-07-15 16:02:18 UTC

Post by Ken Schaefer
IIS will logon the new domain IUSR_<servername> account instead.

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

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.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

Ken Schaefer

2007-07-16 07:15:34 UTC

Post by Ken Schaefer
IIS will logon the new domain IUSR_<servername> account instead.

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

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
\Program Files\Update Services - Read/Read&Execute/List Folder Contents
inherited to all child objects
\Program Files\Update Services\Logfiles - Full Control

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)

Cheers
Ken

Post by Lawrence Garvin (MVP)
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.

Ken Schaefer

2007-07-20 11:48:56 UTC

Post by Ken Schaefer
Of course you can dcpromo an IIS box

Only if you friggin want to break IIS!

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

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.

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.

Cheers
Ken

Lawrence Garvin (MVP)

2007-07-20 14:38:45 UTC

Post by Lawrence Garvin (MVP)
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.

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.

Thank you for the help, Ken! 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?
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

Ken Schaefer

2007-07-21 04:57:19 UTC

Hi,

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)

Cheers
Ken

Post by Lawrence Garvin (MVP)
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.

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.

Thank you for the help, Ken! 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?
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://www.microsoft.com/wsus
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

Lawrence Garvin (MVP)

2007-07-21 15:37:06 UTC

Post by Ken Schaefer
I did this test on a Windows Server 2003 R2 box with SP2 installed.

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.

Post by Ken Schaefer
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.

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.

Post by Ken Schaefer
Those accounts are there for legacy support (e.g. if you run IIS 6.0 in
IIS 5.0 Compatibility Mode)

Or if any application chooses to use them!
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

Ken Schaefer

2007-07-23 02:41:45 UTC

Post by Ken Schaefer
I did this test on a Windows Server 2003 R2 box with SP2 installed.

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.

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.

Post by Ken Schaefer
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.

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

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?

Post by Lawrence Garvin (MVP)
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.

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.

Cheers
Ken

Lawrence Garvin [MVP]

2007-07-23 04:07:27 UTC

Post by Ken Schaefer
I did this test on a Windows Server 2003 R2 box with SP2 installed.

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.

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.

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.

Post by Ken Schaefer
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.

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

What application are you talking about?

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).

Post by Ken Schaefer
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?

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

Well, I don't have a WSUS v2 application handy, so I will have to take
your word for it.

Thank you!

Post by Ken Schaefer
Perhaps that ACL was there to support Windows 2000 installations (where
IWAM_<machinename> is the default account for out-of-process COM+
applications).

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

Post by Ken Schaefer
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.

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.

Post by Ken Schaefer
Occam's Razor would suggest that something else is causing your issues.

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

--
Lawrence Garvin, M.S., MCTS, MCP
MVP - Software Distribution (2005-2007)

Ken Schaefer

2007-07-23 07:45:35 UTC

Post by Lawrence Garvin [MVP]

Post by Lawrence Garvin [MVP]

Post by Ken Schaefer
I did this test on a Windows Server 2003 R2 box with SP2 installed.

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.

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.

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

Before you DCPromo the "Users" group has ExecuteFiles, CreateFiles and
WriteData permissions to the c:\windows\temp folder. Those permissions are
removed by the DomainController security template that is applied by
secedit.exe during the dcpromo process.

All I did was add a subset of those users back (IIS_WPG) group. Instead of
configuring three permissions, I just ticked the "Modify" box.

Post by Ken Schaefer
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.

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

What application are you talking about?

OK - I am going to need some guidance on what is broken here. Do you have
concise, authorative list of issues so I can work out what IIS config needs
to be changed?

I installed WSUS 2.0 SP1 onto a Windows Server 2003 R2 box (no SP2) and
dcpromo-ed the box. IIS still works, and the WSUS admin site still works.
So, presumably something else is not working and I just need to figure out
what needs to be tweaked to get it working.

Rather than try to test every possible piece of functionality, can you
provide a list of what doesn't work and I'll work out what needs to changed.

Post by Lawrence Garvin [MVP]
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 have no idea why it's not documented. But can you test it please, and
either tell us whether it works for you, or whether it's not working and
there are additional steps that need to be done?

I didn't test every piece of functionality, but certainly the "Windows
Internal Database" mentioned in the subject title is started, and the MMC
console is able to connect and administer WSUS v3.

Post by Lawrence Garvin [MVP]
Furthermore, the previously mentioned failures of WSUS on a
Win2003SP1/IIS6/WSUS2 machine also contradict the statement.

<snip>

Post by Lawrence Garvin [MVP]
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.
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.

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".

Cheers
Ken

unknown

2008-06-20 16:34:32 UTC

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..."

thnks for ur help

unknown

2008-06-20 16:34:17 UTC

Myrt Webb

2008-06-20 17:24:31 UTC

Domain controllers cannot have a local group.

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

Put WSUS on another server.

Post by unknown
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..."
thnks for ur help

Jim

2007-07-13 14:32:34 UTC

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.

Post by Jim
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?

Jim, can you please clarify your subject line...
Re: Windows Internal Database will not start after Install Active Directory
Did you run dcpromo on this system *after* installing IIS/WSUS???
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://www.microsoft.com/wsus
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

Jim

2007-07-13 14:24:23 UTC

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) <***@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..
Thanks,
Jim

Jim

2007-07-13 16:52:43 UTC

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.
Jim

Post by Jim
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>
Thanks,
Jim

Lawrence Garvin (MVP)

2007-07-16 03:55:02 UTC

Post by Ken Schaefer
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.

The world is an especially strange place. Today I installed WSUS2 RTM and
WSUS 2 SP1 on a Win2003SP2 system, and much to my surprise discovered that
where the IWAM_<machinename> account used to be configured in the ACLs, now
the ASPNET Machine Account is being used in its place.

The only remnant proof of what I once observed that still exists is a
\Program Files\Update Services folder on an SBS2003 SP1 machine with WSUS
since uninstalled, that still has the DOMAIN\IWAM_<machinename> in the ACL.

I'm wondering if this is a manfestation of installing WSUS on a Win2003SP2
system instead of a Win2003SP1 system<???>

I also have an SBS2003R2 system in a VM that I was using for doing some
install testing. Checking the ACLs on that machine also shows the
DOMAIN\IWAM_<machinename> account.

I'll need to gen up a Win2003SP1 non-DC system to get the rest of the story.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E

Everything you need for WSUS is at
http://www.microsoft.com/wsus

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....

v***@gmail.com

2013-11-05 16:58:24 UTC