Silent update via updater backend fails to execute a batch file on Win Server 2003 and 2008

We have a windows service that is deployed on various customer machines that are running Windows XP, Windows Server 2003, and Windows Server 2008. The service uses wyUpdate to update itself when we publish updates. This has been working fine for about six months. Recently, we added for the first time a .bat file to the Temporary Folder, to be executed after the update is applied and rollback if any non-zero error is returned due to execution of the batch file.

This was tested successfully on two of our own Windows Server 03 and 08 machines, by logging in to the server, stopping the service manually, and then clicking on wyUpdate.exe. The update is applied and the batch file runs successfully.

However, whenever a runnning service calls the updater backend, the update fails on Windows Server 03 and 08 machines. Based on several tests that I conducted, it does not seem to have anything to do with the batch file content. For example, in my most recent tests, the batch file consists of a single line: "@echo off". The error being reported by the updater backend is: 'Failed to execute the file "C:\Users\fictitioususer\wc\9\temp\temp.bat": No such interface supported'.

This problem does not occur on machines running Windows XP.

Any thoughts?

Did some additional testing. This also occurs if the temp file to execute is a do-nothing .exe. If I watch the folder where the updates are being downloaded, I can see that the .exe file (or .bat file in previous tests) is, in fact, being downloaded. It just fails to execute.

Hey Joel,

What's the error that's returned when the *.exe fails to execute? (Copy and paste the full error).

Is the exe a valid executable?

The error is essentially the same, but with the name of the .exe instead of the batch file name:

'Failed to execute the file "C:\Users\fictitioususer\wc\9\temp\updatetest.exe": No such interface supported'

The .exe is a valid executable. It is a console app that simply takes any command line arguments passed to it, and writes them to a file. The command line args passed to the app from wyUpdate are %basedir% %versionfrom% %versionto%. It does not output anything to the console. The app runs fine from the command line. If you want, I can do another test where the .exe does nothing at all. I don't think that will make a difference, however.

Things I have considered:

(1) Security issues, e.g. maybe the OS will not run an exe or bat file if it doesn't know where it came from. But if that were the case, I would expect to have problems running wyUpdate manually as well.

(2) Permission issues. When I run wyUpdate manually I am logged in as a different user than the service runs under when it tries to update itself. That would suggest some sort of permissions error. However, the service runs under an account that is an admin on the machine where it runs, so that seems unlikely.

(3) Console app attempting to interact with the desktop when running as a service. The service runs under a specific user account (i.e., not local System). When running a Windows service under the Local System account, there is an option on the service Log In dialog to "allow service to interact with desktop". This option is not available when running under a specific user account. From that I am assuming that Windows would consider it an error if the app tried to interact with the console. As I said, the app does NOT write to the console. But I am not sure what the OS does when it starts the app, such as attempt to create a console window. Perhaps that causes an error from the get-go. I can run a test tomorrow by running the service under the Local System account, with the "interact with desktop" option enabled, and see if the updater fails under those conditions as well.

I've emailed you.

Thanks, Wyatt. I got your email.

I've sent a detailed reply, but for purposes of this discussion, I'll just point out that the documentation says that we should run services under the LOCAL SYSTEM account. We did that initially, but later on we started running the service as a domain user that is has admin privileges and has "log in as a service" rights. That works fine as long as we don't try to run anything from the temp folder. Since we really need to use a domain user for the service, we will probably figure out a way to run update scripts from the service itself.

Thanks for your help.

Hi JoelLee / Wyatt

could you kindly post a sample code for Silent update via updater backend to execute a batch file(sql scripts) ?i am unable to find the solution , i had use your windows service silent update application for updating batch file.but service not updates automatically.

thank you

Anand, we've covered this a dozens of times in this forum. Plus we have a FAQ item on it, see: Can I update databases (Microsoft SQL Server, MySQL, etc.) as part of my update?

If you get a specific error then tell me what it is. Saying something doesn't work is not nearly enough information.

What was the outcome of this? Looking at @JoelLee's last comment it suggests there's a problem with this when the service is running as a user other than LOCAL SYSTEM?

We're encountering a similar problem "Message: Failed to execute the file "C:\Users\srv_SVCACCOUNT\wc\b\temp\RM.UpdatePrerequsites.exe": No such interface supported" at a customer site, but this prereq exe works fine on our test machines. Is this because they're running using a service account instead of LOCAL SYSTEM?

thanks,

Rory

It depends on what "RM.UpdatePrerequsites.exe" does (you would know, it's your app). My guess is that it needs admin privileges, and thus the updater service will actually have to run with admin privileges (LOCAL SYSTEM), because wyUpdate can't prompt for privilege escalation from within a service.

I'm pretty sure there's no admin privileges required. The previous comments suggested there was some issue with running _any_ batch file or executable, was that not the case?

The error we get is the same one reported by the OP suggesting it's something reported by wyUpdate rather than our app. Do you know what it means specifically?

thanks!

Rory

fyi - the prereq exe just checks whether .net 4.5 is installed on the machine.

Whatever your installer is doing it requires more than limited user account is offering. Honestly, wyUpdate should never be run with a "LOCAL SERVICE". Run it from one of the following:

1. A regular user.2. A guest user.3. An admin / elevated user.4. A Local System Service (a.k.a. an Admin service).

Running wyUpdate from a LOCAL SERVICE is not supported because of the many limitations (and the inability to prompt the user for elevation request). This is covered here: http://wyday.com/wybuild/help/silent-update-windows-service.php

I've confirmed that the windows service is a member of the Administrators group on the local machine, so it does have admin rights.

Does the update work as a Local System Service?

The short answer is that the problem is with whatever executable you're running. Add debugging to the exe to record what you need.

Hi,

I am also facing similar issue1. I am using wyBuild 2.6.18.42. The batch file has only @echo off3. The windows service is running under a user account who is part of builtin administrators group4. In this case, I get the error "Failed to execute the file "...bat". No such interface supported.5. Same works fine when the service is running under LocalSystem account

Any suggestions would be appreciated

Additionally, I observe that if I am logged in as that user, it works fine.But if the logged-in user is different from the user under whom the windows service is running, then it gives the error "No interface supported"

Make your service run as Local System Service. This is covered in the articles.

https://wyday.com/wybuild/help/silent-update-windows-service.php

Running under LocalSystem account is what we usually recommend to our customers. But some customer's internet proxy settings do not allow LocalSystem account to connect to internet and hence, they have no option but to run under a user account.

wyUpdate should either be run with the GUI (default behavior) so that it can prompt the user for elevation, or it should be run from a Local System service.

wyUpdate does not support running from un-elevated services. We make this clear in the documentation: https://wyday.com/wybuild/help/silent-update-windows-service.php

I am not sure I fully understand.

In my example batch file, there is only a @ECHO OFF statement which does not need any elevated permission to be executed. But still it gives the above mentioned error of "No such interface suported"

And in our actual scenario, the user account under which the service runs is part of administrator group and hence I don't think that this is related to the "elevation" of permissions. The update just worked when I logged in to the machine with that user account without making any change at all but did not work as long as the user was not logged in to the machine.

I don't know what's going on. If you can reproduce this with either GUI version or wyUpdate running on a Local *System* service then we'll look into it.

Like I said, wyUpdate doesn't support un-elevated services (like Local "Service" service).