I am trying to do my first script. To simply get PowerShell to pull up a script typed up in notepad and saved as a .ps1 file titled "test" (have also tried Script, but know names have nothing to do with it):
Write-Host "Hello, World!"
In PowerShell I am typing
& "C:\Scripts\test.ps1"
As well as
./test.ps1
And am only met with this:
./test.ps1.txt : The term './test.ps1.txt' 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.
At line:1 char:1
+ ./test.ps1.txt
+ ~~~~~~~~~~~~~~
+ CategoryInfo: ObjectNotFound: (./test.ps1.txt:String) [], CommandNotFoundException
Have tried renaming the file within PowerShell with
PS C:\Scripts> Rename-Item test.ps1.txt test.ps1
I have switched between RemoteSigned and Unrestricted, I have tried a code including executionpolicy bypass (I do apologize, I closed my window without writing that one down). As far as I know everything is up to date and I am running Windows 10, Windows PowerShell, and regular Windows Notepad.
First, I'd HIGHLY recommend using the Windows PowerShell ISE for writing scripts. It's free, and provides a pretty decent console/editor experience, given that it's free (there are allegedly better ones out there, but this has always done just fine for me). I use Visual Studio for other stuff, and while it is an EXPONENTIALLY better product (and should be), the PowerShell ISE is pretty feature-rich.
Next, if you're just getting started, you should check out Don Jone's "Learn PowerShell 3.0 in a Month of Lunches" book. It's two versions behind the most current, however, all of the information is still relevant, and once you've finished the book, you'll be able to seek help for anything else pretty easily on your own. It covers all the basics, and is a very good first step to learning the language.
Now, to answer your question: PowerShell scripts commonly have the .ps1 file extension. Other extensions are generally used for modules (.psm1) or other helper content that Windows PowerShell leverages. For most things, you'll stick to .ps1, and when you've reached a point where you start needing the other extensions, I suspect you will have no problems identifying which ones you need.
There are two ways generally call a PowerShell script. The first is from a normal command prompt, and telling PowerShell to execute your script. This is shown below:
powershell.exe -File MyScript.ps1
There are some additional parameters that I'd recommend you use, but usage is dependent on your requirements. Here's what I usually tag on mine:
powershell.exe -NoProfile -ExecutionPolicy RemoteSigned -File MyScript.ps1
This will tell the PowerShell process to ignore any PowerShell profiles you have set up, which is ideal if you have a bunch of stuff in your profile script that does things like read console input (for your current situation, I'm going to assume you don't, but you may in the future). The other is that ExecutionPolicy one: RemoteSigned will tell PowerShell to basically ignore anything that's been downloaded from the interwebs, but allow anything originating inside your network to run free. Probably not the best practice, but this isn't a TERRIBLE policy if you can trust that your script repository is secured. If not, then go for something tighter than this (you can read up on execution policies by typing "Get-Help about_Execution_Policies" in the PowerShell prompt, or by visiting the TechNet page about them -- the content should be similar if not identical).
The second way is from inside of a Windows PowerShell script. It's actually much easier to do. Note that you must set your execution policy to something that will allow scripts to run, but thereafter, you're smooth sailing.
. .\MyScript.ps1
This is called "dot-sourcing" your script. The advantage of doing this from within Windows PowerShell is that if you've got something like a script full of functions, they get added to the current scope (Get-Help about_Scopes), which means they're now available in your current session. A good example would be defining a function called "Test-DomainConnection" in a script you distribute with your main script: You'd dot-source the script that is distributed with the main one (this is done usually when you separate your "standard" PowerShell functions from your main script), and then use the functions in the main script. There are pros and cons to this approach, but it seems to be generally recommended (there may be some community extensions out there that remove the need to manage this manually).
For additional information, you can call Get-Help about_Scripts from inside Windows PowerShell. Because you're using Windows 10, you may need to run Update-Help from an administrative PowerShell window before the help content is available on your local system.
If you have any more questions, feel free to message me :) I've been doing PowerShell for a while and may be able to help out.
Powershell processes in order (top-down) so the function definition needs to be before the function call:
Am a new bie to Powershell and knew less comlets.
As per my requirement, I need to disable the bit locker protection no a drive.
I have a script to get the status of bit locker protection is On or Off.
$x = Get-WMIObject -Namespace "root/CIMV2/Security/MicrosoftVolumeEncryption" -query "SELECT * FROM Win32_EncryptableVolume WHERE DriveLetter='C:'";
$y = $x.GetProtectionStatus().ProtectionStatus
$y
Which displays the protection status as 0 or 1.
Please help me with script to disable the protection for bit locker drive.
Use the disable-bitlocker command:
PS C:> Disable-BitLocker -MountPoint "D:"
Or whatever drive you need to disable. Why do you need to do this in the first place? There is a difference between disable and recover.
There are as Charles pointed out proper cmdlets for this these days, instead of using the old-school WMI objects.
Get a list of all available commandlets for bitlocker
Get-Command *Bitlocker*
To disable on one of the drives, use the cmdlet:
Disable-Bitlocker
If you're stuck with an older version of Powershell/Windows, you can go for the approach of writing the value to the WMI object.
I want to hunt for the Indicators of Compromise (IoC) in a potentially infected Windows PC.
I am writing a batch script that would record the information needed for analysis. It includes the following CMD commands:
time /T
date /T
whoami
systeminfo
net user
dir /a "C:\Users\"
net localgroup administrators
net group administrators
net start
schtasks
tasklist
tasklist -svc
tasklist -v
wmic process list full
wmic product get name
What else should I be looking for?
The script would be written in a way to create a new file for each
command separated by directories such as 'Network Artifacts',
'Processes & Services', 'Machine Info' etc. What can I do to improve
the script?
Do you suggest taking registry & memory dumps at this stage?
I would also take a look at your services:
wmic service list brief
wmic service list full
reg keys:
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
There are many other things you can search for as well (windows event logs with certain id, recently added items to the c:\windows and c:\windows\system32 folders.. maybe even a hash comparison of those directories to a known good state). If you expand this into a PowerShell script, then you can get a lot more out of it I believe.
You can take memory captures at any time. I recommend doing those as early as possible so that you do not leave too big of a footprint on the machine.
I would take a memory image before doing anything else, and if possible try to grab the pagefile. You will need to be running the commands from an administrator command shell in order to be able to copy the pagefile.
Lytledw's answer is good as long as you remember to grab the memory image as early in the process as possible, in order to minimize your impact on what's running.
I'm new to puppet and ruby, and just tried to write custom fact but ... Having the following issue
Facter.add("vsphere_installed") do
confine :operatingsystem => :windows
setcode do
if Facter::Util::Resolution.exec('c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe -NonInteractive -NoProfile -ExecutionPolicy Bypass -Command "Get-WmiObject -Class Win32_Product | Select-Object -DisplayName | ? {$_.DisplayName -Match "vsphere"}"') = true
result = "vSphere installed"
else
result = "false"
end
end
end
I don't know how exactly to do this, I want to list installed programs and search for one and if true(find) to return that it's installed.
This example so far returns only false ....
Puppet is about Desired State - not Procedural
It feels like you are treating Puppet as procedural at the moment and Puppet is more about the desired state. You determine what is installed, you shouldn't necessarily ask.
So on certain server roles you would say the end state is that you need vSphere and also other software.
You get to make those decisions, you shouldn't use Puppet to discover the state, but to tell it the state and let it do what it does best.
Discovery is something you can do out of band with the tool exploring a machine, try puppet resource package and you will see what I mean.
Custom Facts
But to answer your question, you should probably use a custom executable fact and just use PowerShell directly, because the command string still needs to be escaped in the double quotes (and may also need to be escaped in the way that you used apostrophe then double quotes) - the docs also point to using Facter::Core::Execution.exec and not Facter::Util::Resolution.exec.
Use Custom Executable Facts instead.
Also don't use Win32_Product - Win32_Product class can trigger Windows Installer to do a repair on all MSI installed software as a consistency check. It can really cause a machine to do a lot of unnecessary work - its just not a good idea to use it. I'd suggest querying the uninstaller registry keys directly instead.
Trying to use WMI to obtain a list of installed programs for Windows XP. Using wmic, I tried:
wmic /output:c:\ProgramList.txt product get name,version
and I get a listing of many of the installed programs, but after scrubbing this list against what "Add/Remove Programs" displays, I see many more programs listed in the GUI of Add/Remove Programs than with the WMI query. Is there another WMI query I need to use to get the rest of the programs installed? Or is there some other place I need to look for the rest?
Also, there are two installed programs that are listed in the WMI query that aren't in Add/Remove programs. Any idea why?
I believe your syntax is using the Win32_Product Class in WMI. One cause is that this class only displays products installed using Windows Installer (See Here). The Uninstall Registry Key is your best bet.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall
UPDATE FOR COMMENTS:
The Uninstall Registry Key is the standard place to list what is installed and what isn't installed. It is the location that the Add/Remove Programs list will use to populate the list of applications. I'm sure that there are applications that don't list themselves in this location. In that case you'd have to resort to another cruder method such as searching the Program Files directory or looking in the Start Menu Programs List. Both of those ways are definitely not ideal.
In my opinion, looking at the registry key is the best method.
All that Add/Remove Programs is really doing is reading this Registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
Besides the most commonly known registry key for installed programs:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall
wmic command and the add/remove programs also query another registry key:
HKEY_CLASSES_ROOT\Installer\Products
Software name shown in the list is read from the Value of a Data entry within this key called: ProductName
Removing the registry key for a certain product from both of the above locations will keep it from showing in the add/remove programs list. This is not a method to uninstall programs, it will just remove the entry from what's known to windows as installed software.
Since, by using this method you would lose the chance of using the Remove button from the add/remove list to cleanly remove the software from your system; it's recommended to export registry keys to a file before you delete them. In future, if you decided to bring that item back to the list, you would simply run the registry file you stored.
I have been using Inno Setup for an installer. I'm using 64-bit Windows 7 only. I'm finding that registry entries are being written to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
I haven't yet figured out how to get this list to be reported by WMI (although the program is listed as installed in Programs and Features). If I figure it out, I'll try to remember to report back here.
UPDATE:
Entries for 32-bit programs installed on a 64-bit machine go in that registry location. There's more written here:
http://mdb-blog.blogspot.com/2010/09/c-check-if-programapplication-is.html
See my comment that describes 32-bit vs 64-bit behavior in that same post here:
http://mdb-blog.blogspot.com/2010/09/c-check-if-programapplication-is.html?showComment=1300402090679#c861009270784046894
Unfortunately, there doesn't seem to be a way to get WMI to list all programs from the add/remove programs list (aka Programs and Features in Windows 7, not sure about Vista). My current code has dropped WMI in favor of using the registry. The code itself to interrogate the registry is even easier than using WMI. Sample code is in the above link.
Not the best, but whether it is practical method:
Use HijackThis. (Old version: HijackThis)
Run hijack this, click the "Open the Misc Tools section" button
click "Open Uninstall Manager"
click save list (*.txt), yes to the prompts, notepad will open with your add/remove programs list.
Source
You can get it in one line with powershell and batch file :
#echo off
Powershell /command "Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, DisplayVersion, Publisher, InstallDate | Format-List"
Pause
Installed products consist of installed software elements and features so it's worth checking wmic alias's for PRODUCT as well as checking SOFTWAREELEMENT and SOFTWAREFEATURE:
wmic product get name,version
wmic softwareelement get name,version
wmic softwarefeature get name,version
You can use the script from http://technet.microsoft.com/en-us/library/ee692772.aspx#EBAA to access the registry and list applications using WMI.
Hope this helps somebody: I've been using the registry-based enumeration in my scripts (as suggested by some of the answers above), but have found that it does not properly enumerate 64-bit software when run on Windows 10 x64 via SCCM (which uses a 32-bit client). Found something like this to be the most straightforward solution in my particular case:
Function Get-Programs($Bits) {
$Result = #()
$Output = (reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall /reg:$Bits /s)
Foreach ($Line in $Output) {
If ($Line -match '^\s+DisplayName\s+REG_SZ\s+(.+?)$') {
$Result += New-Object PSObject -Property #{
DisplayName = $matches[1];
Bits = "$($Bits)-bit";
}
}
}
$Result
}
$Software = Get-Programs 32
$Software += Get-Programs 64
Realize this is a little too Perl-ish in a bad way, but all other alternatives I've seen involved insanity with wrapper scripts and similar clever-clever solutions, and this seems a little more human.
P.S. Trying really hard to refrain from dumping a ton of salt on Microsoft here for making an absolutely trivial thing next to impossible. I.e., enumerating all MS Office versions in use on a network is a task to make a grown man weep.
With time having moved on quite a bit since this question was asked...
There's a WMI class available these days for the Uninstall entries in the registry. This is much quicker to reference than Win32_Product, which I think also runs verification on the list and can take a while to enumerate. The below Powershell code (possibly requires Powershell 3 or later) will list all entries (The Out-Gridview part is just for a pretty display).
Get-CimInstance Win32Reg_AddRemovePrograms | Out-gridview
Add/Remove Programs also has to look into this registry key to find installations for the current user:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall
Applications like Google Chrome, Dropbox, or shortcuts installed through JavaWS (web start) JNLPs can be found only here.
In order to build a more-or-less reliable list of applications that appear in the "Programs and Feautres" in the Control Panel, you have to consider that not all applications were installed using MSI. WMI only provides the ones installed with MSI.
Here is a short summary of what I've found out:
MSI applications always have a Product Code (GUID) subkey under HKLM\...\Uninstall and/or under HKLM\...\Installer\UserData\S-1-5-18\Products. In addition, they may have a key that looks like HKLM\...\Uninstall\NotAGuid.
Non-MSI applications do not have a product code, and therefore have keys like HKLM\...\Uninstall\NotAGuid or HKCU\...\Uninstall\NotAGuid.
I adapted the MS-Technet VBScript for my needs. It dumps Wow6432Node as well as standard entries into "programms.txt"
Use it at your own risk, no warranty!
Save as dump.vbs
From command line type: wscript dump.vbs
Const HKLM = &H80000002
Set objReg = GetObject("winmgmts://" & "." & "/root/default:StdRegProv")
Set objFSO = CreateObject("Scripting.FileSystemObject")
outFile="programms.txt"
Set objFile = objFSO.CreateTextFile(outFile,True)
writeList "SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\", objReg, objFile
writeList "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\", objReg, objFile
objFile.Close
Function writeList(strBaseKey, objReg, objFile)
objReg.EnumKey HKLM, strBaseKey, arrSubKeys
For Each strSubKey In arrSubKeys
intRet = objReg.GetStringValue(HKLM, strBaseKey & strSubKey, "DisplayName", strValue)
If intRet <> 0 Then
intRet = objReg.GetStringValue(HKLM, strBaseKey & strSubKey, "QuietDisplayName", strValue)
End If
objReg.GetStringValue HKLM, strBaseKey & strSubKey, "DisplayVersion", version
objReg.GetStringValue HKLM, strBaseKey & strSubKey, "InstallDate", insDate
If (strValue <> "") and (intRet = 0) Then
objFile.Write strValue & "," & version & "," & insDate & vbCrLf
End If
Next
End Function
I had the same issue with the WMIC command only showing a subset of all installed programs. I needed a command that would output a CSV file of all the installed programs in Windows 10 and I wanted to make it easy for colleagues to run. The following Powershell command seems to work well, running much quicker than the WMIC command; it will generate a CSV in the user's Documents folder called AppsInstalled.csv with programs sorted by name, and with empty lines removed (numerous blank lines were returned in my tests for some reason?).
Get-ItemProperty HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Select-Object DisplayName, DisplayVersion, Publisher, InstallDate| Where-Object DisplayName -ne $null | Sort-Object -Property DisplayName | Export-Csv "$($env:USERPROFILE)\Documents\AppsInstalled.csv" -NoTypeInformation