Category Archives: Test

Test-ComputerSecureChannel

February 26, 2014 Adam

SYNOPSIS
Tests and repairs the secure channel between the local computer and its domain.

SYNTAX
Test-ComputerSecureChannel [-Repair] [-Server <string>] [-Confirm] [-WhatIf] [<CommonParameters>]

DESCRIPTION
The Test-ComputerSecureChannel cmdlet verifies that the secure channel between the local computer and its domain is working correctly by checking the status of its trust relationships. If a connection fails, you can use the Repair parameter to try to restore it.

Test-ComputerSecureChannel returns “True” if the secure channel is working correctly and “False” if it is not. This result lets you use the cmdlet in conditional statements in Functions and scripts. To get more detailed test results, use the Verbose parameter.

This cmdlet works much like NetDom.exe. Both NetDom and Test-ComputerSecureChannel use the NetLogon service to perform the actions.

PARAMETERS
-Repair [<SwitchParameter>]
Removes and then rebuilds the secure channel established by the NetLogon service. Use this parameter to try to restore a connection that has failed the test (returned “False”.)

To use this parameter, the current user must be a member of the Administrators group on the local computer.

        Required?                    false
        Position?                    named
        Default value                None
        Accept pipeline input?     false
        Accept wildcard characters? false

-Server <string>
Uses the specified domain controller to run the command. If this parameter is omitted, Test-ComputerSecureChannel selects a default domain controller for the operation.

-Confirm [<SwitchParameter>]
Prompts you for confirmation before executing the command.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

-WhatIf [<SwitchParameter>]
Describes what would happen if you executed the command without actually executing the command.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer and OutVariable. For more information, type,
        “Get-Help about_CommonParameters“.

INPUTS
None
You cannot pipe input to this cmdlet.

OUTPUTS
System.Boolean
The cmdlet returns “True” when the connection is working correctly and “False” when it is not.

NOTES

To run a Test-ComputerSecureChannel command on Windows Vista and later versions of Windows, open Windows PowerShell with the “Run as administrator” option.

Test-ComputerSecureChannel is implemented by using the I_NetLogonControl2 Function, which controls various aspects of the Netlogon service.

————————– EXAMPLE 1 ————————–

C:\PS>Test-ComputerSecureChannel

True

    Description
    ———–
    This command tests the secure channel between the local computer and the domain to which it is joined.

————————– EXAMPLE 2 ————————–

C:\PS>Test-ComputerSecureChannel -Server DCName.fabrikam.com

True

    Description
    ———–
    This command specifies a preferred domain controller for the test.

————————– EXAMPLE 3 ————————–

C:\PS>Test-ComputerSecureChannel -Repair

True

    Description
    ———–
    This command resets the secure channel between the local computer and its domain.

————————– EXAMPLE 4 ————————–

C:\PS>Test-ComputerSecureChannel -Verbose

    VERBOSE: Performing operation “Test-ComputerSecureChannel” on Target “SERVER01”.
    True
    VERBOSE: “The secure channel between ‘SERVER01’ and ‘net.fabrikam.com’ is alive and working correctly.”

    Description
    ———–
    This command uses the Verbose common parameter to request detailed messages about the operation. For more information about the Verbose parameter, see about_CommonParameters.

————————– EXAMPLE 5 ————————–

C:\PS>Set-Alias tcsc Test-ComputerSecureChannel

    if (!(tcsc))
         {Write-Host “Connection failed. Reconnect and retry.”}
    else { &(.\get-Servers.ps1) }

    Description
    ———–
    This example shows how to use Test-ComputerSecureChannel to test a connection before running a script that requires the connection.

The first command uses the Set-Alias cmdlet to create an Alias for the cmdlet name. This saves space and prevents typing errors.

The If statement checks the value that Test-ComputerSecureChannel returns before running a script.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=137749
    Checkpoint-Computer
    Restart-Computer
    Stop-Computer
    Reset-ComputerMachinePassword

cmdlet, Connection, Test

Test-Connection

February 26, 2014 Adam

NAME
Test-Connection

SYNOPSIS
Sends ICMP echo request packets (“pings”) to one or more computers.

SYNTAX
Test-Connection [-ComputerName] <string[]> [[-Source] <string[]>] [-AsJob] [-Authentication {Default | None | Connect | Call | Packet | PacketIntegrity | PacketPrivacy | Unchanged}] [-BufferSize <int>] [-Count <int>] [-Credential <PSCredential>] [-Delay <int>] [-Impersonation {Default | Anonymous | Identify | Impersonate | Delegate}] [-Quiet] [-ThrottleLimit <int>] [-TimeToLive <int>] [<CommonParameters>]

DESCRIPTION
The Test-Connection cmdlet sends Internet Control Message Protocol (ICMP) echo request packets (“pings”) to one or more remote computers and returns the echo response replies. You can use this cmdlet to determine whether a particular computer can be contacted across an Internet Protocol (IP) network.

You can use the parameters of Test-Connection to specify both the sending and receiving computers, to run the command as a background job, to set a timeout and number of pings, and to configure the connection and authentication.

Unlike the traditional “ping” command, Test-Connection returns a Win32_PingStatus object that you can investigate in Windows PowerShell, but you can use the Quiet parameter to force it to return only a Boolean value.

PARAMETERS
-AsJob [<SwitchParameter>]
Runs the command as a background job.

Note: To use this parameter, the local and remote computers must be configured for remoting and, on Windows Vista and later versions of Windows, you must open Windows PowerShell with the “Run as administrator” option. For more information, see about_remote_requirements.

When you use the AsJob parameter, the command immediately returns an object that represents the background job. You can continue to work in the session while the job completes. The job is created on the local computer and the results from remote computers are automatically returned to the local computer. To get the job results, use the Receive-Job cmdlet.

For more information about Windows PowerShell background jobs, see about_jobs and about_remote_Jobs.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?     false
        Accept wildcard characters? false

-Authentication <AuthenticationLevel>
Specifies the authentication level that is used for the WMI connection. (Test-Connection uses WMI.)

Valid values are:

        Unchanged:     The authentication level is the same as the previous command.
        Default:         Windows Authentication.
        None:            No COM authentication.
        Connect:         Connect-level COM authentication.
        Call:            Call-level COM authentication.
        Packet:         Packet-level COM authentication.
        PacketIntegrity: Packet Integrity-level COM authentication.
        PacketPrivacy: Packet Privacy-level COM authentication.

        Required?                    false
        Position?                    named
        Default value                4
        Accept pipeline input?     false
        Accept wildcard characters? false

-BufferSize <int>
Specifies the size, in bytes, of the buffer sent with this command. The default value is 32.

        Required?                    false
        Position?                    named
        Default value                32
        Accept pipeline input?     false
        Accept wildcard characters? false

-ComputerName <string[]>
Specifies the computers to ping. Type the computer names or type IP addresses in IPv4 or IPv6 format. Wildcard characters are not permitted. This parameter is required.

This parameter does not rely on Windows PowerShell remoting. You can use the ComputerName parameter even if your computer is not configured to run remote commands.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     true (ByPropertyName)
        Accept wildcard characters? false

-Count <int>
Specifies the number of echo requests to send. The default value is 4.

        Required?                    false
        Position?                    named
        Default value                4
        Accept pipeline input?     false
        Accept wildcard characters? false

-Credential <PSCredential>
Specifies a user account that has permission to perform this action. Type a user name, such as “User01” or “Domain01\User01”, or enter a PSCredential object, such as one from the Get-Credential cmdlet.

        Required?                    false
        Position?                    named
        Default value                Current user
        Accept pipeline input?     false
        Accept wildcard characters? false

-Delay <int>
Specifies the interval between pings, in seconds.

        Required?                    false
        Position?                    named
        Default value                1 (second)
        Accept pipeline input?     false
        Accept wildcard characters? false

-Impersonation <ImpersonationLevel>
Specifies the impersonation level to use when calling WMI. (Test-Connection uses WMI.) The default value is “Impersonate”.

Valid values are:

        Default:     Default impersonation.
        Anonymous:    Hides the identity of the caller.
        Identify:     Allows objects to query the credentials of the caller.
        Impersonate: Allows objects to use the credentials of the caller.

        Required?                    false
        Position?                    named
        Default value                3
        Accept pipeline input?     false
        Accept wildcard characters? false

-Quiet [<SwitchParameter>]
Suppresses all errors and returns $True if any pings succeeded and $False if all failed.

-Source <string[]>
Specifies the names of the computers where the ping originates. Enter a comma-separated list of computer names. The default is the local computer.

        Required?                    false
        Position?                    2
        Default value                Local computer
        Accept pipeline input?     false
        Accept wildcard characters? false

-ThrottleLimit <int>
Specifies the maximum number of concurrent connections that can be established to run this command. If you omit this parameter or enter a value of 0, the default value, 32, is used.

The throttle limit applies only to the current command, not to the session or to the computer.

-TimeToLive <int>
Specifies the maximum time, in seconds, that each echo request packet (“pings”) is active. The default value is 80 (seconds). The Alias of the TimeToLive parameter is TTL.

        Required?                    false
        Position?                    named
        Default value                80
        Accept pipeline input?     false
        Accept wildcard characters? false

INPUTS
None
You cannot pipe input to this cmdlet.

OUTPUTS
System.Management.ManagementObject#root\cimv2\Win32_PingStatus, System.Management.Automation.RemotingJob, System.Boolean
When you use the AsJob parameter, the cmdlet returns a job object. When you use the Quiet parameter, it returns a Boolean. Otherwise, this cmdlet returns a Win32_PingStatus object for each ping.

NOTES

This cmdlet uses the Win32_PingStatus class. A “get-wmiojbect win32_pingstatus” command is equivalent to a Test-Connection command.

————————– EXAMPLE 1 ————————–

C:\PS>Test-Connection server01

    Source        Destination     IPV4Address     IPV6Address Bytes    Time(ms)
    ——        ———–     ———–     ———– —–    ——–
    ADMIN1        Server01        157.59.137.44                32     0
    ADMIN1        Server01        157.59.137.44                32     0
    ADMIN1        Server01        157.59.137.44                32     0
    ADMIN1        Server01        157.59.137.44                32     1

    Description
    ———–
    This command sends echo request packets (“pings”) from the local computer to the Server01 computer. This command uses the ComputerName parameter to specify the Server01 computer, but omits the optional parameter name.

————————– EXAMPLE 2 ————————–

C:\PS>Test-Connection -ComputerName server01, server02, server12 -Credential domain01\user01

    Description
    ———–
    This command sends pings from the local computer to several remote computers. It uses the Credential parameter to specify a user account that has permission to ping all of the remote computers.

————————– EXAMPLE 3 ————————–

C:\PS>Test-Connection -Source Server02, Server 12, localhost -ComputerName Server01

    Description
    ———–
    This command sends pings from different source computers to a single remote computer, Server01. Use this command format to test the latency of connections from multiple points.

————————– EXAMPLE 4 ————————–

C:\PS>Test-Connection -ComputerName Server01 -Count 3 -Delay 2 -TTL 256 -BufferSize 256 -throttle 32

    Description
    ———–
    This command sends three pings from the local computer to the Server01 computer. It uses the parameters of Test-Connection to customize the command.

Use this command format when the ping response is expected to take longer than usual, either because of an extended number of hops or a high-traffic network condition.

————————– EXAMPLE 5 ————————–

C:\PS>$job = Test-Connection -ComputerName (Get-Content servers.txt) -AsJob

C:\PS> if ($job.jobstateinfo.state -ne “Running”) {$results = Receive-Job $job}

    Description
    ———–
    This example shows how to run a Test-Connection command as a Windows PowerShell background job.

The first command uses the Test-Connection cmdlet to ping many computers in an enterprise. The value of ComputerName parameter is a Get-Content command that reads a list of computer names from the Servers.txt file. The command uses the AsJob parameter to run the command as a background job.

The second command checks to see that the job is not still running, and if it is not, it uses a Receive-Job command to get the results and store them in the $results Variable.

————————– EXAMPLE 6 ————————–

C:\PS>Test-Connection Server55 -Credential domain55\user01 -Impersonation Identify

    Description
    ———–
    This command uses the Test-Connection cmdlet to ping a remote computer. The command uses the Credential parameter to specify a user account with permission to ping the remote computer and the Impersonation parameter to change the impersonation level to “Identify”.

————————– EXAMPLE 7 ————————–

C:\PS>if (Test-Connection -ComputerName Server01 -quiet) {New-PSSession Server01}

    Description
    ———–
    This command creates a PSSession on the Server01 only if at least one of the pings sent to the computer succeeds.

The command uses the Test-Connection cmdlet to ping the Server01 computer. The command uses the Quiet parameter, which returns a Boolean value, instead of a Win32_PingStatus object. The value is $True if any of the four pings succeed and is, otherwise, false.

If the Test-Connection command returns a value of $True, the command uses the New-PSSession cmdlet to create the PSSession.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=135266
    Add-Computer
    Restart-Computer
    Stop-Computer

cmdlet, ModuleManifest, Test

Test-ModuleManifest

February 26, 2014 Adam

NAME
Test-ModuleManifest

SYNOPSIS
Verifies that a module manifest file accurately describes the contents of a module.

SYNTAX
Test-ModuleManifest [-Path] <string> [<CommonParameters>]

DESCRIPTION
The Test-ModuleManifest cmdlet verifies that the files that are listed in the module manifest (.psd1) file actually exist in the specified paths.

This cmdlet is designed to help module authors test their manifest files. Module users can also use this cmdlet in scripts and commands to detect errors before running scripts that depend on the module.

The Test-ModuleManifest cmdlet returns an object that represents the module (the same type of object that Get-Module returns). If any files are not in the locations specified in the manifest, the cmdlet also generates an error for each missing file.

PARAMETERS
-Path <string>
Specifies the path to the module manifest file. Enter a path (optional) and the name of the module manifest file with the .psd1 file name extension. The default location is the current directory. This parameter is required. The parameter name (“Path”) is optional. You can also pipe a path to Test-ModuleManifest.

        Required?                    true
        Position?                    1
        Default value                None
        Accept pipeline input?     true (ByValue, ByPropertyName)
        Accept wildcard characters? false

INPUTS
System.String
You can pipe the path to a module manifest to Test-ModuleManifest.

OUTPUTS
System.Management.Automation.PSModuleInfo
Test-ModuleManifest returns a PSModuleInfo object that represents the module. It returns this object even if the manifest has errors.

NOTES

————————– EXAMPLE 1 ————————–

C:\PS>Test-ModuleManifest -Path $pshome\Modules\TestModule.psd1

    Description
    ———–
    This command tests the TestModule.psd1 module manifest.

————————– EXAMPLE 2 ————————–

C:\PS>”$pshome\Modules\TestModule.psd1″ | Test-ModuleManifest

    Test-ModuleManifest : The specified type data file ‘C:\Windows\System32\Wi
    ndowsPowerShell\v1.0\Modules\TestModule\TestTypes.ps1xml’ could not be pro
    cessed because the file was not found. Please correct the path and try aga
    in.
    At line:1 char:34
    + “$pshome\Modules\TestModule.psd1” | Test-ModuleManifest <<<<
        + CategoryInfo         : ResourceUnavailable: (C:\Windows\System32\Win
    dowsPowerShell\v1.0\Modules\TestModule\TestTypes.ps1xml:String) [Test-Modul
    eManifest], FileNotFoundException
        + FullyQualifiedErrorId : Modules_TypeDataFileNotFound,Microsoft.
    PowerShell.Commands.TestModuleManifestCommandName

    Name             : TestModule
    Path             : C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Test
    Module\TestModule.psd1
    Description     :
    Guid             : 6f0f1387-cd25-4902-b7b4-22cff6aefa7b
    Version         : 1.0
    ModuleBase        : C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Test
    Module
    ModuleType        : Manifest
    PrivateData     :
    AccessMode        : ReadWrite
    ExportedAliases : {}
    ExportedCmdlets : {}
    ExportedFunctions : {}
    ExportedVariables : {}
    NestedModules     : {}

    Description
    ———–
    This command uses a pipeline operator (|) to send a path string to Test-ModuleManifest.

The command output shows that the test failed, because the TestTypes.ps1xml file, which was listed in the manifest, was not found.

————————– EXAMPLE 3 ————————–

C:\PS>function Bool-ModuleManifest ($path)
{$a = dir $path | Test-ModuleManifest -ErrorAction SilentlyContinue; $?}

    Description
    ———–
    This Function is like Test-ModuleManifest, but it returns a Boolean value; it returns “True” if the manifest passed the test and “False” otherwise.

The Function uses the Get-ChildItem cmdlet (alias = dir) to get the module manifest specified by the $path Variable. It uses a pipeline operator (|) to pass the file object to the Test-ModuleManifest cmdlet.

The Test-ModuleManifest command uses the ErrorAction common parameter with a value of SilentlyContinue to suppress the display of any errors that the command generates. It also saves the PSModuleInfo object that Test-ModuleManifest returns in the $a Variable, so the object is not displayed.

Then, in a separate command (the semi-colon [;] is the command separator), it displays the value of the $? automatic Variable, which returns “True” if the previous command generated no error and “False” otherwise.

You can use this Function in conditional statements, such as those that might precede an Import-Module command or a command that uses the module.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=141557
    Import-Module
    Get-Module
    New-Module
    Remove-Module
    Export-ModuleMember
    New-ModuleManifest
    about_modules

cmdlet, Path, Test

Test-Path

February 26, 2014 Adam

NAME
Test-Path

SYNOPSIS
Determines whether all elements of a path exist.

SYNTAX
Test-Path [-LiteralPath] <string[]> [-Credential <PSCredential>] [-Exclude <string[]>] [-Filter <string>] [-Include <string[]>] [-IsValid] [-PathType {Any | Container | Leaf}] [-UseTransaction] [<CommonParameters>]

Test-Path [-Path] <string[]> [-Credential <PSCredential>] [-Exclude <string[]>] [-Filter <string>] [-Include <string[]>] [-IsValid] [-PathType {Any | Container | Leaf}] [-UseTransaction] [<CommonParameters>]

DESCRIPTION
The Test-Path cmdlet determines whether all elements of the path exist. It returns TRUE ($true) if all elements exist and FALSE ($false) if any are missing. It can also tell whether the path syntax is valid and whether the path leads to a container or a terminal (leaf) element.

PARAMETERS
-Credential <PSCredential>
Specifies a user account that has permission to perform this action. The default is the current user.

Type a user name, such as “User01” or “Domain01\User01”. Or, enter a PSCredential object, such as one generated by the Get-Credential cmdlet. If you type a user name, you will be prompted for a password.

This parameter is not supported by any providers installed with Windows PowerShell.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     true (ByPropertyName)
        Accept wildcard characters? false

-Exclude <string[]>
Omits the specified items. The value of this parameter qualifies the Path parameter. Enter a path element or pattern, such as “*.txt”. Wildcards are permitted.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

-Filter <string>
Specifies a filter in the provider’s format or language. The value of this parameter qualifies the Path parameter. The syntax of the filter, including the use of wildcards, depends on the provider. Filters are more efficient than other parameters, because the provider applies them when retrieving the objects rather than having Windows PowerShell filter the objects after they are retrieved.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

-Include <string[]>
Tests only the specified paths. The value of this parameter qualifies the Path parameter. Enter a path element or pattern, such as “*.txt”. Wildcards are permitted.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

-IsValid [<SwitchParameter>]
Determines whether the syntax of the path is correct, regardless of whether the elements of the path exist. This parameter returns TRUE if the path syntax is valid and FALSE if it is not.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

-LiteralPath <string[]>
Specifies a path to be tested. Unlike Path, the value of the LiteralPath parameter is used exactly as it is typed. No characters are interpreted as wildcards. If the path includes escape characters, enclose it in single quotation marks. Single quotation marks tell Windows PowerShell not to interpret any characters as escape sequences.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     true (ByPropertyName)
        Accept wildcard characters? false

-Path <string[]>
Specifies a path to be tested. Wildcards are permitted. If the path includes spaces, enclose it in quotation marks. The parameter name (“Path”) is optional.

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?     true (ByValue, ByPropertyName)
        Accept wildcard characters? false

-PathType <TestPathType>
Tells whether the final element in the path is of a particular type. This parameter returns TRUE if the element is of the specified type and FALSE if it is not.

Valid values are:
— Container: An element that contains other elements, such as a directory or Registry key.

— Leaf: An element that does not contain other elements, such as a file.

— Any: Either a container or a leaf.Tells whether the final element in the path is of a particular type. Returns TRUE if the element is of the specified type and FALSE if it is not.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

-UseTransaction [<SwitchParameter>]
Includes the command in the active transaction. This parameter is valid only when a transaction is in progress. For more information, see about_transactions.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

INPUTS
System.String
You can pipe a string that contains a path (but not a literal path) to Test-Path.

OUTPUTS
System.Boolean
The cmdlet returns “True” when the path exists and “False” when it does not.

NOTES

The cmdlets that contain the Path noun (the Path cmdlets) manipulate path names and return the names in a concise format that all Windows PowerShell providers can interpret. They are designed for use in programs and scripts where you want to display all or part of a path name in a particular format. Use them like you would use Dirname, Normpath, Realpath, Join, or other path manipulators.

You can use the Path cmdlets with several providers, including the FileSystem, Registry, and Certificate providers.

The Test-Path cmdlet is designed to work with the data exposed by any provider. To list the providers available in your session, type “Get-PSProvider“. For more information, see about_providers.

————————– EXAMPLE 1 ————————–

C:\PS>Test-Path -Path “C:\Documents and Settings\NicoleH”

    Description
    ———–
    This command tells whether all elements in the path exist, that is, the C: directory, the Documents and Settings directory, and the NicoleH directory. If any are missing, the cmdlet returns FALSE. Otherwise, it returns TRUE.

————————– EXAMPLE 2 ————————–

C:\PS>Test-Path -Path $profile

C:\PS>Test-Path -Path $profile -IsValid

    Description
    ———–
    These commands test the path to the Windows PowerShell profile.

The first command determines whether all elements in the path exist. The second command determines whether the syntax of the path is correct. In this case, the path is FALSE, but the syntax is correct (TRUE). These commands use $profile, the automatic Variable that points to the location for the profile, even if the profile does not exist.

For more information about automatic Variables, see about_Automatic_Variables.

————————– EXAMPLE 3 ————————–

C:\PS>Test-Path -Path “C:\CAD\Commercial Buildings\*” -Exclude *.dwg

    Description
    ———–
    This command tells whether there are any files in the Commercial Buildings directory other than .dwg files.

The command uses the Path parameter to specify the path. Because it includes a space, the path is enclosed in quotes. The asterisk at the end of the path indicates the contents of the Commercial Building directory. (With long paths, like this one, type the first few letters of the path, and then use the TAB key to complete the path.)

The command uses the Exclude parameter to specify files that will be omitted from the evaluation.

In this case, because the directory contains only .dwg files, the result is FALSE.

————————– EXAMPLE 4 ————————–

C:\PS>Test-Path -Path $profile -Pathtype leaf

    Description
    ———–
    This command tells whether the path stored in the $profile Variable leads to a file. In this case, because the Windows PowerShell profile is a .ps1 file, the cmdlet returns TRUE.

————————– EXAMPLE 5 ————————–

C:\PS>Test-Path -Path HKLM:\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

TRUE

C:\PS> Test-Path -Path HKLM:\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell\ExecutionPolicy
FALSE

    Description
    ———–
    These commands use the Test-Path cmdlet with the Windows PowerShell Registry provider.

The first command tests whether the Registry path to the Microsoft.PowerShell Registry key is correct on the system. If Windows PowerShell is installed correctly, the cmdlet returns TRUE.

Test-Path does not work correctly with all Windows PowerShell providers. For example, you can use Test-Path to test the path to a Registry key, but if you use it to test the path to a Registry entry, it always returns FALSE, even if the Registry entry is present.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=113418
    about_providers
    Convert-Path
    Split-Path
    Resolve-Path
    Join-Path

cmdlet, Test, WSMan

Test-WSMan

February 26, 2014 Adam

NAME
Test-WSMan

SYNOPSIS
Tests whether the WinRM service is running on a local or remote computer.

SYNTAX
Test-WSMan [[-ComputerName] <string>] [-Authentication <Authentication>] [-Credential <PSCredential>] [<CommonParameters>]

DESCRIPTION
The Test-WSMan cmdlet submits an identification request that determines whether the WinRM service is running on a local or remote computer. If the tested computer is running the service, the cmdlet displays the WS-Management identity schema, the protocol version, the product vendor, and the product version of the tested service.

PARAMETERS
    -Authentication <Authentication>
        Specifies the authentication mechanism to be used at the server. Possible values are:
        – Basic: Basic is a scheme in which the user name and password are sent in clear text to the server or proxy.
        – Default : Use the authentication method implemented by the WS-Management protocol.
        – Digest: Digest is a challenge-response scheme that uses a server-specified data string for the challenge.
        – Kerberos: The client computer and the server mutually authenticate by using Kerberos Certificates.
        – Negotiate: Negotiate is a challenge-response scheme that negotiates with the server or proxy to determine the scheme to use for authentication. For example, this parameter value allows negotiation to determine whether the Kerberos protocol or NTLM is used.
        – CredSSP: Use Credential Security Service Provider (CredSSP) authentication, which allows the user to delegate credentials. This option is designed for commands that run on one remote computer but collect data from or run additional commands on other remote computers.

Caution: CredSSP delegates the user’s credentials from the local computer to a remote computer. This practice increases the security risk of the remote operation. If the remote computer is compromised, when credentials are passed to it, the credentials can be used to control the network session.

Important: If the authentication parameter is not specified, then the Test-WSMan request will be sent to the remote machine anonymously (without using authentication). If the Test-WSMan request is made anonymously, it does not return any information that is specific to the operating-system version. Instead, Test-WSMan displays null values for the operating system version and service pack level (OS: 0.0.0 SP: 0.0).

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

-ComputerName <string>
Specifies the computer against which you want to run the management operation. The value can be a fully qualified domain name, a NetBIOS name, or an IP address. Use the local computer name, use localhost, or use a dot (.) to specify the local computer. The local computer is the default. When the remote computer is in a different domain from the user, you must use a fully qualified domain name must be used.

        Required?                    false
        Position?                    1
        Default value                localhost
        Accept pipeline input?     false
        Accept wildcard characters? false

-Credential <PSCredential>
Specifies a user account that has permission to perform this action. The default is the current user. Type a user name, such as “User01”, “Domain01\User01”, or User@Domain.com. Or, enter a PSCredential object, such as one returned by the Get-Credential cmdlet. When you type a user name, you will be prompted for a password.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?     false
        Accept wildcard characters? false

INPUTS
None
This cmdlet does not accept any input.

OUTPUTS
None
This cmdlet does not generate any output object.

NOTES

By default, the Test-WSMan cmdlet queries the WinRM service without using authentication, and it does not return any information that is specific to the operating-system version. Instead, it displays null values for the operating system version and service pack level (OS: 0.0.0 SP: 0.0).

————————– EXAMPLE 1 ————————–

C:\PS>Test-WSMan

    wsmid         : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
    ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
    ProductVendor : Microsoft Corporation
    ProductVersion : OS: 0.0.0 SP: 0.0 Stack: 2.0

    Description
    ———–
    This command determines whether the WinRM service is running on the local computer or on a remote computer.

————————– EXAMPLE 2 ————————–

C:\PS>Test-WSMan -ComputerName server01

    Description
    ———–
    This command determines whether the WinRM service is running on the server01 computer named.

————————– EXAMPLE 3 ————————–

C:\PS>Test-WSMan -Authentication default

    Description
    ———–
    This command tests to see if the WS-Management (WinRM) service is running on the local computer using the authentication parameter.

Using the authentication parameter allows the Test-WSMan cmdlet to return the Operating System version.

————————– EXAMPLE 4 ————————–

C:\PS>Test-WSMan -ComputerName server01 -Authentication default

    Description
    ———–
    This command tests to see if the WS-Management (WinRM) service is running on the computer named server01 using the authentication parameter.

Using the authentication parameter allows the Test-WSMan cmdlet to return the operating system version.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkId=141464
    Connect-WSMan
    Disable-WSManCredSSP
    Disconnect-WSMan
    Enable-WSManCredSSP
    Get-WSManCredSSP
    Get-WSManInstance
    Invoke-WSManAction
    New-WSManInstance
    New-WSManSessionOption
    Remove-WSManInstance
    Set-WSManInstance
    Set-WSManQuickConfig