June 2014 Entries

This usually happens when you restore a database. For example, you restore a copy of production database X to your QA server. In essence, you have overwritten the user info of that specific database with what exists in production. This creates an orphan user -- where you have no login associated with a user in that database on a server that once associated that user with the old copy of the database.

Here is what to do fix the issue:

1.  Validate that what you think is the problem is the  problem. Do this by listing the known orphans. You may have others show up--but be sure the id you are interested in is on the list:

use [your database instance]

go

EXEC sp_change_users_login 'Report'

2. Fix the broken login:

EXEC sp_change_users_login 'Auto_Fix', 'orphan username'


There are several reasons for this. The most common reason is that the account you are using while logged into mssql through ssms does not have access to the drive definition you are using as your source. Network drives are a good example of an access conflict.

Assuming you have access to the drive, try redirecting the network drive to a local drive letter via xp_cmdshell  (Note: be sure use of xp_cmdshell is enabled) .

exec master..xp_cmdshell 'net use Z: "\\BackupServerXX\<share>\PathWithoutTrailingSlash" YourADpasswordHere /user:domain\your.Username'
Declare @restorefile varchar(1024) = 'Z:\thebackupfile.bak'
Restore database x
From disk = @restoreFile


When you are done, or if you've made a mistake and need to reassign the drive, delete the reference.

exec master..xp_cmdshell 'net use Z: /delete'