@scottalanmiller said in Need to Install SQL Server Management Studio: @Pete-S said in Need to Install SQL Server Management Studio: I'm pretty sure you can install the management studio on any computer. Doesn't have to be on the computer that actually has the SQL server installed. That's correct. SQL Studio requires Windows, but SQL Server does not. So we sometimes do that, as well. Yes or a 64-bit Windows 10 with a new version of Management Studio, managing an older 32-bit Windows 7 SQL Server install

@scottalanmiller said in SQL mirroring advise: @Ambarishrh said in SQL mirroring advise: @scottalanmiller said in SQL mirroring advise: @Ambarishrh said in SQL mirroring advise: @scottalanmiller said in SQL mirroring advise: @Ambarishrh said in SQL mirroring advise: @Dashrender said in SQL mirroring advise: Are the two SQL servers sitting side by side? If not, shared storage and low latency for it's use would be super expensive. Though I do wonder how their DR plan works if there isn't a cluster for the DB, what purpose does the second server serve? Warm spare? Yes the servers are side by side, basically just sits there, and when a new site is created on SP side, run the script which mirrors the new DB created on server 1 to server 2. Eventually they were planning to introduce the witness server once our testing is complete and then enable auto failover. The downside here is that someone need to manually run the script for db mirroring of new databases So the big thing here is that the databases are not mirrored, just the framework (schema) is at creation time. Very different from mirroring or clustering at that aspect level. Yes, we've told them this won't work and asked them to look at a clustered setup. Since the licenses are already in place and is SQL standard no option for Always-On. I want to know what would be the drawbacks for the clustered setup, as for sure there are some more advantages on Always-ON compared to the clustered setup. Won't work... for what? What's the end goal? Won't work: Current stage its 2 separate DB servers and mirroring needs to be done by executing a script whenever there is a new db is created by SP. End Goal: A fully automated failover setup giving high availability for the SharePoint solution What they are doing is unrelated to their end goal. How does mirroring database creation help with failover. There isn't even a first step in preparing for a failover here. What is going on is totally something different. Exactly what i was asking earlier.

I got it restored to a new db,.. but i did have to change the file name.

In this case, it was a matter of the settings during the restore. Under GENERAL you had to select your source and destination as normal. Destination was changed so that it was the new History file. Under FILES you updated the DB and LOG files to reflect the new DB, otherwise you would over write the originals. This is where they borked it. They didn't mention FILES only going to OPTIONS, and there is where they mentioned updating the file names. The main discovery was that you need to uncheck LEAVE Source database in the restoring state. When I emailed them about removing the 'borked' databases I had created the called me back. I mentioned it to the fellow and we had a short discussion on the matter where he took notes and agreed that the directions were incorrect. When I got to the part about unchecking LEAVE Source database in the restoring state he mentioned that he uncheck Take tail-log backup before restore Hope this helps.