Windows PowerShell has been proven to be a strong automation tool that has various usages for IT professionals as well as developers; that is why you might hear different answers for this question: What is Windows PowerShell? One of the answers is "it is a scripting language"; other answers are, "it is a command-line interface", "it is an automation tool", and others. The good news is that there is no wrong definition for Windows PowerShell; each person defines it according to his own use of it. So the optimum and widest definition for Windows PowerShell is that it is an automation engine that provides a task-based command-line interface, a dynamic scripting environment, an interactive shell engine, and much more. All of these are bundled together in one component and shipped with the Windows operating system in order to provide a common automation platform for Microsoft technologies, alongside interoperability and integration with various technologies from different vendors.
Windows PowerShell is also available as part of Windows Management Framework (WMF). The WMF is a package that includes updates and enhancements to different management technologies such as PowerShell, Windows Remote Management (WinRM), and Windows Management Instrumentation (WMI). The WMF allows to use the latest management technologies on older operating systems. For example, WMF 4.0 allows you to use Windows PowerShell 4.0 on Windows Server 2008 R2 with SP1 or Windows 7 with SP1.
Windows PowerShell has been built on top of .NET framework, Common Language Runtime (CLR), and Dynamic Language Runtime (DLR). This architecture made it a powerful, dynamic, consistent, and extensible shell. Also it made PowerShell an object-based (object-oriented) shell where everything is produced as an object (.NET object) unlike other shells that deal with everything as raw text. Using the .NET framework makes the Windows PowerShell syntax almost like C# except for some differences in specific areas. Also, it made it easy to deal with other technologies such as Component Object Model (COM), Windows Management Instrumentation (WMI), and Extensible Markup Language (XML).
Moreover, it is possible to compile C# code inside PowerShell and execute PowerShell code as part of the code managed by .NET. Last but not least, PowerShell is shipped with its own Application Programming Interface (API) to give you the capability to build customized PowerShell commands and extensions for your own developed applications.
Windows PowerShell became part of Microsoft's Common Engineering Criteria (CEC) program in 2009. In case you don't know what the Microsoft CEC is, it is a program started in 2005 to define, unify, and standardize a set of engineering requirements across all Microsoft server products; some of these requirements are related to security, automation, and manageability. In other words, starting with 2005, each Microsoft server product must follow and pass these requirements before being released to the end users. In our case, starting with 2009, each and every server products must provide a management interface via Windows PowerShell. Today, almost all Microsoft server products support Windows PowerShell.
In Windows PowerShell, we refer to commands as cmdlets (pronounced "command-lets") where each cmdlet represent a function or task-based script. The cmdlets can be used individually for simple tasks or together in combination to perform more complex tasks. A cmdlet has a consistent naming style known as verb-noun, where each cmdlet has a verb and a noun separated by a dash (-) symbol, for example, Get-Service, Restart-Computer, and Add-User. This naming style makes the cmdlets' names easier to remember and even to guess and expect the new cmdlets. Windows Server 2012 is shipped with more than 2,400 cmdlets covering most of Windows Server roles and features.