10-27-2011 11:54 AM
This is our first time to attempt to use the "Desktop and Laptop Option for Backup Exec" in our network.
For some reason we are unable to create a "New Storage Location".
The steps are: we select a server on the network; it then asks for a path; we browse to an existing path, and then it comes up with:
Warning V-139-32775-123
The filename, directory name, or volumne label syntax is incorrect.
Unable to ceate the directory 'd:\DLO-Storage' on computer 'STORAGE-DC'. Please check the path does not reside on a read-only device such as a CD-ROM drive and that the DLO database servcie '' logon account has sufficient permissions to create the directory. You can change the long account via the Services control panel. Service returned error code 0x8007007b
Well from the same machine with the same (domain administrator) account we can access the share, we can create sub-directories, no problems. The service is running as the domain administrator.
What is going on here?
There are two odd things about this message. First it leaves blank the information about the name of the service. It reads "..database service ''" and leaves blanks in the quote.
Also it seems to be trying to create a share that uses a drive letter like this: \\STORAGE-DC\d:\STORAGE-DC which does not seem correct.
It is probably somethig simple since this is our first attempt.
Any help is really appreciated.
Solved! Go to Solution.
10-28-2011 08:43 AM
If this is fresh installation of Backup Exec 11d and later make sure the service SQL Server (BKUPEXEC) is running under domain admin account which has FULL permission on the drive where you are trying to create Storage Location.
Aslo install the DLO Maintainance Service on the remote server where you are trying to create the storage location. You can do so by pushing the installation as you do for the Remote Agent.
10-27-2011 06:17 PM
Hi
It can be one of the following things below
1> Admin shares were not enabled on the drive that hosts the Storage location.
2> These two services are not running under a service account that has Domain administrator rights.
Backupexec DLO Administration service
SQL Server (DLO)
3> The DLO Service account does not have sufficient permissions to create directories in the storage location.
The NTFS security and the Share permissions on the root NUDF should be configured as follows...
Administrator: Full Control
Everyone: Full Control
10-27-2011 06:45 PM
Your answer is extracted from
http://www.symantec.com/docs/TECH76073
If you want to quote from a document, you should direct the user to the document. Otherwise, people will think you are plagarising the document.
10-28-2011 07:06 AM
Hi,
Could you try the solution in TN - http://www.symantec.com/docs/TECH128853
Ensure that the " Backup Exec Maintenance Service " is running on LSA.
Regards
DB_Sym
10-28-2011 08:43 AM
If this is fresh installation of Backup Exec 11d and later make sure the service SQL Server (BKUPEXEC) is running under domain admin account which has FULL permission on the drive where you are trying to create Storage Location.
Aslo install the DLO Maintainance Service on the remote server where you are trying to create the storage location. You can do so by pushing the installation as you do for the Remote Agent.
10-28-2011 11:35 AM
pkh, thanks for such a quick response. We appreciate it.
We did check out this issue with the permissions and they are all set as described.
But just to be sure we will take a second look at this and let you know what we find.
Thanks.
10-28-2011 12:40 PM
pkh, we checked this. We had the permissions for the "administrators" group but not for the specific "administrator" of the domain. We added that and set the permissions as outlined.
However, no change in behavior. Same as reported originally.
Thanks again for the help. It must be something else.
10-28-2011 01:32 PM
Neer, I think your suggestion was the final one that fixed it. We changed the login of the SQL Server instance "BKUPEXEC" and restarted it.
At that point when we brought up the DLO options on the server, it reported that the account had changed and wanted to know if it should change the account for some other services (sorry we did not check what exactly it said.)
We replied "yes" and then everything started working.
You might want to add that to the technical notes the other folks referenced since there is NO mention of the login account for the SQL Server instance on the media sever.
Thanks to everyone who offered their suggestions. They were all appreciated and we tried them all to get the problem resolved.