Retrospect Launcher service not working

[haggis999]

If I remember correctly, I was still using Windows 7 when the autolaunch facility of Retrospect stopped working. It was certainly quite a long time ago. I'm now on Windows 10, and running a later version of Retrospect, but nothing has changed. To get around the problem, I have been manually starting Retrospect 12.6.1 every morning. When I mentioned this in a thread on another topic earlier this year, I was advised to leave Retrospect running all the time I am using my PC.

It's possible that such a shortcut was always there, but I can now confirm that my Startup folder contains a shortcut to Retrospect.exe. Sadly, this has made no difference. The first automated script of the day still generates the following email notification.

• From Retrospect: Script "MyPicsDuplicateToNAS" failed during automatic execution, error -1017 (insufficient permissions). Please launch Retrospect and check the log for details.

The log simply repeats the same information. If Retrospect is already running in the foreground at the time this script is activated, the script runs to completion without any errors. I've no idea why there should be a permissions issue in one situation but not the other.

That's not the only irritation. When I view the Dashboard after getting that error message, I am told that "Retrospect is currently running in the background. Click Launch Retrospect to stop any running executions and launch Retrospect", but clicking Launch Retrospect has no effect other than to display the message "Waiting for Retrospect to exit". The only way I can get the full version of Retrospect to run is to kill the first of two Retrospect processes listed in Windows Task Manager. It's all a bit of a mess  .

Any guidance would be much appreciated. 

 

[Hofstede]

What user are you using to lauch the service? I have mine set to the user I also use to login to the computer.

You can set the user Retrospect uses under Preferences.

I don't have a shortcut in the Startup folder. There is no need for it.

[haggis999]

My preferences are also set to 'Run Retrospect as the logged-in user'. I don't think I had a shortcut in the Startup folder back when the Launcher service used to work. It was only added as a result of a suggestion from David Hertzberg, one of the resident gurus on this forum, though I'm struggling to find the thread where that got mentioned (I think it was in April 2018).

I first raised this topic via the following thread in October 2017, http://forums.retrospect.com/topic/154427-error-1017-insufficient-permissions/, but it never generated a solution. On re-reading that old thread, I see that the problem actually first arose under Windows 10. It always worked under Windows 7.

[Hofstede]

I am sorry, I should have worded it differently.

I have set Retrospect to "Always run Retrospect as the specified user" and then used the same credentials for the user that I normally use to login.

This allows the program to start the service while you are not logged into the machine and also gives it the same authorisations you have when you login. 

If you are using a Microsoft Account to login to Windows 10:

Username: The email adres of your Microsoft Account, something like xxx@outlook.com

Password: The password you use for your Microsoft Account

Computer: Name of your computer.

 

Has been running fine for me since years.

Remove the shortcut.

 

 

 

[haggis999]

I removed retrospect.exe from my Start-Up folder and then changed my Retrospect preferences to select "Always run Retrospect as the specified user", using my normal Windows login credentials. I also stopped the Retrospect process that was currently listed on Task Manager (as a result of my previous Start-Up setting).

Unfortunately, it has not fixed the problem. My next automated backup script was due to start 10 mins ago, but nothing happened. The fact that this overdue backup commenced as soon as I started Retrospect manually proves that the Launcher service never worked. I don't think it even tried to work, as no error message has been logged.

[Hofstede]

Did you restart the computer? You need to restart for the service to use the new credentials.

[haggis999]

No, I didn't realise that was necessary. However, I have now restarted the computer and set up a one-off backup job to run in a couple of minutes. While watching Task Manager, I could see the Retrospect process starting at the specified time, but after waiting for longer than this job was expected to take, I had still received no automated email message to confirm its status.

I then launched Retrospect manually, which had the effect of triggering the start of the one-off job I had created. In other words, the only automated action had been to start the Retrospect process. My scheduled job had been ignored.

We seem to be making a degree of progress, but the final goal has not yet been achieved     

[haggis999]

I have just unearthed some advice I got from Retrospect tech support back in 2013. They told me that the Retrospect preference setting 'Always run Retrospect as the specified user' would not work unless you disabled Microsoft's User Access Control (UAC), which would generate a security risk.

That would explain why my test of that setting the other day just ignored my scheduled jobs. I have now returned to using the 'Run Retrospect as the logged in user' setting. Needless to say, my first scheduled job of the day once again fails with the -1017 (insufficient permissions) error.

The job in question duplicates the folder G:\My Pictures from the PC that is running Retrospect to a folder on my Synology NAS. The security settings for G:\My Pictures show my normal Windows user account as the owner of the folder, so that looks OK. The login credentials for my NAS were saved by Windows a long time ago, though I don't know where. Accessing the relevant NAS folder via Windows File Manager works fine without any need to repeat a manual login process.

Back in 2013, Retrospect tech support advised me to "manually open Retrospect and leaving it running prior to a scheduled backup operation. This will give you full access to the user interface so that you can view what Retrospect is doing and troubleshoot any issues that may come up during a backup, such as a media request dialog box". That is indeed the only method that works at present. However, if I could find a way to make Windows 10 automatically start up the full Retrospect app at boot time, that should achieve the same objective with less hassle.

Unfortunately, putting a shortcut to Retrospect.exe in my Startup folder doesn't actually work as I expected. It just seems to start some Retrospect-related processes rather than the full application.

[haggis999]

BTW, there is more than one Startup folder in Windows 10. The folder where I put a shortcut to Retrospect.exe is shown below. Just as a test, I added a Photoshop shortcut to this same folder and restarted my PC. As soon as I logged into my Windows user account, a Photoshop window appeared on my desktop. Does anyone know why Retrospect does not start up automatically in a similar manner?

     C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Start-up

[Scillonian]

3 hours ago, haggis999 said:

Does anyone know why Retrospect does not start up automatically in a similar manner?

Retrospect requires/uses more privileges than Photoshop. When you start Retrospect you get a UAC prompt which you have to say yes to for the application to run. Because there is no way to pass the 'Yes' to an application trying to start from a link in one of the 'Start-up' locations the default answer will be 'No' and the application will not run. When you start Photoshop there is no UAC prompt.

 

4 hours ago, haggis999 said:

However, if I could find a way to make Windows 10 automatically start up the full Retrospect app at boot time, that should achieve the same objective with less hassle.

If you have the time and the inclination you could try one of the automation scripting languages such as AutoIt. It is a long time since I last used AutoIt but it should be able to do what you want.

[haggis999]

I'm in full zombie mode when I respond to those regular UAC prompts, so that never occurred to me. That fully explains the problem. Many thanks for shedding light on the matter

Thanks also for the info about AutoIt. I will check that out.

 

[Lucky_Phil]

Pardon me if I'm asking a silly question, but have you got the Retrospect Launcher Service set to "Automatic" under Windows Services?

 

Even if you do ... perhaps try stopping it in the Services and restart it in the services then leave it set to automatic to see if that does anything to help.

 

 

[haggis999]

The Retrospect Launcher service is indeed set to Automatic. It was working, but failed to fully open Retrospect because of the UAC prompt issue highlighted by Scillonian.  

I went looking for a way to bypass the UAC prompt for a specific program. The following Youtube clip tells you how you can create a special shortcut for this purpose using the Windows Scheduler. I then added that new shortcut to my Windows Start-up folder instead of a direct shortcut to Retrospect.exe.

    https://www.youtube.com/watch?v=Ai_l_L-8o-c

This successfully opens Retrospect every time I start Windows, so I no longer have to start it manually every morning.

I thought my problems would now be over, but my first scheduled task still failed with the same permissions error. Given that I never got this error when opening Retrospect manually, there had to be something different happening when using the Launcher Service. It then occurred to me that perhaps my NAS does not see the access request as coming from my normal login. Up to now, only 'adminstrators' had any access to the destination folder on the NAS. Adding a permission for 'SYSTEM' to have read/write access made my Retrospect problem disappear!

Many thanks to Scillonian, who set me on the right track to resolving this long-standing problem

[haggis999]

Interestingly, my second scheduled job to run under an automatically-launched version of Retrospect generated a popup to request login credentials for my NAS. The first job, which has never recently generated such a popup, was a duplication, while the second job was a backup. I have no idea why they behaved differently.

As a test, I scheduled another run of the same backup job and this time it remembered the previously entered credentials, so all appeared to be well.

However, I then realised that there was no longer any need to use the Retrospect Launcher Service, as I am now successfully starting Retrospect automatically via Windows. Turning off the launcher meant that my scheduled scripts are now being run under my normal login, so I was able to delete the NAS folder access permission I had just given to the SYSTEM user.

[Scillonian]

7 hours ago, haggis999 said:

I thought my problems would now be over, but my first scheduled task still failed with the same permissions error. Given that I never got this error when opening Retrospect manually, there had to be something different happening when using the Launcher Service. It then occurred to me that perhaps my NAS does not see the access request as coming from my normal login. Up to now, only 'adminstrators' had any access to the destination folder on the NAS. Adding a permission for 'SYSTEM' to have read/write access made my Retrospect problem disappear!

4 hours ago, haggis999 said:

Interestingly, my second scheduled job to run under an automatically-launched version of Retrospect generated a popup to request login credentials for my NAS. The first job, which has never recently generated such a popup, was a duplication, while the second job was a backup. I have no idea why they behaved differently.

You've now run into a little known networking limitation in consumer Windows because it can only have one user active at any one time. (The server versions of Windows can have multiple simultaneous active users so I don't think the following applies to the same extent.)

Unlike Linux and the BSD based OSes, consumer Windows does not allow a user instance [your logged-on session] to access a network resource [your NAS] with more than one set of credentials at any one time. So if Retrospect has accessed the NAS running under the SYSTEM account for the first job then tries on the second job to access under your account it will be denied access because the NAS has already been accessed using SYSTEM account credentials. SYSTEM will remain as the set of credentials in use until you restart Windows or the credentials are manually revoked.

 

[haggis999]

2 hours ago, Scillonian said:

You've now run into a little known networking limitation in consumer Windows because it can only have one user active at any one time. (The server versions of Windows can have multiple simultaneous active users so I don't think the following applies to the same extent.)

Unlike Linux and the BSD based OSes, consumer Windows does not allow a user instance [your logged-on session] to access a network resource [your NAS] with more than one set of credentials at any one time. So if Retrospect has accessed the NAS running under the SYSTEM account for the first job then tries on the second job to access under your account it will be denied access because the NAS has already been accessed using SYSTEM account credentials. SYSTEM will remain as the set of credentials in use until you restart Windows or the credentials are manually revoked.

My understanding is that the Launcher Service will use the SYSTEM login, so I was really expecting Job #2 to fail with an error -1017 (insufficient permissions) as its destination folder on the NAS allows no access for the SYSTEM account. I was therefore rather surprised to be presented with a login prompt for Job #2. When this happened, I entered my normal login details, which were accepted.

However, this is now purely of academic interest. Thanks to your assistance, my problem is now fixed.

[haggis999]

On 6/1/2018 at 8:20 PM, Scillonian said:

You've now run into a little known networking limitation in consumer Windows because it can only have one user active at any one time .....

I suspect that this may be the cause of a new error I hit after attempting to dispense with using the Retrospect Launcher Service.

After launching a non-UAC prompting version of Retrospect via the Windows Start-up folder, as previously described, and turning off the Launcher Service, I found that the Retrospect duplication script that is triggered first every day could not gain access to any network resources. Even when I tried to manually update the destination, I got -1016 errors. The Knowledgebase article that covers the similar -1017 error is over 6 years old and did not provide any useful assistance.

However, I'm struggling to think of why any user other than my own normal Windows account is involved in this scenario. In the meantime, I have turned the Launcher Service back on and that duplication script ran OK this morning.

[cfieldgate]

Haggis999,

Perhaps I have misunderstood your thread , but I use the Retrospect Launcher to fire up Retrospect every day to run my scripted backups regular as clockwork.

I have set Retrospect Launcher  service to login as an account I have set up for backups in my AD (i.e. a non-local account) which has access to my NAS shares used for backup storage, and not as the default System account. I also have Retrospect set to run as the logged in user - which when automatically launched (by the Retrospect Launcher) will be my designated AD account. I have no UAC issues and have no need for a link in the startup folder. This has worked in ever yversion since 7 that I have purchased (I have missed out several along the way).

[haggis999]

2 hours ago, cfieldgate said:

Haggis999,

Perhaps I have misunderstood your thread , but I use the Retrospect Launcher to fire up Retrospect every day to run my scripted backups regular as clockwork.

I have set Retrospect Launcher  service to login as an account I have set up for backups in my AD (i.e. a non-local account) which has access to my NAS shares used for backup storage, and not as the default System account. I also have Retrospect set to run as the logged in user - which when automatically launched (by the Retrospect Launcher) will be my designated AD account. I have no UAC issues and have no need for a link in the startup folder. This has worked in ever yversion since 7 that I have purchased (I have missed out several along the way).

I'm guessing that your reference to AD means a Microsoft Active Directory. If so, then that certainly makes your environment a little different from mine. I'm just a home-based user with my own private local network.

If you are using Active Directory, I assume it means you are running under Windows Server. As Scillonian pointed out above on 1 June, Windows Server will tolerate a user instance to access a network resource with more than one set of credentials at any one time. That is not the case for my consumer version of Windows 10, and this is the limitation that I strongly suspect lies behind the rather unreliable behaviour of the Retrospect Launcher Service. Most of the time it works, but I still get the -1017 error about every week or so.

 

[cfieldgate]

Nope, no Windows Server here. I am running Active Directory on my Synology NAS courtesy of Samba. Retrospect runs on a Windows 10 Pro PC, not on the NAS (obviously, as the NAS is Linux based). So i think even using a local account (which I used to do) will work for you.

The reason for my using an AD account is simply to provide central management of accounts and their access privileges in my home lab.

[haggis999]

58 minutes ago, cfieldgate said:

Nope, no Windows Server here. I am running Active Directory on my Synology NAS courtesy of Samba. Retrospect runs on a Windows 10 Pro PC, not on the NAS (obviously, as the NAS is Linux based). So i think even using a local account (which I used to do) will work for you.

The reason for my using an AD account is simply to provide central management of accounts and their access privileges in my home lab.

I've never heard the term 'home lab' before, but a Google search provided some enlightenment from a variety of USA-based sources. Here in the UK, we think of 'laboratories' as places where research chemists in white coats carry out their experiments. We would not normally use that word for a computer room. For Brits, any reference to a 'lab' usually means a labrador dog!

When I get some time, I might try experimenting with Synology's Active Directory Server package. I don't have any obvious need for multiple user accounts with varying privileges, but perhaps it provides a way to get around the restrictions mentioned by Scillonian and could thus make my Retrospect Launcher service work more reliably.

[cfieldgate]

As I said in my post, an AD account isn't strictly necessary - a local account (on the PC running Retrospect) with access to the destination shares (on a Synology NAS?) works just fine. Just make sure the accounts have the same username/password - I even setup a mapped drive to be sure I had access, although I did not use the resulting drive letter within Retrospect. The share Volume I declare by running the Retrospect Client on the NAS (but even that isn't strictly necessary) - you can just set up the Backup Set with the \\NASname\Share method.

The key thing is setting up the Retrospect Launcher Service to login with a user account which you define (in your case a local account on the PC) that has access to wherever you want the backups stored, and in Retrospect Preferences set Retrospect to run as the logged in user - which will be the same user as the Retrospect Launcher as it will fire up Retrospect at the appointed time set in your scripts.

[cfieldgate]

P.S. I am a Brit living in the UK. Clearly I read too many US technology posts ?