tag:blogger.com,1999:blog-11201447.post3471001133549086849..comments2023-09-21T23:03:52.887+08:00Comments on Naaman's Life: How to move Microsoft SharePoint databases from one SQL server to anotherGrailhttp://www.blogger.com/profile/17414296743604504718noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-11201447.post-67326132084664709582010-03-01T03:31:14.578+08:002010-03-01T03:31:14.578+08:00can you not just remove the server from the farm u...can you not just remove the server from the farm under "servers in farm" so that you dont have to delete the line from the SQL objects table in sharepoint config database?Luke Watsonhttps://www.blogger.com/profile/17093135416195327923noreply@blogger.comtag:blogger.com,1999:blog-11201447.post-86197394022974116022009-10-14T04:13:53.313+08:002009-10-14T04:13:53.313+08:00Just a couple of minor items for anyone using this...Just a couple of minor items for anyone using this walk-through later. <br /><br />In our case we used the Microsoft best practices for Least privilege security and had several specific non-admin domain accounts configured for Sharepoint, including those that needed access directly to the DB. If you are using this and moving to a new SQL server, backing up and restoring the databases will migrate the database specific permissions, however it will *not* add the domain accounts as login accounts on the new SQL server, so you will need to add those accounts to the new SQL server in order to give them permissions to log in. <br /><br />Also one other thing that this caused us is that in Step 1 part 2, we were unable to run the "deletecontentdb" when running as the domain admin. This is because the AdminContent app pool was running specifically as a DBAccess account that we had created as part of the least privilege setup. I did a couple of quick searches and found that I had to have that user as a local admin on the MOSS server, and then use the runas command to actually run the stsadm command *as* that user, then everything else fell into place.<br /><br /><br />The only other place where we ran into any issues was with the Shared Service Providers. Since the SSP in my case was running as a separate web app, I had to create a new web app for the new SSP, then it would not let me re-assign the "SSP Admin" web app from the original to the new SSP, which in turn meant there was still one web app managed by the old SSP and so we could not delete the SSP. I went back and deleted the web app associated with the old SSP and then I was able to delete the old SSP. <br /><br />Other than those minor hitches things went smooth using this walkthrough. The orinal by Ahmed was great, but with your additional notes it is even better....Unknownhttps://www.blogger.com/profile/17501250223941512543noreply@blogger.comtag:blogger.com,1999:blog-11201447.post-52863002646688516232009-10-14T01:09:02.815+08:002009-10-14T01:09:02.815+08:00This is a great post. Just want to say thanks for ...This is a great post. Just want to say thanks for the good work ><br />Bravo!Umarnoreply@blogger.com