LOG SHIPPING WIZARD - why do I have to explcitly include ...
randyv
Posts: 166
Well - This is bizarre.
I have 4 copies of SQL Backup running on 4 standalone servers.
Each uses the following account for the Agent service and the MSSQL service <domain>/SQLBackup.
This account is also set up on each server as a member of sysadmin role and public.
I created a network share for log shipping. When running the wizard I get along fine until step 4; specify network share. I press the elipsis button, then select my destination server and the shared network folder on that server's SAN (which displays fine in the Folder Browser).
Then when I'm returned to the wizard, I'm promptly told that the Folder does not exist. Why I could see it in the Browser, but the application can't 'see' it eludes me. My Network Share path is: \\<dest server>\LOGSHIP\Logs2Process.
I asked my network admin if he could figure it out. We checked permissions, the account has access. We did everything we could think of, the wizard insists it cannot see the folder.
Then, he said, stick your drive$ in the path name. So we changed the path to: \\<dest server>\L$\LOGSHIP\Logs2Process and whamo, application gave me a green check mark. Just checked at the top of the hour when the log backup on the source server should have started processing; and low and behold there is a backup file in the Logs2Process folder.
Why is it necessary to explicitly state the drive, if the Folder Browser can see it I wonder?
randyv
I have 4 copies of SQL Backup running on 4 standalone servers.
Each uses the following account for the Agent service and the MSSQL service <domain>/SQLBackup.
This account is also set up on each server as a member of sysadmin role and public.
I created a network share for log shipping. When running the wizard I get along fine until step 4; specify network share. I press the elipsis button, then select my destination server and the shared network folder on that server's SAN (which displays fine in the Folder Browser).
Then when I'm returned to the wizard, I'm promptly told that the Folder does not exist. Why I could see it in the Browser, but the application can't 'see' it eludes me. My Network Share path is: \\<dest server>\LOGSHIP\Logs2Process.
I asked my network admin if he could figure it out. We checked permissions, the account has access. We did everything we could think of, the wizard insists it cannot see the folder.
Then, he said, stick your drive$ in the path name. So we changed the path to: \\<dest server>\L$\LOGSHIP\Logs2Process and whamo, application gave me a green check mark. Just checked at the top of the hour when the log backup on the source server should have started processing; and low and behold there is a backup file in the Logs2Process folder.
Why is it necessary to explicitly state the drive, if the Folder Browser can see it I wonder?
randyv
What we do in life echoes in eternity <><
Randy Volters
Randy Volters
Comments
Permissions are always a curious one. That it works using L$ confirms that SQLBackup is a member of the administrators group on the machine hosting the share. The green tick indicates that *both* instances have access. I suspect that if there's a permissions problem, it's on the server hosting the destination instance (since the wizard's file browser uses the SQL Backup agent on the source server to browse and that worked for you).
If you log onto the destination server using the SQL Backup account you could try two things:
1) Browse the shared folder using Windows Explorer, and if this doesn't fail:
2) Use (locally) SQLCMD or Management Studio to execute If both show you the contents of the share then I'm confused as to why the wizard would complain.
Please let me know how you get on,
Regards,
Development
Red-Gate Software