April 15, 2012 at 9:30 pm
I'm migrating an application database to new hardware, but due to application requirements I need to use the same version of SQL currently being used. This is SQL 2005 SP3.
The new environment consists of a 2 node Windows 2003 Cluster on HP Blades with 24 logical CPUs on each node. The install fails because of this known issue: http://support.microsoft.com/kb/954835
The work around to set the CPU number to 1 also failed as the server starts up in a restricted mode and I couldn't connect remotely to the server to do the install (I can only work remotely on this clients servers).
I then tried to use the alternate work around, extracting SP2 and using a command line install to apply the hotfix sqlrun_sql.msp file. This however fails when the installer tries to start the Scheduled Task on the 2nd node. This is the task that does the install on the 2nd node. The scheduler gets an "access denied" error on start up. I can't find where access is denied in any of the Windows Event logs, and since this portion of the install worked when I didn't include the sqlrun_sql.msp path, I'm assuming the problem is related to the inclusion of this file.
Has anyone ever come across this? I've not found any articles spesifically covering merging a SQL Server 2005 SP with the RTM to install on a cluster. I've picked up that this isn't referred to as "slipstreaming" because after the install (if it ever works) I still have to install the service pack.
Any ideas on how I can get this to work?
Cheers
Leo
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated.
April 18, 2012 at 11:34 am
hmmm ... you found the CPU issue - good deal.
Now a question or two ..
- Do you have security/logon errors on the remote node where the installation is failing ?
- are your AD credentials Local Administrators group on both cluster nodes ?
- are the SQL Server service account AD credentials in the Local Administrators group on both cluster nodes ?
Also, before trying things again I would reboot both cluster nodes to clean up any 'dangling' leftovers from the fialed installation.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply