I am trying to delete some folders on my C: drive, but I cannot remove them after we got switched over to using AD and Group policy on our domain. When I try to delete the folder it tells me "You require permission from OURDOMAIN\matt.johnson to make changes to this folder", but then if I open up powershell and run whoami it tells my I am 'OURDOMAIN\matt.johnson'... so why do I still not have permission to delete it! I even tried using takeown then rmdir and I still get permission denied errors.
Well, not exactly a PowerShell issue but more about user rights elevation in the post-XP OSes.
Right click on PowerShell Icon, and choose "runas Administrator", then run your command.
Related
I run the cmd prompt as administrator.
The cmd is attrib +h +s +r filename.png
.But the error Access denied is appeared.Can someone help me to get through .I already searching in google .Nothing have solved it yet.
You can change your permissions to the file, remove TrustedInstaller and add yourself make sure you check everything on, then try again.
as administrator I cannot execute commands in cmd, access denied, nor does it allow me to run gpedit, change settings on network adapters, or change permissions on any folder.
Click Windows button and write "command"
Then you'll get "Run as administration".
Every day when I log into VDI my vscode extensions get removed on a daily basis.
So I need to install them every day. Is there any walk around to keep the extensions with persistence and that I don't have to download/install it again on a daily basis when ever I log in.
Any help would be much appreciated and thanks in advance.
It seems that you are using a nonpersistent VDI, so you should ask your IT to install the vscode extensions that you need in the image stored in the servers.
Excerpt retrieved here:
There are two main approaches to VDI: persistent and nonpersistent. Persistent VDI provides each user with his or her own desktop image, which can be customized and saved for future use, much like a traditional physical desktop. Nonpersistent VDI provides a pool of uniform desktops that users can access when needed. Nonpersistent desktops revert to their original state each time the user logs out.
Found this on GitHub and it is down near the bottom... https://github.com/microsoft/vscode/issues/17691
Create an environment variable named VSCODE_EXTENSIONS. Set the path you wish the extensions to be stored. We used a network share in our implementation to keep extensions persistent in a non-persistent VDI. (e.g VSCODE_EXTENSIONS = \\Server\Share\%USERNAME%\.vscode)
This environment variable must be in place before VSCode launches. We are utilizing this with VSCode 1.52.1 and it is working for us.
This is how I got it to work in my environment. You need to install the extensions using the .vis format, and then copy the extensions from that local profile to a location any user can access. After that, create a GPO that will run this script at every logon and set the scope to your VDI access AD group. The logon GPO is located at User Configuration > Policies > Windows Settings > Scripts > Logon > Powershell This may be a crude way of doing it, but it's working in my environment.
#This will not work unless there are extensions on the root of the default user
#folder. Install Visual Studio Code and its extensions first, then copy the
#entire "\.vscode" folder from the user profile you installed it into and onto
#the default user profile root folder.
#This script tests to see if the extensions already exist in the root folder of
#the user logging in using the path described in the below variable.
$vscodeextensions = "$env:USERPROFILE\.vscode\extensions\ms-vscode.cpptools-
1.13.2"
#This will just allow the script to run.
Set-ExecutionPolicy bypass
If(-not(Test-Path $vscodeextensions)){
Copy-Item -Path "C:\Users\Default\.vscode\" -Destination "$env:USERPROFILE\"
-Force -Recurse
}
else{
Write-Host "Extensions already copied"
}
I have a scheduled task on a Windows 2008 R2 server. The task includes a Start In directory entry. The task runs, and the batch file it runs does what it is supposed to do. When I run the batch file from a command prompt, I see no errors. The problem is that the "Last run result" is 0x1 (incorrect function call).
I did get this at one time with an incorrect DOS statement IF EXISTS file.txt DO (Copy file.txt file1.txt) that was corrected by dropping the DO statement. The current batch file does not show me any errors or warnings.
Why am I getting a 0x1 result?
Batch file that is run:
PUSHD \\JUKEBOX4\Archives\CallRecording
REM only move csv and wma together. wma should be created last.
IF NOT EXIST C:\CallRecording (MKDIR C:\CallRecording)
FOR /f %%f IN ('DIR /b *.wma') DO (
IF EXIST %%~nf.csv (MOVE /Y %%~nf.* C:\CallRecording\)
)
POPD
CD /D "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload"
CollybusUpload.exe
POPD
Info on scheduled task setup:
Program to run: C:\Program Files (x86)\Olim, LLC\Collybus DR Upload\CallRecordingUploadFromH.cmd
Start in: C:\Program Files (x86)\Olim, LLC\Collybus DR Upload
Run whether user is logged on or not, highest privileges.
History screen, task completed entry
"Task Scheduler successfully completed task "\Call recording upload to portal from NH" , instance "{1449ad42-2210-427a-bd69-2c15e35340e6}" , action "C:\Windows\SYSTEM32\cmd.exe" with return code 1."
First screen of Task Scheduler shows "Run Result" of "Success"
It seems many users are having issues with this. Here are some fixes:
Right click on your task > "Properties" > "Actions" > "Edit" |
Put ONLY the file name under 'Program/Script', no quotes and ONLY the directory under 'Start in' as described, again no quotes.
Right click on your task > "Properties" > "General"
| Test with any/all of the following:
"Run with highest privileges" (test both options)
"Run wheter user is logged on or not" (test both options)
Check that "Configure for" is set to your machine's OS version
Make sure the user account running the program has the right permissions
I found that I have ticked "Run whether user is logged on or not" and it returns a silent failure.
When I changed tick "Run only when user is logged on" instead it works for me.
I've had the same problem. It is just a batch-file, working when manually started, but not working as a scheduled task.
there were drive-letters in the batch-file like this:
put z:\folder\file.ext
seems like you should not use drive-letters, they are bound to the user, who created them - for me this little change made it work again:
put \\server\folder\file.ext
For Powershell scripts
I have seen this problem multiple times while scheduling Powershell scripts with parameters on multiple Windows servers.
The solution has always been to use the -File parameter:
Under "Actions" --> "Program / Script" Type: "Powershell"
Under "Add arguments", instead of just typeing "C:/script/test.ps1" use -File "C:/script/test.ps1"
Happy scheduling!
Windows Task scheduler (Windows server 2008r2)
Same error for me (last run result: 0x1)
Tabs
Action: remove quotes/double-quotes in
program/script
and
start in
even if there is spaces in the path name...
General:
Run with highest privileges
and
configure for your OS...
Now it work!
last run result: The operation completed successfully
Probably not the cause of the OP's problem; for me the problem was caused by the fact that my program called a SQL function, and the service account the windows task was set up with did not have the required SQL permissions. That also gives a 0x1
This answer was originally edited into the question by the asker.
The problem was that the batch file WAS throwing a silent error. The final POPD was doing no work and was incorrectly called with no opening PUSHD.
Broken code:
CD /D "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload" CALL CollybusUpload.exe POPD
Correct code:
PUSHD "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload" CALL CollybusUpload.exe POPD
In my case it was an encoding issue. We wanted to start en existing batch file, and it resulted in "return code 1", and the desired action wasn't performed. I've accidentally found that the batch file was shown in Notepad as one with UTF-8 encoding (actually without any reason, as we have no special characters in the text). I saved it as ANSI, and it solved the problem for us. Might be, that it was a kind of encoding corruption in the file that prohibited Task Scheduler and cmd.exe to open the file, although it was displayed correctly in Notepad.
On our servers it was a problem with the system path. After upgrading PHP runtime (using installation directory whose name includes version number) and updating the path in system variable PATH we were getting status 0x1. System restart corrected the issue. Restarting Task Manager service might have done it, too.
I was running a PowerShell script into the task scheduller but i forgot to enable the execution-policy to unrestricted, in an elevated PowerShell console:
Set-ExecutionPolicy Unrestricted
After that, the error disappeared (0x1).
Just had the same problem here. In my case, the bat files had space " "
After getting rid of spaces from filename and change into underscore, bat file worked
sample before it wont start
"x:\Update & pull.bat"
after rename
"x:\Update_and_pull.bat"
For me the problem was the PowerShell script being ran had #Requires -RunAsAdministrator at the top, meaning it needs to run in an elevated command prompt as an Admin, but the user the Scheduled Task was set to run as wasn't an admin on the local computer. So even though Run with highest privileges was checked in the scheduled task, I still had to make the user an Administrator on the computer. Once I did that, the script ran as expected.
Since there is always more than one reason this could happen I thought I'd share some troubleshooting tips that helped me diagnose my issue.
Always adding a "start in" parameter first since thats an easy fix, even just adding the drive letter can help, e.g. C:\
If you're running "whether user is logged on or not" and it is failing it might be an issue with your user and/or user environment.
Switch the task to run only when user is logged in temporarily for
troubleshooting purposes.
Make sure you're actually logged in AS the user you're telling the task
to run as. (PATH and other environment variables are different by user
and if you see the task running on one user successfully that doesn't
necessarily mean it will run successfully for another user even if they're in the same security group.)
Add pauses or some other type of debugging to your script to give you
time to see any errors that may pop up.
Perform a manual run from the task scheduler window.
Fix any errors you see from your debugging statements. Rinse and repeat.
If it runs successfully switch back to run "whether user is logged on
or not" and try another manual run. If it works now you're all set.
If nothing has helped so far you might need to dig in deeper to your user and file privileges. My troubleshooting tips assume that you have been able to get a past task running using a specific user login already. They don't cover building a scheduled task from a fresh install necessarily. Luckily I haven't had to do that.
What solved it for me was that I was using a local administrator account instead of the domain account so I changed the "Run as" to the domain account.
It turns out that a FTP download call using winscp as last thing to do in the batch caused the problem. After inserting the echo command it works fine. Guess the problems source could be the winscp.exe which do not correctly report the end of the current task to the OS.
del "C:\_ftpcrawler\Account Export.csv" /S /Q
"C:\Program Files (x86)\WinSCP\WinSCP.exe" /console /script="C:\_isource\scripte\data.txt"
echo Download ausgeführt am %date%%time% >> C:\_isource\scripte\data.log
I had this in my Windows services:
C:/Program Files/PostgreSQL/8.4/bin/pg_ctl.exe runservice -N "postgresql-8.4" -D "D:/PostgreSQL/8.4/data" -w
It never finishes executing. But if I did this on the dos shell:
C:/Program Files/PostgreSQL/8.4/bin/pg_ctl.exe start -N "postgresql-8.4" -D "D:/PostgreSQL/8.4/data" -w
Notice that I only changed the "runservice" to "start" and it works just fine.
Any idea?
The command runservice can only be executed by the service manager
in order to fix my localhost windows 7 to start postgres as a service
i used the following command to start the data
pg_ctl -D "C:\Program Files\PostgreSQL\9.1\data" start
Then checked the status for errors
pg_ctl -D "C:\Program Files\PostgreSQL\9.1\data" status
if you get error 1063 , its more than likely permissions, i executed the following command
cacls "C:\Program Files\PostgreSQL\9.1\data" /E /T /C /G postgres:F
then reran the start/status, it showed everything fine, but still service manager would not start the service
So, in Services->postgresql->options->logon i set the log on as the Local system account instead of the postgres user, and voila it worked
this happened to me because i set my data directory to be somewhere the postgres windows user account didn't have access to.
I had this problem in Windows after a system crash. Running the first command showed invalid data in C:\Program Files\PostgreSQL\9.1\data\postmaster.pid. Deleting that file did the trick. Reference.
I faced the same issue after moving manually the database data files (PG_DATA directory) without recreating all the necessary permissions.
Here is how I solved my issue:
1. Check permissions on old PG_DATA directory:
cacls "c:\path\to\old\pgdata\dir"
2. Check permissions on new PG_DATA directory:
cacls "d:\path\to\NEW\pgdata\dir"
3. Compare outputs from 1. and 2.
Find the differences between users and/or permissions then synchronize them.
Nota: I found it easier to use explorer for the synchronization step rather than using cacls directly from the command line.
If you changed pg_hba.conf , maybe you missed somewhere in file. For example there must be CIDR after IP in that file. It must be like 192.168.1.100/32
If you forgot to put 32, then server doesnt restart.
Investigation of startup logs could be a clue. For the case problem is in the pg_hba.conf you could see something like this:
2018-11-13 00:39:34.841 PST [8284] FATAL: could not load pg_hba.conf
2018-11-13 00:39:34.842 PST [8284] LOG: database system is shut down
You need to check your logfiles and the windows eventlog for some hint of what the problem is. If there is nothing at all there, you need to break out something like Process Monitor and get a stacktrace of where it's hung.
I have had this issue in the past, and it was that the installer did not set up the permissions correctly for the user that the service was to run as.
I've also ran into this problem with postgresql throwing and error after trying to initialize the database cluster. After analyzing the log files and running command line scripts for 4 hours I've got the solution to anyone running into this problem for Windows Versions.
This is not a detailed description as to why its happening. I've installed odoo 10, 11, 12 and 13 numerous times on countless client servers and windows systems and this is the first time I've ever ran into this problem. I cant say if its because I have MS VS Enterprise installed and Android Studio on this machine or what. But Below is the easy answer on how to fix it and initialize the cluster and create the database files in the data folder.
Open the data folder for postgresql. - For Odoo installs it will normally be "C:\Program Files (x86)\Odoo 13.0\PostgreSQL" Unless you chose another location when installing.
Remove any or all files from this folder - If not you will get an error when running initdb.exe
Right click the data folder and open up the properties for it. Click on the Security tab and then click the advanced button on the bottom.
You need to change the owner of this folder to openpgsvc. Click Change and type in openpgsvc and click ok. Once done click the check box below saying that you want this change to affect containers with this container as well.
Then on the Permissions tab click the add button on the bottom. You need to add openpgsvc as a user and give this user full rights. Click apply and and ok to close out of all the folder properties.
Now you need to open cmd.exe - Once open we are going to call initdb.exe and pass some values to it as well.
First run chdir and change the working directory to the location of initdb.exe. For me, running odoo 13 on a windows 10 machine the location is this..
"C:\Program Files (x86)\Odoo 13.0\PostgreSQL\bin"
There is one variable that need to be passed as well to make this work here is the list. NEEDS TO BE INCLUDED IN THE CALL TO initdb.exe
Postgres Data Dir: "C:\Program Files (x86)\Odoo 13.0\PostgreSQL\data"
The End Result with the parameter would look like this for my installation:
"C:\Program Files (x86)\Odoo 13.0\PostgreSQL\bin\initdb.exe" -D "C:\Program Files (x86)\Odoo 13.0\PostgreSQL\data"
Hit Enter and let it rip. The output of this command should look like this below.
Cmd.exe running initdb.exe script
Make sure there is no buggy empty file Program at C:\ like C:\Program
In this case, explorer will warn whenever you log on into Windows.
File Name Warning
-----------------
There is a file or folder on your computer called "C:\Program" which
could cause certain applications to not function correctly. Renaming it
to "C:\Program1" would solve this problem. Would you like to rename
it now?
Installing PostgreSQL 10 On Windows 7 (yes the clock is ticking...). I first tried the latest version 11 which completely failed to install... not a good sign for Windows users. Anyway.
Quick answer: Change the account in the Windows Services panel from Network to Local.
Details of my case
During installation I created/selected a data folder in the user profile folder, because obviously the folder suggested by default, within the program folder, wouldn't work, and if it worked it would be a very idea to put data here (I don't know whether it's usual to do that on Unix/Linux, but for Windows it's it's not allowed for a long time).
At the end (when populating the data cluster) I received an error:
Failed to load SQL Modules into database Cluster
but the installation was able to complete. I found two pages about previous error, here and here, but they didn't seem relevant to my case, so I just started pgAdmin and, on the left "browser", saw the server wasn't active.
I tried to start it from here (had to type the main password), but it went inactive immediately again. So I tried to use the Windows services panel to start "postgresql-x64-10", no joy. I copied the command from this panel and pasted it into a Windows console (cmd.exe) where I finally received this
error 1063.
Searching I found this related question, and was convinced the problem was about permissions.
Solution working for my case
In the services panel I changed the account used to start the service from Network Service to Local System as suggested in a comment by #AlexanderRios.
sc create "postgresql-9.2" binPath= "\"C:/Program Files (x86)/PostgreSQL/9.2/bin/pg_ctl.exe\" runservice -N \"postgresql-9.2\" -D \"C:/Program Files (x86)/PostgreSQL/9.2/data\" -w" DisplayName= "postgresql-9.2" start= auto
Try this on CMD run as Administrator
(Add your parameters depend on your version)
Stop all postgres processes
Go to the postgres data folder (C:\Program Files\PostgreSQL\9.6\data)
Delete the postmaster.opts and postmaster.pid files
From the control panel, in administrative
tools and the services console start the postgres service
open pgAdmin III and then in right pane find server then just right click and connect, enter the password. after connected go to the browser and refresh ODOO. Problem solved.
See image to get better understanding