I am using PowerShell 6.2 preview at the moment. In my script I am trying to do stuff with Windows 10 apps. To be able to use commands like Get-AppxPackage, I need to import Windows modules from previous PowerShell like so:
Import-Module C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Appx\Appx.psd1 -SkipEditionCheck
Import-Module C:\Windows\system32\WindowsPowerShell\v1.0\Modules\dism\dism.psd1 -SkipEditionCheck
Does PowerShell core has its own modules to work with this? I found Get-Package for example, but that does not give me anything.
Since this is one of the top search results for PowerShell Core Get-AppxPackage, I'm going to take the information from the link provided in the comments and provide an answer, with example.
As LangsGalgEnRad pointed out in the comments, it's easiest just to do this from Windows PowerShell, but ultimately that's just-shy-of-deprecated at this point, with Microsoft stating that there are to be no more fixes or changes other than critical security issues. That said, it's still (afaik) universally available in Windows installations.
But for those of us who want to follow Microsoft's advice to use PowerShell Core, LangsGalgEnRad also points out in the comments the WindowsCompatibility module from Microsoft. Reading the blog post, this seems a bit safer than importing a Windows module (e.g. AppX) from PowerShell Core, since among other things ...
WindowsCompatibility is very careful to not overwrite native PowerShell core commands.
To install from PowerShell Gallery:
Install-Module WindowsCompatibility
Example usage for AppX:
Import-Module WindowsCompatibility
Import-WinModule AppX
Get-AppxPackage
Related
I'm quite confused at the differences here and would appreciate some clarification.
What I think is that in PowerShell 1.0, there were Modules (commands written in PowerShell) and Snap-Ins (a dynamic link library that implements cmdlets and providers). However, the lines became blurred as Modules can contain DLLs that the Cmdlets and Functions in the module can call, so eventually Snap-Ins are now effectively redundant.
Then came NuGet packages, which seems to be some kind of package deployment system (build by Microsoft??). This is not PowerShell specific in the way that the PowerShell Gallery is, and NuGet packages can deploy any kind of functionality to a Windows system. Is it correct to think of NuGet as the successor of MSI as a package deployment method?
So, we have PowerShell Gallery (only for PowerShell modules) and NuGet (for anything, but also contains PowerShell packages). What is a Package and how is it defined differently from a Module in the context of PowerShell?
Then, I notice that PowerShell have *-Package and *-Module Cmdlets, so you can run:
find-module *7zip*
find-package *7zip*
The same four items are returned here, but where are these Cmdlets pointing? If you run install-module is the Module installed from the PowerShell Gallery, and if you run install-package is an equivalent package (that is not a Module, but a package, whatever that is!) installed from NuGet?
Any clarification on the above would be greatly appreciated as I'm finding it hard to find clear definitions of what all of these things are and how they interact with each other (and indeed, what is the best way for me to approach installing them and upkeep)?
I just started writing scripts in PowerShell.
The desired script is supposed to create a local GroupPolicyObject (GPO) which will be specified afterwards. Research showed that it could be done with the New-GPO command within the GroupPolicy module for PowerShell. I tried to install the mentioned module but unfortunately nothing I found worked. May I ask for help?
I am using Windows 7 and Powershell 5.1.14409.1005
Error I receive when running example from Microsoft page (New-GPO -Name TestGPO -Comment "This is a test GPO."):
It is actually extremely simple, but the organization of the modules and features has changed many times in the past ten years, Microsoft Docs don't document the up-to-date way anywhere and all articles found online are very old.
Anyway, to install the Powershell Module called GroupPolicy, you need to install the Windows Feature called GPMC (Group Policy Management Console) which includes the mentioned module.
Install-WindowsFeature GPMC
This feature was once a subfeature of the RSAT feature, which is the cause of confusion.
Step 1. Install RSAT from Microsoft site:
https://www.microsoft.com/en-in/download/details.aspx?id=7887
Step 2. Enable Group Policy from Windows Features.
Following link describes the steps in details:
https://www.powershellmagazine.com/2012/05/14/managing-group-policy-with-powershell
Have you installed the RSAT (Remote Server Administration Tools) Group Policy component?
We have a PowerShell snapin that requires version 3.0 of PowerShell to function. So we used the following file element in a WiX (3.8) file:
<File Id="MySnapin.dll"
Name="MySnapin.dll"
Assembly=".net"
KeyPath="yes"
Vital="no"
Checksum="yes"
DiskId="1"
Source="$(var.FilesPath)\Bin\MySnapin.dll"
AssemblyApplication="MySnapin.dll">
<ps:SnapIn Id="MySnapin"
Description="This is a PowerShell snap-in"
Vendor="My Company Inc."
RequiredPowerShellVersion="3.0">
<ps:FormatsFile FileId="MySnapin.format.ps1xml" />
</ps:SnapIn>
</File>
However, when installing this the snapin cannot be found in powershell (Get-PSSnapIn -Registered). When examining the registry it turns out that the snapin has been registered in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\PowerShell\3\PowerShellSnapIns\MySnapin. But when running installutil.exe on the DLL, the registration ends up in HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\PowerShellSnapIns\MySnapin, and powershell finds it properly. Is this a bug in WiX Toolset, or am I doing something wrong here?
Where are the registrations really supposed to go?
Yea this sounds like a bug, so you might want to report it to the WiX maintainers, but there is better way.
The recommended way to add cmdlets and functions is through PowerShell Modules. Snap-ins are the older way to extend PowerShell and while still supported are not recommended. If you do not need to support adding your cmdlets to older versions of PowerShell use a module.
Modules are somewhat easier to deploy than snap-ins. Basically you can put them anywhere, however if you want users to be able to load them by name they need to exist on the PSModulePath environment variable. Your installer would add your files and update the PSModulePath variable to include a Modules folder from your install folder. Then users will simply be able to call Import-Module MyModule to load them. Also, see the documentation on PSModulePath.
This blog post contains a detailed walkthrough of how to write a WiX installer to do this. It also has instructions on how to check that the required PowerShell version is installed. Basically, you are going to check the under both those registry keys you mentioned for the PowerShellEngine\PowerShellVersion value.
Hi I'm wondering if it's possible to create application installers for MSI's. What I want it to do is when I run an MSI I want to be able to run it in it's own process so I can reference it via it's process ID so I can send various keys to it so it installs the way I want it too.
I can code in both C and Java but for the Sys Admins would be good if I could code it in Powershell for them. Also I've seen other installers that can detect when the next instance of the install screen appears so it immediately send the new command keys, well appears that way.
Any advice is welcomed.
MSI's traditionally allow for admins to provide an answer file or arguments using msiexec.
See this q/a on SuperUser or this SO Q/A for more info.
You can then use PowerShell to call the exe's by using the 3rd party Windows Installer PowerShell Module
.
[The Windows Installer PowerShell Module] Exposes Windows Installer functionality to PowerShell, providing means to query installed product and patch information and to query views on packages.
for example:
install-msiproduct .\example.msi -destination (join-path $env:ProgramFiles Example)
See this page for additional examples.
If you need to send keystrokes to the msi gui; you could look in to the Windows Automation Snapin for PowerShell. I have never used this personally.
I've heard powershell 2.0 CTP has modules, but I can't find much example code or instructions. I've read what little help there seems to be online...
But I just keep getting "The term 'Add-Module' is not recognized as a cmdlet..." when I try and load a module.
Any help would be gratefully received!
Edit (July 2010)
Please note this question is based on powershell 2.0 CTP and is therefore a year and half out of date! Please see Samuel Jack's answer for help with the powershell 2.0 RTM.
With the Win7 build, Add-Module is gone. The new cmdlet is Import-Module. The easiest way to create a module is rename a PS1 file to a PSM1 file. From there you can do all sorts of things including the module manifest.
I'm no Powershell expert, but here's what I just figured out using PowerShell 2.0 RTM.
Suppose you want to create a module called MyModule:
Make sure that you have created the folder %My Documents%\WindowsPowershell\Modules
Create a folder inside Modules called MyModule
Put your code in a file inside MyModule and name the file MyModule.psm1
Remember to use the Export-ModuleMember command as the last thing in your script file. Export-ModuleMember -Function * -Alias * will export all functions and aliases
In scripts where you want to use the module, use the command Import-Module MyModule
By default Powershell is configured not to run any kinds of scripts from files, so you need to alter the security settings. Set-ExecutionPolicy Unrestricted will get you going if you're not concerned about scripts needing to be signed.
Here's a little bit of information.
http://huddledmasses.org/powershell-modules/
http://blogs.msdn.com/mediaandmicrocode/archive/2008/08/10/microcode-all-about-modules-windows-powershell-ctp2.aspx
Let's hope that the upcoming CTP3 has some useful documentation about modules.
Modules will hopefully solve a few problems. Right now, we can use dot sourcing to get functions, variables, and scripts into a PowerShell session's global scope.
The problem is that this can pollute your session with all kinds of global variables and helper functions that an end user may not want/need directly.
Modules will allow you as an author to build scripts and only make certain functions/variables avaiable to the end user of the module.
They also essentially replace the concept of a PSSnapin. You can use Add-Module Some.dll to add an assembly that has cmdlets in it.
What is really cool is what is called a Module Manifest. This is a hash table that basically specifies all kinds of dependcies as well as author, name, GUID Identifier, and version number. When a user loads a module that has a module manifest, it will check all the dependencies and run any scripts the module author deems necessary.
There should be some decent documentation on these when CTP3 ships.
Hope that helps a bit.
Andy
Windows PowerShell v2.0: TFM (sapienpress.com) has information and samples in one of the chapters. It's available as an ebook which is updated as new CTPs are released. I also blogged about them on ConcentratedTech.com, and there's been discussion on them at PowerShellCommunity.org in the forums.