NetWorker: SQL-sikkerhetskopieringsfeil i daemonlogg "Kan ikke lese forespørsel fra '<klientnavn>' for en statusoppdatering for GSS-godkjenning"

NMM/SQL-sikkerhetskopier har feil i serverens bakgrunnsprosesslogg på:
nsrexecd NSR critical Unable to authenticate user USERNAME: Unable to read request from 'CLIENTNAME' for a GSS authentication status update: Connection reset by peer. Consult CLIENTNAME s daemon log for additional information.

Klientdemonen har feil:
nsrexecd NSR notice 06/28/16 17:19:42.763849 Encountered BSAFE SSL error: The SSL read operation did not complete

Hvis det kjøres i feilsøkings- 1- eller 2-modus, kan følgende feil vises med representasjonen på NW-serveren:
 
nsrexecd NSR critical Unable to authenticate user USERBANE/CLIENTNAME@DOMAINNAME: Unable to read request from 'CLIENTNAME' for a GSS authentication status update: Connection reset by peer. Consult CLIENTNAME's daemon log for additional information

Godkjenningen mislykkes på grunn av at du ikke kan åpne datakanalen som ble opprettet, og faller tilbake til svak godkjenning:
 
06/30/16 12:54:11.244790 DEBUG: the pipe name -> \\CLIENTNAME\pipe\nsridentity2ce0
06/30/16 12:54:11.244790 DEBUG: failed to open pipe
06/30/16 12:54:11.416677 RPC Authentication: error in LookupAccountSid: No mapping between account names and security IDs was done. (Win32 error 0x534)
06/30/16 12:54:11.432303 An unexpected error occured in file: rpc/lib/gsslgtov1.c, line: 2756, message = "Could not open file"
101036:save: Falling back to a weaker RPC authentication flavor since GSS authentication failed: Authentication error; why = GSS-API context problem
06/30/16 12:54:11.432303 Setting DNS cache TTLs to 1800 secs for positive lookups and 1800 secs for negative lookups
79355:save: Could not get session key from CLIENTNAME for GSS authentication with NW_SERVERNAME: Authentication error; why = GSS-API context problem
 

Problemer med brukerrepresentasjon oppstår når SQL-agenten sqlagent.exe Kjører som en brukerkonto som ikke er en lokal administratorkonto på grunn av sikkerhetskrav.
NW-sikkerhetskopien utløses ved hjelp av en SQL-proxykonto (med etterligning) som heller ikke er en lokal administratorkonto.
 

Følgende midlertidige løsninger er funnet på dette problemet:

• Fjern sterk godkjenning (nsrauth) fra SQL-vertene slik at de bruker oldauth isteden.
• Gjør SQLAGENT-brukerkontoen lokal administrator på SQL-verten (og start SQL Server-tjenesten på nytt) 
• Start jobben fra oppgaveplanleggeren i Windows
• Start jobbene manuelt fra kommandolinjen