Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

SQL Server PowerShell Provider


The SQL Server provider for Windows PowerShell exposes the hierarchy of SQL Server objects in paths similar to file system paths. You can use the paths to locate an object, and then use methods from the SQL Server Management Object (SMO) models to perform actions on the objects.

The paths implemented by the SQL Server provider enable easily and interactively reviewing all of the objects in an instance of SQL Server. You can navigate the paths using Windows PowerShell aliases similar to the commands you typically use to navigate file system paths.

Products whose data or object models can be represented in a hierarchy use Windows PowerShell providers to expose the hierarchies. The hierarchy is exposed by using a drive and path structure similar to what the Windows file system uses.

Each Windows PowerShell provider implements one or more drives. Each drive is the root node of a hierarchy of related objects. The SQL Server provider implements a SQLSERVER: drive. The provider also defines a set of primary folders for the SQLSERVER: drive. Each folder and its subfolders represent the set of objects that can be accessed by using a SQL Server management object model. When you are focused on a subfolder in a path that starts with one of these primary folders, you can use the methods from the associated object model to perform actions on the object that is represented by the node. The Windows PowerShell folders implemented by the SQL Server 2016 provider are listed in the following table.


SQL Server object model namespace







Database objects, such as tables, views, and stored procedures.




Policy-based management objects, such as policies and facets.




Registered server objects, such as server groups and registered servers.



Utility objects, such as managed instances of the Database Engine.



Data-tier application objects such as DAC packages, and operations such as deploying a DAC.



Data collector objects, such as collection sets and configuration stores.



Integration Services objects such as projects, packages, and environments.



Analysis Services objects such as cubes, aggregations, and dimensions.

For example, you can use the SQLSERVER:\SQL folder to start paths that can represent any object that is supported by the SMO object model. The leading part of a SQLSERVER:\SQL path is SQLSERVER:\SQL\ComputerName\InstanceName. The nodes after the instance name alternate between object collections (such as Databases or Views) and object names (such as AdventureWorks2012). Schemas are not represented as object classes. When you specify the node for a top-level object in a schema, such as a table or view, you must specify the object name in the format SchemaName.ObjectName.

This is the path of the Vendor table in the Purchasing schema of the AdventureWorks2012 database in a default instance of the Database Engine on the local computer:


For more information about the SMO object model hierarchy, see SMO Object Model Diagram.

Collection nodes in a path are associated with a collection class in the associated object model. Object name nodes are associated with an object class in the associated object model, as in the following table.


SMO class





Task Description


Describes how to use Windows PowerShell cmdlets to navigate through the nodes in a path, and at each node get a list of the objects at that node.

Navigate SQL Server PowerShell Paths

Describes how to use the SMO methods and properties to report on and perform work on the object represented by a node in a path. Also describes how to get a list of the SMO methods and properties for that node.

Work With SQL Server PowerShell Paths

Describes how to convert a SMO Uniform Resource Name (URN) to a SQL Server provider path.

Convert URNs to SQL Server Provider Paths

Describes how to open SQL Server Authentication connections by using the SQL Server provider. By default, the provider uses Windows Authentication connections made using the credentials of the Windows account running the Windows PowerShell session.

Manage Authentication in Database Engine PowerShell

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

© 2015 Microsoft