I am using Windows 7 as well as windows 2008 r2, I am trying to write a powershell script to find all the software installed on all the machines on my network. I have done research and see the cmdlets I need to do this task but I get some many unrecognized cmdlts. I am new to powershell and the other admins only use GUI's and I am trying to show them how powerful the command line can be. Is there something I need to run to update my machine with the latest cmdlets?
$PSVersionTable.PSVersion
Major Minor Build Revision
----- ----- ----- --------
3 0 -1 -1
currently the command that is failing is Get-RemoteProgram
I am using 64-bit machines
Assuming that you are using thisGet-RemoteProgram, you need to "dot source" it before you can use the command. This tells your script to read the file and include the functions it contains in your script.
. .\Get-RemoteProgram.ps1
Load the function into memory by dot-sourcing the script file this makes the Get-RemoteProgram function available in your current session of PowerShell
So your script would need to include
. .\Get-RemoteProgram.ps1
prior to any call to Get-RemoteProgram
As far as the version of PowerShell, 3.0 is certinaly not the latest. You can always find the latest version at Microsoft. Currently, https://msdn.microsoft.com/powershell is a good place to reference, or even check Wikipedia--lots of places are kept updated with the latest info on PowerShell.
Related
I have been studying privilege escalation on windows and came across some powershell script that look up vulnderabilties.
When i run these ( multiple scripts) I get no output while the documentation i find on them and video's all show output. Unless I specifically tell it to output it to a file,
This makes me think it has something to do with my system. I am running windows 7 64-bit on a local standard user.
For example i used:
https://github.com/rasta-mouse/Sherlock
and:
https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerUp
Did you try to check if your current user has changed to Administrator ?Maybe there is a GPO or theses privileges esclations are not working for your version
I use Powershell 5.1 and we often install modules from our internal module repository hosted on our on-prem Azure Artifacts (we use Azure DevOps Server 2019).
The problem is that it is very slow. Takes regularly over 10 seconds to load one module. And this is not the network, which is pretty fast. It is the Install-Module internals.
I tried running Set-PSDebug -Trace 2 from within an Azure DevOps build in order to get line timestamps, but it is useless. For example, observe this output snippet:
2020-06-29T04:20:40.6944925Z DEBUG: 267+ switch ( >>>> $MsgID)
2020-06-29T04:20:40.6957451Z DEBUG: ! SET $switch = ''.
2020-06-29T04:20:40.6972578Z DEBUG: 290+ >>>> }
2020-06-29T04:20:40.6986528Z DEBUG: ! SET $switch = ''.
2020-06-29T04:20:40.6998323Z DEBUG: 232+ >>>> }
2020-06-29T04:20:48.3791151Z DEBUG: 220+ $script:PackageManagementInstallModuleMessageResolverScriptBlock = >>>> {
2020-06-29T04:20:48.3808676Z DEBUG: ! CALL function '<ScriptBlock>' (defined in file 'C:\Program
2020-06-29T04:20:48.3811147Z Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1')
2020-06-29T04:20:48.3822332Z DEBUG: 222+ >>>> $PackageTarget =
2020-06-29T04:20:48.3824673Z $LocalizedData.InstallModulewhatIfMessage
It show 8 seconds pause, but the place where it shows it does not make any sense.
So, my question is this - why is it so slow? Is there a way to profile it reliably?
EDIT 1
Have just installed PS Core 7 - the same lousy performance for Install-Module. My version of PowershellGet is:
C:\> Get-Module PowershellGet | Select Version
Version
-------
2.2.4
C:\>
EDIT 2
Found this page - https://learn.microsoft.com/en-us/powershell/scripting/gallery/how-to/working-with-packages/manual-download?view=powershell-7 It explicitly warns against simulating Install-Module with nuget, even though it explains how to do it. I would like to understand more about the implications of using nuget instead of Install-Module, besides it working 5 times faster (on average).
EDIT 3
The modules are not signed. We are talking about our internal modules. But installing modules from PSGallery, like Az.Accounts, Az.Storage and Az.Sql takes about the same time. When our build needs to make sure 5 modules are installed it takes easily a minute. On another note, Install-Module is not concurrency safe, so when our builds were running it bare we were facing all kinds of weird errors. They went away when we introduced explicit named mutex around Install-Module. Needless to say, it did not contribute to performance.
While this doesn't answer your "why", you might like to look at JustinGrote's high performance Powershell Gallery Module Installer:
.SYNOPSIS
High Performance Powershell Module Installation
.DESCRIPTION
This is a proof of concept for using the Powershell Gallery OData
API and HTTPClient to parallel install packages
It is also a demonstration of using async tasks in powershell
appropriately. Who says powershell can't be fast?
This drastically reduces the bandwidth/load against Powershell
Gallery by only requesting the required data
It also handles dependencies (via Nuget), checks for existing
packages, and caches already downloaded packages
.NOTES
THIS IS NOT FOR PRODUCTION, it should be considered "Fragile" and
has very little error handling and type safety
It also doesn't generate the PowershellGet XML files currently, so
PowershellGet will see them as "External" modules
It is indeed much faster.
I am trying to run a PowerShell script to uninstall owncloud-client from my Windows 10 virtual machine. The code shown below can be found at
https://chocolatey.org/packages/owncloud-client (tools\chocolateyUninstall.ps1)
I would like just to test the code by running it from PowerShell to see if it actually uninstalls the software.
$unfile = "ownCloud\uninstall.exe"
if (Test-Path "${Env:ProgramFiles(x86)}\$unfile") {
$unpath = "${Env:ProgramFiles(x86)}\$unfile"
} else {
$unpath = "${Env:ProgramFiles}\$unfile"
}
Uninstall-ChocolateyPackage 'owncloud-client' 'exe' '/S' "$unpath"
I run script from the directory that contains it by typying:
.\chocolateyUninstall.ps1
As output I get the following error:
Uninstall-ChocolateyPackage is not recognized as the name of cmdlet, function, script file, or operable program.
The Uninstall-ChocolateyPacakge.ps1 package is provided by chocolatey. I checked on my machine and this package is present under:
C:\ProgramData\chocolatey\helpers\functions\Uninstall-ChocolateyPackage.ps1
but still it is not recognized as cmdlet by powershell. How can I solve this problem? thanks
When running the installation/uninstallation scripts, Chocolatey first includes the Chocolatey PowerShell module. This is done in the background, and normally, the end user doesn't need to worry about it.
For what you are trying to do, you will need to first do an Import-Module on the Chocolatey module, to bring it into the current PowerShell session. You can find this here:
old: C:\ProgramData\chocolatey\lib\chocolatey\tools\chocolateyInstall\helpers\chocolateyInstaller.psm1
new: C:\ProgramData\chocolatey\helpers\chocolateyInstaller.psm1
That should allow you to test the script directly.
Alternatively, you could run the install of the package, and then run the uninstall to see if it works as well.
With the latest moderation tools, you don't need to check every package (I mean, unless it makes you feel safer). You can always check the automated tests. There's a status dot to the right of the package title.
You can find the test summary
owncloud-client v2.1.1.5837 - Passed - Package Test Results
https://chocolatey.org/packages/owncloud-client/2.1.1.5837
Tested 10 Feb 2016 12:51:22 +00:00
Tested against win2012r2x64 (Windows Server 2012 R2 x64)
Tested with the latest version of choco, possibly a beta version.
Tested with chocolatey-package-verifier service v0.4.0-15-g979d0cc
Install was successful.
Uninstall was successful.
https://gist.github.com/choco-bot/45f343e23cc12e101130#file-_summary-md
or explore the uninstall log directly.
https://gist.github.com/choco-bot/45f343e23cc12e101130#file-uninstall-txt
I have a PowerShell script named myscript.ps1 on a remote server.
I would like to know what is the version of this file.
Unfortunately this command gives me nothing :
(Get-Item "C:\myscript.ps1").VersionInfo.FileVersion
My question is : is there a way to add some information regarding the version of the script or else ? If yes, how please ?
My end goal is to check if the running script is the latest version otherwise download latest version on remote server and execute.
Thank you all.
I'm not sure you're going to find that information there unless it was set. I usually see that info in things like DLLs.
If it were me, and I was looking to see if a file was different (a script or otherwise) I would use the Get-FileHash commandlet instead.
You can not set FileVersionInfo in .Net, so you will always get a null value when you check the FileVersionInfo on your PowerShell script. What you may want to do instead is to check the LastWriteTime property to see if the file on the server is newer than what you have locally.
We are currently testing deployments using WINPE 5 x64 and are running into issues when we need to pull OU information from AD/specify the location for a newly provisioned machine.
In previous versions, WinPE allowed the use of the netdom command, which we built inside an executable that added the machine to the correct ou. Sample snippet below. (Correct location is output to a text file for the task sequence to read).
CString strPathToNetdom = (filebuf);
CString Command = ("\"") + strPathToNetdom + _T("\\netdom.exe\" query ou /Domain:contoso.com /ud:CONTOSO\\SCCMADM /pd: > X:\\Windows\\Temp\\ou_list.txt") + _T("\"");
Command = _T("\"") + Command;
CT2A ascii(Command);
I would just use powershell cmdlets, however WINPE5 out the box does not support the .net components to run powershell and the overhead of upwards of 90mb is something we aren't really too keen on.
Are there any alternatives that someone has come across?
Have you tried using dsadd?
dsadd computer /?
for syntax and usage help.