Windows Internal Database will not start after Active Directory Install
As you can understand my issue by reading the title. I found a KB article which shows how to fix the issue. But still I am not able to find the msi file name. What does that means. From where I can download it. Can anyone provide me more highlight on the workaround part - Msiexec /i SSEE_10.msi CALLERID=OCSetup.exe REINSTALL=ALL REINSTALLMODE=omus /qn REBOOT=ReallySupress /l*v <Log_File_Path>
You cannot start the SQL Server service after you install Active Directory on a Windows Server 2003-based member server or you run the DCPromo command on a Windows Server 2003-based domain controller
re: Windows Internal Database will not start after Active Directory Install
I had gone with many measures to run IIS properly but yet not success in that. The issue appear when I installed IIS on a non-dc server. There are some local accounts which are created by the setup. Here all can access IIS through that IUSR_machinename account. So the next time when you run dcpromo it clears the SAM and other anonymous users tries to find the same on machine which does not exist. That is the reason does not work. There are some basic steps that you need to do to make this thing work. A same kind of issue also occur when you try to run dcpromo on a Domain Controller through IIS. The account I had mentioned above IUSR_machinename and IWAM_machinename is stored in Active Directory. You can manually create those accounts and then assign the necessary permission through the web server for those new accounts. I had provided a reference link below that can help you for the process.
How To Promote a Member Server Running IIS to a Domain Controller Running IIS
DCPROMO does not retain permissions on some IIS folders
re: Windows Internal Database will not start after Active Directory Install
I am facing issue with WSUS 3 proper function. I found that IIS_WPG does not has any permission on the temp folder. Other than this I cannot find any IIS account which has permission for Update service. The issue lies from a long time. Here for me the IWAN and ASPNET account really does not matter. As they are still a kind of unresolved issue. It is correct that Microsoft Knowledge Base offer more simple approach to the issue.
re: Windows Internal Database will not start after Active Directory Install
I am running Windows XP SP3 in one client system. Recently I had installed Office 2007 Enterprise edition. Now the internal sql error looks like giving some error. I had seen that in a log file. It was related to some event ID 17207. I found a patch on Microsoft to fix the same. It worked. You can check the link below. The work around mention in the patch is somewhat related to a common error which above all are facing. Hope this helps.
You cannot start the SQL Server service after you install Active Directory on a Windows Server 2003-based member server or you run the DCPromo command on a Windows Server 2003-based domain controller
re: Windows Internal Database will not start after Active Directory Install
Quote:
"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.
re: Windows Internal Database will not start after Active Directory Install
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
re: Windows Internal Database will not start after Active Directory Install
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
re: Windows Internal Database will not start after Active Directory Install
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