Win eXpose I/O v2.0 & Win eXpose Registry v1.0 First

Screenshot of a Windows PowerShell session
Paradigm	Imperative, pipeline, object-oriented, functional and reflective
Designed by	Jeffrey Snover, Bruce Payette, James Truher (et al.)
Developer	Microsoft
First appeared	November 14, 2006; 13 years ago (2006-11-14)
Stable release	7.0.3 / July 16, 2020; 2 months ago (2020-07-16)[1]
Preview release	v7.1.0-preview.5 / July 6, 2020; 2 months ago (2020-07-06)[2]
Typing discipline	Strong, safe, implicit and dynamic
Implementation language	C#
Platform	.NET Framework, .NET Core
OS	Windows 7 and later Windows Server 2008 R2 and later macOS 10.12 and later Ubuntu 14.04, 16.04, 17.04, and 18.04 Debian 8.7+, 9, and 10 CentOS 7 and 8 Red Hat Enterprise Linux 7 openSUSE 42.2, 42.3, 15.0, 15.1, 15.2 Fedora 28, 29, 30
License	MIT License[3] (but the Windows component remains proprietary)
Filename extensions	.ps1 (Script) .ps1xml (XML Document) .psc1 (Console File) .psd1 (Data File) .psm1 (Script Module) .pssc (Session Configuration File) .psrc (Role Capability File) .cdxml (Cmdlet Definition XML Document)
Website	microsoft.com/powershell
Influenced by
Python, Ksh, Perl, C#, CL, DCL, SQL, Tcl, Tk,[4]Chef, Puppet

PowerShell is a task automation and configuration management framework from Microsoft, consisting of a command-lineshell and the associated scripting language. Initially a Windows component only, known as Windows PowerShell, it was made open-source and cross-platform on 18 August 2016 with the introduction of PowerShell Core.^[5] The former is built on the .NET Framework, the latter on .NET Core.

In PowerShell, administrative tasks are generally performed by cmdlets (pronounced command-lets), which are specialized .NET classes implementing a particular operation. These work by accessing data in different data stores, like the file system or registry, which are made available to PowerShell via providers. Third-party developers can add cmdlets and providers to PowerShell.^[6][7] Cmdlets may be used by scripts and scripts may be packaged into modules.

PowerShell provides full access to COM and WMI, enabling administrators to perform administrative tasks on both local and remote Windows systems as well as WS-Management and CIM enabling management of remote Linux systems and network devices. PowerShell also provides a hosting API with which the PowerShell runtime can be embedded inside other applications. These applications can then use PowerShell functionality to implement certain operations, including those exposed via the graphical interface. This capability has been used by Microsoft Exchange Server 2007 to expose its management functionality as PowerShell cmdlets and providers and implement the graphical management tools as PowerShell hosts which invoke the necessary cmdlets.^[6][8] Other Microsoft applications including Microsoft SQL Server 2008 also expose their management interface via PowerShell cmdlets.^[9]

PowerShell includes its own extensive, console-based help (similar to man pages in Unix shells) accessible via the cmdlet. Updated local help contents can be retrieved from the Internet via the cmdlet. Alternatively, help from the web can be acquired on a case-by-case basis via the switch to .

Background[edit]

Every version of Microsoft Windows for personal computers has included a command line interpreter (CLI) for managing the operating system. Its predecessor, MS-DOS, relied exclusively on a CLI. These are in MS-DOS and Windows 9x, and in the Windows NT family of operating systems. Both support a few basic internal commands. For other purposes, a separate console application must be written. They also include a basic scripting language (batch files), which can be used to automate various tasks. However, they cannot be used to automate all facets of graphical user interface (GUI) functionality, in part because command-line equivalents of operations are limited, and the scripting language is elementary. In Windows Server 2003, the situation was improved, but scripting support was still unsatisfactory.^[10]

Microsoft attempted to address some of these shortcomings by introducing the Windows Script Host in 1998 with Windows 98, and its command-line based host: . It integrates with the Active Script engine and allows scripts to be written in compatible languages, such as JScript and VBScript, leveraging the APIs exposed by applications via the component object model (COM). However, it has its own deficiencies: its documentation is not very accessible, and it quickly gained a reputation as a system vulnerability vector after several high-profile computer viruses exploited weaknesses in its security provisions. Different versions of Windows provided various special-purpose command line interpreters (such as netsh and WMIC) with their own command sets but they were not interoperable.

In an interview published 2017 September 13, Jeffrey Snover explained the motivation for the project:^[11]

I'd been driving a bunch of managing changes, and then I originally took the UNIX tools and made them available on Windows, and then it just didn't work. Right? Because there's a core architectural difference between Windows and Linux. On Linux, everything's an ASCIItext file, so anything that can manipulate that is a managing tool. AWK, grep, sed? Happy days!

I brought those tools available on Windows, and then they didn't help manage Windows because in Windows, everything's an API that returns structured data. So, that didn't help. [...] I came up with this idea of PowerShell, and I said, "Hey, we can do this better."

By 2002, Microsoft had started to develop a new approach to command line management, including a CLI called Monad (also known as Microsoft Shell or MSH). The ideas behind it were published in August 2002 in a white paper titled Monad Manifesto.^[12] Monad was to be a new extensible CLI with a fresh design that would be capable of automating a full range of core administrative tasks. Microsoft first showed off Monad at the Professional Development Conference in Los Angeles in October 2003. A private beta program began a few months later which eventually led to a public beta program.

Microsoft published the first Monad public beta release on June 17, 2005, Beta 2 on September 11, 2005, and Beta 3 on January 10, 2006. Not much later, on April 25, 2006 Microsoft formally announced that Monad had been renamed Windows PowerShell, positioning it as a significant part of their management technology offerings.^[13] Release Candidate 1 of PowerShell was released at the same time. A significant aspect of both the name change and the RC was that this was now a component of Windows, and not an add-on product.

Release Candidate 2 of PowerShell version 1 was released on September 26, 2006 with final Release to the web (RTW) on November 14, 2006 and announced at TechEd Barcelona. PowerShell for earlier versions of Windows was released on January 30, 2007.^[14]

PowerShell v2.0 development began before PowerShell v1.0 shipped. During the development, Microsoft shipped three community technology previews (CTP). Microsoft made these releases available to the public. The last CTP release of Windows PowerShell v2.0 was made available in December 2008.

PowerShell for Linux 6.0 Alpha 9 on Ubuntu 14.04 x64

PowerShell v2.0 was completed and released to manufacturing in August 2009, as an integral part of Windows 7 and Windows Server 2008 R2. Versions of PowerShell for Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008 were released in October 2009 and are available for download for both 32-bit and 64-bit platforms.^[15]

Windows 10 shipped a testing framework for PowerShell.^[16]

On 18 August 2016, Microsoft announced^[17] that they had made PowerShell open-source and cross-platform with support for Windows, macOS, CentOS and Ubuntu.^[5] The source code was published on GitHub.^[18] The move to open source created a second incarnation of PowerShell called "PowerShell Core", which runs on .NET Core. It is distinct from "Windows PowerShell", which runs on the full .NET Framework.^[19] Starting with version 5.1, PowerShell Core is bundled with Windows Server 2016 Nano Server.^[20][21]

Design[edit]

PowerShell's developers based the core grammar of the tool on that of the POSIX 1003.2Korn shell.^[22]

Windows PowerShell can execute four kinds of named commands:^[23]

• cmdlets (.NET Framework programs designed to interact with PowerShell)
• PowerShell scripts (files suffixed by )
• PowerShell functions
• standalone executable programs

If a command is a standalone executable program, PowerShell launches it in a separate process; if it is a cmdlet, it executes in the PowerShell process. PowerShell provides an interactive command-line interface, wherein the commands can be entered and their output displayed. The user interface offers customizable tab completion. PowerShell enables the creation of aliases for cmdlets, which PowerShell textually translates into invocations of the original commands. PowerShell supports both named and positional parameters for commands. In executing a cmdlet, the job of binding the argument value to the parameter is done by PowerShell itself, but for external executables, arguments are parsed by the external executable independently of PowerShell interpretation.^{[citation needed]}

The PowerShell Extended Type System (ETS) is based on the .NET type system, but with extended semantics (for example, propertySets and third-party extensibility). For example, it enables the creation of different views of objects by exposing only a subset of the data fields, properties, and methods, as well as specifying custom formatting and sorting behavior. These views are mapped to the original object using XML-based configuration files.^[24]

Cmdlets[edit]

Cmdlets are specialized commands in the PowerShell environment that implement specific functions. These are the native commands in the PowerShell stack. Cmdlets follow a Verb-Noun naming pattern, such as Get-ChildItem, helping to make them self-descriptive.^[25] Cmdlets output their results as objects and can also receive objects as input, making them suitable for use as recipients in a pipeline. If a cmdlet outputs multiple objects, each object in the collection is passed down through the entire pipeline before the next object is processed.^[25]

Cmdlets are specialized .NET classes, which the PowerShell runtime instantiates and invokes at run-time. Cmdlets derive either from or from , the latter being used when the cmdlet needs to interact with the PowerShell runtime.^[25] These base classes specify certain methods – , and – which the cmdlet's implementation overrides to provide the functionality. Whenever a cmdlet runs, PowerShell invokes these methods in sequence, with being called if it receives pipeline input.^[26] If a collection of objects is piped, the method is invoked for each object in the collection. The class implementing the cmdlet must have one .NET attribute – – which specifies the verb and the noun that make up the name of the cmdlet. Common verbs are provided as an enum.^[27][28]

If a cmdlet receives either pipeline input or command-line parameter input, there must be a corresponding property in the class, with a mutator implementation. PowerShell invokes the mutator with the parameter value or pipeline input, which is saved by the mutator implementation in class variables. These values are then referred to by the methods which implement the functionality. Properties that map to command-line parameters are marked by ^[29] and are set before the call to . Those which map to pipeline input are also flanked by , but with the attribute parameter set.^[30]

The implementation of these cmdlet classes can refer to any .NETAPI and may be in any .NET language. In addition, PowerShell makes certain APIs available, such as , which is used to access PowerShell-specific functionality, such as writing resultant objects to the pipeline. Cmdlets can use .NET data access APIs directly or use the PowerShell infrastructure of PowerShell Providers, which make data stores addressable using unique paths. Data stores are exposed using drive letters, and hierarchies within them, addressed as directories. Windows PowerShell ships with providers for the file system, registry, the certificate store, as well as the namespaces for command aliases, variables, and functions.^[31] Windows PowerShell also includes various cmdlets for managing various Windows systems, including the file system, or using Windows Management Instrumentation to control Windows components. Other applications can register cmdlets with PowerShell, thus allowing it to manage them, and, if they enclose any datastore (such as databases), they can add specific providers as well.^{[citation needed]}

PowerShell V2 added a more portable version of cmdlets called Modules. The PowerShell V2 release notes state:

Modules allow script developers and administrators to partition and organize their Windows PowerShell code in self-contained, reusable units. Code from a module executes in its own self-contained context and does not affect the state outside of the module. Modules also enable you to define a restricted runspace environment by using a script.^[32]

The number of cmdlets has generally increased with each version:

Pipeline[edit]

PowerShell implements the concept of a pipeline, which enables piping the output of one cmdlet to another cmdlet as input. For example, the output of the cmdlet could be piped to the to filter any process that has less than 1 MB of paged memory, and then to the cmdlet (e.g., to sort the objects by handle count), and then finally to the cmdlet to select just the first 10 (i.e., the 10 processes based on handle count).^{[citation needed]}

As with Unix pipelines, PowerShell pipelines can construct complex commands, using the operator to connect stages. However, the PowerShell pipeline differs from Unix pipelines in that stages execute within the PowerShell runtime rather than as a set of processes coordinated by the operating system, and structured .NET objects, rather than byte streams, are passed from one stage to the next. Using objects and executing stages within the PowerShell runtime eliminates the need to serialize data structures, or to extract them by explicitly parsing text output.^[37] An object can also encapsulate certain functions that work on the contained data, which become available to the recipient command for use.^[38][39] For the last cmdlet in a pipeline, PowerShell automatically pipes its output object to the cmdlet, which transforms the objects into a stream of format objects and then renders those to the screen.^[40][41]

Because all PowerShell objects are .NET objects, they share a method, which retrieves the text representation of the data in an object. In addition, PowerShell allows formatting definitions to be specified, so the text representation of objects can be customized by choosing which data elements to display, and in what manner. However, in order to maintain backwards compatibility, if an external executable is used in a pipeline, it receives a text stream representing the object, instead of directly integrating with the PowerShell type system.^[42][43][44]

Scripting[edit]

Windows PowerShell includes a dynamically typedscripting language which can implement complex operations using cmdlets imperatively. The scripting language supports variables, functions, branching (), loops (, , , and ), structured error/exception handling and closures/lambda expressions,^[45] as well as integration with .NET. Variables in PowerShell scripts are prefixed with . Variables can be assigned any value, including the output of cmdlets. Strings can be enclosed either in single quotes or in double quotes: when using double quotes, variables will be expanded even if they are inside the quotation marks. Enclosing the path to a file in braces preceded by a dollar sign (as in ) creates a reference to the contents of the file. If it is used as an L-value, anything assigned to it will be written to the file. When used as an R-value, the contents of the file will be read. If an object is assigned, it is serialized before being stored.^{[citation needed]}

Object members can be accessed using notation, as in C# syntax. PowerShell provides special variables, such as , which is an array of all the command line arguments passed to a function from the command line, and , which refers to the current object in the pipeline.^[46] PowerShell also provides arrays and associative arrays. The PowerShell scripting language also evaluates arithmetic expressions entered on the command line immediately, and it parses common abbreviations, such as GB, MB, and KB.^[47][48]

Using the keyword, PowerShell provides for the creation of functions, the following general form:^[49]

The defined function is invoked in either of the following forms:^[49]

PowerShell supports named parameters, positional parameters, switch parameters and dynamic parameters.^[49]

PowerShell allows any .NET methods to be called by providing their namespaces enclosed in brackets (), and then using a pair of colons () to indicate the static method.^[50] For example, . Objects are created using the cmdlet. Calling methods of .NET objects is accomplished by using the regular notation.^[50]

PowerShell accepts strings, both raw and escaped. A string enclosed between single quotation marks is a raw string while a string enclosed between double quotation marks is an escaped string. PowerShell treats straight and curly quotes as equivalent.^[51]

The following list of special characters is supported by PowerShell:^[52]

For error handling, PowerShell provides a .NET-based exception-handling mechanism. In case of errors, objects containing information about the error ( object) are thrown, which are caught using the construct (although a construct is supported as well). PowerShell can be configured to silently resume execution, without actually throwing the exception; this can be done either on a single command, a single session or perpetually.^[53]

Scripts written using PowerShell can be made to persist across sessions in either a file or a file (the latter is used to implement a module). Later, either the entire script or individual functions in the script can be used. Scripts and functions operate analogously with cmdlets, in that they can be used as commands in pipelines, and parameters can be bound to them. Pipeline objects can be passed between functions, scripts, and cmdlets seamlessly. To prevent unintentional running of scripts, script execution is disabled by default and must be enabled explicitly.^[54] Enabling of scripts can be performed either at system, user or session level. PowerShell scripts can be signed to verify their integrity, and are subject to Code Access Security.^[55]

The PowerShell scripting language supports binary prefix notation similar to the scientific notation supported by many programming languages in the C-family.^[56]

Hosting[edit]

One can also use PowerShell embedded in a management application, which uses the PowerShell runtime to implement the management functionality. For this, PowerShell provides a managed hosting API. Via the APIs, the application can instantiate a runspace (one instantiation of the PowerShell runtime), which runs in the application's process and is exposed as a object.^[6] The state of the runspace is encased in a object. When the runspace is created, the Windows PowerShell runtime initializes the instantiation, including initializing the providers and enumerating the cmdlets, and updates the object accordingly. The Runspace then must be opened for either synchronous processing or asynchronous processing. After that it can be used to execute commands.^{[citation needed]}

To execute a command, a pipeline (represented by a object) must be created and associated with the runspace. The pipeline object is then populated with the cmdlets that make up the pipeline. For sequential operations (as in a PowerShell script), a Pipeline object is created for each statement and nested inside another Pipeline object.^[6] When a pipeline is created, Windows PowerShell invokes the pipeline processor, which resolves the cmdlets into their respective assemblies (the command processor) and adds a reference to them to the pipeline, and associates them with , and objects, to represent the connection with the pipeline. The types are verified and parameters bound using reflection.^[6] Once the pipeline is set up, the host calls the method to run the commands, or its asynchronous equivalent – . If the pipeline has the cmdlet at the end of the pipeline, it writes the result onto the console screen. If not, the results are handed over to the host, which might either apply further processing or display the output itself.^{[citation needed]}

Microsoft Exchange Server 2007 uses the hosting APIs to provide its management GUI. Each operation exposed in the GUI is mapped to a sequence of PowerShell commands (or pipelines). The host creates the pipeline and executes them. In fact, the interactive PowerShell console itself is a PowerShell host, which interprets the scripts entered at command line and creates the necessary objects and invokes them.^{[citation needed]}

Desired State Configuration[edit]

DSC allows for declaratively specifying how a software environment should be configured.^[57]

Upon running a configuration, DSC will ensure that the system gets the state described in the configuration. DSC configurations are idempotent. The Local Configuration Manager (LCM) periodically polls the system using the control flow described by resources (imperative pieces of DSC) to make sure that the state of a configuration is maintained.

Versions[edit]

Initially using the code name "Monad", PowerShell was first shown publicly at the Professional Developers Conference in October 2003 in Los Angeles. All major releases are still supported, and each major release has featured backwards compatibility with preceding versions.

Windows PowerShell 1.0[edit]

PowerShell 1.0 was released in November 2006 for Windows XP SP2, Windows Server 2003 SP1 and Windows Vista.^[58] It is an optional component of Windows Server 2008.

Windows PowerShell 2.0[edit]

PowerShell 2.0 is integrated with Windows 7 and Windows Server 2008 R2^[59] and is released for Windows XP with Service Pack 3, Windows Server 2003 with Service Pack 2, and Windows Vista with Service Pack 1.^[60][61]

PowerShell v2 includes changes to the scripting language and hosting API, in addition to including more than 240 new cmdlets.^[62][63]

New features of PowerShell 2.0 include:^[64][65][66]

• PowerShell remoting: Using WS-Management, PowerShell 2.0 allows scripts and cmdlets to be invoked on a remote machine or a large set of remote machines.
• Background jobs: Also called a PSJob, it allows a command sequence (script) or pipeline to be invoked asynchronously. Jobs can be run on the local machine or on multiple remote machines. An interactive cmdlet in a PSJob blocks the execution of the job until user input is provided.
• Transactions: Enable cmdlet and developers can perform transactional operations. PowerShell 2.0 includes transaction cmdlets for starting, committing, and rolling back a PSTransaction as well as features to manage and direct the transaction to the participating cmdlet and provider operations. The PowerShell Registry provider supports transactions.
• Advanced functions: These are cmdlets written using the PowerShell scripting language. Initially called "script cmdlets", this feature was later renamed "advanced functions".^[67]
• SteppablePipelines: This allows the user to control when the , and functions of a cmdlet are called.
• Modules: This allows script developers and administrators to organize and partition PowerShell scripts in self-contained, reusable units. Code from a module executes in its own self-contained context and does not affect the state outside the module. Modules can define a restricted runspace environment by using a script. They have a persistent state as well as public and private members.
• Data language: A domain-specific subset of the PowerShell scripting language that allows data definitions to be decoupled from the scripts and allows localized string resources to be imported into the script at runtime (Script Internationalization).
• Script debugging: It allows breakpoints to be set in a PowerShell script or function. Breakpoints can be set on lines, line & columns, commands and read or write access of variables. It includes a set of cmdlets to control the breakpoints via script.
• Eventing: This feature allows listening, forwarding, and acting on management and system events. Eventing allows PowerShell hosts to be notified about state changes to their managed entities. It also enables PowerShell scripts to subscribe to ObjectEvents, PSEvents, and WmiEvents and process them synchronously and asynchronously.
• Windows PowerShell Integrated Scripting Environment (ISE): PowerShell 2.0 includes a GUI-based PowerShell host that provides integrated debugger, syntax highlighting, tab completion and up to 8 PowerShell Unicode-enabled consoles (Runspaces) in a tabbed UI, as well as the ability to run only the selected parts in a script.
• Network file transfer: Native support for prioritized, throttled, and asynchronous transfer of files between machines using the Background Intelligent Transfer Service (BITS).^[68]
• New cmdlets: Including , which displays tabular data in the WPFGridView object, on systems that allow it, and if ISE is installed and enabled.
• New operators: , , and Splatting () operators.
• Exception handling with Try-Catch-Finally: Unlike other .NET languages, this allows multiple exception types for a single catch block.
• Nestable Here-Strings: PowerShell Here-Strings have been improved and can now nest.^[69]
• Block comments: PowerShell 2.0 supports block comments using and as delimiters.^[70]
• New APIs: The new APIs range from handing more control over the PowerShell parser and runtime to the host, to creating and managing collection of Runspaces (RunspacePools) as well as the ability to create Restricted Runspaces which only allow a configured subset of PowerShell to be invoked. The new APIs also support participation in a Windows PowerShell managed transaction.

Windows PowerShell 3.0[edit]

PowerShell 3.0 is integrated with Windows 8 and with Windows Server 2012. Microsoft has also made PowerShell 3.0 available for Windows 7 with Service Pack 1, for Windows Server 2008 with Service Pack 1, and for Windows Server 2008 R2 with Service Pack 1.^[71][72]

PowerShell 3.0 is part of a larger package, Windows Management Framework 3.0 (WMF3), which also contains the WinRM service to support remoting.^[72] Microsoft made several Community Technology Preview releases of WMF3. An early community technology preview 2 (CTP 2) version of Windows Management Framework 3.0 was released on 2 December 2011.^[73] Windows Management Framework 3.0 was released for general availability in December 2012^[74] and is included with Windows 8 and Windows Server 2012 by default.^[75]

New features in PowerShell 3.0 include:^{[72][76]:33–34}

• Scheduled jobs: Jobs can be scheduled to run on a preset time and date.
• Session connectivity: Sessions can be disconnected and reconnected. Remote sessions have become more tolerant of temporary network failures.
• Improved code writing: Code completion (IntelliSense) and snippets are added. PowerShell ISE allows users to use dialog boxes to fill in parameters for PowerShell cmdlets.
• Delegation support: Administrative tasks can be delegated to users who do not have permissions for that type of task, without granting them perpetual additional permissions.
• Help update: Help documentations can be updated via Update-Help command.
• Automatic module detection: Modules are loaded implicitly whenever a command from that module is invoked. Code completion works for unloaded modules as well.
• New commands: Dozens of new modules were added, including functionality to manage disks , volumes, firewalls, network connections and printer management, previously performed via WMI.^{[further explanation needed]}

Windows PowerShell 4.0[edit]

PowerShell 4.0 is integrated with Windows 8.1 and with Windows Server 2012 R2. Microsoft has also made PowerShell 4.0 available for Windows 7 SP1, Windows Server 2008 R2 SP1 and Windows Server 2012.^[77]

New features in PowerShell 4.0 include:

• Desired State Configuration:^[78][79][80] Declarative language extensions and tools that enable the deployment and management of configuration data for systems using the DMTF management standards and WS-Management Protocol
• New default execution policy: On Windows Servers, the default execution Policy is now RemoteSigned.
• Save-Help: Help can now be saved for modules that are installed on remote computers.
• Enhanced debugging: The debugger now supports debugging workflows, remote script execution and preserving debugging sessions across PowerShell session reconnections.
• -PipelineVariable switch: A new ubiquitous parameter to expose the current pipeline object as a variable for programming purposes
• Network diagnostics to manage physical and Hyper-V's virtualized network switches
• Where and ForEach method syntax provides an alternate method of filtering and iterating over objects.

Windows PowerShell 5.0[edit]

Windows Management Framework (WMF) 5.0 RTM which includes PowerShell 5.0 was re-released to web on February 24, 2016, following an initial release with a severe bug.^[81]

Key features include:

• The new keyword that creates classes for object-oriented programming
• The new keyword that creates enumerations
• cmdlets to support the Chocolateypackage manager^[82]
• Extending support for switch management to layer 2 network switches.^[83]
• Debugging for PowerShell background jobs and instances of PowerShell hosted in other processes (each of which is called a "runspace")
• Desired State Configuration (DSC) Local Configuration Manager (LCM) version 2.0
• DSC partial configurations
• DSC Local Configuration Manager meta-configurations
• Authoring of DSC resources using PowerShell classes

Windows PowerShell 5.1[edit]

It was released along with the Windows 10 Anniversary Update^[84] on August 2, 2016, and in Windows Server 2016.^[85] PackageManagement now supports proxies, PSReadLine now has ViMode support, and two new cmdlets were added: Get-TimeZone and Set-TimeZone. The LocalAccounts module allows for adding/removing local user accounts.^[86] A preview for PowerShell 5.1 was released for Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 on July 16, 2016,^[87] and was released on January 19, 2017.^[88]

PowerShell 5.1 is the first version to come in two editions of "Desktop" and "Core". The "Desktop" edition is the continuation of the traditional Windows PowerShell that runs on full .NET Framework stack. The "Core" edition runs on .NET Core and is bundled with Windows Server 2016 Nano Server. In exchange for smaller footprint, the latter lacks some features such as the cmdlets to manage clipboard or join a computer to a domain, WMI version 1 cmdlets, Event Log cmdlets and profiles.^[21] This was the final version of PowerShell made exclusively for Windows.

PowerShell Core 6[edit]

PowerShell Core 6.0 was first announced on 18 August 2016, when Microsoft unveiled PowerShell Core and its decision to make the product cross-platform, independent of Windows, free and open source.^[5] It achieved general availability on 10 January 2018 for Windows, macOS and Linux.^[89] It has its own support lifecycle and adheres to the Microsoft lifecycle policy that is introduced with Windows 10: Only the latest version of PowerShell Core is supported. Microsoft expects to release one minor version for PowerShell Core 6.0 every six months.^[90]

The most significant change in this version of PowerShell is the expansion to the other platforms. For Windows administrators, this version of PowerShell did not include any major new features. In an interview with the community on 11 January 2018, the PowerShell team was asked to list the top 10 most exciting things that would happen for a Windows IT professional who would migrate from Windows PowerShell 5.1 to PowerShell Core 6.0; in response, Angel Calvo of Microsoft could only name two: cross-platform and open-source.^[91]

According to Microsoft, one of the new features of PowerShell 6.1 is "Compatibility with 1900+ existing cmdlets in Windows 10 and Windows Server 2019."^[92] Still, no details of these cmdlets can be found it the full version of the change log.^[93] Microsoft later professes that this number was insufficient. as PowerShell Core failed to replace Windows PowerShell 5.1 and gain traction on Windows.^[94] It was, however, popular on Linux.^[94]

PowerShell Core 6.2 is focused primarily on performance improvements, bug fixes, and smaller cmdlet and language enhancements that improve the quality of life for users.^[95]

PowerShell 7[edit]

PowerShell 7 is the replacement product for PowerShell Core 6.x products as well as Windows PowerShell 5.1, which is the last supported Windows PowerShell version.^[96][94] The focus in development was to make PowerShell 7 a viable replacement for Windows PowerShell 5.1, i.e. to have near parity with Windows PowerShell in terms of compatibility with modules that ship with Windows.^[97]

New features in PowerShell 7 include:^[98]

• The switch for the cmdlet to help handle parallel processing
• Near parity with Windows PowerShell in terms of compatibility with built-in Windows modules
• A new error view
• The cmdlet
• Pipeline chaining operators ( and ) that allow conditional execution of the next cmdlet in the pipeline
• The ?: operator for ternary operation
• The operator that only assigns a value to a variable when the variable's existing value is null
• The operator for null coalescing
• Cross-platform (experimental)
• Return of the cmdlet
• Return of the switch for the

Comparison of cmdlets with similar commands[edit]

The following table contains a selection of the cmdlets that ship with PowerShell, noting similar commands in other well-known command-line interpreters. Many of these similar commands come out-of-the-box defined as aliases within PowerShell, making it easy for people familiar with other common shells to start working.

Notes

Filename extensions[edit]

Application support[edit]

The Windows Registry is a hierarchical database that stores low-level settings for the Microsoft Windows operating system and for applications that opt to use the registry. The kernel, device drivers, services, Security Accounts Manager, and user interface can all use the registry. The registry also allows access to counters for profiling system performance.

In other words, the registry or Windows Registry contains information, settings, options, and other values for programs and hardware installed on all versions of Microsoft Windows operating systems. For example, when a program is installed, a new subkey containing settings such as a program's location, its version, and how to start the program, are all added to the Windows Registry.

When introduced with Windows 3.1, the Windows Registry primarily stored configuration information for COM-based components. Windows 95 and Windows NT extended its use to rationalise and centralise the information in the profusion of INI files, which held the configurations for individual programs, and were stored at various locations.^[1][2] It is not a requirement for Windows applications to use the Windows Registry. For example, .NET Framework applications use XML files for configuration, while portable applications usually keep their configuration files with their executables.

Rationale[edit]

Prior to the Windows Registry, .INI files stored each program's settings as a text or binary file, often located in a shared location that did not provide user-specific settings in a multi-user scenario. By contrast, the Windows Registry stores all application settings in one logical repository (but a number of discrete files) and in a standardized form. According to Microsoft, this offers several advantages over .INI files.^[2][3] Since file parsing is done much more efficiently with a binary format, it may be read from or written to more quickly than a text INI file. Furthermore, strongly typed data can be stored in the registry, as opposed to the text information stored in .INI files. This is a benefit when editing keys manually using , the built-in Windows Registry Editor. Because user-based registry settings are loaded from a user-specific path rather than from a read-only system location, the registry allows multiple users to share the same machine, and also allows programs to work for less privileged users. Backup and restoration is also simplified as the registry can be accessed over a network connection for remote management/support, including from scripts, using the standard set of APIs, as long as the Remote Registry service is running and firewall rules permit this.

Because the registry is a database, it offers improved system integrity with features such as atomic updates. If two processes attempt to update the same registry value at the same time, one process's change will precede the other's and the overall consistency of the data will be maintained. Where changes are made to .INI files, such race conditions can result in inconsistent data that does not match either attempted update. Windows Vista and later operating systems provide transactional updates to the registry by means of the Kernel Transaction Manager, extending the atomicity guarantees across multiple key and/or value changes, with traditional commit–abort semantics. (Note however that NTFS provides such support for the file system as well, so the same guarantees could, in theory, be obtained with traditional configuration files.)

Structure[edit]

Keys and values[edit]

The registry contains two basic elements: keys and values. Registry keys are container objects similar to folders. Registry values are non-container objects similar to files. Keys may contain values and subkeys. Keys are referenced with a syntax similar to Windows' path names, using backslashes to indicate levels of hierarchy. Keys must have a case insensitive name without backslashes.

The hierarchy of registry keys can only be accessed from a known root key handle (which is anonymous but whose effective value is a constant numeric handle) that is mapped to the content of a registry key preloaded by the kernel from a stored "hive", or to the content of a subkey within another root key, or mapped to a registered service or DLL that provides access to its contained subkeys and values.

E.g. HKEY_LOCAL_MACHINE\Software\Microsoft\Windows refers to the subkey "Windows" of the subkey "Microsoft" of the subkey "Software" of the HKEY_LOCAL_MACHINE root key.

There are seven predefined root keys, traditionally named according to their constant handles defined in the Win32 API, or by synonymous abbreviations (depending on applications):

• HKEY_LOCAL_MACHINE or HKLM
• HKEY_CURRENT_CONFIG or HKCC
• HKEY_CLASSES_ROOT or HKCR
• HKEY_CURRENT_USER or HKCU
• HKEY_USERS or HKU
• HKEY_PERFORMANCE_DATA (only in Windows NT, but invisible in the Windows Registry Editor)
• HKEY_DYN_DATA (only in Windows 9x, and visible in the Windows Registry Editor)

Like other files and services in Windows, all registry keys may be restricted by access control lists (ACLs), depending on user privileges, or on security tokens acquired by applications, or on system security policies enforced by the system (these restrictions may be predefined by the system itself, and configured by local system administrators or by domain administrators). Different users, programs, services or remote systems may only see some parts of the hierarchy or distinct hierarchies from the same root keys.

Registry values are name/data pairs stored within keys. Registry values are referenced separately from registry keys. Each registry value stored in a registry key has a unique name whose letter case is not significant. The Windows API functions that query and manipulate registry values take value names separately from the key path and/or handle that identifies the parent key. Registry values may contain backslashes in their names, but doing so makes them difficult to distinguish from their key paths when using some legacy Windows Registry API functions (whose usage is deprecated in Win32).

The terminology is somewhat misleading, as each registry key is similar to an associative array, where standard terminology would refer to the name part of each registry value as a "key". The terms are a holdout from the 16-bit registry in Windows 3, in which registry keys could not contain arbitrary name/data pairs, but rather contained only one unnamed value (which had to be a string). In this sense, the Windows 3 registry was like a single associative array, in which the keys (in the sense of both 'registry key' and 'associative array key') formed a hierarchy, and the registry values were all strings. When the 32-bit registry was created, so was the additional capability of creating multiple named values per key, and the meanings of the names were somewhat distorted.^[4] For compatibility with the previous behavior, each registry key may have a "default" value, whose name is the empty string.

Each value can store arbitrary data with variable length and encoding, but which is associated with a symbolic type (defined as a numeric constant) defining how to parse this data. The standard types are:

Root keys[edit]

The keys at the root level of the hierarchical database are generally named by their Windows API definitions, which all begin "HKEY".^[2] They are frequently abbreviated to a three- or four-letter short name starting with "HK" (e.g. HKCU and HKLM). Technically, they are predefined handles (with known constant values) to specific keys that are either maintained in memory, or stored in hive files stored in the local filesystem and loaded by the system kernel at boot time and then shared (with various access rights) between all processes running on the local system, or loaded and mapped in all processes started in a user session when the user logs on the system.

The HKEY_LOCAL_MACHINE (local machine-specific configuration data) and HKEY_CURRENT_USER (user-specific configuration data) nodes have a similar structure to each other; user applications typically look up their settings by first checking for them in "HKEY_CURRENT_USER\Software\Vendor's name\Application's name\Version\Setting name", and if the setting is not found, look instead in the same location under the HKEY_LOCAL_MACHINE key^{[citation needed]}. However, the converse may apply for administrator-enforced policy settings where HKLM may take precedence over HKCU. The Windows Logo Program has specific requirements for where different types of user data may be stored, and that the concept of least privilege be followed so that administrator-level access is not required to use an application.^[a][5]

HKEY_LOCAL_MACHINE (HKLM)[edit]

Abbreviated HKLM, HKEY_LOCAL_MACHINE stores settings that are specific to the local computer.^[6]

The key located by HKLM is actually not stored on disk, but maintained in memory by the system kernel in order to map all the other subkeys. Applications cannot create any additional subkeys. On Windows NT, this key contains four subkeys, "SAM", "SECURITY", "SYSTEM", and "SOFTWARE", that are loaded at boot time within their respective files located in the %SystemRoot%\System32\config folder. A fifth subkey, "HARDWARE", is volatile and is created dynamically, and as such is not stored in a file (it exposes a view of all the currently detected Plug-and-Play devices). On Windows Vista and above, a sixth and seventh subkey, "COMPONENTS" and "BCD", are mapped in memory by the kernel on-demand and loaded from %SystemRoot%\system32\config\COMPONENTS or from boot configuration data, \boot\BCD on the system partition.

• The "HKLM\SAM" key usually appears as empty for most users (unless they are granted access by administrators of the local system or administrators of domains managing the local system). It is used to reference all "Security Accounts Manager" (SAM) databases for all domains into which the local system has been administratively authorized or configured (including the local domain of the running system, whose SAM database is stored a subkey also named "SAM": other subkeys will be created as needed, one for each supplementary domain). Each SAM database contains all builtin accounts (mostly group aliases) and configured accounts (users, groups and their aliases, including guest accounts and administrator accounts) created and configured on the respective domain, for each account in that domain, it notably contains the user name which can be used to log on that domain, the internal unique user identifier in the domain, a cryptographic hash of each user's password for each enabled authentication protocol, the location of storage of their user registry hive, various status flags (for example if the account can be enumerated and be visible in the logon prompt screen), and the list of domains (including the local domain) into which the account was configured.
• The "HKLM\SECURITY" key usually appears empty for most users (unless they are granted access by users with administrative privileges) and is linked to the Security database of the domain into which the current user is logged on (if the user is logged on the local system domain, this key will be linked to the registry hive stored by the local machine and managed by local system administrators or by the builtin "System" account and Windows installers). The kernel will access it to read and enforce the security policy applicable to the current user and all applications or operations executed by this user. It also contains a "SAM" subkey which is dynamically linked to the SAM database of the domain onto which the current user is logged on.
• The "HKLM\SYSTEM" key is normally only writable by users with administrative privileges on the local system. It contains information about the Windows system setup, data for the secure random number generator (RNG), the list of currently mounted devices containing a filesystem, several numbered "HKLM\SYSTEM\Control Sets" containing alternative configurations for system hardware drivers and services running on the local system (including the currently used one and a backup), a "HKLM\SYSTEM\Select" subkey containing the status of these Control Sets, and a "HKLM\SYSTEM\CurrentControlSet" which is dynamically linked at boot time to the Control Set which is currently used on the local system. Each configured Control Set contains:
  • an "Enum" subkey enumerating all known Plug-and-Play devices and associating them with installed system drivers (and storing the device-specific configurations of these drivers),
  • a "Services" subkey listing all installed system drivers (with non device-specific configuration, and the enumeration of devices for which they are instantiated) and all programs running as services (how and when they can be automatically started),
  • a "Control" subkey organizing the various hardware drivers and programs running as services and all other system-wide configuration,
  • a "Hardware Profiles" subkey enumerating the various profiles that have been tuned (each one with "System" or "Software" settings used to modify the default profile, either in system drivers and services or in the applications) as well as the "Hardware Profiles\Current" subkey which is dynamically linked to one of these profiles.
• The "HKLM\SOFTWARE" subkey contains software and Windows settings (in the default hardware profile). It is mostly modified by application and system installers. It is organized by software vendor (with a subkey for each), but also contains a "Windows" subkey for some settings of the Windows user interface, a "Classes" subkey containing all registered associations from file extensions, MIME types, Object Classes IDs and interfaces IDs (for OLE, COM/DCOM and ActiveX), to the installed applications or DLLs that may be handling these types on the local machine (however these associations are configurable for each user, see below), and a "Policies" subkey (also organized by vendor) for enforcing general usage policies on applications and system services (including the central certificates store used for authenticating, authorizing or disallowing remote systems or services running outside the local network domain).
• The "HKLM\SOFTWARE\Wow6432Node" key is used by 32-bit applications on a 64-bit Windows OS, and is equivalent but separate to "HKLM\SOFTWARE". The key path is transparently presented to 32-bit applications by WoW64 as HKLM\SOFTWARE^[7] (in a similar way that 32-bit applications see %SystemRoot%\Syswow64 as %SystemRoot%\System32)

HKEY_CURRENT_CONFIG (HKCC)[edit]

Abbreviated HKCC, HKEY_CURRENT_CONFIG contains information gathered at runtime; information stored in this key is not permanently stored on disk, but rather regenerated at boot time. It is a handle to the key "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles\Current", which is initially empty but populated at boot time by loading one of the other subkeys stored in "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles".

HKEY_CLASSES_ROOT (HKCR)[edit]

Abbreviated HKCR, HKEY_CLASSES_ROOT contains information about registered applications, such as file associations and OLE Object Class IDs, tying them to the applications used to handle these items. On Windows 2000 and above, HKCR is a compilation of user-based HKCU\Software\Classes and machine-based HKLM\Software\Classes. If a given value exists in both of the subkeys above, the one in HKCU\Software\Classes takes precedence.^[8] The design allows for either machine- or user-specific registration of COM objects.

HKEY_USERS (HKU)[edit]

Abbreviated HKU, HKEY_USERS contains subkeys corresponding to the HKEY_CURRENT_USER keys for each user profile actively loaded on the machine, though user hives are usually only loaded for currently logged-in users.

HKEY_CURRENT_USER (HKCU)[edit]

Abbreviated HKCU, HKEY_CURRENT_USER stores settings that are specific to the currently logged-in user.^[9] The HKEY_CURRENT_USER key is a link to the subkey of HKEY_USERS that corresponds to the user; the same information is accessible in both locations. The specific subkey referenced is "(HKU)\(SID)\..." where (SID) corresponds to the Windows SID; if the "(HKCU)" key has the following suffix "(HKCU)\Software\Classes\..." then it corresponds to "(HKU)\(SID)_CLASSES\..." i.e. the suffix has the string "_CLASSES" is appended to the (SID).

On Windows NT systems, each user's settings are stored in their own files called NTUSER.DAT and USRCLASS.DAT inside their own Documents and Settings subfolder (or their own Users sub folder in Windows Vista and above). Settings in this hive follow users with a roaming profile from machine to machine.

HKEY_PERFORMANCE_DATA[edit]

This key provides runtime information into performance data provided by either the NT kernel itself, or running system drivers, programs and services that provide performance data. This key is not stored in any hive and not displayed in the Registry Editor, but it is visible through the registry functions in the Windows API, or in a simplified view via the Performance tab of the Task Manager (only for a few performance data on the local system) or via more advanced control panels (such as the Performances Monitor or the Performances Analyzer which allows collecting and logging these data, including from remote systems).

HKEY_DYN_DATA[edit]

This key is used only on Windows 95, Windows 98 and Windows ME.^[10] It contains information about hardware devices, including Plug and Play and network performance statistics. The information in this hive is also not stored on the hard drive. The Plug and Play information is gathered and configured at startup and is stored in memory.^[11]

Hives[edit]

Even though the registry presents itself as an integrated hierarchical database, branches of the registry are actually stored in a number of disk files called hives.^[12] (The word hive constitutes an in-joke.)^[13]

Some hives are volatile and are not stored on disk at all. An example of this is the hive of the branch starting at HKLM\HARDWARE. This hive records information about system hardware and is created each time the system boots and performs hardware detection.

Individual settings for users on a system are stored in a hive (disk file) per user. During user login, the system loads the user hive under the HKEY_USERS key and sets the HKCU (HKEY_CURRENT_USER) symbolic reference to point to the current user. This allows applications to store/retrieve settings for the current user implicitly under the HKCU key.

Not all hives are loaded at any one time. At boot time, only a minimal set of hives are loaded, and after that, hives are loaded as the operating system initializes and as users log in or whenever a hive is explicitly loaded by an application.

File locations[edit]

The registry is physically stored in several files, which are generally obfuscated from the user-mode APIs used to manipulate the data inside the registry. Depending upon the version of Windows, there will be different files and different locations for these files, but they are all on the local machine. The location for system registry files in Windows NT is ; the user-specific HKEY_CURRENT_USER user registry hive is stored in inside the user profile. There is one of these per user; if a user has a roaming profile, then this file will be copied to and from a server at logout and login respectively. A second user-specific registry file named UsrClass.dat contains COM registry entries and does not roam by default.

Windows NT[edit]

Windows NT systems store the registry in a binary file format which can be exported, loaded and unloaded by the Registry Editor in these operating systems. The following system registry files are stored in :

• – HKEY_LOCAL_MACHINE\SAM
• – HKEY_LOCAL_MACHINE\SECURITY
• – HKEY_LOCAL_MACHINE\SOFTWARE
• – HKEY_LOCAL_MACHINE\SYSTEM
• – HKEY_USERS\.DEFAULT
• – Not associated with a hive. Used only when upgrading operating systems.^[14]

The following file is stored in each user's profile folder:

• – HKEY_USERS\<User SID> (linked to by HKEY_CURRENT_USER)

For Windows 2000, Server 2003 and Windows XP, the following additional user-specific file is used for file associations and COM information:

• (path is localized) – HKEY_USERS\<User SID>_Classes (HKEY_CURRENT_USER\Software\Classes)

For Windows Vista and later, the path was changed to:

• (path is not localized) alias – HKEY_USERS\<User SID>_Classes (HKEY_CURRENT_USER\Software\Classes)

Windows 2000 keeps an alternate copy of the registry hives (.ALT) and attempts to switch to it when corruption is detected.^[15] Windows XP and Windows Server 2003 do not maintain a hive because NTLDR on those versions of Windows can process the file to bring up to date a System hive that has become inconsistent during a shutdown or crash. In addition, the folder contains a copy of the system's registry hives that were created after installation and the first successful startup of Windows.

Each registry data file has an associated file with a ".log" extension that acts as a transaction log that is used to ensure that any interrupted updates can be completed upon next startup.^[16] Internally, Registry files are split into 4 kB "bins" that contain collections of "cells".^[16]

Windows 9x[edit]

The registry files are stored in the directory under the names and with the addition of in Windows ME. Also, each user profile (if profiles are enabled) has its own file which is located in the user's profile directory in .

Windows 3.11[edit]

The only registry file is called and it is stored in the directory.

Windows 10 Mobile[edit]

Note: To access the registry files, the Phone needs to be set in a special mode using either: 

If any of above Methods worked - The Device Registry Files can be found in the following location:

Note: InterOp Tools also includes a registry editor.

Editing[edit]

Registry editors[edit]

The registry contains important configuration information for the operating system, for installed applications as well as individual settings for each user and application. A careless change to the operating system configuration in the registry could cause irreversible damage, so it is usually only installer programs which perform changes to the registry database during installation/configuration and removal. If a user wants to edit the registry manually, Microsoft recommends that a backup of the registry be performed before the change.^[17] When a program is removed from control panel, it is not completely removed and the user must manually check inside directories such as program files. After this, the user needs to manually remove any reference to the uninstalled program in the registry. This is usually done by using RegEdit.exe.^[18] Editing the registry is sometimes necessary when working around Windows-specific issues e.g. problems when logging onto a domain can be resolved by editing the registry.^[19]

Windows Registry can be edited manually using programs such as RegEdit.exe, although these tools do not expose some of the registry's metadata such as the last modified date.

The registry editor for the 3.1/95 series of operating systems is RegEdit.exe and for Windows NT it is RegEdt32.exe; the functionalities are merged in Windows XP. Optional and/or third-party tools similar to RegEdit.exe are available for many Windows CE versions.

Registry Editor allows users to perform the following functions:

• Creating, manipulating, renaming^[20] and deleting registry keys, subkeys, values and value data
• Importing and exporting . files, exporting data in the binary hive format
• Loading, manipulating and unloading registry hive format files (Windows NT systems only)
• Setting permissions based on ACLs (Windows NT systems only)
• Bookmarking user-selected registry keys as Favorites
• Finding particular strings in key names, value names and value data
• Remotely editing the registry on another networked computer

. files[edit]

. files (also known as Registration entries) are text-based human-readable files for exporting and importing portions of the registry. On Windows 2000 and later, they contain the string Windows Registry Editor Version 5.00 at the beginning and are Unicode-based. On Windows 9x and NT 4.0 systems, they contain the string REGEDIT4 and are ANSI-based.^[21] Windows 9x format . files are compatible with Windows 2000 and later. The Registry Editor on Windows on these systems also supports exporting . files in Windows 9x/NT format. Data is stored in . files using the following syntax:^[21]

The Default Value of a key can be edited by using "@" instead of "Value Name":

String values do not require a <Value type> (see example), but backslashes ('\') need to be written as a double-backslash ('\\'), and quotes ('"') as backslash-quote ('\"').

For example, to add the values "Value A", "Value B", "Value C", "Value D", "Value E", "Value F", "Value G", "Value H", "Value I", "Value J", "Value K", "Value L", and "Value M" to the HKLM\SOFTWARE\Foobar key:

Data from . files can be added/merged with the registry by double-clicking these files or using the /s switch in the command line. files can also be used to remove registry data.

To remove a key (and all subkeys, values and data), the key name must be preceded by a minus sign ("-").^[21]

For example, to remove the HKLM\SOFTWARE\Foobar key (and all subkeys, values and data),

To remove a value (and its data), the values to be removed must have a minus sign ("-") after the equal sign ("=").^[21]

For example, to remove only the "Value A" and "Value B" values (and their data) from the HKLM\SOFTWARE\Foobar key:

To remove only the Default value of the key HKLM\SOFTWARE\Foobar (and its data):

Lines beginning with a semicolon are considered comments:

Group policies[edit]

Windows group policies can change registry keys for a number of machines or individual users based on policies. When a policy first takes effect for a machine or for an individual user of a machine, the registry settings specified as part of the policy are applied to the machine or user settings.

Windows will also look for updated policies and apply them periodically, typically every 90 minutes.^[22]

Through its scope a policy defines which machines and/or users the policy is to be applied to. Whether a machine or user is within the scope of a policy or not is defined by a set of rules which can filter on the location of the machine or user account in organizational directory, specific users or machine accounts or security groups. More advanced rules can be set up using Windows Management Instrumentation expressions. Such rules can filter on properties such as computer vendor name, CPU architecture, installed software, or networks connected to.

For instance, the administrator can create a policy with one set of registry settings for machines in the accounting department and policy with another (lock-down) set of registry settings for kiosk terminals in the visitors area. When a machine is moved from one scope to another (e.g. changing its name or moving it to another organizational unit), the correct policy is automatically applied. When a policy is changed it is automatically re-applied to all machines currently in its scope.

The policy is edited through a number of administrative templates which provides a user interface for picking and changing settings. The set of administrative templates is extensible and software packages which support such remote administration can register their own templates.

Command line editing[edit]

The registry can be manipulated in a number of ways from the command line. The and utility tools are included in Windows XP and later versions of Windows. Alternative locations for legacy versions of Windows include the Resource Kit CDs or the original Installation CD of Windows.

Also, a file can be imported from the command line with the following command:

The /s means the file will be silent merged to the registry. If the parameter is omitted the user will be asked to confirm the operation. In Windows 98, Windows 95 and at least some configurations of Windows XP the switch also causes to ignore the setting in the registry that allows administrators to disable it. When using the switch does not return an appropriate return code if the operation fails, unlike which does.

exports the whole registry in V5 format to a UNICODE file, while any of

export the specified (sub)key (which has to be enclosed in quotes if it contains spaces) only.

exports the whole registry in V4 format to an ANSI file.

exports the specified (sub)key (which has to be enclosed in quotes if it contains spaces) only.

It is also possible to use . Here is a sample to display the value of the registry value Version:

Other command line options include a VBScript or JScript together with CScript, WMI or and Windows PowerShell.

Registry permissions can be manipulated through the command line using and the tool. For example, the permissions on the HKEY_LOCAL_MACHINE\SOFTWARE key can be displayed using:

PowerShell commands and scripts[edit]

Using PowerShell to navigate the registry

Windows PowerShell comes with a registry provider which presents the registry as a location type similar to the file system. The same commands used to manipulate files/directories in the file system can be used to manipulate keys/values of the registry.

Also like the file system, PowerShell uses the concept of a current location which defines the context on which commands by default operate. The (also available through the alias or ) retrieves the child keys of the current location. By using the (or the alias ) command the user can change the current location to another key of the registry. Commands which rename items, remove items, create new items or set content of items or properties can be used to rename keys, remove keys or entire sub-trees or change values.

Through PowerShell scripts files a user/administrator can prepare scripts which, when executed, make changes to the registry. Such scripts can be distributed to users/administrators who can execute them on individual machines.

The PowerShell Registry provider supports transactions, i.e. multiple changes to the registry can be bundled into a single atomic transaction. An atomic transaction ensures that either all of the changes are committed to the database, or if the script fails, none of the changes are committed to the database.

Programs or scripts[edit]

The registry can be edited through the APIs of the Advanced Windows 32 Base API Library (advapi32.dll).^[23]

Many programming languages offer built-in runtime library functions or classes that wrap the underlying Windows APIs and thereby enable programs to store settings in the registry (e.g. in VB.NET and C#, or in Delphi and Free Pascal). COM-enabled applications like Visual Basic 6 can use the WSH object. Another way is to use the Windows Resource Kit Tool, by executing it from code,^[24] although this is considered poor programming practice.

Similarly, scripting languages such as Perl (with ), Python (with winreg), TCL (which comes bundled with the registry package),^[25]Windows Powershell and Windows Scripting Host also enable registry editing from scripts.

Offline editing[edit]

The offreg.dll^[26] available from the Windows Driver Kit offers a set of APIs for the creation and manipulation of currently not loaded registry hives similar to those provided by advapi32.dll.

It is also possible to edit the registry (hives) of an offline system from Windows PE or Linux (in the latter case using open source tools).

COM self-registration[edit]

Prior to the introduction of registration-free COM, developers were encouraged to add initialization code to in-process and out-of-process binaries to perform the registry configuration required for that object to work. For in-process binaries such as .DLL and .OCX files, the modules typically exported a function called DllInstall()^[27] that could be called by installation programs or invoked manually with utilities like Regsvr32.exe;^[28] out-of-process binaries typically support the commandline arguments /Regserver and /Unregserver that created or deleted the required registry settings.^[29] COM applications that break because of DLL Hell issues can commonly be repaired with RegSvr32.exe or the /RegServer switch without having to re-invoke installation programs.^[30]

Advanced functionality[edit]

Windows exposes APIs that allows user-mode applications to register to receive a notification event if a particular registry key is changed.^[31] APIs are also available to allow kernel-mode applications to filter and modify registry calls made by other applications.^[32]

Windows also supports remote access to the registry of another computer via the function^[33] if the Remote Registry service is running, correctly configured and its network traffic is not firewalled.^[34]

Security[edit]

Each key in the registry of Windows NT versions can have an associated security descriptor. The security descriptor contains an access control list (ACL) that describes which user groups or individual users are granted or denied access permissions. The set of registry permissions include 10 rights/permissions which can be explicitly allowed or denied to a user or a group of users.

As with other securable objects in the operating system, individual access control entries (ACE) on the security descriptor can be explicit or inherited from a parent object.^[35]

Windows Resource Protection is a feature of Windows Vista and later versions of Windows that uses security to deny Administrators and the system WRITE access to some sensitive keys to protect the integrity of the system from malware and accidental modification.^[36]

Special ACEs on the security descriptor can also implement mandatory integrity control for the registry key and subkeys. A process running at a lower integrity level cannot write, change or delete a registry key/value, even if the account of the process has otherwise been granted access through the ACL. For instance, Internet Explorer running in Protected Mode can read medium and low integrity registry keys/values of the currently logged on user, but it can only modify low integrity keys.^[37]

Outside security, registry keys cannot be deleted or edited due to other causes. Registry keys containing NUL characters cannot be deleted with standard registry editors and require a special utility for deletion, such as RegDelNull.^[38][39]

Backups and recovery[edit]

Different editions of Windows have supported a number of different methods to back up and restore the registry over the years, some of which are now deprecated:

• System Restore can back up the registry and restore it as long as Windows is bootable, or from the Windows Recovery Environment (starting with Windows Vista).
• NTBackup can back up the registry as part of the System State and restore it. Automated System Recovery in Windows XP can also restore the registry.
• On Windows NT, the Last Known Good Configuration option in startup menu relinks the key, which stores hardware and device driver information.
• Windows 98 and Windows ME include command line (Scanreg.exe) and GUI (Scanregw.exe) registry checker tools to check and fix the integrity of the registry, create up to five automatic regular backups by default and restore them manually or whenever corruption is detected.^[40] The registry checker tool backs up the registry, by default, to Scanreg.exe can also run from MS-DOS.^[41]
• The Windows 95 CD-ROM included an Emergency Recovery Utility (ERU.exe) and a Configuration Backup Tool (Cfgback.exe) to back up and restore the registry. Additionally Windows 95 backs up the registry to the files system.da0 and user.da0 on every successful boot.
• Windows NT 4.0 included , a utility to back up and restore the entire registry.^[42]
• Windows 2000 Resource Kit contained an unsupported pair of utilities called Regback.exe and RegRest.exe for backup and recovery of the registry.^[43]
• Periodic automatic backups of the registry are now disabled by default on Windows 10 May 2019 Update (version 1903). Microsoft recommends System Restore be used instead.^[44]

Policy[edit]

Group policy[edit]

Windows 2000 and later versions of Windows use Group Policy to enforce registry settings through a registry-specific client extension in the Group Policy processing engine.^[45] Policy may be applied locally to a single computer using , or to multiple users and/or computers in a domain using .

Legacy systems[edit]

With Windows 95, Windows 98, Windows ME and Windows NT 4.0, administrators can use a special file to be merged into the registry, called a policy file (). The policy file allows administrators to prevent non-administrator users from changing registry settings like, for instance, the security level of Internet Explorer and the desktop background wallpaper. The policy file is primarily used in a business with a large number of computers where the business needs to be protected from rogue or careless users.

The default extension for the policy file is . The policy file filters the settings it enforces by user and by group (a "group" is a defined set of users). To do that the policy file merges into the registry, preventing users from circumventing it by simply changing back the settings. The policy file is usually distributed through a LAN, but can be placed on the local computer.

The policy file is created by a free tool by Microsoft that goes by the filename for Windows 95/Windows 98 and with a computer management module for Windows NT. The editor requires administrative permissions to be run on systems that uses permissions. The editor can also directly change the current registry settings of the local computer and if the remote registry service is installed and started on another computer it can also change the registry on that computer. The policy editor loads the settings it can change from files, of which one is included, that contains the settings the Windows shell provides. The file is plain text and supports easy localisation by allowing all the strings to be stored in one place.

Virtualization[edit]

INI file virtualization[edit]

Windows NT kernels support redirection of INI file-related APIs into a virtual file in a registry location such as HKEY_CURRENT_USER using a feature called "InifileMapping".^[46] This functionality was introduced to allow legacy applications written for 16-bit versions of Windows to be able to run under Windows NT platforms on which the System folder is no longer considered an appropriate location for user-specific data or configuration. Non-compliant 32-bit applications can also be redirected in this manner, even though the feature was originally intended for 16-bit applications.

Registry virtualization[edit]

Windows Vista introduced limited registry virtualization, whereby poorly written applications that do not respect the principle of least privilege and instead try to write user data to a read-only system location (such as the HKEY_LOCAL_MACHINE hive), are silently redirected to a more appropriate location, without changing the application itself.

Similarly, application virtualization redirects all of an application's invalid registry operations to a location such as a file. Used together with file virtualization, this allows applications to run on a machine without being installed on it.

Low integrity processes may also use registry virtualization. For example, Internet Explorer 7 or 8 running in "Protected Mode" on Windows Vista and above will automatically redirect registry writes by ActiveX controls to a sandboxed location in order to frustrate some classes of security exploits.

The Application Compatibility Toolkit^[47] provides shims that can transparently redirect HKEY_LOCAL_MACHINE or HKEY_CLASSES_ROOT Registry operations to HKEY_CURRENT_USER to address "LUA" bugs that cause applications not to work for users with insufficient rights.

Disadvantages[edit]

Critics labeled the registry in Windows 95 a single point of failure, because re-installation of the operating system was required if the registry became corrupt.^{[citation needed]} However, Windows NT uses transaction logs to protect against corruption during updates. Current versions of Windows use two levels of log files to ensure integrity even in the case of power failure or similar catastrophic events during database updates.^[48] Even in the case of a non-recoverable error, Windows can repair or re-initialize damaged registry entries during system boot.^[48]

Equivalents and alternatives[edit]

In Windows, use of the registry for storing program data is a matter of developer's discretion. Microsoft provides programming interfaces for storing data in XML files (via MSXML) or database files (via SQL Server Compact) which developers can use instead. Developers are also free to use non-Microsoft alternatives or develop their own proprietary data stores.

In contrast to Windows Registry's binary-based database model, some other operating systems use separate plain-text files for daemon and application configuration, but group these configurations together for ease of management.

• In Unix-like operating systems (including Linux) that follow the Filesystem Hierarchy Standard, system-wide configuration files (information similar to what would appear in HKEY_LOCAL_MACHINE on Windows) are traditionally stored in files in and its subdirectories, or sometimes in . Per-user information (information that would be roughly equivalent to that in HKEY_CURRENT_USER) is stored in hidden directories and files (that start with a period/full stop) within the user's home directory. However XDG-compliant applications should refer to the environment variables defined in the Base Directory specification.^[49]
• In macOS, system-wide configuration files are typically stored in the folder, whereas per-user configuration files are stored in the corresponding folder in the user's home directory, and configuration files set by the system are in . Within these respective directories, an application typically stores a property list file in the sub-directory.
• RISC OS (not to be confused with MIPS RISC/os) uses directories for configuration data, which allows applications to be copied into application directories, as opposed to the separate installation process that typifies Windows applications; this approach is also used on the ROX Desktop for Linux.^[50] This directory-based configuration also makes it possible to use different versions of the same application, since the configuration is done "on the fly".^[51] If one wishes to remove the application, it is possible to simply delete the folder belonging to the application.^[52][53] This will often not remove configuration settings which are stored independently from the application, usually within the computer's !Boot structure, in !Boot.Choices or potentially anywhere on a network fileserver. It is possible to copy installed programs between computers running RISC OS by copying the application directories belonging to the programs, however some programs may require re-installing, e.g. when shared files are placed outside an application directory.^[51]
• IBM AIX (a Unix variant) uses a registry component called Object Data Manager (ODM). The ODM is used to store information about system and device configuration. An extensive set of tools and utilities provides users with means of extending, checking, correcting the ODM database. The ODM stores its information in several files, default location is /etc/objrepos.
• The GNOME desktop environment uses a registry-like interface called dconf for storing configuration settings for the desktop and applications.
• The Elektra Initiative provides alternative back-ends for various different text configuration files.
• While not an operating system, the Winecompatibility layer, which allows Windows software to run on a Unix-like system, also employs a Windows-like registry as text files in the WINEPREFIX folder: system.reg (HKEY_LOCAL_MACHINE), user.reg (HKEY_CURRENT_USER) and userdef.reg.

18 Sep 2020 » Podman Posts of Interest

I’ve run across a number of posts over the past few weeks concerning Podman and have been busy getting other work done. So now I have a few moments and thought I’d add some links to the posts. Enjoy!

02 Sep 2020 » Podman remote clients for macOS and Windows

In a recent blog post on the Red Hat Enable Sysadmin site, Podman remote clients for macOS and Windows, Brent Baude and Ashley Cui walk you through setting up a remote client on either Windows or macOS to let you manage your containers and images on your Linux backend. The post covers installation, ssh setup, creating the initial connection and finally how to use the client. Give it a quick look!

31 Aug 2020 » The podman play kube command now supports deployments

In a recent blog post on the Red Hat Enable Sysadmin site, The podman play kube command now supports deployments, you can now learn all about the recent features added to Podman to interact with Kubernetes objects. The command allows you to export your existing containers into Kubernetes Pod YAML. This YAML can then be imported into OpenShift or a Kubernetes cluster. The does the opposite, it allows you to take a Kubernetes YAML and run it in Podman. Learn all of the details and more in the blog post!

24 Aug 2020 » Tick-tock. Does your container know what time it is?

Ashley Cui recently joined our team at Red Hat and just wrote her first ever blog post that is now on the Red Hat Enable Sysadmin site Tick-tock. Does your container know what time it is?. In this timely post, Ashley walks you through setting the timezone within a container using the option. Just prior to this posting, I had answered a very similar question for someone. This is a really good and quick blog, and I’m sure the first of many for Ashley.

21 Aug 2020 » Container video series: Rootless containers, process separation, and OpenSCAP

Do you want to know more about Rootless containers, process separation, and OpenSCAP? If you’re like many, a video is a better learning device than a blog post. Well you’re in luck, Brian Smith just landed a blog post on the Red Hat Enable Sysadmin site Container video series: Rootless containers, process separation, and OpenSCAP with a number of blog posts on the subject, many featuring Podman.

13 Aug 2020 » Learning Red Hat's Podman (docker), Buildah, Skopeo and Quay.io

Four engineers at IBM and Red Hat, JJ Asghar, Brian Tannous, Jason Dobies and Cedric Clyburn spent some time in a stream learning about Podman, Buildah, Skopeo from the ground up in this video blog post. Check out the video to get a great introduction to the tools.

11 Aug 2020 » Moving from docker-compose to Podman pods

Nathan Lager just landed a blog post on the Red Hat Enable Sysadmin site Moving from docker-compose to Podman pods. In the post, Nathan talks about ins and outs of the migration process.

10 Aug 2020 » Podman Go bindings

In the release of Podman 2.0, we removed the experimental tag from its recently introduced RESTful service. While it might be interesting to interact with a RESTful server using curl, using a set of Go based bindings is probably a more direct route to a production ready application. More details from Lokesh Mandvekar and Parker Van Roy in this post.

02 Aug 2020 » Improved systemd integration with Podman 2.0

Valentin Rothberg just landed a blog post on the Red Hat Enable Sysadmin site Improved systemd integration with Podman 2.0. In the post, Valentin talks about how systemd in Podman v2.0 is even more tightly integrated than it was in prior versions.

01 Aug 2020 » Podman API v1.0 Deprecation and Removal Notice

A Podman API v1.0 Deprecation and Removal Notice has just been posted. The Podman v1.0 API based on the varlink library has been deprecated and will soon be removed from Podman in favor of the new Podmand v2.0 RESTful API. Please see the notice for more details.

18 Jul 2020 » Speed up container builds with overlay mounts

Dan Walsh has another blog post on the Red Hat Enable Sysadmin site this time he’s writing on how to Speed up container builds with overlay mounts. In the article Dan walks you through speeding up builds for multiple distributions by sharing the host’s metadata.

17 Jul 2020 » Exploring additional image stores in Podman

Dan Walsh has another blog post on the Red Hat Enable Sysadmin site this time he’s writing about Exploring additional image stores in Podman. In the article Dan shows you how to store container images on shares, permitting the images to be accessed over the network.

16 Jul 2020 » Building images using Podman and cron

Tom Sweeney has another blog post on the Red Hat Enable Sysadmin site this time he’s writing about Building images using Podman and cron. In the article Tom talks about how necessity became the mother of invention and cron was put into use to build container images on a regular schedule.

07 Jul 2020 » The Podman repository has been renamed

The GitHub repository for the Podman project has been moved from github.com/containers/libpod to github.com/containers/podman. More details from Matt Heon in this blog post.

01 Jul 2020 » Podman REST API and Docker compatibility

Matt Heon talks about the compatibility of the new Podman REST API and Docker’s API is this blog post.

29 Jun 2020 » Announcing Podman v2.0

Announcing Podman v2.0!

Podman v2.0 is here! Brent Baude talks about the major highlights of the new release, including the new RESTful API, remote client improvements, Auto-update functionality and systemd integration improvements. More details in the announcement post.

13 May 2020 » Update on Podman v2

The local Podman v2 client is complete. It is passing all of its rootfull and rootless system and integration tests.

The CI/CID tests have been re-enabled upstream and are run with each pull request submission. We are now hard at work finishing up some of the core podman-remote functions. Once those functions are complete, we can then begin to run our podman-remote system and integration tests to catch any regressions.

More details in the announcement post.

06 May 2020 » Podman installation documentation in French

Est-ce que tu parles français? Le mien est horrible. But if your abilities to read and speak French is better than mine, check out this website that I was just pointed to. Installation podman sur CentOS 8 by Bilal Kalem shows you how to install Podman on Centos 8. If nothing else, check out the graphic at the top of the page!

17 Apr 2020 » Podman v1.9.0 Released

Podman has gone 1.9.0!

16 Apr 2020 » Podman v2 development update

Podman v2.x is under development and due to the development, some of the upstream commands may become unstable for a period of time until the final release is completed. More details in the announcement post.

14 Apr 2020 » Dockerless: Build and Run Containers with Podman and Systemd

In this video, Kirill Shirinkin will show how to use Podman to build container images and run Java applications in containers with Systemd. We are going to learn why we should at least try alternatives to Docker, how container runtime landscape changed and how Podman is different and in certain ways better than Docker. Watch now.

05 Apr 2020 » Managing Podman pods with pods-compose

Managing Podman pods with pods-compose makes your move to Podman easier. Balázs Németh already converted his docker-compose services to pods with Podman, however some features were missing, up until now. Let’s meet pods-compose.

04 Apr 2020 » Convert docker-compose services to pods with Podman

How to deploy pods with Podman when you only need a single-host system and not a complete Kubernetes. Check the blog post Convert your docker-compose services to pods with Podman by Balázs Németh to see how it can be done.

31 Mar 2020 » Pulling podman images from a container repository

Tom Sweeney has another blog post on the Red Hat Enable Sysadmin site this time he’s writing about Pulling podman images from a container repository. Learn the different varieties of pull that the command can use to speed up or further secure your environment in this post.

03 Mar 2020 » What happens behind the scenes of a rootless Podman container?

Dan Walsh along with Matt Heon have a blog post on the Red Hat Enable Sysadmin site, What happens behind the scenes of a rootless Podman container?. If you ever wanted to know what happens under the covers of a rootless container, this is the article for you!

02 Mar 2020 » Building Container Images with Podman and Buildah

We were just pointed to this post Building Container Images with Podman and Buildah by Puja Abbassi on the Giant Swarm site. In the article Puja goes over how Podman and Buildah handle daemonless and rootless building processes. A tardy link on this site, but worth a read!

07 Feb 2020 » 6 guides on making containers secure

Dan Walsh has another blog post on the Red Hat Enable Sysadmin site this time he’s writing about 6 guides on making containers secure. It’s a quick article with pointers to other blog posts showing how to secure your containers.

06 Feb 2020 » Deploy a Pod on CentOS with Podman

Jack Wallen has a blog post on the THENEWSTACK site with a great introduction on how to Deploy a Pod on CentOS with Podman. In the post, Jack talks about how Podman fits in the Red Hat ecosystem and then walks you through the fundamentals of creating and running a pod using Podman.

30 Jan 2020 » How to run Podman on Windows with WSL2

Brent Baude has another blog post on the Red Hat Enable Sysadmin site this time it’s all about How to run Podman on Windows with WSL2. If you want to know how to run Podman on Windows 10, this article will show you how.

22 Jan 2020 » Blog posts from the Web

A number of blog posts were posted over the past month and given the holiday crunch, we didn’t get them listed on the site. So as a catch up, checkout the Blog posts on the Web blog which has a number of links on it to those great articles and videos.

17 Jan 2020 » New API coming for Podman

The new API for Podman, referred to as apiv2, has been merged into the libpod repository. It’s a simpler REST API that’s more compatible with Docker implementations than the varlink protocol that’s currently in use. For more details, see this release announcement by Brent Baude.

15 Jan 2020 » Bioinformatics and rootless containers with Podman

Bryan Hepworth demonstrating how to create a rootless container image for a Bioinformatics program here.

17 Dec 2019 » Running containers with Podman and shareable systemd services

Podman version 1.7 is coming out soon and will include new features that will make management of containers with systemd services even easier. Valentin Rothberg has a blog post on the Red Hat Enable Sysadmin site that previews the features: Running containers with Podman and shareable systemd services. In the post Valentin goes over the highlights and then gives a great working example.

14 Dec 2019 » Working with Linux containers on RHEL 8 with Podman, image builder and web console

Do you want to know how to setup RHEL 8 to run containers using Podman? Xuegang Jin has a blog post on the Red Hat Blog about this very subject, Working with Linux containers on RHEL 8 with Podman, image builder and web console. In the post Xuegang shows you how you can use Image Builder to create an OS image, how to run containers with Podman, and how to check the host and containers performance using Web Console.

11 Dec 2019 » Understanding root inside and outside a container

Do you run containers as root, or as a regular user? Scott McCarty has a blog post on the Red Hat Blog about this very subject, Understanding root inside and outside a container. In the post Scott walks you through what a rootless container does and how it can be a safer alternative to a container run by root.

26 Nov 2019 » Rootless Podman and NFS

Dan Walsh has another blog post on the Red Hat Enable Sysadmin site this time about Rootless Podman and NFS. In the post Dan talks about how you can make some minor configuration changes to allow Podman to use a user’s home directory on an NFS share. Give it a read!

20 Nov 2019 » How To Install Podman on Debian

Josphat Mutai posted a blog post on the Computing for Geeks site talking about How To Install Podman on Debian. In the post Josphat walks through all the steps necessary from ‘A’ to ‘Z’ to get Podman up and running on Debian and how to do some initial Podman commands.

13 Nov 2019 » Leasing routable IP addresses with Podman containers

Brent Baude has another blog post on the Red Hat Enable Sysadmin site this time about Leasing routable IP addresses with Podman containers. In the post Brent talks about using the macvlan and the dhcp plugins that ship with the container-networking project in order to lease ip addresses for your containers.

12 Nov 2019 » Fedora 31 and Control Group v2

Dan Walsh has another blog post on the Red Hat Enable Sysadmin site this time about Fedora 31 and Control Group v2. In the post Dan talks about the new version of control groups that is part of the Fedora 31 release and how it makes containers even more secure.

08 Nov 2019 » Building freely distributed containers with open tools

Scott McCarty (@fatherlinux) has an amazing video on YouTube about Building freely distributed containers with open tools. As only Scott could say “Although explaining how to ride a Tron-style light cycle is beyond the scope of this tutorial, we will discuss something almost as exhilarating—building containers with #Podman and #RedHat Universal Base Image (UBI). We will cover how to build and run #containers based on #UBI using just your regular user account—no daemon, no root (rootless), no fuss. Finally, we will order the deresolution of all of our containers with a really cool command. You probably won’t be promoted to CEO of ENCOM after this talk, but you will have new tools in your toolbelt for how to find, run, build, and share container images.”

07 Nov 2019 » Basic security principles for containers and container runtimes

has another blog post on the Red Hat Enable Sysadmin site this time about Basic security principles for containers and container runtimes. In the post Brent talks about the three core security themes concerning containers and why user privileges matter in the space.

05 Nov 2019 » Migrating from Docker to Podman

Elliott Sales de Andrade’s post on Quantum Logic, Migrating from Docker to Podman takes a look at his migration from Docker to Podman and a good assessment of where the Podman tool stands in comparison to Docker.

31 Oct 2019 » The current adoption status of cgroup v2 in containers

In case you missed Akihiro Suda’s post on Medium.com, The current adoption status of cgroup v2 in containers, here’s a quick link to it. In the article Akihiro talks all things cgroup v2 and what changes it promises to bring to the world of containers, and Podman is at the forefront of that change.

29 Oct 2019 » First Look: Rootless Containers and cgroup v2 on Fedora 31

Want to allow your users without privileges to run a container securerly on your host? Then this post: First Look: Rootless Containers and cgroup v2 on Fedora 31 will show you how. It’s quick, it’s easy, it’s secure and it won’t even cost $19.99!

28 Oct 2019 » Podman and NFS

Adrian Reber wrote up a quick post on “Podman and NFS” here. In the article Adrian shows how he extended his HPC environment to us a shared NFS home directory.

23 Oct 2019 » PMM Server + podman: Running a Container Without root Privileges

Ceri Williams talks about how the Percona Monitoring and Management (PMM) can be run in a container using Podman without root privileges here. In the post Ceri talks about how Percona was able to replace Docker with Podman and Buildah and are able to run containers more securely by doing so.

15 Oct 2019 » Generate SECCOMP Profiles for Containers Using Podman and eBPF

Valentin Rothberg checks in with the “Generate SECCOMP Profiles for Containers Using Podman and eBPF” blog here. In the article Valentin introduces the OCI seccomp hook which allows you to trace the syscalls of a container and then runs through a working example.

14 Oct 2019 » Here’s why podman is more secured than Docker – DevSecOps

Ganesh Mani discusses why Podman is more secure than Docker here on the CLOUDNWEB site. Ganesh talks about why Podman’s fork and execute model is more secure than Docker’s client server model.

14 Oct 2019 » Say “Hello” to Buildah, Podman, and Skopeo

Saharsh Singh talks about how he’s moved on from his Docker daemon and moved on to Podman, Buildah and Skopeo here on the Red Hat Service Blog site. Saharsh walks you through a history of container tools and then talks about Podman, Buildah and Skopeo with a lot of great examples.

02 Oct 2019 » Configuring container networking with Podman

has a blog post on the Red Hat Enable Sysadmin site about Configuring container networking with Podman. In the post Brent goes over how you can communicate between a container and the host, between containers in and out of a pod, while running as a root and as a non-root user.

25 Sep 2019 » Podman in HPC environments

Adrian Reber talks all about the Message Passing Interface (MPI) in a High-Performance Computing (HPC) environment with the help of Podman here. Adrian provides a nice walk through of how he accomplished this and then explains each of his steps in great detail.

11 Sep 2019 » Why can’t rootless Podman pull my image?

Matt Heon has a blog post on the Red Hat Enable Sysadmin site about Why can’t rootless Podman pull my image?. In the blog Matt discusses why restrictions on rootless containers can be inconvenient, but why they’re necessary. In the blog Matt covers the use of user namespace and the allocations of uid and gid’s that are required to make rootless containers work securely in your environment.

28 Aug 2019 » Best practices for running Buildah in a container

Dan Walsh has recently posted a blog on the Red Hat Developer Blog, Best practices for running Buildah in a container. The post walks you through the balancing act of running a container securely using Podman while keeping an eye on performance. A big boost to the performance side of things is the concept of “Additional Stores”. Dan walks you through the use of those in this blog and then wraps it all up with an on-line video at the end.

23 Aug 2019 » Podman, contenedores sin Docker

How’s your espanol? If it’s good, checkout this video blog on YouTube Podman, contenedores sin Docker! In it Iñigo Serrano shows how to run Wildfly in a Podman container without Docker.

22 Aug 2019 » Using the rootless containers Tech Preview in RHEL 8.0

Scott McCarty has a blog post on the Red Hat Blog about Using the rootless containers Tech Preview in RHEL 8.0. Podman rootless containers has hit Tech Preview for RHEL 8.0 and Scott walks you through the setup necessary for rootless containers. Small hint, it’s a short post because it’s just that easy.

14 Aug 2019 » Podman v1.5.0 Released

Podman has gone 1.5.0!

10 Aug 2019 » How templating works with Podman, Kubernetes, and Red Hat OpenShift

Olaph Wagner has put together a nice introduction on How templating works with Podman, Kubernetes, and Red Hat OpenShift on the IBM Developer blog site. If you want to find out how to use Podman to create images that helps Red Hat OpenShift to make templates on the IBM Cloud(TM), then this is the article for you!

08 Aug 2019 » Command Highlight: podman images

A quick asciinema demo highlighting what the command can do. A great way to get quickly immersed with this command in just a few minutes time. Checkout the demo here and if you want to run the script yourself, it can be found here.

29 Jul 2019 » Podman: Linux containers made easy, part 3

It’s in German again, but a worthy read Podman: Linux containers made easy, part 3. Valentin Rothberg (@vrothberg) introduces Podman to the reader and talks about how it fits in the container eco-system. If your German is a little rusty, you may need to lean on Google Translate.

06 Jul 2019 » How Podman replaces Docker and Docker Compose for local development

Is it possible to completely replace Docker with Podman without any loss of developer’s productivity? Read about real use case in new article on mkdev.me blog: Dockerless, part 3: Moving development environment to containers with Podman.

26 Jun 2019 » Replacing Docker with Podman

Ganesh Mani recently wrote the blog Replacing Docker with Podman — Power of Podman — Cloudnweb. The article gives a nice overview of Docker, Podman, their differences, and how you can use Podman to replace Docker. A nice read and really, who doesn’t love a blog that wraps up with a meme featuring The Rock?

19 Jun 2019 » OnDemand Course: Container pipelines for sys admins—and anyone, really—with Buildah and Podman

Red Hat has recently posted an OnDemand course: Container pipelines for sys admins—and anyone, really—with Buildah and Podman. The session teaches you how to integrate both Podman and Buildah into your continuous delivery (CI/CD) solutions and also serves as a good introduction to both tools. The cost can’t be beat (free!), so if you’re looking for a quick introduction into the tools, this is a good way to go.

17 Jun 2019 » Announcing the Podman Mailing List!

We’ve received a number of requests for a mailing list for Podman and we’re happy to announce that one has just been created! We’ve built a friendly community on IRC and GitHub and plan to continue that growth in this new mailing list. The maintainers of the project are all members of the list and we’re happy to take any and all questions there about Podman. You can also just use the list as a way to track what’s going on with Podman as release announcements and other important news will be posted there.

Get all the details on this blog post!

13 Jun 2019 » Podman Cheat Sheet

Red Hat Developer recently posted a new Podman Cheat Sheet on their blog. It’s a handy guide that cover the commands that focus on images, containers and container resources. Check it out!

14 Dec 2018 » New Blog from Emilien Macchi, Part 4!

Emilien Macchi has posted a fourth blog on how his group is running Healthchecks for Podman containers: “OpenStack Containerization with Podman – Part 4 (Healthchecks)”. Check it out!

10 Sep 2018 » What's NEW!

If you’ve missed the news so far, CoreOS was acquired by Red Hat at the beginning of 2018. This also means some changes for Buildah and Podman.

Buildah and Podman were previously projects within Project Atomic which is going to be sunset in favor of an immutable host combination of Container Linux and Fedora Atomic Host: this combination is called Fedora CoreOS. We therefore welcome you to the new websites, buildah.io and podman.io where you will find news, announcements, and more around the respective projects.

To start it up, check out the new Blogs and Releases sections on the site.