I recently started messing around with a .BAT file to remote shut down a computer lab.
I have the file to where it will shutdown almost everyone of the machines flawlessly, but a few of them will give an error. Sadly, I did not take note of it, but I believe it had "53" after it. It stated something about the machine not supporting remote shutdown or not having administrative rights.
I started the BAT from an administrator acct., and each PC in the lab was imaged with the same image. The BAT worked fine for almost every machine except a few. I checked each failed machine and they did not have any programs open that would require user feedback to close.
I used the same line for all 20 machines only changing the number after LAB
Here's what I came up with:
ECHO Shutdown
C:\windows\system32\shutdown.exe /s /m \\HES-LAB-01
PAUSE
Any feedback would be appreciated!
Thanks!
C:\Users\User>net helpmsg 53
The network path was not found.
Presumably the server specified doesn't exist or not turned on
Related
i'm using psexec.exe from my CMD to access a remote machine.
everything worked fine for the first couple attempts,
but on the nth attempt (in my case the 5th attempt) i got the following error prompt message:
is not a valid win32 application
this is my command:
"C:\Program Files (x86)\myfolder\psexec.exe" \\MY_REMOTE_IP -u MY_USERNAME -p MY_PASSWORD cmd
could it be a problem of too many open connections?
where can i see my open connections if any?
how can i properly close a remote connection?
i reinstall PSExec.exe and it solved the problem, not sure what cause the issue but it definitely solved the problem.
This error usually means that the psexec service is down in the target machine.
In my case it was down because drive C was out of storage. After I free some space in drive C, I had to restart the machines for the service to start again (I couldn’t start the psexec service manually)
I have been attempting to automate the installation of one of my applications but have run into a few roadblocks and I really need some help.
Currently we are using Dell's KACE technology to push the installer to the local machines. The installer is run as the SYSTEM user meaning it does not and can not have direct access to network shares (relevant later).
The application installation workflow is as follows:
Stop Local Security Services to allow software install
Remove anything mapped to drive letter X
Map network drive X \test\test
TestApp.exe /s
msiexec /i Test.msi /quiet
Start Local Security Services to allow software install
copy shortcut file to desktop
The installation itself has 1 Executable and 1 MSI that have to be run. The EXE installs a mainframe application. The MSI file installs a few files locally and then registers 6 DLL files located on that mapped drive.
This is where the issue comes in - Because those files MUST be on that share drive and the installer is running as SYSTEM -> The System account account can't access the mapped drive to register the files so the installation fails.
I am further limited by the fact that I can't simply store a username/password in plaintext in the batch file.
Here is my code so far:
REM Stopping McAfee Services
echo Stopping McAfee Services.
net stop mcshield
net stop mcafeeframework
REM Map Network Drive
echo Mapping Network Drive
net use X: /delete /y
net use X: \\test\test
(Here is where I need help - Is there a way to force a username/password prompt here for the user? I basically just want the user to authenticate to the X drive mapping, which will allow the installation to move forward)
echo Starting Test 1 Installation
Test1.exe /s /v"/qb"
echo Starting Test 2 Installation
msiexec /i Test2.msi /quiet
(If the drive has not been mapped by this point, the installation fails as the SYSTEM account can't access the drive)
echo.
REM Restarting Mcafee Services
echo Starting McAfee Services.
net start mcshield
net start mcafeeframework
echo.
REM Copy Shortcut
xcopy "shortcut\*" "C:\Users\public\desktop"
Alternatively,
Could/should I convert this to a PS script? I know PS is more powerful than batch, but wasn't sure how to go about it.
If by forcing authentication prompt, you mean something that will need human input (and you aren't running this script remotely), then this line should interact with existing login session and ask for credentials:
start explorer \\test\test
echo After you have entered network credentials
pause
Once user enters valid ones, the remaining script can continue
net use X: \\test\test
After toying with ideas about this problem for a couple of weeks I decided to take a new approach.
I created a new batch file using a simple NET USE and passed the credentials of a service account w/ access to the network share in plain text. Next, I compiled the batch into an executable. It's not the most elegant solution out there I'm sure, but it's sufficient for our needs currently.
Thanks for the help everyone!
I had no problems with SCCM 2007 scripting application deployments, but SCCM 2012 has me pulling my hair out and I have very little left.
We tend to have heavily scripted installs and most of the time the installs fail in SCCM 2012, the latest failure is symantec enterprise vault, I wrote a script that would check the main DLL plugin version and use the correct uninstall string to remove the previous version, before installing the latest version.
my script is very simple and works fine outside of SCCM, but inside SCCM it fails.
If I recreate the application as a MSI deployment and use the MSI file then it installs fine, so SCCM is working correctly to the client. The uninstall that SCCM puts in from the MSI failed, but that is covered below in the example. I have checked all the client side log files and can not find any issue.
I even return the successfull install return code 1707 and 0 at the end of the script to try and get SCCM to make it a success.
I have written the script first in VB.net as a console service app and then rewrote it in vb script. both scripts fail. I used to use AutoIT to write scripts in the past, but that too was failing, so I thought I would switch to something more microsoft.
For detection I use the windows installer selection and point to the msi file where it picks up the product code.
deployment type is script.
The only thing I can think of is SCCM 2012 does not like the sleeps that are in the scripts.
or it just does not like scripts. :-(
The MSI uninstall failed, because it needed to run as administrator, as you can see from the script below, I run as administrator and this works outside SCCM, but not in SCCM. the install uses pretty much the same code but more logic and many more uninstall strings.
even the uninstall fails and here is how simple the uninstall script is;
Set WshShell = WScript.CreateObject("WScript.Shell")
If WScript.Arguments.length = 0 Then
Set ObjShell = CreateObject("Shell.Application")
ObjShell.ShellExecute "wscript.exe", """" &
WScript.ScriptFullName & """" & "RunAsAdministrator", , "runas", 1
Else
end if
Set objShell = CreateObject("WScript.Shell")
Set objExec = objShell.Exec("MsiExec.exe /x{ADEBB592-4986-4FD1-868C-D59DB32F0BC2} /q")
WScript.Sleep 8000
returnValue = 1707
WScript.Quit(returnValue)
Just because it works outside of SCCM, does not mean a lot if you have to make it work with SCCM! people make that comparison all the time a work and it means nothing, what you need to do, is enable verbose logging on the MSI, the command line it's something like this msiexec /x {xyz-code} /l*v c:\somelogpath.log, try it you may find something equally bizarre like a 1303 error inside the log files
Use PSEXEC and execute the command under system account.
I found some setups/installers do not like to be executed without GUI or other non-user account.
Another thing, in SCCM 2012 you have packages that just simple execute the program, with only exit code check.
And there are Applications that can have detection rules, which can be used to really verify if the program installed/executed correctly.
Also always check ITninja for tips.
Something like this you may need to make sure that outlook.exe is closed you may want to add a taskkill to your script and then try it:
taskkill /IM outlook.exe /T
msiexec /a "path to file" /qn
might work as a simple .cmd file
This is an old thread, but maybe this is helpful for people searching the web:
SCCM Applications usually run as SYSTEM, no need to "run as administrator" (you could configure that within the Deployment Type).
You cannot "break" out of SYSTEM context and do a "run as"
runas and system account.
Tried that once and finally did an ugly workaround by creating a scheduled task that runs under a specific user, then ran that task from my script, which is running as SYSTEM.
As already mentioned, test your scripts interactively using SYSTEM account:
psexec.exe \\localhost -s cmd
Check with whoami that you're running the cmd with SYSTEM.
Make sure you add the COMPUTER account of your test client to the share/folder ACL of your networked scripts folder, otherwise the system account does NOT have access rights.
If running the script as SYSTEM works but SCCM still reports an error, chances are high that the Detection Method failed, NOT the actual install!
Check the following logs here: C:\Windows\CCM\Logs
(See 4. below how to use the index service to speed up troubleshooting logs.)
AppDiscovery.log
AppEnforce.log
AppIntentEval.log
Open up the Windows Indexing Service Options. Configure *.log to index file contents as well. Then add the path C:\Windows\CCM\Logs to the index. Howto.
This way you could easily search for the application name and you will find all log files which deal with that application. You will also find the matching AppDT ID, so you could search for that ID and will find even more info about your package/application.
On your admin machine create a new log collection folder, add this folder to the index. This allows you to copy the whole log folder of a client to your admin folder. A few minutes later it's indexed and fully searchable on your local machine!
There's a tool available from Microsoft which could gather a full log package on a client: ConfigMgr Support Center
Do you have SCCM setup to run it as administrator in the program that you defined?
I'm trying to set up kernel debugging with VS 2013. When I go to Drivers/Add to add a new target machine, it connects to the remote computer and runs through a lot of setup, but it there are always 2 commands that fail.
I looked up the command that is failing in the log and I pasted it into a batch file and ran it on the target machine. I runs just fine. But then when I try to rerun Add Computer from VS, I get the same failure.
RemoteExecute: Binary: $KitRoot$\Testing\Runtimes\TAEF\te.exe
RemoteExecution: Arguments:
"%SystemDrive%\DriverTest\Run\DriverTestTasks.dll"
/select:"#Name='DriverTestTasks::_ConfigureKernelDebugger'"
/p:"DebugTransport=NET" /p:"NetHost=192.168.1.109" /p:"NetPort=50015"
/p:"NetKey=8XD3HYLMVI0D.RKFEA2BPIXO.27JOLNYURED5.MV9OGRF4XR9V"
/p:"StartPolicy=Active" /p:"IgnoreUserModeExceptions=0"
/p:"SuppressReboot=1"
/rebootStateFile:%SystemDrive%\DriverTest\Logs\DriverTestReboot.xml
/enableWttLogging
/wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Logs\Configure_debugger_settings_(x86)_(possible_reboot)_00007.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*"
/runas:Elevated RemoteExecute: Process creation return code: 0
RemoteExecute: Process exit code: 0 Initialize: Computer: w8x86wdk-hp
Result completed Test process exit code: -1
I have tried this both with a VMware VM target and against a physical PC target and I have tried adding the computer in the reverse direction and I always get the same failures. I can ping these machines from each other and all machines are Win8 x86. Network discovery and sharing are on. The Windows firewalls are off. These are virgin OS installations so there's nothing on the machines except the OS, VS2013, and WDK 8.1.
Any tips on how to resolve this?
Had same issue when used ws2012 for TARGET machine.
When installed WIN81 instead, turned off UAC and DID NOT install wdk on TARGET - everything started working. Read carefully how to PROVISION TARGET. (it says: dont' install WDK there:)
HOST and TARGET was in the same home workgroup with same passwords for Administrator and MyUserAcc.
also:
under HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System set EnableLUA=0
I am just testing it so I think you should first check your target computer security issue. Then set your port pipe connection and your network adapter setting in your virtual pc.
After that setting make your computer configuration then works perfectly.
I modified this script from the net, which is suppose to install .exe applications for remote machines:
$m = Read-Host "Enter machine name"
$File = "c:\temp\office2007sp2-kb958194-fullfile-en-us.exe"
$product = [WMICLASS]"\\$m\ROOT\CIMV2:win32_Process"
$product.Create($File)
When I run this script, I have noticed that this program promptly creates a process in the remote machine with the application name office2007sp2-kb958194-fullfile-en-us.exe.
This can be checked in the task manager also.
But other than that, there is no way to find out if this is getting installed in the remote machine or not.
Is there a way to find out, if the installation is really happening?
Or does this script actually works?
Not a proper answer because I haven't tried remote process launching like that, but I have used psexec to launch processes on other machines.
If you are still having problems with your script you may want to check out ps_exec, it lets you execute processes on other machines as if it was your own. You can check the exit code of the process just like you would if you were executing the process locally.
It's offered as a free tool by microsoft: http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx