SQL Server sa password lost, or the Print Director database shows Recovery Pending

All of Print Director’s settings, users and transactions are in its SQL Server database, normally called PDDB2. If SQL Server cannot open that database, Print Director stops working. This article covers three problems that can turn up separately or together:

What you see	Go to
Nobody knows the sa password, and no Windows account is a SQL Server administrator	Get administrator access back
In SQL Server Management Studio the database shows PDDB2 (Recovery Pending), or opening it gives error 945	Find out why the database is in Recovery Pending
SQL Server reports error 9002, The transaction log for database ‘master’ is full	Rebuild the system databases

Note. Nothing in this article needs a SQL Server password. It needs a Windows account that is a local administrator on the SQL Server computer.

Before you start

Use Command Prompt, not PowerShell. Open it with Run as administrator. Every command in this article is written for Command Prompt.
Know your instance name. The examples are for a default instance. For a named instance, change them as shown:

Default instance Named instance, for example PD

Windows service name MSSQLSERVER MSSQL$PD

Server name for sqlcmd . .\PD
Plan for downtime. SQL Server is restarted several times, so Print Director, and anything else that uses this SQL Server, is unavailable while you work.
If this SQL Server also holds other applications’ databases, involve their administrator first. Rebuild the system databases removes every login and disconnects every database on the instance.
Stop the Print Director services on the server in Services: PDServerService, PDServerFx, PDSync, and PDAgent if it is installed there. Start them again when you finish.

	Default instance	Named instance, for example PD
Windows service name	`MSSQLSERVER`	`MSSQL$PD`
Server name for sqlcmd	`.`	`.\PD`

Get administrator access back

When SQL Server is started in single-user mode, any member of the computer’s local Administrators group can connect as a SQL Server administrator. Use that to give a Windows account permanent administrator rights.

Stop SQL Server, and start it in single-user mode. SQLCMD must be in capitals: it lets only the sqlcmd program connect, so nothing else can take the single connection.
```
net stop MSSQLSERVER
net start MSSQLSERVER /mSQLCMD
```
Connect with your Windows account:
```
sqlcmd -S . -E
```
Make your Windows account a SQL Server administrator. Replace DOMAIN\User with the account, or with a Windows group:
```
CREATE LOGIN [DOMAIN\User] FROM WINDOWS;
ALTER SERVER ROLE sysadmin ADD MEMBER [DOMAIN\User];
GO
```

Type exit, then restart SQL Server normally:

net stop MSSQLSERVER
net start MSSQLSERVER

That account can now sign in to SQL Server Management Studio with Windows authentication and manage everything.

To set a new sa password as well, run this in step 3 or afterwards. Do it only when you know nothing else signs in as sa. A scheduled backup script is a common example (see How to back up the Print Director database); update the password there too.

ALTER LOGIN sa WITH PASSWORD = 'a new strong password';
ALTER LOGIN sa ENABLE;
GO

If it does not work

Message	Meaning
Msg 15247, User does not have permission to perform this action	SQL Server is not in single-user mode, the Command Prompt was not opened with Run as administrator, or your account is not a local administrator. In SQL Server’s ERRORLOG file (see Find out why the database is in Recovery Pending), the latest start must list `-m SQLCMD` under Command Line Startup Parameters.
Login failed … Server is in single user mode. Only one administrator can connect at this time	Another sqlcmd window already has the connection. Close it and try again.
Msg 15025, The server principal already exists	The login was already there. Run the `ALTER SERVER ROLE` line by itself.
Msg 9002, The transaction log for database ‘master’ is full	The master database is faulty. Go to Rebuild the system databases, which also restores administrator access.

Find out why the database is in Recovery Pending

Recovery Pending means SQL Server could not finish opening the database when it started. SQL Server writes the reason to a text file called ERRORLOG, which you can read without any SQL Server rights:

C:\Program Files\Microsoft SQL Server\MSSQL<version>.<instance>\MSSQL\Log\ERRORLOG

Open it in Notepad. It starts at the most recent start of SQL Server. Find the line Starting up database ‘PDDB2’ and read on from there, then look for any error that names the master database.

The log says	Cause	What to do
Operating system error 5 (Access is denied) against a PDDB2 file	The SQL Server service account cannot open the database files	Give that account Full control of the files and their folder, then bring the database online (below)
Operating system error 2 or 3 (file or path not found)	A database file, or the drive it is on, is missing	Put the drive or file back, then bring the database online
Operating system error 112 (not enough space on the disk), or error 9002 or 1105 naming PDDB2	The disk holding the database is full	Free up disk space, then bring the database online
Error 9002 naming master	The master database’s log is full, and no database can finish opening	See below
Error 823, 824 or 9004	A database file is damaged	Restore the most recent backup. Contact Print Director support first if you do not have one.

To bring the database online after fixing the cause, restart the SQL Server service, or run this as a SQL Server administrator:

ALTER DATABASE PDDB2 SET ONLINE;

When the error names master. In the log, the Print Director database usually looks healthy: transactions rolled forward, 0 transactions rolled back, and then error 9002 for master. The Print Director database is not damaged; it is waiting on master. As a SQL Server administrator (see Get administrator access back), first try to give master’s log more room:

ALTER DATABASE master MODIFY FILE (NAME = mastlog, SIZE = 64MB, MAXSIZE = UNLIMITED, FILEGROWTH = 16MB);
GO
CHECKPOINT;
GO

If both succeed, restart SQL Server and the Print Director database opens. If they also return error 9002, master cannot be repaired from inside SQL Server: go to Rebuild the system databases.

Note. While a database is in Recovery Pending, do not detach it, and never delete or rename its log file (.ldf). Before any repair, stop SQL Server and copy the database’s .mdf and .ldf files somewhere safe.

Rebuild the system databases

SQL Server keeps its own records (logins, the list of databases, server settings) in system databases, of which master is the main one. Rebuilding them puts SQL Server back to the state of a fresh installation. Your Print Director database files are not touched, and you connect them again afterwards.

The rebuild also sets a new sa password and makes a Windows account of your choice an administrator, so it solves a lost sa password at the same time.

What is lost: every login, every server-level setting, and SQL Server Agent jobs. Steps 1 and 5 save the logins and put them back.

Step 1: save the logins and the list of database files

SQL Server must be running, and you must be connected as an administrator. If you have no administrator access, start SQL Server in single-user mode first (see Get administrator access back, step 1). This works even when master’s log is full, because it only reads.

mkdir C:\PDRecovery
sqlcmd -S . -E -W -h -1 -o "C:\PDRecovery\logins.sql" -Q "SET NOCOUNT ON; SELECT 'CREATE LOGIN ' + QUOTENAME(name) + ' WITH PASSWORD = ' + CONVERT(varchar(200), password_hash, 1) + ' HASHED, SID = ' + CONVERT(varchar(100), sid, 1) + ', CHECK_POLICY = OFF;' FROM sys.sql_logins WHERE name <> 'sa' AND LEFT(name, 2) <> '##'; SELECT 'CREATE LOGIN ' + QUOTENAME(name) + ' FROM WINDOWS;' FROM sys.server_principals WHERE type IN ('U', 'G'); SELECT '-- database file: ' + DB_NAME(database_id) + ' = ' + physical_name FROM sys.master_files WHERE database_id > 4;"

The second command is one long line. Open C:\PDRecovery\logins.sql in Notepad and check that it contains:

a CREATE LOGIN line for each login, including the one Print Director connects with (normally PDUser). These lines recreate each login with the password it has now, so Print Director keeps working with the password already saved on every computer.
a -- database file: line for each file of each database on this SQL Server. You need these paths in step 4.

Note. This file contains password hashes. Keep it on the server, and delete it when you have finished.

Step 2: stop SQL Server and copy the database files

net stop MSSQLSERVER

Copy the whole folder that holds the database files (the DATA folder in the paths from step 1) into C:\PDRecovery. This is your way back if anything goes wrong.

Step 3: rebuild

In SQL Server’s ERRORLOG file (see Find out why the database is in Recovery Pending), find the line Default collation: and note the name, for example Latin1_General_CI_AS. The rebuild must use the same one, or Print Director can fail with collation errors.
In Command Prompt, change to SQL Server’s setup folder. It is in C:\Program Files\Microsoft SQL Server\<number>\Setup Bootstrap\, in the folder named after the SQL Server release (for example SQL2019 or SQL2022; not Log or Update Cache). The number is 130 for SQL Server 2016, 140 for 2017, 150 for 2019 and 160 for 2022.
```
cd /d "C:\Program Files\Microsoft SQL Server\150\Setup Bootstrap\SQL2019"
```

Run the rebuild, with your own values:

setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS="DOMAIN\User" /SAPWD="a new strong password" /SQLCOLLATION=Latin1_General_CI_AS

Parameter	Value
`/INSTANCENAME`	`MSSQLSERVER` for a default instance, or the instance’s name (for example `PD`)
`/SQLSYSADMINACCOUNTS`	The Windows account or group that becomes a SQL Server administrator
`/SAPWD`	The new sa password. Store it in your password manager.
`/SQLCOLLATION`	The collation you noted

It takes a few minutes and returns to the prompt without a message. The result is at the end of Summary.txt in the Setup Bootstrap\Log folder.

Step 4: start SQL Server and attach the databases

net start MSSQLSERVER
sqlcmd -S . -E

Attach the Print Director database, using the two paths from the -- database file: lines in logins.sql:

CREATE DATABASE PDDB2 ON
 (FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\PDDB2.mdf'),
 (FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\PDDB2_LOG.ldf')
FOR ATTACH;
GO

Do the same for any other database listed in the file. Type exit when you are done.

Step 5: put the logins back

sqlcmd -S . -E -i "C:\PDRecovery\logins.sql"

Some errors are expected, and the other logins are still created:

Error 15025 (The server principal already exists) for the built-in Windows logins that the rebuild created itself.
Error 15401 (Windows NT user or group not found) for a Windows account that no longer exists.

Then check that the Print Director login is connected to its user in the database:

sqlcmd -S . -E -d PDDB2 -Q "EXEC sp_change_users_login 'Report';"

No rows means every database user is linked to its login. If PDUser is listed, link it:

sqlcmd -S . -E -d PDDB2 -Q "ALTER USER [PDUser] WITH LOGIN = [PDUser];"

If you could not save the logins in step 1, create the Print Director login by hand instead. Use the password Print Director is set up with (PDUser, unless your IT team changed it), so that you do not have to change it on every computer:

CREATE LOGIN [PDUser] WITH PASSWORD = N'the password Print Director uses', DEFAULT_DATABASE = [PDDB2], CHECK_EXPIRATION = OFF, CHECK_POLICY = OFF;
GRANT VIEW SERVER STATE TO [PDUser];
GO
USE PDDB2;
ALTER USER [PDUser] WITH LOGIN = [PDUser];
GO

Step 6: start Print Director and test

Start the Print Director services again, open Resource Manager, and print and release a test job.

If Print Director cannot connect, open Start menu > Print Director 2 > Database Settings on the server and check the server name, database, user name and password against the login you restored.

Afterwards

Back up the database every night, and include the master database. With a backup of master, this problem is a short restore. See How to back up the Print Director database.
Store the sa password in a password manager, and keep at least one Windows account or group as a SQL Server administrator, so that a lost password does not lock you out again.
Install the latest cumulative update for your SQL Server version.
Delete C:\PDRecovery\logins.sql, and the copy of the database files once you are confident everything works.
Server roles are not saved with the logins. If another login was a SQL Server administrator before, add it to the sysadmin role again.

Microsoft references

Document revision date: 2026/11/12

SQL Server sa password lost, or the Print Director database shows Recovery Pending