I am building an auto-updating mechanism. A windows service that runs on a local service account responsible with the auto-updating of a msi.
The service downloads the msi file then it tries to install it using this code:
Process process = new Process();
process.StartInfo.FileName = "msiexec.exe";
process.StartInfo.Arguments = string.Format(" /i \"{0}\" /qn /norestart ALLUSERS=1", sMSIPath);
process.Start();
process.WaitForExit();
Where sMSIPath is a string representing the path to the file, for example "C:\test.msi".
This code, from a regular console application seems to be running fine. I managed to silently install adobe reader, for example.
But from my windows service, it does nothing. According to the logs, i get a warning with this message:
Failed to connect to server. Error: 0x80070005
Where the user is "LOCAL SERVICE" (as i mentioned, my windows service runs as a local service).
Also, the projects have target x86, but i am running a 64-bit OS. (i need them at x86, i want this software to be able to run on multiple operating systems).
Any help is very well received.
Thanks alot!
I don't think you have much chance of making this work. If the MSI tries to access folders like Desktop, User's Program Menu, the CommonFilesFolder (not a complete list) or looks at the LogonUser property and any number of other things it will fail because in a normal install from the interactive user these are all valid properties associated with that installing user. When the installing user is localservice you're likely to be in a mess.
If you need to do this, configure the service to run as a valid administrator account - that might give you a chance of it working better. It's possible that the failure to connect to server error is because MSI files are expected to be run from some kind of user account.
Open service management console Start->Run->Services.msc
Right click on your service and go to properties
On property page select second tab i.e. "Log On"
Check checkbox called "Allow Service to interact with desktop".
Harry Johnston is right, local service doesn't have the privileges to do that. Local system works great though, so i'll use a local system account.
Thank you for your answers, they were all helpful!
Related
I'm running a .Net Core microservice on Linux (Ubuntu) and am trying to remote debug with Visual Studio over SSH. But the service is run under the user svcuser and my user is mainuser. Main user is in the same group as the service user.
In visual studio, I can see the process that the service is running under, but when I try to attach I get:
One or more errors occurred. Failed to attach to process. The .Net Debugger has insufficient privileges to debug the process. To debug this process, vsdbg must be running with root permissions.
I checked in MS documentation but for Linux all they have is this: https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-dotnet-core-linux-with-ssh?view=vs-2019 which has no info on running the service with a different user
And the only info they have on fixing such a problem is for windows only: https://learn.microsoft.com/en-us/visualstudio/debugger/error-the-microsoft-visual-studio-remote-debugging-monitor-on-the-remote-computer-is-running-as-a-different-user?view=vs-2019
If you have sudo privileges then this is relatively easy, and can be kept secured to those users with sudo privs. Avoids needing to reconfigure users/environments, and allows you to debug any process on the machine regardless of which user account it is running as.
If you use Visual Studio to make an initial attempt to debug you will find that a ~/.vs-debugger folder has been created in the home directory of the user account you were attempting to use. This command will help you locate the vsdbg binary which was installed. You can install VsDbg manually but I find leveraging the automated process is easier. If you are using VSCode this becomes a manual process, and an exercize left for the reader, but I would still use VS2019 IDE to prep the target just to keep things consistent between tools.
find ~ | grep vsdbg
For my installation the binary is located at ~/.vs-debugger/vs2019/vsdbg and this path will most likely change over time.
First, rename the binary to something convenient:
mv ~/.vs-debugger/vs2019/vsdbg ~/.vs-debugger/vs2019/vsdbg-bin
Second, create a script to replace the binary:
touch ~/.vs-debugger/vs2019/vsdbg
chmod 770 ~/.vs-debugger/vs2019/vsdbg
nano ~/.vs-debugger/vs2019/vsdbg
The script content might look something like this, note the full path to vsdbg-bin, the use of $# ensures all command-line args passed to your script are forwarded to VsDbg.
#!/bin/bash
sudo ~/.vs-debugger/vs2019/vsdbg-bin $#
Now retry your debug session from Visual Studio, if you did things correctly you should be able to attach to any remote process on the target machine using SSH->VsDbg. "Works on my machine." ;) This was confirmed with VS2019 16.8.4, .NET 5.0, and VsDbg 16.9.20122.2 debugging an ASP.NET Core application running on Debian 5.4.8 (x64) launched by systemd under a service user account in Azure. "Sweet."
HTH!
When I run my selenium test (mvn test) from jenkins (windows) I see only the console output. I don't see the real browsers getting opened . How can I configure jenkins so that I can see the browsers running the test?
I had the same problem, i got the solution after many attempts.
This solution works ONLY on windows XP
If you are using jenkins as a windows service you need to do the following :
1) In windows service select the service of jenkins
2) Open properties window of the service -> Logon-> enable the checkbox "Allow service to interact with desktop"
After then you should reboot the service jenkins
Hope this help you :)
UPDATE:
Actually, I'm working on a an automation tool using Selenium on Windows 10, I've installed Jenkins ver. 2.207 as windows application (EXE file), it's running as windows service and ALL drivers (Chrome, FireFox, IE) are visible during test executions WITHOUT performing a mere configuration on the System or Jenkins
I got the solution. I ran jenkins from command prompt as "java -jar jenkins.war" instead of the windows installer version. Now I can see my browser based tests being executed.
If you are already doing what #Sachin suggests in a comment (i.e. looking at the machine where Jenkins actually runs) and still do not see the browsers, then your problem may be the following:
If you run Jenkins as a service in the background it won't open apps in the foreground. You may either try to run it not as a service in the foreground, or run it as a Local System account and check Allow the service to interact with desktop option. In the latter case you may get into permission problems, though.
Update: To make sure this answer is understood properly by others: Jenkins Windows 'native' installation is not really native. It's a wrapper around Java that runs it as a service.
To interact with desktop GUI, you should launch slave agent via JNLP:
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-LaunchslaveagentviaJavaWebStart
After adding the node in Jenkins (configured as Java Web Start launch), just make a startup batch script on the node machine:
java -jar slave.jar -jnlpUrl http://{Your Jenkins Server}:8080/computer/{Your Jenkins Node}/slave-agent.jnlp
(slave.jar can be downloaded from http://{Your Jenkins Server}:8080/jnlpJars/slave.jar)
See more answers here:
How to run GUI tests on a jenkins windows slave without remote desktop connection?
In the case of Windows 7 you should not install jenkins as windows application (because in this recent version, Microsoft decided to give services their own hidden desktop even you enable the functionality "interact with desktop" in jenkins service), you may have to deploy it from a war file as follows:
1) Download jenkins.war from Jenkins official site
2) Deploy it by the command prompt : java -jar {directoryOfJenkinsFile}/jenkins.war
3) Now you can access jenkins administration on http:// localhost:8080
Hope that helps you !
this is an issue for Jenkins. on Windows it is possible to access logon user's session (screen) under system account. to make the UI testing visible, Jenkins needs to bypass UAC (user access
control) at background. this solution works for me with my own service running as system account.
I also faced the same issue earlier in my local machine (Windows 10).
My test was running perfectly from the NetBeans but when I moved to Jenkins it was only running in console mode. I was unable to view the UI.
So for that, you just need to make your local machine as a Jenkins slave by creating a new slave node in your Jenkins and select that node to execute the Jenkins job.
If jenkins installed by windows installer it is showing only Console out put only. To see browsers download jenkins.war file and run java -jar jenkins.war from command line.
Go through this site:
http://learnseleniumtesting.com/jenkins-and-continuous-test-execution/
If you have the following situation,
You are able to login to the remote machine
You don't see the Jenkins agent window
This slave machine is accessed by many users then try the following,
then try the following suggestion.
Login to slave machine
Go to Task manager
Users
Logout all the users
Then login again.
This worked for me.
I have created a code, which compares XML files on the client side (in PC) with the XML file located on the FTP server; where once it detects that client is running older version of the program, it will download the latest build (so that user has always up to date program).
Here is the trick. Due to the fact, that I am overwriting files at run-time, I had to create an external console application which is being called from the main app if user wants to update. This way, first console application is executed and afterwards main app is closed, so that no files are locked by the system (application's .exe file would otherwise be locked and we could not replace it with the new one).
This process runs perfectly, if it is being installed somewhere else other than under the system folder (by that I mean e.g. C:\Program Files\ drive). If user has decided to install main application there, then suddenly my app crashes as it does not have admin privileges.
I am using Install Shield LE when disbursing this app, and users that are using this program are not administrators (which means that I go to every computer and type admin password when I/users install this program).
Is there a way, how to execute my updated console application with admin rights, or how to define via Install Shield that once this app has been executed, I always want it to be executed as admin?
Hope that my explanation has not been confusing. I am more than happy to share additional details if necessary, as I need to figure out how to solve this thing.
I imagine you don't have an AD configuration as Emmanuel suggest, because in this case you would push the updates without any problems and would not have to design an automatic updater.
I don't know if InstallShield has something like this, but Advanced Installer has the support to install a dedicated updater that runs as a service, thus it has all the permissions required to install an application under Program Files.
Of course this means you need to replace your updater with the one from Advanced Installer and also that the initial installation of the application on the end user machines will still require admin credentials. (future installs can install silently, without the user's intervention)
You'll need to add the following line to your app manifest:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Documentation on the msdn is here.
I am not able to debug any of my services after migrating from XP and VS2005, to Win7 and VS2010.
I can compile, I can install, I can run the services correctly.
But, I need to debug them. And when I try to attach to the process, I select the running process as I always did on VS2005, and I receive an error telling that I need admin permission.
I am already an administrator. Also, after searching a lot on the internet, I found that running VS2010 as an admin (via right click) should fix it, but I still can't.
I also tried to mark the checkbox on vslauncher.exe properties to run it always as administrator. The VS2010 window shows on top that it actually is running as admin, but again, when I try to attach to the process it says that I need admin rights.
Has anybody any idea about how to proceed?
It was a permissions problem.
Win7 comes with a new security system, and I had to add to my profile (even being an admin) this permission:
Control panel -> Administrative tools -> Local Security policy -> Local Policies -> User rights Assignment -> Debug programs -> Add user or group .
And there, I added my own user. Reboot machine(Important!! Without rebooting, it won't work).
After that, I was able to attach processes to debug them. It's been a really long time to solve this, I hope to help other people that find this same problem.
Thanks everybody for your help.
Edit your service and put the following line into the OnStart() method:
Debugger.Launch(); It's important that you do this in OnStart() rather than a thread launched by OnStart() so that if there is any bug, you can catch it prior to your service crashing.
When your service starts the debugger will open. Windows will then offer to automatically launch an elevated visual studio so you can attach to your service. I find it very useful to put this line in with an app.config setting so you can enable it as required (i.e launch and attach debugger to service).
FYI when you use Vista / Windows 7 you can run apps as administrator. However these apps explicitly reject administrative privileges unless you launch them with "Elevated" permissions. This is a security feature called UAC.
I have the following error:
OpenSCManager Failed 5: Access is denied.
Can someone help me? Is there another way besides using installutil to install the windows service ?
P.S : I am using Visual studio 2008. I did look for installutil in C:\VisualStudio... but i can't find it either.
I found the InstallUtil.exe executable. I run the application and now i have the error: c:...\InstallUtil,installLog is denied. WHY?
There are two questions here:
For the access denied problem. Chances are you are don't have permissions. Run the command with administrative privilegies. This means that you have to be a member of administrators group and your process has to be elevated, i.e. you have to right-click -> Run As Administrator to lauch the process.
There are many ways to install service. Since you already know InstallUtil, I don't have to mention it.
There is Win32 API called CreateService.
There is command line utility sc.exe -- it comes with OS by default
If you are so inclined, you can hack registry -- it is not that difficult to reverse engineer records under HKLM\System\CurrentControlSet\Service\
I personally prefer sc.exe. It installs managed services just fine.