We have a batch file that certain users can launch from their local machines that will run a PowerShell script on a DC in order to unlock user accounts or reset a password. However, all of a sudden it's not working, not even for network admins running it as an administrator. If we log on to the DC and run it locally, it works exactly as it should.
There haven't been any changes to the permissions of the file and no changes to the AD groups that have permission to run the file.
The batch file is this:
#echo off
cls
echo Loading, Please Wait...
;C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe -ExecutionPolicy Bypass -File %logonserver%\<PATH TO FILE>\FILENAME.ps1
Same batch file that it's always been, but now when we run it remotely, we get multiple errors:
The term 'Get-ADGroupMember' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Locally, it runs just fine. And yes, the first thing the PowerShell script does is
Import-Module ActiveDirectory -ErrorAction SilentlyContinue
As I said, it used to work but now it doesn't and we're completely lost as to why. We've searched and searched, but can't seem to find any information as to what might be causing it to error out.
If anyone has any ideas or suggestions, we would appreciate it.
Discovered that RSAT wasn't on any of the machines anymore. It required downloading the installer and running it on the machines. Once we did that, everything works like it should.
Related
I have a PowerShell script that configures WinRM on our remote servers when ran on the local user's account. However, I need to upload the script to TFS and have each host run the script themselves.
The script checks if WinRM is configured. If it is not, then it checks if the C:\PSTools\PsExec.exe path exists. If the path exists, it needs to configure WinRM using:
$configure = (C:\PSTools\PsExec.exe \\$hostname -s winrm.cmd -q 2> $null)
However, the above results in the error
The term 'C:\PSTools\PsExec.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I know the file is there, so I am not sure what I am doing wrong here. Other examples I've seen use either psexec alone or ./PsExec.exe, but none of those work.
Any advise appreciated, thanks.
While this doesn't answer why psexec.exe isn't working (although I suspect it's because the file isn't actually there), you can use WMI to enable WinRM instead:
([wmiclass]"\\$hostname\root\cimv2:win32_process").
Create('powershell "Enable-PSRemoting -Force -SkipNetworkProfileCheck"')
and to restart your service remotely (even though Enable-PSRemoting handles this):
$svc = [wmi]"\\$hostname\root\cimv2:win32_service.Name='winrm'"
$svc.StopService()
$svc.StartService()
I am experiencing below issue when I run the batch script as administrator. When I
ran the same script normally, there were no issues.
Please share some thoughts on this issue.
snapshot of the error
When you run as administrator, the user session changes from your user session to one based in %SystemRoot%\System32. What you need to do is get the path of the current invocation of your Powershell script and make it the path of your build1.ps1 script:
$ScriptPath = Split-Path $MyInvocation.InvocationName
& "$ScriptPath\build1.ps1" -Target prepare-qa
This way, regardless of user, the script is executed in the proper location.
When you open powershell as a user, the default directory is C:\Users\MyName.
When you open powershell as an admin, the default directory is C:\WINDOWS\System32.
In your script, try using Set-Location C:\Users\myusername or where ever your script is located. Or, fully qualify the script's path.
I'm trying to have a few scripts that I can map to run from my keyboard for quickly changing the monitor/screen brightness. After some searching on the internet, I found this script which works when I enter it into Powershell.
$monitor=#(gwmi WmiMonitorBrightnessMethods -ns root/wmi)[0]
$monitor.WmiSetBrightness(50,0)
After I saved it as a .ps1 file and tried running it from the file, powershell tells me: The term "path of the file" is not recognized as the name of a cmdlet, function... and so on.
I'm not familiar with Powershell at all, can someone help with what I need to add in order for the script to run properly?
By default you can't run a PowerShell script that is in the current directory without putting .\ in front of the script name, or calling the full path of the script.
This is a security feature.
If you are in the directory that contains the script, run it by executing in a PowerShell window:
.\yourscript.ps1
Where yourscript is the name of your script.
See here for more information: https://ss64.com/ps/syntax-run.html
You may also see this error if your script has spaces in its name. If that is the case, enclose the path in quotes:
.\'your script.ps1'
I'm trying to have powershell create a folder for me and it works fine when I type it into the console. However, when I run the same command as a script, no folder is created and no error messages are supplied.
This is the line of code I am using.
new-item - path c:\test\ -name testfolder -itemtype directory
edit: I am on Windows 7
This should be a comment, but I cannot comment. There is definitely nothing wrong with that line of code. It runs on my machine, either from the terminal window or as a script. Because the code works for you at the terminal window but not when executing as a script my first guess is that your system may be configured to disallow powershell scripts. This is the default setting, and it will prevent a script file from executing but will not prevent commands typed at the prompt from working. Open a powershell session and type get-executionpolicy. If it returns "restricted" then you have found the culprit. This setting can be changed by opening an elevated powershell session (run as admin) and typing set-executionpolicy -executionpolicy RemoteSigned. Of course you should read about what those settings mean before changing them to determine what is best for your situation. For example the remotesigned option means that scripts originating from your machine will execute without a trusted signature, but external scripts will require a signature.
I have this setup with a GPO to run as a logon script, obviously to map a drive for clients.
net use H: \\server1\share\$env:username
Dead simple. If I put in a specific username in place of the variable then it works. Also, if I run this script directly on a client machine it works.
Do you get an error? Does it helps if you wrap the path in double quotes?
"\\server1\share\$env:username"
That should work with or without the quotation marks. Are the clients all Windows 7? I believe that Powershell logon/startup scripts don't work on earlier versions, even if you have Powershell installed, because it's an add-on rather than a native shell. If you're using downlevel clients, you can invoke the powershell script from a cmd batch file. But if you're going to do that, might as well skip Powershell and just run net use H:\\server1\share\%username% from your batch file.
Run this in a .bat file as a login script (use a FQDN for the server name):
net use H: \\server.example.com\share\%USERNAME%
If that not works, your GPO is just not yet applied. You can force that by running on the machine gpupdate /force.
For testing make sure that the GPO is applied to the right OU to the group "Authenticated Users" (computers are in the group too). And if that is not working, you can also "Enforce" the GPO. Don't forget to do a gpupdate /force after any change to the GPO or it settings.
You can also try a .js logon script like:
var WSH = new ActiveXObject("WScript.Shell");
// Map share
WSH.Run("net use H: \\\\server.example.com\\share");