1.Can this be used for multiple server say with a.txt file? I also received the error:. Psexec.exe: Connecting to SERVER.com. At C: path to PSEx ec Install-Patc hes.psm1:163 char:17 +. Psexec.exe -accepteula -s -i $computer cscript.exe C. + + CategoryInfo: NotSpecified: (Connecting to SERVER.com.:S tring) , RemoteException + FullyQualifiedE rrorId: NativeCommandEr ror Starting PSEXESVC service on SERVER.com.Co nnecting with PsExec service on SERVER.com.St arting cscript.exe on SERVER.com. Cscript.exe exited on SERVER.com with error code 0.
Is there a way to resolve this error? I get this message when I run your (excellent) module:. Psexec.exe: At C: Users. Documents Windo wsPowerShell Mo dules Install-P atches Install- Patches.psm1:16 3 char:17 +.
Psexec.exe -accepteula -s -i $computer cscript.exe C: update. + + CategoryInfo: NotSpecified: (:String) , RemoteException + FullyQualifiedE rrorId: NativeCommandEr ror Two questions: 1. What can I do to resolve this error? If I want to run this silently on the remote system, do I have to remove the '-i' parameter from psexec.exe?
In my current environment, I am one of many people in our shop that carry the same task as many of you. That task is to patch our systems to ensure we keep ourselves up to date on the latest security updates. This can be done many different ways from manually downloading and installing patches, setting deadlines in WSUS to complete the installations, managing the installations via Group Policy to name a few of the possible scenarios.
Another way that I will show you combines a melting pot of technologies using PowerShell, VBScript and PSExec.exe to completely automate this task. If you have seen my other function, and its associated blog posting, then I would consider this the partner module to that. Ok, you might be asking me: “Boe, why would we use this old legacy scripting language when we have the awesomeness that is PowerShell?” Good question! The answer to that is that while we do have PowerShell which makes our jobs and life soooo much easier, most of us simply do not have it installed on every system, or some systems older and cannot have PowerShell installed on them. Hence, we have VBscript which bridges that gap and gives us a scripting language that works on legacy systems all the way up to our Win2K8R2 systems.
The trick to this is that instead of having a vbscript file to copy each time, I simply use a here-string to contain the code and then use Out-File to write the vbscript to the remote machine. This also makes this code more portable as you only have one file to deal with as opposed to multiple files. The Module I decided to go with a module so I can only export the one function I need while leaving the other functions that do the background work hidden. With that in mind, when you copy the code you must save it with a.psm1 extension and use the Import-Module cmdlet. I wrote the module so that you can supply a collection of computers if needed and it will do all of the processing of each system itself. You will need to download PSExec from and place it in the same directory from where ever you are calling the function from.
The Install-Patches function is the only visible function that you have available to run, but there are a total of 3 functions that are available within the module (Install-Patches,Create-UpdateVBS and Format-InstallPatchLog). It will then call the Create-UpdateVBS function to use the hardcoded Here-String of the vbs code and use the Out-File cmdlet to create the required Update.vbs file on each system. I cannot take credit for most of this vbscript as it was created by Microsoft and is available to view from their site. I say most because I did make some adjustments to make it more PowerShell friendly such as writing out the log file to a CSV instead of a text file. I also made some adjustments such as accepting a EULA if needed for an update prior to installing.
I also took out the downloading of updates as well since they will have already been downloaded to the machine from WSUS (or downloaded if set up to do so on your computer to do so automatically). After the file has been created successfully, the Install-Patches function continues on and uses PSExec to remotely (or not remotely if running against your local machine) install the patches. I chose this route as I have not found a feasible way to remotely install patches. Using a WMI method with the Win32Process and Create method does not work and neither does PowerShell remoting. This is a “by design” feature of the COM object and does not look to be changed any time soon.
PSexec is my best approach at working around this obstacle. After the Update.vbs script a CSV file is created either showing what patches were installed or showing that no patches were installed for one reason or another. After PSExec runs, I then check the value of $LASTEXITCODE, which tells you the return code of the application that ran with a 0 being successful. $LASTEXITCODE is described as: Contains the exit code of the last win32 executable execution If no issues are encountered with PSExec, then the next function that is called is Format-InstallPatchLog which takes the created CSV file and makes a couple of adjustments to the log file before presenting it as the output object.
Module in Action Ok, enough talk about the module itself and now onto the actual module in action. The first thing I do is import my module into the PowerShell console using the following line of code. Import-Module Install-Patches.psm1 -Force I use the –Force switch because I already had the module imported and wanted to “overwrite” the existing function. I say “overwrite” because if you run the command while with –Verbose, you will see that it actually removes the existing function before adding the new function. The next step is to make sure that you are in the same directory as PSExec.exe to be sure that the function will properly, otherwise it will throw a message and halt the function. Ok, lets actually run the function against a remote system and see what happens. Install-Patches -Computername DC1 As you can see, the PSExec operation took place against DC1 as expected and the reporting object was also returned which is good.
Looking at this, we can see that the InstallResultCode is reporting that a reboot is required to complete the patch installation. This is by design that the installation does not automatically reboot the system. It is important to keep in mind that if there are more patches, then it will take longer to run through the installation of each patch. This function does accept a collection of systems and also accepts those from the pipeline as well which allows you some flexibility in how you would like to run the command. There may be instances when a result code is not displayed or says “Unable to determine Result Code”.
This means that the result code returned from the script could not be decoded by the function. That is not to say that the code can never be figured out, it is that I chose to not include the hundreds of possible codes in the script. If you would like a listing of all of the codes to search from, you can find that. With that, you can see how this might prove useful to you based on your environment. You could pipe the results into a CSV file if you wanted something to email folks with. This also makes it easy to determine if any patches failed or which systems would need to be rebooted after the installations. You can even use as an extra measure to make sure no other patches have snuck in and need to be installed.
Code As always, the code is available to copy from either here or from the following locations. Blogroll. Email Subscription Enter your email address to subscribe to this blog and receive notifications of new posts by email.
Join 417 other followers. @ I don’t know much about it but can take a look. Where did you get it from?. @ Using this as my iPhone wallpaper. New Team blog! DSC Resource Kit Release February 2018.
RT @: Live Views of Starman. @ Weird.
Never seen a space come out like that. It seems like it might not be a space but some kind of.
Blog Stats. 2,832,324 Visitors Since August 5, 2010. Meta.
Glp ypoc 250 pro manual. No it cannot be. The script calls on the comobject Microsoft.Updat e.Session which would make a connection to the configured WSUS server (SUP).
Some thing that I've seen in a few environments in NZ with updates not downloading, installing or evaluating; Publishing the WSUS server address via group policy could interfere with the Local WSUS Policy set by the SCCM client (ccmexec service). The WSUS or SUP server address is a local policy element and not a group policy element. So if you've got a group policy enforcing a WSUS server source(s) remove it. Thanks very much for replying.
Not trying to be a bother but, where do I set the directory where the updates are being store. I'm user sccm 2012 r2. I'ver created automatic download and distribute to DP's. So I need to have the script pull the updates from the designated dp share directory.
Can you provide info on how to set your script up to do this? Sorry, in the process of learning powershell.
If you're wondering why - we are using cisco waas that only use smb. We transfer our update directory to the cisco waas for sccm clients to pull the updates. Unfortunately sccm only uses bits for microsoft updates. Using your scipt will force the cisco waas to look at the updates as a package and allow smb. Hope that make sense. Once again your help is greatly appreciated.
Install Microsoft Patches
Okay tried to script something for you today. But its proving to be more complex that what I had initially anticipated.
Without a catalog it is dangerous to install a list of updates from a share. If this is the only way; drop the following BAT or CMD file into the folder wherein you've got all the updates. Package that folder and run the BAT file as the SCCM program.
Install Windows Patches
Now advertise to run the package from the Distribution point. Be mindful of the fact that this can be done only when the client is connected within a fast (LAN) network boundary. Randomly installing updates from a share without using a catalog could prove detrimental to any environment. REM START of BAT or CMD file for%%f in (.msu) do (Wusa%%dp0f /quiet /norestart) REM END of BAT or CMD file. Yes, you can run this from SCCM as a normal software package. But, you HAVE to define a update source either via group policy or a directly in registry. This script will NOT install a list of updates from a share (it relies on an updates source being set).
How To Install Oracle Patches
But, I guess you could copy all the required updates from your share locally and then use a script to install them one by one using the below command. Something like this. REM START of BAT or CMD file @echo off%dp0 1.msu /quiet /norestart%dp0 2.msu /quiet /norestart%dp0 3.msu /quiet /norestart%dp0 4.msu /quiet /norestart%dp0 5.msu /quiet /norestart%dp0 6.msu /quiet /norestart%dp0 7.msu /quiet /norestart%dp0 8.msu /quiet /norestart%dp0 9.msu /quiet /norestart REM END of BAT or CMD file.