I am trying to create a script that add a certain user/group to "log on as a service" in my Windows 2008 box. However I have tried using the ntrights.exe, downloaded it and ran the line ntrights +r SeInteractiveLogonRight -u CSSGroup in cmd but it failed because of the incompatibility.
Can someone help me or point me in any other useful direction?
These things are stored in the registry. Only System has access. So use psexec
psexec -s -i <your script>
to run script as system giving you access to the security info (which you'll have to turn on and compare to regkeys when turned off as they are in binary structures).
You can also take ownership of the keys and give yourself permission to access.
HKEY_LOCAL_MACHINE\SECURITY
I'm trying to call a Jenkins job remotely using a post-commit script. I'm currently committing code through Eclipse Kepler/Subversive/SVNKit Connector.
post-commit script:
if svnlook dirs-changed -r "$REV" "$REPOS" | grep -qEe '^trunk/'; then
wget --post-data="job=APS-RemoteServerAction&token=SECRET&ACTION=deploy&ASSET_NAME=POST-COMMIT-TEST&DEPLOY_ENV=DEV&REVISION=$REV" "http://my.domain.com:8080/buildByToken/buildWithParameters"
fi
Screenshot of error through Eclipse:
Important notes:
Code does get committed properly, repository browser indicates a new version
The job runs on Jenkins, the history shows that
Everytime I commit, I get this error message
I tried adding the flag --quiet, but I got the same exit code.
I'm thinking it's due to wget and posting the values?
Edit #1
I would like to point out that I'm using the Jenkins Build Authorization Token Root Plugin. I switched to a POST instead of a GET (which works) due to eventually moving onto https and keeping the token out of the URL.
I interpret the error message to mean that wget can not write a file with the name buildWithParameters in its current directory. Use wget -O - to write the output to stdout.
The error is (I think) because it's trying to download the webpage to a local dir. You just need to ping the endpoint to make jenkins build, so I used the --spider (doesn't download), --no-proxy (I was getting cached responses sometimes) and -q (don't output, cuz svn will report it).
wget --post-data="job=APS-RemoteServerAction&token=SECRET&ACTION=deploy&ASSET_NAME=POST-COMMIT-TEST&DEPLOY_ENV=DEV&REVISION=$REV" "http://my.domain.com:8080/buildByToken/buildWithParameters" --spider --no-proxy -q
Environment & Task: I have configured the ssh password less authentication(by exchanging public key) between user1 of machine1(2003) and user2 of machine2(HP-UX) machine after words I am using that ssh connection in the perl script to execute the ssh command at machine2.
Issue: When ever i am manually executing the script from machine1 it is not asking any password for user2 of machine2, If i execute the same throught the task shedular of windows2003 it is asking the password of user2 of machine2.
can any body help me out in knowing the reason..
Thanks in advance,
kishore.
This was a nightmare.
I finally figured out that you need to set the HOMEDRIVE and HOMEPATH environment variables. Using the command 'set' to print out the environment variables when running interactive and with task scheduler and comparing the output, these were the only two that were not present with task scheduler and thank God they worked. After setting these, the task scheduler could finally see the known hosts,
If you want to use scp to copy files to the windows machine you will probably come across another delightful problem when running via task scheduler: for some reason scp cannot copy to any old folder, it must be the home folder of the logged in user. Well maybe it's not quite as restrictive as that but I honestly could not be bothered finding out by the time I was done with 6 hours of this nonsense. Anyway, the workaround is to first scp the files to the logged in user's home folder, then move them to the final destination after that.
Here is how my batch file ended up (run from inside the final destination directory):
set HOMEDRIVE=C:
set HOMEPATH=\Documents and Settings\loggedinuser
echo Compressing data files on server...
ssh user#host "cd /foo/bar ; gzip -fc foobar > foobar.gz"
echo Copying files from server...
scp user#host:/foo/bar/foobar.gz "%HOMEPATH%"
move "%HOMEPATH%\foobar.gz" .
I hope this helps some poor soul out there someday.
I have to download a file daily from perforce depot.
Presently I do it manually by selecting that file and using "Get latest version" option.
I want to write a script which I will schedule in my windows task schedular to get the file daily.
Please help me/guide me how to do this task automatically.
I am using p4v client software in windows XP operating system.
Using P4V will make it hard to automate. I suggest you use the command-line client, p4.exe, instead. If there's only one file that you need the contents of you could simply use "p4 print" and avoid the need for creating a workspace (client) spec, e.g:
p4 print -o <local filename> //depot/path/to/file
Note that the above command requires you to be already logged on to the Perforce server. There's at least two ways around this:
1) Specify the username and password on the command-line (not really recommended for security reasons):
p4 -u myuser -P mypasswd print -o <local filename> //depot/path/to/file
2) Use a dedicated background user for the task, with an unlimited login expiration time (see p4 group and the Timeout field):
p4 -u backgrounduser print -o <local filename> //depot/path/to/file
A licensed "background user" designated for only performing automated tasks can be obtained at no further cost from Perforce Software. Try contacting Perforce support and ask them about this.
In a bat you can use the p4.exe commandline tool that comes with p4v and issue the sync command:
p4 sync myFileThatINeedToGetDaily.txt
Before Issuing Sync, make sure you have logged in and set the port and client view
p4 -u myuser -P mypasswd
p4 set P4PORT=server:nnnn
p4 sync file1.txt
The command you need is p4 sync.
While I'm using PSEXEC.exe getting 'Access denied' error for remote systems.
Any idea about how to solve this?
Hi i am placing here a summary from many sources online for various solutions to "access is denied" :
most information can be found here (including requirements needed) - sysinternal help
as someone mentioned add this reg key, and then restart the computer :
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system
/v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Read this knowledge base article to learn what this does and why it is
needed
Disable firewall (note - this will leave you with out any firewall
protection)
netsh advfirewall set allprofiles state off
if target user has a blank PW and you dont want to add one, run on target:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LimitBlankPasswordUse"=dword:00000000
This didnt work for me, but i have read it did for others in a few places,
on target execute:
Start -> Run -> secpol.msc -> Local Policies -> Security Options -> Network Access: Sharing > and security model for local accounts > Classic – local users authenticate as themselves
if already in 'Classic':
move to "Guest only - .." run from elevated command prompt gpupdate \force
move back to 'Classic - .." again run from elevated command prompt gpupdate \force
This one solved my issue:
run on target from elevated command prompt "net use" look at ouput chart and for shares listed in remote column there (i only deleted the disconnected ones - you can try them all) run "net use [remote path from before list] /delete" then run 'net use \target\Admin$ /user:[user name]' enter prompt password request (if empty PW just press enter), viola should work.
I just solved an identical symptom, by creating the registry value HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy and setting it to 1. More details are available here.
This helped in my case:
cmdkey.exe /add:<targetname> /user:<username> /pass:<password>
psexec.exe \\<targetname> <remote_command>
PsExec has whatever access rights its launcher has. It runs under regular Windows access control. This means whoever launched PsExec (be it either you, the scheduler, a service etc.) does not have sufficient rights on the target machine, or the target machine is not configured correctly. The first things to do are:
Make sure the launcher of PsExec is familiar to the target machine, either via the domain or by having the same user and password defined locally on both machines.
Use command line arguments to specify a user that is known to the target machine (-u user -p password)
If this did not solve your problem, make sure the target machine meets the minimum requirements, specified here.
You can try the command
net use \\computername\ipc$ /user:adminname password
to get admin permissions on remote PC before use psexec.
I had the same problem. And after a hard work, I found a easy and full solution:
I use runas to run the script in a admin account
I use the -s parameter in psExec to run in a system account
Inside the PsExec, I login again with a admin account
You can use & to run multiples commands
Remember to replace [USERNAME], [PASSWORD], [COMPUTERNAME], [COMMAND1] and [COMMAND2] with the real values
The code looks like this:
runas /user:[USERNAME] "psexec -e -h -s -u [USERNAME] -p [PASSWORD] \\[COMPUTERNAME] cmd /C [COMMAND1] & [COMMAND2]"
If you whant to debug your script in the another machine, run the following template:
runas /user:[USERNAME] "psexec -i -e -h -s -u [USERNAME] -p [PASSWORD] \\[COMPUTERNAME] cmd /C [COMMAND1] & [COMMAND2] & pause"
Try setting this key on the target (remote) machine, and restart the machine:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001
See: http://forum.sysinternals.com/topic10924.html and http://www.brandonmartinez.com/2013/04/24/resolve-access-is-denied-using-psexec-with-a-local-admin-account/
I just added "-с" parameter. It makes Psexec copy executable to remote machine. So it works without access errors.
I found Sophos kept placing psexec.exe into the Quarantine section. Once I authorized it, it ran fine.
I still use psexec, even on win 10. Replace the psexec.exe in the Windows 10's win32 folder with the older version to work -> I use version 2.11.0.0. The Windows 10 version I was using would only run .bat files as background/hidden process on the remote computer. Took a whole day to figure this out.
Adding the registry key from above to the remote computer helps as well:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
I found another reason PSEXEC (and other PS tools) fail - If something (...say, a virus or trojan) hides the Windows folder and/or its files, then PSEXEC will fail with an "Access is Denied" error, PSLIST will give the error "Processor performance object not found on " and you'll be left in the dark as to the reason.
You can RDP in; You can access the admin$ share; You can view the drive contents remotely, etc. etc., but there's no indication that file(s) or folder(s) being hidden is the reason.
I'll be posting this information on several pages that i was perusing yesterday while trying to determine the cause of this odd problem, so you might see this elsewhere verbatim - just thought I'd put the word out before anyone else pulled their hair out by the roots trying to understand why the performance counter has anything to do with PSEXEC running.
I had a case where AV was quarantining Psexec - had to disable On-access scanning
For anybody who may stumble upon this. There is a recent (Dec 2013) Security Update from Microsoft Windows on Windows 7 that is preventing remote execution.
See http://support.microsoft.com/kb/2893294/en-us
I uninstalled the Security Update by going to Control Panel\Programs\Programs and Features\Installed Updates
It worked right after that.
The following worked, but only after I upgraded PSEXEC to 2.1 from Microsoft.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"LocalAccountTokenFilterPolicy"=dword:00000001 See:
http://forum.sysinternals.com/topic10924.html
I had a slightly older version that didn't work. I used it to do some USMT work via Dell kace, worked a treat :)
On Windows Server 2012 R2 I had trouble to run from user account
psexec -u administrator -p password \\machinename -h -s -d -accepteula cmd.exe
But it works fine if you run without parameters -h -s. That's why I use this to solve my trouble:
psexec -accepteula -u administrator -p password \\machinename %PathToLocalUtils%\psexec.exe -h -s -d cmd.exe
I couldn't get access to remote machines unless I had UAC disabled.
That has to be done locally, either from control panel or running the following through cmd:
reg.exe ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v EnableLUA /t REG_DWORD /d 0 /f
While UAC is enabled, make sure you run cmd as administrator.
For a different command I decided to change the network from public to work.
After trying to use the psexec command again it worked again.
So to get psexec to work try to change your network type from public to work or home.
I tried a lot of way but I could not use psexec. It gives "Access denied". After I change the target user account type from Standard to Admin, I connected the machine via psexec.
I researched the reason why admin type account is required then I found this answer.
You can change target machine user account this way: Control Panel -> User Accounts -> Change Account Type. You must enter an admin account and password to change that account if you logged in standard account.
After that I logged in with this command: psexec \\remotepcname -u remoteusername -p remotepassword cmd
Tried all suggestions above, but still was unable to resolve the error. Finally once I made the below change, I could successfully run the PSexec command.
Turns out that when you have UAC enabled psexec does not work as supposed. We need to set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA to 0 then psexec starts working as expected.