Unanswered: restoring SQL server after cloning system
Hello. Newbie here and pardon me if this question is already posted somewhere. Would be glad if you can redirect me if ever. ^_^
The hdd of our sql server crashed but we managed to retrieve the model, master and all other db files (mdf, logs) and some backUps (bak). Now we installed a new hard drive and put a clone of an older image of the SQL server. The clone runs fine but it has outdated database. So I tried to attach the newer db copy we salvaged from the bad hdd and replace the old one in the clone system but when I did that I keep getting Error 500. Please note that I did not restore or touch the master, model and all other db under System Database. not sure if I also need to do that and If i do, what's the proper steps. Please assume that the salvaged copy are working one. I hope someone can help me how to properly update my old SQL server with my newer databases. :'(
I'm assuming the paths of the old clone - are exactly the same as the the system databases you're attempting to replace?
On the SQL Server start up (after you've replaced the files) check the Event Viewer - could you post the full error message?
Yes. All paths are the same. Error message when I tried the site URL: "Operation Aborted: (Exception from HRESULT: 0x8000404 (E_Abort))". In event viewer there's EVENT ID: 33002 but description says "Description for this even cannot be found"
Actually, after a lot of fiddling Error 500 is now out of the picture. I'm now stuck with the Even ID: 33002 / E_Abort error. I've seen posts sighting it's due to a hotfix not properly installed. So at the moment I'm downloading all necessary hotfixes. I'll let you guys know how it goes tomorrow.
Ahh. This is a Sharepoint database you are trying to connect to, and sharepoint is giving you Event ID 33002.
Check in the SQL Server errorlog to see if you are getting login failures from the sharepoint instance. If this is a new copy of the master database (or fresh install of SQL Server), the logins may not be defined at the instance level. Login failures would point to that case.
If this server was brought up under a different name, then Sharepoint may be having trouble finding the old instance, as the names of the servers get buried deep within the myriad config files that are sharepoint.
master is an old version. Log is one of my problem. When I tried to go to Object Explorer>Management>SQL Server Logs it gives me an error "failed to retrieve data for this request". Last night after I download all patches I have the ff events in application event log: 17137, 3408, 9666, 9688, 17401, 17137, 3454.
Greate thanks to McCrowley and Jack Vamvas. ^_^ Managed to check SQL logs and you are right about possible login issue. I saw: "Error: 18456, Severity: 14, State: 16." It's weird coz other than loading a newer copy of wss_content database, I haven't changed anything rights and access wise. so I'm not sure why I'm having login issues now. I have the latest copy of master database' mdf file but I don't know how to properly load it up. I tried stoping all services and copy paste the new master mdf to the old master mdf location but when I did that SQL Server won't connect.
Access to SQL Server comes in two parts. The login, and the user. The login grants access to the server. The user grants access to an individual database. When you restored the database (or attached it), you had the user mappings in place, but there was no corresponding login in the master database. You can either restore the master database from a recent backup (assuming you have not applied any SQL Service Packs, Cummulative Updates, or other random patches since that backup), and the logins will be restored, or you can just re-create those logins. If they are windows logins, the mappings will take care of themselves. If it is a SQL login, there are a few more steps to take.
Thanks McCrowley, managed to resolve the issue by deleting the entire site in Sharepoint Administration after I attached the new DB. Now the teamsite is back up. However users from the network can't seem to access the site using their own login. In the Authentication settings we chose Integrated Windows Authentication using NTLM. What we are trying to achieve is that the server will authenticate all access with our AD/DC.