I have a program I wrote in Visual Basic Express 2013 to put a classification banner at the top of the screen. I set up a scheduled task using ngen.exe which makes it run at login. The problem is that it doesn't run as admin so any non-privileged user can kill the task.
This program is to replace another program called Netbanner because there are a few issues with Netbanner. The program I wrote resolves all of these issues except for the admin issue. Netbanner is implemented exactly the same way (ngen.exe) but it won't let a non-privileged user kill the task.
I don't know if it is something in the program itself or I missed something in the deployment process.
This is the command used to deploy Netbanner which I duplicated to deploy mine:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\ngen.exe install "C:\Program Files\Microsoft\NetBanner\NetBanner.exe"
Also, these are the files in C:\Program Files\Microsoft\NetBanner:
NetBanner.exe
NetBanner.InstallState
NetBanner.pdb
NetBannerSchTask.xml
Any ideas?
Thanks.
You could try to go into the properties->Compatibility->Run this program as an administrator for the application.
Alternatively, you could do the same thing for a batch file that you can schedule to run on startup.
Related
I have an SSIS job that contains a script task.
There is also a connection to another server within the package that can only be executed accessed by a specific user and the agent cannot be given read rights to the other server.
So the solution to this is have the SQL job be run as the required user.
The problem with this is this user does not have full control over the folder/file where the script task will be temporarily located while the code runs so I get a failure on the script task but if I run it in visual studio or with the normal agent account the script task executes successfully.
I have tried giving the user access to all major drives on the server but this has not solved the problem
Is the script doing something on the folder?
Or does it just need permission to execute script?
I would anyway advise you to implement error handling in script:
https://learn.microsoft.com/en-us/sql/integration-services/extending-packages-scripting/task/logging-in-the-script-task?view=sql-server-2017
Make sure it works in visual studio, so that when you get that error you are sure that the error is caused by permissions/environment.
You could also take a look at this article:
article
I have a self hosted asp.net core app deployed and in use in an enterprise environment on Windows Server 2012.
I am looking for a way to automate the update process, I am currently doing this through a bat file but keep getting windows file lock errors where the file cannot be deleted. The process I am following in the bat file is as follows:
kill the dotnet core process for the web app
clear the directory (after sleep for a couple of seconds)
copy the updates over
restart the web app
I am getting the errors in 2 where I try to clear out the existing directory which still has file locks even though I have killed the process - "Cannot delete output file - access is denied".
My question is how can I upgrade the self contained asp.net core web app in place and avoid the file locks? If the site is offline for a few seconds it is not an issue.
Thanks
There a several reasons i can think of that deleting the directory gives access denied errors.
Your process isn't actually stopped yet. I know you can use powershell to await until porcess is stopped. (or check if process is stopped yet and otherwise wait 3 more seconds)
Another process still runs in this folder. (maybe even a command line, or explorer.exe is opened in the folder.)
You need admin rights to delete this folder.
The bat file you are executing executes from this directory, and itself is locking the directory.
Try one of the following:
powershell Stop-Service.
It should wait until service is really stopped.
powershell Wait-Process Waits untill process is stopped. you can call this directly after Stop-Process
Try to run powershell to wait like this for example (in commandline):
powershell -Command "Wait-Process -Name MyProcess"`
(warning you might run into ExecutionPolicy problems)
Tip
Use msdeploy, you can remote execute commands and deploy your application.
You can use pre and post scripts (to stop and start the app) and msdeploy it self will sync the folder/directory for you.
I'm trying to run a batch file from Windows 8 Task scheduler and I'm getting an access denied error on the command prompt for the following command line.
echo "Hello World" >> C:\File.txt
However, if I tick the checkbox "Run with higest privileges" under the task scheduler then it works fine.
The question is why do I require to tick the checkbox when I can run the batch manually without the "Run as administrator"?
A couple possibilities:
If a task is registered using the Administrators group for the security context of the task, then you must also make sure the Run with highest privileges check box is checked if you want to run the task.
If you are using the S4U functionality, make sure the Logon as batch job policy is set for the user.
Make sure the user account the task is using has write access to the C:\ directory
By default in modern Windows you cannot write to the root directory. Use "%temp%\file.txt" instead.
I am using the 7zip standalone .exe to unzip a file. I am using the Execute Process task for this. I have tested this over and over again on multiple machines and I know it works (at least in debug mode/visual studio). I have uploaded this package the server. I have created a job that calls said package from the Package Store. The package is not able to find the .exe no matter where I put it.
My first thought was to put the .exe on the C:\ drive, which failed. I have also failed in my attempts to place the .exe on a network location that the account the package is running under has full control over.
Basically, has anybody else had issues getting the Execute Process Task to find an executable when the package is uploaded to the server?
The error message is
Can't find 7za.exe in directory C:\7zip
I'll risk a downvote for being wrong, but I believe you have a permission issue.
You say it runs fine on other servers from BIDS, try it without BIDS. Call it from a command-line on a box that it works on.
dtexec.exe /file C:\HereComesTheUnzipper.dtsx
If that works, then repeat the step on the troublesome server. RDC into the box and try again
dtexec.exe /ser localhost /sq HereComesTheUnzipper
If that still works, then you are looking at an issue with the job. What account is the SQL Agent service running as? Is the SSIS job step running as a particular set of credentials? If so, is it a SQL Server login (which wouldn't map to anything on the physical box)? Regardless of what your answer is, the resolution will be to ensure the account has access to
7z.exe
whatever scratch area 7zip may use while unpacking files (I assume %temp%)
the output folder (C:\bin\7z.exe -e e:\data\MyThing.7z)
We have a web page that uses Process.Start to run msbuild, and we supply it with an msbuild file to process.
The msbuild script contains many normal msbuild tasks, and an Exec task to run hg.exe.
When we tell Process.Start to simply run "msbuild.exe" it works fine. The script is executed, hg.exe is run, everything is fine.
But when we tell Process.Start to run "c:\specific-path-to-4.0\msbuild.exe" it fails. It does try to execute the script, and it does execute some of the tasks, but it fails to run the Exec task that runs hg.exe. It gives an "access denied" error.
The problem is, we have some tasks in there that require 4.0, so we do need to use that version of msbuild.
We have gone around giving priviliges like crazy to exes and paths all to no avail. Any help would be greatly appreciated.
the problem had something to do with 64bit versus 32bit. while it "runs on my machine!" and on other servers just fine, on some servers we had the problem listed here. All of the test machines were 64 bit, but some had the problem and some did not. in the end, the fix was simple:
we needed to call:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
instead of calling:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe
we never could figure out what exactly was the cause, or why it worked on some servers but not others. but this simple change works on all of them, so we're happy!
not sure if this is appropriate or not but to give credit where it is due... our fantatical support at Rackspace figured it out for us!