Windows Internal Database will not start after Install Active Directory

Discussion in 'Update Services' started by Jim, Jul 12, 2007.

  1. Jim

    Jim Guest

    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, Jul 12, 2007
    #1
    1. Advertisements

  2. Jim

    Myweb Guest

    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.
     
    Myweb, Jul 12, 2007
    #2
    1. Advertisements

  3. Jim

    Jim Guest

    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
     
    Jim, Jul 12, 2007
    #3
  4. 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
     
    Fei Cao \(MSFT\), Jul 12, 2007
    #4
  5. 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\), Jul 13, 2007
    #5
  6. Jim

    Jim Guest

    Lawrence,
    It was a WSUS member server. Then I dcpromo it up to a DC.
    Jim
     
    Jim, Jul 13, 2007
    #6
  7. Jim

    Jim Guest

    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) <> 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, Jul 13, 2007
    #7
  8. Jim

    Jim Guest

    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.
     
    Jim, Jul 13, 2007
    #8
  9. Jim

    Jim Guest

    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
     
    Jim, Jul 13, 2007
    #9
  10. 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\), Jul 14, 2007
    #10
  11. Jim

    Ken Schaefer Guest

    Of course you can dcpromo an IIS box

    Cheers
    Ken

     
    Ken Schaefer, Jul 14, 2007
    #11
  12. 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.
    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
    .....
     
    Lawrence Garvin \(MVP\), Jul 14, 2007
    #12
  13. Jim

    Ken Schaefer Guest

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

    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.
     
    Ken Schaefer, Jul 15, 2007
    #13
  14. 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!


    --
    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\), Jul 15, 2007
    #14
  15. Jim

    Ken Schaefer Guest

    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.

    Cheers
    Ken
     
    Ken Schaefer, Jul 15, 2007
    #15

  16. 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
    .....
     
    Lawrence Garvin \(MVP\), Jul 15, 2007
    #16
  17. Jim

    Ken Schaefer Guest

    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
     
    Ken Schaefer, Jul 16, 2007
    #17
  18. Jim

    Ken Schaefer Guest

    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
     
    Ken Schaefer, Jul 20, 2007
    #18
  19. 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\), Jul 20, 2007
    #19
  20. Jim

    Ken Schaefer Guest

    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
     
    Ken Schaefer, Jul 21, 2007
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.