Thanks to Mark Russinovich of Sysinternals fame, there is a very painless way to solve this problem without any downtime: PsExec.

Plus, unless you uninstall the old instance first, the new instance will have a new instance name, and therefore all client applications will need to be updated.

In addition to downtime, the problem here is that you must also re-create all of the logins, linked servers, jobs, and other elements outside of the database in order to have a fully functioning system again. And depending on what needs to be managed on the server, it might not be feasible to wait for a scheduled maintenance window.Ī more extreme workaround is to shut down SQL Server, copy all of the MDF/LDF files, install a new instance of SQL Server, and attach all of the user databases. However, this approach requires at least some downtime in some systems, this would be unacceptable. The typical workaround I have seen employed is to restart SQL Server in single user mode. Of course that person was the only one who knew the sa password as well, and being a local admin or even a domain admin might not help you. I've seen cases where an employee has moved on, but their Windows account, being the only one with Administrator privileges for SQL Server, had been completely obliterated from the system. This means that it is possible, especially if you don't use mixed authentication (or have forgotten the sa password), that you can be completely locked out of your own SQL Server instance. Starting with SQL Server 2008, the local Administrators group is no longer added by default during SQL Server setup you even have to use a manual step to add the current user as a local administrator. By: Aaron Bertrand | Updated: | Comments (96) | Related: > Security

Breaking ms access password