Backup File Location on Network - Unable to drill down

TCLivenTCLiven Posts: 4
edited September 28, 2009 6:14AM in SQL Backup Previous Versions
We have several SQL servers being backed up with Red Gate. All servers but two have the option to drill down to specific network shared folders within the backup file location field. The servers specifically can access the network shared folders via unc and network neighborhood with no problems, so the permissions are OK. It is just Red Gate that will not allow that drill down. Is there anything specific that needs to be config'd to allow this via Red Gate?

I did not setup the other servers, I just built a new SQL server that is having this issue... Any advice is greatly appreciated. Thanks

Comments

  • Eddie DEddie D Posts: 1,780 Rose Gold 5
    Thank you for your post into the forum.

    New to SQL Backup V6, users can create a new registry key and list the user accounts that are able to browse.

    The Registry value name is BrowsingUserList. Key type is either REG_SZ (single value) or REG_MULTI_SZ (multiple names) and the value data list the user names or names and must be in the DOMAIN\user format.

    Can you please try configuring the above registry on the SQL Server with SQL Backup Server Components installed in the following registry directory:

    HKEY_LOCAL_MACHINE\SOFTWARE\Red Gate\SQL Backup\BackupSettingsGlobal\(local) or SQL Instance Name

    Many Thanks
    Eddie
    Eddie Davis
    Senior Product Support Engineer
    Redgate Software Ltd
    Email: support@red-gate.com
  • Thanks for the reply however this post is for SQL Backup 5. We have not yet upgraded to 6. Can I perform this same registry hack within 5?

    Update -> I have confirmed that I can not use this registry hack in SQL Backup 5 since the path's are not there.
  • Just to point out, prior to 6.0, you have to do quite a bit of security configuration to get the file browser working when you use Windows authentication in SQL Backup's UI and are running the UI from a computer other than the SQL Server and the share was on a third computer. This situation causes a "double-hop" authentication issue that you can only work around by ensuring that you authenticate to the SQL Server using Kerberos.

    Versions 5.3 and lower simply require you to be a member of the computer's local administrator group, then the file browser would use the SQL Server account credentials. It's a bit messy, I'll admit. That's why the "browsinguserlist" registry key came into being.
  • We are on version 5.4. The user as well as the sql service (just to be safe) is part of the local admin group. Bummer.. still no luck..
  • In 5.4, you essentially need to configure the SQL Server and SQL Server services for Kerberos to avoid the NTLM double-hop issue.
Sign In or Register to comment.