Jump to content

Error -1017


laskew

Recommended Posts

I am using Pro 6.0 in a peer to peer environment running on XP Professional and using duplicate scripts to move data to a volume on a 2000 Professional machine between backups to removable media.

 

 

 

My question has to do with the duplicate scripts. I received an error -1017 and read the posts to find that I needed to change the user account in the Retrospect autolaunch service from system to a created account. Upon changing to the account that is used on a daily basis with administrator rights, the application refuses to launch as scheduled either stating that the service is unavailable (upon exit) or launching into the application with only an outline of the windows visible. When the application launches into these "phantom screens" I have to use task mgr to close Retro and upon viewing the logs, I have the -1017 error. Oh, and everything does work when running the scripts manually from the created icon under the same user account specified in the service.

 

 

 

As I am using on a peer to peer network, I created an account also with admin rights on the 2000 box of the same name and password. Does Retro refer to the SID or the user name and password. If the SID is used to authenticate on the remote machine, how do I go about using your launch feature in the absense of domain user accounts?

 

 

 

As a workaround, I am using Windows scheduler to launch the app just before the scripts are to run and that seems to work just fine, but had rather use the features in the software if possible.

 

 

 

thanks in advance.

Link to comment
Share on other sites

not every time. One of two things would happen when permissions were set correctly in the service - either the screen redraw issue - or - the service would appear to be running, but the scripts would not run until Retro was opened. When this was the case, an error message would appear upon exit stating that the service was not running, though XP Pro would report it as running.

Link to comment
Share on other sites

Yes, I rebooted every time following changes to the service and did all of this using the admin account that is used day to day. It was after reboot that the service would not function correctly according to Retro and it was then that I "reinstalled" the service as outlined in the procuct documentation. The service was then recognized, but of course did not carry the correct permissions. Upon changing the permissions, the issues would again arise.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...