none
SQLRUN_SQL.MSI is not valid for Service pack 1 SQL 2005 command line REINSTALL

    Question

  • Hello,

    I have recently tried to run this command line utility for SQL Server 2005 -

    "start /wait \sqlfoder\setup.exe /qb INSTANCENAME=myinstance REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=[password] SQLCOLLATION=SQL_Latin1_General_CP1_CI_AI"

    Unfortunately I recived an error stating the "Installation package for the product SQL Server 2005 (64bit) cannto be found.  Please locate a valid SQLRUN_SQL.MSI".   Which I couldn't find anywhere., so....

    I created a fresh instance on my 2005 server, held back on installing SP1, and ran the command line again.   This time it worked.

    My best guess is that the installation scripts check the version header on the MSI file during install and display a compatibilty error thus halting the install.

    My question is, has anyone seen,  overcome this problem.  I can't believe that this is a bug like error as there would be posts about it all over the interweb.... which there isn't.

    Any thoughts.

    Mike.

    (p.s) I know that I shouldn't really try to amend the collation on a sql server, but I have little choice at the moment :-(

     

     

    Wednesday, June 28, 2006 3:28 PM

Answers

  • I believe I was able to repro this last night.  The issue only occurs if you don't have access to the original media location of where the RTM bits where installed from.  In that scenario, you see the error about the installation package not being found.

    To workaround this, run a similar reinstall command line first to re-cache the media from your new location.  The command line would look like this:

    \sqlfoder\setup.exe /qb INSTANCENAME=myinstance REINSTALL=SQL_Engine REINSTALLMODE=v

    After that succeeds, you can then run the normal rebuild database command line and it should succeed, as Windows Installer will know look for the RTM media from the new location.

    Friday, March 2, 2007 7:11 PM

All replies

  • Mike, is your original SQL installation on an x64 machine (with an x64 OS installed)?  And are you running the same setup.exe as the original install? 

    Thanks,
    Sam Lester (MSFT)

    Wednesday, June 28, 2006 3:41 PM
    Moderator
  • Hello,

    Thanks for the prompt response.

    Yes I am using the same installation files, on exactly the same machine that has the original installation (yes with an x64 OS installed).  

    In fact, in the test mentioned in my original post, if I upgrade the new Instance to SP1 and then run the CMD utility it now returns the MSI error.

    Cheers buddy

    Mike

     

     

    Wednesday, June 28, 2006 3:46 PM
  • Is there any chance this feature will be fixed, or working utility provided (suggest it could be called rebuildm.exe)

    It makes DR recoveries of SQL 2005 SP1 system extremely difficult, as it seems it is now necessary to completely reinstall SQL2005 from scratch, (by which time rebuilding of master database is a somewhat pointless exercise), upgrade to SP1, then start the reimport of the original backups of master extra.

    The clients are going to love the extra time being added to their recovery :(

    Thursday, March 1, 2007 12:34 PM
  • Are you seeing the same error as the original poster?  Could you clarify the details about the error you are seeing?  Could you start by posting the contens of the Summary.txt file from %programfiles%\microsoft sql server\90\setup bootstrap\log?
    Thursday, March 1, 2007 4:43 PM
  • The error and scenario was identical except we were using 32 bit OS and SQL.

    I tried 2 different media sources for the SQL setup files (Enterprise and standard), to be sure it was not a rogue corruption SQLRUN_SQL.MSI as the more detailed error suggests.

    Running the setup program without parameters throws a version error, it seems to think that SQL2005 no SP is a version upgrade of SQL2005 SP1.

    This was a DR (fortunately a practice), and it finished 30 minutes before your post, and I have left the site (100+ miles away). The servers have not been wiped yet (will be early tomorrow), if I can get details for VPN access tonight, I will try and get the log files to post, but am not too hopeful.

    A successful recovery was eventually achieved by arranging a service outage of the live system with the client, to get get copies of the system databases to use a a starting point, then restoring all the system backups over them, finally restoring the user databases.

    We will now be having to review a lot of clients SQL 2005 applications now (and trying to get service outages, so we can get offline backups of the master, model and msdb databases). Explaining to the clients that SQL2005 SP1 has broken the DR process will be very interesting I expect. Personally I have always prefered to start with the offline system copies, even with older versions, though getting this in place until now has been difficult.

    Two questions are coming out of this:

    1. Is there a way to create default system databases for SQL2003 SP1 (without a clean install and then service packing it)?

    2. Does SQL2005 SP2 support slipstream (which was expected), and will that therefore support creation of default system databases?

    Thursday, March 1, 2007 8:31 PM
  • Sorry if I'm not understanding the scenario, but can you confirm that you are asking how to perform a rebuild database operation after SP1 has been applied?  Is that what is broken?  Once SP1 is applied you can't get the rebuild database command line to succeed?
    Thursday, March 1, 2007 8:46 PM
  • Sorry for not being clear:

     I was trying to to carry out a rebuild database operation after SP1 has been applied.

    I did not try without SP1 (as that would have required a complete reinstall)

    ===============================================================

    This was discovered in a Disaster Recovery (DR) practise, the more precise scenario is.

    MS 2003 SP1 server with SQL 2005 SP1 is restored after a disaster from offsite tapes at the remote site of a DR provider.

    The normal process previously was to effectively initialise SQL server with new system databases (the rebuildm.exe method of old), then restore the system databases from backups, then restore the user databases (with loads of messing around with moving the db's at each stage).

    With SQL 2005 SP1 it seems this DR method has been superceded by a complete reinstall of the database server.

    Thursday, March 1, 2007 9:11 PM
  • Thank you, I understand the issue now.  Could you post the error details if you get access to the logs?  I just tried a rebuild database operation on a test SP1 instance, using RTM media, and I didn't hit a failure.  Therefore I'm going to need to know the exact error being hit to troubleshoot this.

    If you get the logs, I would like to see the Summary.txt.  It should list the error hit in the SqlRun_SQL.msi.  You can search inside the log it points you to for the error message listed, and then paste that to the forum.

    Thursday, March 1, 2007 9:51 PM
  • Just managed to get on the server before it was flattened...

    Microsoft SQL Server 2005 9.00.2047.00
    ==============================
    OS Version      : Microsoft Windows Server 2003 family, Enterprise Edition Service Pack 1 (Build 3790)
    Time            : Thu Mar 01 12:13:51 2007
     
    WRKSM1001 : To change an existing instance of Microsoft SQL Server 2005 to a different edition of SQL Server 2005, you must run SQL Server 2005 Setup from the command prompt and include the SKUUPGRADE=1 parameter.
    Machine         : WRKSM1001
    Product         : SQL Server Database Services
    Error           : An installation package for the product Microsoft SQL Server 2005 cannot be found. Try the installation again using a valid copy of the installation package 'SqlRun_SQL.msi'.
    --------------------------------------------------------------------------------
    Machine         : WRKSM1001
    Product         : Microsoft SQL Server 2005
    Product Version : 9.00.1399.06
    Install         : Failed
    Log File        : C:\Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG\Files\SQLSetup0021_WRKSM1001_SQL.log
    Last Action     : InstallFinalize
    Error String    : An installation package for the product Microsoft SQL Server 2005 cannot be found. Try the installation again using a valid copy of the installation package 'SqlRun_SQL.msi'.
    Error Number    : 1706

    A few extra bits of info may be relevant:

    1. SQL Install was to the E: drive

    2. There were no existing system or user databases, as this was a server restore.

    Friday, March 2, 2007 9:26 AM
  • I believe I was able to repro this last night.  The issue only occurs if you don't have access to the original media location of where the RTM bits where installed from.  In that scenario, you see the error about the installation package not being found.

    To workaround this, run a similar reinstall command line first to re-cache the media from your new location.  The command line would look like this:

    \sqlfoder\setup.exe /qb INSTANCENAME=myinstance REINSTALL=SQL_Engine REINSTALLMODE=v

    After that succeeds, you can then run the normal rebuild database command line and it should succeed, as Windows Installer will know look for the RTM media from the new location.

    Friday, March 2, 2007 7:11 PM
  • Excellent news, thanks for your help with this, much appreciated.

    I will add that to the generic SQL restore procedures, and hopefully test in the near future.

    Also the issue has been useful in getting focus on how useful offline backups of system databases are as an easier DR process, and that will be added to the SQL install and service pack process.

     

    Friday, March 2, 2007 7:25 PM
  • I had a similar problem. I couldn't manage to have an install location containing blank spaces.

    I managed to do it by keeping the installation files in the original inst. lib while installing from the new location. This fits the other given solution very well because the installation is able to read the msi header from the original file.

    But still i haven't figured out why the command line didn't like "c:\blablabla\bla    bla\setup.exe" /qn - it wasn't able to read the next parm.

    using an ini file might have been another solution to this now that i think of it. But i didn't try it out.

    Morten

    Tuesday, March 6, 2007 1:06 PM
  •  

    Hi All

    Thanks for your post. I also hit this issue where the MSI location could not be determined - and this post has corrected the issue.

    In my case I was running a SETUP command to rebuild the master database to a different collation on a SQL 2005 EE A-A-P cluster.

    I got the errors when I ran the setup from files copied to the C:\ array instead of from the D:\ array (which is where SQL was first installed from on this cluster).

    Quite amazingly simply moving the install kit files from C:\ to the orig location on D:\ fixed the issue!

    Again thanks for the post.

    Rolf

     

    Friday, September 21, 2007 8:24 AM
  • Hello,
    I had the same problem, but the line

    ... \sqlfoder\setup.exe /qb INSTANCENAME=myinstance REINSTALL=SQL_Engine REINSTALLMODE=v
    doesn't seems to working.

    Can you please help me on this?

    Thank you in advance,
    Stavros Makridis.
    smakridis@noesisnet.gr


    Monday, August 4, 2008 9:10 AM
  • Hi All - just adding more to this thread.

     

    My platform is a SQL 2005 x32 SP2 3168 Ent Edition Active-Active cluster.

     

    I also tried the REINSTALLMODE=v option and that didn't work.

     

    To work around this issue you need to update the registry as follows on ALL nodes in the cluster - or just the single server when running a standalone install.

     

    I reccommend to backup the registry before doing this.

    1. Open regedit
    2. Search for the string "SqlRun_SQL.msi". (the key will be found in several spots in the registry under HKLM and Classes Root)
    3. Where the key is found the registry structure will look something like this (example where D:\ is the DVD drive);

    HKLM\SOFTWARE\Classes\Installer\Products\B29A3732C1C117E44B49C59AF769AA91

    \Patches

    \SourceList

    \Media

    LastUsedSource = m;1;D:\Setup\

    \Net

    1 = D:\Setup\

    1. Update the \Media key "LastUsedSource" as the directory path to your new SQL 2005 media location. The rules for the key entry go something like this;

    m / n ; # ; <path>

     

    Where...

    m = media  ...or...   n = network

    # = a number that indicates the network path entry that corosponds to the entry under \Net

    <path> = the path to the "SqlRun_SQL.msi" file. You need to put a trailing "\" at the end of the path.

    1. Update the \Net key "1" as the <path> element to your new SQL 2005 media location. This just needs to be the directory path only. Sometimes this key does not exist. If not then you dont need to update or add it in. If it does the you need to update it.
    2. So after doing the update in my example from the D:\ DVD drive to my local hard drive, it would look something like this (example)

    HKLM\SOFTWARE\Classes\Installer\Products\B29A3732C1C117E44B49C59AF769AA91

    \Patches

    \SourceList

    \Media

    LastUsedSource = n;1;C:\Software\SQL2005\Servers\

    \Net

    1 = C:\Software\SQL2005\Servers\

    1. Search and update the rest of the registry for the search string. NOTE - You may find other search strings (ie such as the SQL 2005 Native Client or BOL install MSI's) but I have found that these do not need to be updated.
    2. Once updated, rerun the SETUP install command.
    3. Done!

    Also one more note for people who have copied CD media to the local disk. Make sure your copied local disk media structure contains the correct folder structure of \Servers and \Tools. Check this article; http://support.microsoft.com/kb/916760

     

    Cheers - Rolf

     

     

     

    Sunday, August 24, 2008 11:40 PM