Fix heading levels: samples directory

reference/docs-conceptual/samples/Changing-Computer-State.md

@@ -8,7 +8,7 @@ ms.assetid:  8093268b-27f8-4a49-8871-142c5cc33f01
 
 To reset a computer in Windows PowerShell, use either a standard command-line tool or a WMI class. Although you are using Windows PowerShell only to run the tool, learning how to change a computer's power state in Windows PowerShell illustrates some of the important details about working with external tools in Windows PowerShell.
 
-### Locking a Computer
+## Locking a Computer
 
 The only way to lock a computer directly with the standard available tools is to call the **LockWorkstation()** function in **user32.dll**:
 
@@ -22,7 +22,7 @@ When you lock a workstation while Fast User Switching is enabled, such as on Win
 
 To shut down particular sessions on a Terminal Server, use the **tsshutdn.exe** command-line tool.
 
-### Logging Off the Current Session
+## Logging Off the Current Session
 
 You can use several different techniques to log off of a session on the local system. The simplest way is to use the Remote Desktop/Terminal Services command-line tool, **logoff.exe** (For details, at the Windows PowerShell prompt, type **logoff /?**). To log off the current active session, type **logoff** with no arguments.
 
@@ -40,7 +40,7 @@ A third option is to use WMI. The Win32_OperatingSystem class has a Win32Shutdow
 
 For more information, and to find other features of the Win32Shutdown method, see "Win32Shutdown Method of the Win32_OperatingSystem Class" in MSDN.
 
-### Shutting Down or Restarting a Computer
+## Shutting Down or Restarting a Computer
 
 Shutting down and restarting computers are generally the same types of task. Tools that shut down a computer will generally restart it as well—and vice versa. There are two straightforward options for restarting a computer from Windows PowerShell. Use either Tsshutdn.exe or Shutdown.exe with appropriate arguments. You can get detailed usage information from **tsshutdn.exe /?** or **shutdown.exe /?**.
 

reference/docs-conceptual/samples/Collecting-Information-About-Computers.md

@@ -16,7 +16,7 @@ We specify the **ComputerName** parameter with the dot value (**.**), which repr
 You can specify a name or IP address associated with any computer you can reach through WMI.
 To retrieve information about the local computer, you could omit the **ComputerName** parameter.
 
-### Listing Desktop Settings
+## Listing Desktop Settings
 
 We'll begin with a command that collects information about the desktops on the local computer.
 
@@ -38,15 +38,15 @@ Get-CimInstance -ClassName Win32_Desktop -ComputerName . | Select-Object -Exclud
 
 To filter out the metadata, use a pipeline operator (|) to send the results of the `Get-CimInstance` command to `Select-Object -ExcludeProperty "CIM*"`.
 
-### Listing BIOS Information
+## Listing BIOS Information
 
 The WMI **Win32_BIOS** class returns fairly compact and complete information about the system BIOS on the local computer:
 
 ```powershell
 Get-CimInstance -ClassName Win32_BIOS -ComputerName .
 ```
 
-### Listing Processor Information
+## Listing Processor Information
 
 You can retrieve general processor information by using WMI's **Win32_Processor** class, although you will likely want to filter the information:
 
@@ -64,7 +64,7 @@ SystemType
 X86-based PC
 ```
 
-### Listing Computer Manufacturer and Model
+## Listing Computer Manufacturer and Model
 
 Computer model information is also available from **Win32_ComputerSystem**.
 The standard displayed output will not need any filtering to provide OEM data:
@@ -82,7 +82,7 @@ MyPC Jane Doe         WORKGROUP 804765696           DA243A-ABA 6415cl NA910 Comp
 Your output from commands such as this, which return information directly from some hardware, is only as good as the data you have.
 Some information is not correctly configured by hardware manufacturers and may therefore be unavailable.
 
-### Listing Installed Hotfixes
+## Listing Installed Hotfixes
 
 You can list all installed hotfixes by using **Win32_QuickFixEngineering**:
 
@@ -137,7 +137,7 @@ HotFixId
 KB4048951
 ```
 
-### Listing Operating System Version Information
+## Listing Operating System Version Information
 
 The **Win32_OperatingSystem** class properties include version and service pack information.
 You can explicitly select only these properties to get a version information summary from **Win32_OperatingSystem**:
@@ -161,7 +161,7 @@ ServicePackMajorVersion : 0
 ServicePackMinorVersion : 0
 ```
 
-### Listing Local Users and Owner
+## Listing Local Users and Owner
 
 Local general user information — number of licensed users, current number of users, and owner name — can be found with a selection of **Win32_OperatingSystem** class' properties.
 You can explicitly select the properties to display like this:
@@ -176,7 +176,7 @@ A more succinct version using wildcards is:
 Get-CimInstance -ClassName Win32_OperatingSystem -ComputerName . | Select-Object -Property *user*
 ```
 
-### Getting Available Disk Space
+## Getting Available Disk Space
 
 To see the disk space and free space for local drives, you can use the Win32_LogicalDisk WMI class.
 You need to see only instances with a DriveType of 3 — the value WMI uses for fixed hard disks.
@@ -197,15 +197,15 @@ FreeSpace 109839607808
 Size      326846914560
 ```
 
-### Getting Logon Session Information
+## Getting Logon Session Information
 
 You can get general information about logon sessions associated with users through the **Win32_LogonSession** WMI class:
 
 ```powershell
 Get-CimInstance -ClassName Win32_LogonSession -ComputerName .
 ```
 
-### Getting the User Logged on to a Computer
+## Getting the User Logged on to a Computer
 
 You can display the user logged on to a particular computer system using Win32_ComputerSystem.
 This command returns only the user logged on to the system desktop:
@@ -214,7 +214,7 @@ This command returns only the user logged on to the system desktop:
 Get-CimInstance -ClassName Win32_ComputerSystem -Property UserName -ComputerName .
 ```
 
-### Getting Local Time from a Computer
+## Getting Local Time from a Computer
 
 You can retrieve the current local time on a specific computer by using the **Win32_LocalTime** WMI class.
 
@@ -234,7 +234,7 @@ Year         : 2017
 PSComputerName : .
 ```
 
-### Displaying Service Status
+## Displaying Service Status
 
 To view the status of all services on a specific computer, you can locally use the `Get-Service` cmdlet.
 For remote systems, you can use the **Win32_Service** WMI class.

reference/docs-conceptual/samples/Creating-.NET-and-COM-Objects--New-Object-.md

@@ -8,7 +8,7 @@ ms.assetid:  2057b113-efeb-465e-8b44-da2f20dbf603
 
 There are software components with .NET Framework and COM interfaces that enable you to perform many system administration tasks. Windows PowerShell lets you use these components, so you are not limited to the tasks that can be performed by using cmdlets. Many of the cmdlets in the initial release of Windows PowerShell do not work against remote computers. We will demonstrate how to get around this limitation when managing event logs by using the .NET Framework **System.Diagnostics.EventLog** class directly from Windows PowerShell.
 
-### Using New-Object for Event Log Access
+## Using New-Object for Event Log Access
 
 The .NET Framework Class Library includes a class named **System.Diagnostics.EventLog** that can be used to manage event logs. You can create a new instance of a .NET Framework class by using the **New-Object** cmdlet with the **TypeName** parameter. For example, the following command creates an event log reference:
 
@@ -21,7 +21,7 @@ PS> New-Object -TypeName System.Diagnostics.EventLog
 
 Although the command has created an instance of the EventLog class, the instance does not include any data. That is because we did not specify a particular event log. How do you get a real event log?
 
-#### Using Constructors with New-Object
+### Using Constructors with New-Object
 
 To refer to a specific event log, you need to specify the name of the log. **New-Object** has an **ArgumentList** parameter. The arguments you pass as values to this parameter are used by a special startup method of the object. The method is called a *constructor* because it is used to construct the object. For example, to get a reference to the Application log, you specify the string 'Application' as an argument:
 
@@ -36,7 +36,7 @@ Max(K) Retain OverflowAction        Entries Name
 > [!NOTE]
 > Since most of the .NET Framework core classes are contained in the System namespace, Windows PowerShell will automatically attempt to find classes you specify in the System namespace if it cannot find a match for the typename you specify. This means that you can specify Diagnostics.EventLog instead of System.Diagnostics.EventLog.
 
-#### Storing Objects in Variables
+### Storing Objects in Variables
 
 You might want to store a reference to an object, so you can use it in the current shell. Although Windows PowerShell lets you do a lot of work with pipelines, lessening the need for variables, sometimes storing references to objects in variables makes it more convenient to manipulate those objects.
 
@@ -56,7 +56,7 @@ PS> $AppLog
   16,384      7 OverwriteOlder          2,160 Application
 ```
 
-#### Accessing a Remote Event Log with New-Object
+### Accessing a Remote Event Log with New-Object
 
 The commands used in the preceding section target the local computer; the **Get-EventLog** cmdlet can do that. To access the Application log on a remote computer, you must supply both the log name and a computer name (or IP address) as arguments.
 
@@ -71,7 +71,7 @@ PS> $RemoteAppLog
 
 Now that we have a reference to an event log stored in the $RemoteAppLog variable, what tasks can we perform on it?
 
-#### Clearing an Event Log with Object Methods
+### Clearing an Event Log with Object Methods
 
 Objects often have methods that can be called to perform tasks. You can use **Get-Member** to display the methods associated with an object. The following command and selected output show some the methods of the EventLog class:
 
@@ -112,7 +112,7 @@ PS> $RemoteAppLog
      512      7 OverwriteOlder              0 Application
 ```
 
-### Creating COM Objects with New-Object
+## Creating COM Objects with New-Object
 You can use **New-Object** to work with Component Object Model (COM) components. Components range from the various libraries included with Windows Script Host (WSH) to ActiveX applications such as Internet Explorer that are installed on most systems.
 
 **New-Object** uses .NET Framework Runtime-Callable Wrappers to create COM objects, so it has the same limitations that .NET Framework does when calling COM objects. To create a COM object, you need to specify the **ComObject** parameter with the Programmatic Identifier or *ProgId* of the COM class you want to use. A complete discussion of the limitations of COM use and determining what ProgIds are available on a system is beyond the scope of this user's guide, but most well-known objects from environments such as WSH can be used within Windows PowerShell.
@@ -128,7 +128,7 @@ New-Object -ComObject Scripting.FileSystemObject
 
 Although most of the functionality of these classes is made available in other ways in Windows PowerShell, a few tasks such as shortcut creation are still easier to do using the WSH classes.
 
-### Creating a Desktop Shortcut with WScript.Shell
+## Creating a Desktop Shortcut with WScript.Shell
 
 One task that can be performed quickly with a COM object is creating a shortcut. Suppose you want to create a shortcut on your desktop that links to the home folder for Windows PowerShell. You first need to create a reference to **WScript.Shell**, which we will store in a variable named **$WshShell**:
 
@@ -197,7 +197,7 @@ $lnk.TargetPath = $PSHome
 $lnk.Save()
 ```
 
-### Using Internet Explorer from Windows PowerShell
+## Using Internet Explorer from Windows PowerShell
 
 Many applications (including the Microsoft Office family of applications and Internet Explorer) can be automated by using COM. Internet Explorer illustrates some of the typical techniques and issues involved in working with COM-based applications.
 
@@ -256,7 +256,7 @@ Remove-Variable ie
 > [!NOTE]
 > There is no common standard for whether ActiveX executables exit or continue to run when you remove a reference to one. Depending on circumstances such as whether the application is visible, whether an edited document is running in it, and even whether Windows PowerShell is still running, the application may or may not exit. For this reason, you should test termination behavior for each ActiveX executable you want to use in Windows PowerShell.
 
-### Getting Warnings About .NET Framework-Wrapped COM Objects
+## Getting Warnings About .NET Framework-Wrapped COM Objects
 
 In some cases, a COM object might have an associated .NET Framework *Runtime-Callable Wrapper* or RCW, and this will be used by **New-Object**. Since the behavior of the RCW may be different from the behavior of the normal COM object, **New-Object** has a **Strict** parameter to warn you about RCW access. If you specify the **Strict** parameter and then create a COM object that uses an RCW, you get a warning message:
 

reference/docs-conceptual/samples/Creating-Get-WinEvent-queries-with-FilterHashtable.md

@@ -31,7 +31,7 @@ Get-WinEvent -FilterHashtable @{
 }
 ```
 
-### Blog posts about enumeration
+## Blog posts about enumeration
 
 This article presents information about how to use enumerated values in a hash table. For more
 information about enumeration, read these **Scripting Guy** blog posts. To create a function that
@@ -40,7 +40,7 @@ returns the enumerated values, see
 For more information, see the
 [Scripting Guy series of blog posts about enumeration](https://devblogs.microsoft.com/scripting/?s=about+enumeration).
 
-### Hash table key/value pairs
+## Hash table key/value pairs
 
 To build efficient queries, use the `Get-WinEvent` cmdlet with the **FilterHashtable** parameter.
 **FilterHashtable** accepts a hash table as a filter to get specific information from Windows event
@@ -74,7 +74,7 @@ for a data value.
 | Data         | `<String[]>`       | No  |
 | *            | `<String[]>`       | No  |
 
-### Building a query with a hash table
+## Building a query with a hash table
 
 To verify results and troubleshoot problems, it helps to build the hash table one **key/value** pair
 at a time. The query gets data from the **Application** log. The hash table is equivalent to
@@ -109,7 +109,7 @@ If your query needs to get data from archived event logs, use the **Path** key.
 specifies the full path to the log file. For more information, see the **Scripting Guy** blog post,
 [Use PowerShell to Parse Saved Event Logs for Errors](https://devblogs.microsoft.com/scripting/use-powershell-to-parse-saved-event-logs-for-errors).
 
-### Using enumerated values in a hash table
+## Using enumerated values in a hash table
 
 **Keywords** is the next key in the hash table. The **Keywords** data type is an array of the `[long]`
 value type that holds a large number. Use the following command to find the maximum value of `[long]`:
@@ -182,7 +182,7 @@ Get-WinEvent -FilterHashtable @{
 }
 ```
 
-#### Keywords static property value (optional)
+### Keywords static property value (optional)
 
 The **Keywords** key is enumerated, but you can use a static property name in the hash table query.
 Rather than using the returned string, the property name must be converted to a value with the
@@ -199,7 +199,7 @@ Get-WinEvent -FilterHashtable @{
 }
 ```
 
-### Filtering by Event Id
+## Filtering by Event Id
 
 To get more specific data, the query's results are filtered by **Event Id**. The **Event Id** is
 referenced in the hash table as the key **ID** and the value is a specific **Event Id**. The
@@ -217,7 +217,7 @@ Get-WinEvent -FilterHashtable @{
 }
 ```
 
-### Filtering by Level
+## Filtering by Level
 
 To further refine the results and include only events that are errors, use the **Level** key.
 **Windows Event Viewer** displays the **Level** as string values, but they are enumerated values. In
@@ -269,7 +269,7 @@ Get-WinEvent -FilterHashtable @{
 }
 ```
 
-#### Level static property in enumeration (optional)
+### Level static property in enumeration (optional)
 
 The **Level** key is enumerated, but you can use a static property name in the hash table query.
 Rather than using the returned string, the property name must be converted to a value with the

reference/docs-conceptual/samples/Managing-Current-Location.md

@@ -10,7 +10,7 @@ When navigating folder systems in File Explorer, you usually have a specific wor
 
 Windows PowerShell uses the noun **Location** to refer to the working directory, and implements a family of cmdlets to examine and manipulate your location.
 
-### Getting Your Current Location (Get-Location)
+## Getting Your Current Location (Get-Location)
 
 To determine the path of your current directory location, enter the **Get-Location** command:
 
@@ -24,7 +24,7 @@ C:\Documents and Settings\PowerUser
 > [!NOTE]
 > The Get-Location cmdlet is similar to the **pwd** command in the BASH shell. The Set-Location cmdlet is similar to the **cd** command in Cmd.exe.
 
-### Setting Your Current Location (Set-Location)
+## Setting Your Current Location (Set-Location)
 
 The **Get-Location** command is used with the **Set-Location** command. The **Set-Location** command allows you to specify your current directory location.
 
@@ -90,7 +90,7 @@ chdir -Path .. -PassThru
 sl -Path HKLM:\SOFTWARE -PassThru
 ```
 
-### Saving and Recalling Recent Locations (Push-Location and Pop-Location)
+## Saving and Recalling Recent Locations (Push-Location and Pop-Location)
 
 When changing locations, it is helpful to keep track of where you have been and to be able to return to your previous location. The **Push-Location** cmdlet in Windows PowerShell creates a ordered history (a "stack") of directory paths where you have been, and you can step back through the history of directory paths by using the complementary **Pop-Location** cmdlet.
 

reference/docs-conceptual/samples/Managing-Windows-PowerShell-Drives.md

@@ -76,7 +76,7 @@ Path
 HKLM:\SOFTWARE\Microsoft
 ```
 
-### Adding New Windows PowerShell Drives (New-PSDrive)
+## Adding New Windows PowerShell Drives (New-PSDrive)
 
 You can add your own Windows PowerShell drives by using the **New-PSDrive** command. To get the syntax for the **New-PSDrive** command, enter the **Get-Command** command with the **Syntax** parameter:
 
@@ -140,7 +140,7 @@ cvkey:\
 
 The New-PsDrive cmdlet adds the new drive only to the current Windows PowerShell session. If you close the Windows PowerShell window, the new drive is lost. To save a Windows PowerShell drive, use the Export-Console cmdlet to export the current Windows PowerShell session, and then use the PowerShell.exe **PSConsoleFile** parameter to import it. Or, add the new drive to your Windows PowerShell profile.
 
-### Deleting Windows PowerShell Drives (Remove-PSDrive)
+## Deleting Windows PowerShell Drives (Remove-PSDrive)
 
 You can delete drives from Windows PowerShell by using the **Remove-PSDrive** cmdlet. The **Remove-PSDrive** cmdlet is easy to use; to delete a specific Windows PowerShell drive, you just supply the Windows PowerShell drive name.
 
@@ -166,6 +166,6 @@ At line:1 char:15
 + remove-psdrive  <<<< -name office
 ```
 
-### Adding and Removing Drives Outside Windows PowerShell
+## Adding and Removing Drives Outside Windows PowerShell
 
 Windows PowerShell detects file system drives that are added or removed in Windows, including network drives that are mapped, USB drives that are attached, and drives that are deleted by using either the **net use** command or the **WScript.NetworkMapNetworkDrive** and **RemoveNetworkDrive** methods from a Windows Script Host (WSH) script.