Tag Archives: ProcessorArchitecture

Register-PSSessionConfiguration

NAME
    Register-PSSessionConfiguration

SYNOPSIS
    Creates and registers a new session configuration.

SYNTAX
    Register-PSSessionConfiguration [-AssemblyName] <string> [-ConfigurationTypeName] <string> [-ApplicationBase <string>] [-Name] <string> [-Force] [-MaximumReceivedDataSizePerCommandMB <double>] [-MaximumReceivedObjectSizeMB <double>] [-NoServiceRestart] [-ProcessorArchitecture <string>] [-SecurityDescriptorSddl <string>] [-ShowSecurityDescriptorUI] [-StartupScript <string>] [-ThreadApartmentState {STA | MTA | Unknown}] [-ThreadOptions {Default | UseNewThread | ReuseThread | UseCurrentThread}] [-Confirm] [-WhatIf] [<CommonParameters>]

DESCRIPTION
    The Register-PSSessionConfiguration cmdlet creates and registers a new session configuration on the local computer. This is an advanced cmdlet that is designed to be used by system administrators to manage customized session configurations for their users.

    Every Windows PowerShell remote session uses a session configuration. When users create a session that connects to the computer, they can select a configuration or use the default configurations that are registered when you enable Windows PowerShell remoting. Users can also set the $PSSessionConfigurationName preference Variable, which specifies a default configuration for sessions created in the current session.

    The session configuration configures the Environment for the session. You can define the configuration by using an assembly that implements a new configuration class and by using a script that runs in the session. The configuration can determine which commands are available in the session, and it can include settings that protect the computer, such as those that limit the amount of data that the session can receive remotely in a single object or command. You can also specify a security descriptor that determines the permissions that are required to use the configuration.

PARAMETERS
    -ApplicationBase <string>
        Specifies the path to the assembly file (*.dll) that is specified in the value of the AssemblyName parameter. Use this parameter when the value of the AssemblyName parameter does not include a path. The default is the current directory.

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

    -AssemblyName <string>
        Specifies the name of an assembly file (*.dll) in which the configuration type is defined. You can specify the path to the .dll in this parameter or in the value of the ApplicationBase parameter.

        This parameter is required when the ConfigurationTypeName parameter is specified.

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

    -ConfigurationTypeName <string>
        Specifies the fully qualified name of the Microsoft .NET Framework type that is used for this configuration. The type that you specify must implement the System.Management.Automation.Remoting.PSSessionConfiguration class.

        To specify the assembly file (.dll) that implements the configuration type, use the AssemblyName and AssemblyBase parameters.

        Creating a type allows you to control more aspects of the session configuration, such as exposing or hiding certain parameters of cmdlets, or setting data size and object size limits that users cannot override.

        If you omit this parameter, the DefaultRemotePowerShellConfiguration class is used for the session configuration.

        Required?                    true
        Position?                    3
        Default value                System.Management.Automation.Remoting.PSSessionConfiguration
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Force [<SwitchParameter>]
        Suppresses all users prompts and restarts the WinRM service without prompting. Restarting the service makes the configuration change effective.

        To prevent a restart and suppress the restart prompt, use the NoServiceRestart parameter.

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

    -MaximumReceivedDataSizePerCommandMB <double>
        Limits the amount of data that can be sent to this computer in any single remote command. Enter the data size in megabytes (MB). The default is 50 MB.

        If a data size limit is defined in the configuration type that is specified in the ConfigurationTypeName parameter, the limit in the configuration type is used and the value of this parameter is ignored.

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

    -MaximumReceivedObjectSizeMB <double>
        Limits the amount of data that can be sent to this computer in any single object. Enter the data size in megabytes (MB). The default is 10 MB.

        If an object size limit is defined in the configuration type that is specified in the ConfigurationTypeName parameter, the limit in the configuration type is used and the value of this parameter is ignored.

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

    -Name <string>
        Specifies a name for the session configuration. This parameter is required.

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

    -NoServiceRestart [<SwitchParameter>]
        Does not restart the WinRM service, and suppresses the prompt to restart the service.

        By default, when you enter a Register-PSSessionConfiguration command, you are prompted to restart the WinRM service to make the new session configuration effective. Until the WinRM service is restarted, the new session configuration is not effective.

        To restart the WinRM service without prompting, use the Force parameter. To restart the WinRM service manually, use the Restart-Service cmdlet.

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

    -ProcessorArchitecture <string>
        Specifies a processor architecture for the configuration. This value determines whether a 32-bit or 64-bit version of the process that hosts Windows PowerShell is started when the configuration is used. Valid values are x86, AMD64, and IA64.

        The default is determined by the processor architecture of the computer that hosts the session configuration.

        Required?                    false
        Position?                    named
        Default value                The processor architecture of the host computer.
        Accept pipeline input?     false
        Accept wildcard characters? false

    -SecurityDescriptorSddl <string>
        Specifies a Security Descriptor Definition Language (SDDL) string for the configuration.

        This string determines the permissions that are required to use the new session configuration. To use a session configuration in a session, users must have at least “Execute(Invoke)” permission for the configuration.

        If the security descriptor is complex, consider using the ShowSecurityDescriptorUI parameter instead of this parameter. You cannot use both parameters in the same command.

        If you omit this parameter, the root SDDL for the WinRM service is used for this configuration. To view or change the root SDDL, use the WS-Management provider. For example “Get-Item WSMan:\localhost\service\rootSDDL”. For more information about the WS-Management provider, type “Get-Help WSMan“.

        Required?                    false
        Position?                    named
        Default value                The value of the root SDDL
        Accept pipeline input?     false
        Accept wildcard characters? false

    -ShowSecurityDescriptorUI [<SwitchParameter>]
        Displays a property sheet that helps you to create the SDDL for the session configuration. The property sheet appears after you enter the Register-PSSessionConfiguration command and then restart the WinRM service.

        When setting the permissions for the configuration, remember that users must have at least “Execute(Invoke)” permission to use the session configuration in a session.

        You cannot use the SecurityDescriptorSDDL parameter and this parameter in the same command.

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

    -StartupScript <string>
        Specifies the fully qualified path to a Windows PowerShell script. The specified script runs in the new session that uses the session configuration.

        You can use the script to further configure the session. If the script generates an error (even a non-terminating error), the session is not created and the user’s New-PSSession command fails.

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

    -ThreadApartmentState <ApartmentState>
        Determines the apartment state of the threads in the session. Valid values are STA, MTA, and Unknown. Unknown is the default.

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

    -ThreadOptions <PSThreadOptions>
        Defines how threads are created and used when a command is executed in the session. Valid values are Default, ReuseThread, UseCurrentThread, and UseNewThread. UseCurrentThread is the default.

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

    -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
    Microsoft.WSMan.Management.WSManConfigContainerElement

NOTES

        To run this cmdlet on Windows Vista, Windows Server 2008, and later versions of Windows, you must start Windows PowerShell with the “Run as administrator” option.

        This cmdlet generates XML that represents a Web Services for Management (WS-Management) plug-in configuration and sends the XML to WS-Management, which registers the plug-in on the local computer (“New-Item WSMan:\localhost\plugin”).

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

    C:\PS>Register-PSSessionConfiguration -Name NewShell -ApplicationBase c:\MyShells\ -assemblyName MyShell.dll -configurationTypeName MyClass

    Description
    ———–
    This command registers the NewShell session configuration. It uses the ApplicationName and ApplicationBase parameters to specify the location of the MyShell.dll file, which specifies the cmdlets and providers in the session configuration. It also uses the ConfigurationTypeName parameter to specify a new class that further configures the session.

    To use this configuration, users would type “New-PSSession -configurationname newshell”.

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

    C:\PS>Register-PSSessionConfiguration -Name MaintenanceShell -StartupScript c:\ps-test\Maintenance.ps1

    Description
    ———–
    This command registers the MaintenanceShell configuration on the local computer. The command uses the StartupScript parameter to specify the Maintenance.ps1 script.

    When a user uses a New-PSSession command and selects the MaintenanceShell configuration, the Maintenance.ps1 script runs in the new session. The script can configure the session, including importing modules, adding Windows PowerShell snap-ins, and setting the execution policy for the session. If the script generates any errors, including non-terminating errors, the New-PSSession command fails.

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

    C:\PS>$sddl = “O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;FA;SA;GWGX;;WD)”

    C:\PS> Register-PSSessionConfiguration -Name AdminShell -SecurityDescriptorSddl $sddl -MaximumReceivedObjectSizeMB 20 -StartupScript c:\scripts\AdminShell.ps1

    Description
    ———–
    This example registers the AdminShell session configuration.

    The first command saves a custom SDDL in the $sddl Variable.

    The second command registers the new shell. The command uses the SecurityDescritorSDDL parameter to specify the SDDL in the value of the $sddl Variable and the MaximumReceivedObjectSizeMB parameter to increase the object size limit. It also uses the StartupScript parameter to specify a script that configures the session.

    As an alternative to using the SecurityDescriptorSDDL parameter, you can use the ShowSecurityDescriptorUI parameter, which displays a property sheet that you can use to set permissions for the session configuration. When you click “OK” in the property sheet, the tool generates an SDDL for the session configuration.

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

    C:\PS>$s = Register-PSSessionConfiguration -Name MaintenanceShell -StartupScript c:\ps-test\Maintenance.ps1

    C:\PS> $s

     WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Plugin

    Name                     Type                 Keys
    —-                     —-                 —-
    MaintenanceShell         Container            {Name=MaintenanceShell}

    C:\PS> $s.getType().fullname
    TypeName: Microsoft.WSMan.Management.WSManConfigContainerElement

    C:\PS> $s | Format-List -property *

    PSPath            : Microsoft.WSMan.Management\WSMan::localhost\Plugin\MaintenanceShell
    PSParentPath     : Microsoft.WSMan.Management\WSMan::localhost\Plugin
    PSChildName     : MaintenanceShell
    PSDrive         : WSMan
    PSProvider        : Microsoft.WSMan.Management\WSMan
    PSIsContainer     : True
    Keys             : {Name=MaintenanceShell}
    Name             : MaintenanceShell
    TypeNameOfElement : Container

    C:\PS> dir WSMan:\localhost\plugin

    Name                     Type                 Keys
    —-                     —-                 —-
    MaintenanceShell         Container            {Name=MaintenanceShell}
    microsoft.powershell     Container            {Name=microsoft.powershell}
    microsoft.powershell32    Container            {Name=microsoft.powershell32}

    Description
    ———–
    This example shows that a Register-PSSessionConfiguration command returns a WSManConfigContainerElement. It also shows how to find the container elements in the WSMan: drive.

    The first command uses the Register-PSSessionConfiguration cmdlet to register the MaintenanceShell configuration. It saves the object that the cmdlet returns in the $s Variable.

    The second command displays the contents of the $s Variable.

    The third command uses the GetType method and its FullName property to display the type name of the object that Register-PSSessionConfiguration returns.

    The fourth command uses the Format-List cmdlet to display all the properties of the object that Register-PSSessionConfiguration returns in a list. The PSPath property shows that the object is stored in a directory of the WSMan: drive.

    The fifth command uses the Get-ChildItem cmdlet to display the items in the WSMan:\LocalHost\PlugIn path. These include the new MaintenanceShell configuration and the two default configurations that come with Windows PowerShell.

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

    C:\PS>Register-PSSessionConfiguration -Name WithProfile -StartupScript add-profile.ps1

    # Add-Profile.ps1

    . c:\users\admin01\documents\windowspowershell\profile.ps1

    Description
    ———–
    This command creates and registers the WithProfile session configuration on the local computer. The command uses the StartupScript parameter to direct Windows PowerShell to run the specified script in any session that uses the session configuration.

    The content of the specified script, Add-Profile.ps1, is also displayed. The script contains a single command that uses dot sourcing to run the user’s CurrentUserAllHosts profile in the current scope of the session.

    For more information about profiles, see about_profiles. For more information about dot sourcing, see about_scopes.

RELATED LINKS
    Online version: http://go.microsoft.com/fwlink/?LinkID=144306
    about_Session_Configurations
    Disable-PSSessionConfiguration
    Enable-PSSessionConfiguration
    Get-PSSessionConfiguration
    Set-PSSessionConfiguration
    Unregister-PSSessionConfiguration
    WS-Management Provider

New-ModuleManifest

NAME
    New-ModuleManifest

SYNOPSIS
    Creates a new module manifest.

SYNTAX
    New-ModuleManifest [-Path] <string> -Author <string> -CompanyName <string> -Copyright <string> -Description <string> -FileList <string[]> -FormatsToProcess <string[]> -ModuleToProcess <string> -NestedModules <string[]> -RequiredAssemblies <string[]> -TypesToProcess <string[]> [-AliasesToExport <string[]>] [-ClrVersion <Version>] [-CmdletsToExport <string[]>] [-DotNetFrameworkVersion <Version>] [-FunctionsToExport <string[]>] [-Guid <Guid>] [-ModuleList <Object[]>] [-ModuleVersion <Version>] [-PassThru] [-PowerShellHostName <string>] [-PowerShellHostVersion <Version>] [-PowerShellVersion <Version>] [-PrivateData <Object>] [-ProcessorArchitecture {None | MSIL | X86 | IA64 | Amd64}] [-RequiredModules <Object[]>] [-ScriptsToProcess <string[]>] [-VariablesToExport <string[]>] [-Confirm] [-WhatIf] [<CommonParameters>]

DESCRIPTION
    The New-ModuleManifest cmdlet creates a new module manifest (.psd1) file, populates its values, and saves the manifest file in the specified path.

    Module authors can use this cmdlet to create a manifest for their module. A module manifest is a .psd1 file that contains a hash table. The keys and values in the hash table describe the contents and attributes of the module, define the prerequisites, and determine how the components are processed. Manifests are not required for a module.

    New-ModuleManifest creates a manifest that includes all of the commonly used manifest keys, so you can use the default output as a manifest template. To add or change values, or to add module keys that this cmdlet does not add, open the resulting file in a text editor.

    Each parameter of this cmdlet (except for Path and PassThru) creates a module manifest key and its value. In a module manifest, only the ModuleVersion key is required. However, several other parameters of this cmdlet are mandatory. As a result, you can type a “New-ModuleManifest” command without parameters and the cmdlet will prompt you for values for other commonly used keys. To leave the value empty, press ENTER.

    For a complete description of the format, effects, and requirements of a module manifest, see “How to Write a Module Manifest” in the MSDN (Microsoft Developer Network) library at http://go.microsoft.com/fwlink/?LinkId=143613.

PARAMETERS
    -AliasesToExport <string[]>
        Specifies the Aliases that the module exports. Wildcards are permitted.

        You can use this parameter to restrict the Aliases that are exported by the module. It can remove Aliases from the list of exported Aliases, but it cannot add Aliases to the list.

        If you omit this parameter, New-ModuleManifest creates an AliasesToExport key with a value of * (all), meaning that all Aliases that are exported by the module are exported by the manifest.

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

    -Author <string>
        Specifies the module author.

        This parameter is required by the cmdlet, but the Author key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates an Author key with the name of the current user.

        Required?                    true
        Position?                    named
        Default value                Name of the current user
        Accept pipeline input?     false
        Accept wildcard characters? false

    -ClrVersion <Version>
        Specifies the version of the Common Language Runtime (CLR) of the Microsoft .NET Framework that the module requires.

        If you omit this parameter, New-ModuleManifest creates a CLRVersion key with an empty string value.

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

    -CmdletsToExport <string[]>
        Specifies the cmdlets that the module exports. Wildcards are permitted.

        You can use this parameter to restrict the cmdlets that are exported by the module. It can remove cmdlets from the list of exported cmdlets, but it cannot add cmdlets to the list.

        If you omit this parameter, New-ModuleManifest creates a CmdletsToExport key with a value of * (all), meaning that all cmdlets that are exported by the module are exported by the manifest.

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

    -CompanyName <string>
        Identifies the company or vendor who created the module.

        This parameter is required by the cmdlet, but the CompanyName key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a CompanyName key with a value of “Unknown”.

        Required?                    true
        Position?                    named
        Default value                “Unknown”
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Copyright <string>
        Specifies a copyright statement for the module.

        This parameter is required by the cmdlet, but the Copyright key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a Copyright key with a value of “(c) <year> <username>. All rights reserved.” where <year> is the current year and <username> is the value of the Author key (if one is specified) or the name of the current user.

        Required?                    true
        Position?                    named
        Default value                (c) <year> <username>. All rights reserved.
        Accept pipeline input?     false
        Accept wildcard characters? false

    -Description <string>
        Describes the contents of the module.

        This parameter is required by the cmdlet, but the Description key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a Description key with an empty string value.

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

    -DotNetFrameworkVersion <Version>
        Specifies the version of the Microsoft .NET Framework that the module requires.

        If you omit this parameter, New-ModuleManifest creates a DotNetFrameWorkVersion key with an empty string value.

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

    -FileList <string[]>
        Specifies all items that are included in the module.

        This key is designed to act as a module inventory. These files are not automatically exported with the module.

        This parameter is required by the cmdlet, but the FileList key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a FileList key with an empty array value.

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

    -FormatsToProcess <string[]>
        Specifies the formatting files (.ps1xml) that run when the module is imported.

        When you import a module, Windows PowerShell runs the Update-FormatData cmdlet with the specified files. Because formatting files are not scoped, they affect all session states in the session.

        This parameter is required by the cmdlet, but the FormatsToProcess key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a FormatsToProcess key with an empty array value.

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

    -FunctionsToExport <string[]>
        Specifies the Functions that the module exports. Wildcards are permitted.

        You can use this parameter to restrict the Functions that are exported by the module. It can remove Functions from the list of exported Aliases, but it cannot add Functions to the list.

        If you omit this parameter, New-ModuleManifest creates an FunctionsToExport key with a value of * (all), meaning that all Functions that are exported by the module are exported by the manifest.

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

    -Guid <Guid>
        Specifies a unique identifier for the module. The GUID can be used to distinguish among modules with the same name.

        If you omit this parameter, New-ModuleManifest creates a GUID key in the manifest and generates a GUID for the value.

        To create a new GUID in Windows PowerShell, type “[guid]::NewGuid()”.

        Required?                    false
        Position?                    named
        Default value                A GUID generated for the module
        Accept pipeline input?     false
        Accept wildcard characters? false

    -ModuleList <Object[]>
        Lists all modules that are packaged with this module.

        Enter each module name as a string or enter a hash table with ModuleName and GUID keys. The hash table can also have an optional ModuleVersion key.

        This key is designed to act as a module inventory. These modules are not automatically processed.

        If you omit this parameter, New-ModuleManifest creates a ModuleList key in the manifest with an empty array value.

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

    -ModuleToProcess <string>
        Specifies the primary or “root” file of the module. When the module is imported, the members that are exported from the root module file are imported into the caller’s session state. Enter the file name of one script module (.psm1) or binary module (.dll).

        If a module has a manifest file and no root file has been designated in the ModuleToProcess key, the manifest becomes the primary file for the module, and the module becomes a “manifest module” (ModuleType = Manifest).

        To export members from .psm1 or .dll files in a module that has a manifest, the names of those files must be specified in the values of the ModuleToProcess or NestedModules keys in the manifest. Otherwise, their members are not exported.

        This parameter is required by the cmdlet, but the ModuleToProcess key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a ModuleToProcess key with an empty string value.

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

    -ModuleVersion <Version>
        Specifies the version of the module.

        This parameter is not required by the cmdlet, but a ModuleVersion key is required in the manifest. If you omit this parameter, New-ModuleManifest creates a ModuleVersion key with a value of “1.0”.

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

    -NestedModules <string[]>
        Specifies script modules (.psm1) and binary modules (.dll) that are imported into the module’s session state. The files in the NestedModules key run in the order in which they are listed in the value.

        Typically, nested modules contain commands that the root module needs for its internal processing. By default, the commands in nested modules are exported from the module’s session state into the caller’s session state, but the root module can restrict the commands that it exports (for example, by using an Export-Module command).

        Nested modules in the module session state are available to the root module, but they are not returned by a Get-Module command in the caller’s session state.

        Scripts (.ps1) that are listed in the NestedModules key are run in the module’s session state, not in the caller’s session state. To run a script in the caller’s session state, list the script file name in the value of the ScriptsToProcess key in the manifest.

        This parameter is required by the cmdlet, but the NestedModules key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a NestedModules key with an empty array value.

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

    -PassThru [<SwitchParameter>]
        Writes the resulting module manifest to the console, in addition to creating a .psd1 file. By default, this cmdlet does not generate any output.

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

    -Path <string>
        Specifies the path and file name of the new module manifest. Enter a path and file name with a .psd1 file name extension, such as “$pshome\Modules\MyModule\MyModule.psd1”. This parameter is required.

        If you specify the path to an existing file, New-ModuleManifest replaces the file without warning unless the file has the read-only attribute.

        The manifest should be located in the module’s directory, and the manifest file name should be the same as the module directory name, but with a .psd1 file name extension.

        Note: You cannot use Variables, such as $pshome or $home, in response to a prompt for a Path parameter value. To use a Variable, include the Path parameter in the command.

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

    -PowerShellHostName <string>
        Specifies the name of the Windows PowerShell host program that the module requires. Enter the name of the host program, such as “Windows PowerShell ISE Host” or “ConsoleHost”. Wildcards are not permitted.

        To find the name of a host program, in the program, type “$host.name”.

        If you omit this parameter, New-ModuleManifest creates a PowerShellHostName key with an empty string value.

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

    -PowerShellHostVersion <Version>
        Specifies the minimum version of the Windows PowerShell host program that works with the module. Enter a version number, such as 1.1.

        If you omit this parameter, New-ModuleManifest creates a PowerShellHostName key with an empty string value.

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

    -PowerShellVersion <Version>
        Specifies the minimum version of Windows PowerShell that will work with this module. Enter 1.0 or 2.0. Requirements for versions greater than 2.0 are not enforced.

        If you omit this parameter, New-ModuleManifest creates a PowerShellVersion key with an empty string value.

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

    -PrivateData <Object>
        Specifies data that is passed to the module when it is imported.

        If you omit this parameter, New-ModuleManifest creates a PrivateData key with an empty string value.

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

    -ProcessorArchitecture <ProcessorArchitecture>
        Specifies the processor architecture that the module requires. Valid values are x86, AMD64, IA64, and None (unknown or unspecified).

        If you omit this parameter, New-ModuleManifest creates a ProcessorArchitecture key with an empty string value.

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

    -RequiredAssemblies <string[]>
        Specifies the assembly (.dll) files that the module requires. Windows PowerShell loads the specified assemblies before updating types or formats, importing nested modules, or importing the module file that is specified in the value of the ModuleToProcess key.

        Use this parameter to list all the assemblies that the module requires, including assemblies that must be loaded to update any formatting or type files that are listed in the FormatsToProcess or TypesToProcess keys, even if those assemblies are also listed as binary modules in the NestedModules key.

        This parameter is required by the cmdlet, but the RequiredAssemblies key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a RequiredAssemblies key with an empty array value.

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

    -RequiredModules <Object[]>
        Specifies modules that must be in the global session state. If the required modules are not in the global session state, attempts to import this module will fail.

        Enter each module name as a string or enter a hash table with the ModuleName and GUID keys. The hash table can also have an optional ModuleVersion key. For more information, see the examples.

        Windows PowerShell does not import required modules automatically. It verifies only that the required modules are present. However, modules can include scripts (.ps1) that import the required modules into the global session state.

        If you omit this parameter, New-ModuleManifest creates a RequiredModules key with an empty array value.

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

    -ScriptsToProcess <string[]>
        Specifies script (.ps1) files that run in the caller’s session state when the module is imported. You can use these scripts to prepare an Environment, just as you might use a login script.

        To specify scripts that run in the module’s session state, use the NestedModules key.

        If you omit this parameter, New-ModuleManifest creates a ScriptsToProcess key with an empty array value.

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

    -TypesToProcess <string[]>
        Specifies the type files (.ps1xml) that run when the module is imported.

        When you import the module, Windows PowerShell runs the Update-TypeData cmdlet with the specified files. Because type files are not scoped, they affect all session states in the session.

        This parameter is required by the cmdlet, but the TypesToProcess key is not required in the manifest. If you omit this parameter and do not enter a value when prompted, New-ModuleManifest creates a TypesToProcess key with an empty array value.

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

    -VariablesToExport <string[]>
        Specifies the Variables that the module exports. Wildcards are permitted.

        You can use this parameter to restrict the Variables that are exported by the module. It can remove Variables from the list of exported Variables, but it cannot add Variables to the list.

        If you omit this parameter, New-ModuleManifest creates a VariablesToExport key with a value of * (all), meaning that all Variables that are exported by the module are exported by the manifest.

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

    -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
    None or System.String
        By default, New-ModuleManifest does not generate any output. However, if you use the PassThru parameter, it generates a System.String object representing the module manifest..

NOTES

        Module manifests are usually optional. However, a module manifest is required to export an assembly that is installed in the global assembly cache.

        To add or change files in the $pshome\Modules directory (%Windir%\System32\WindowsPowerShell\v1.0\Modules), start Windows PowerShell with the “Run as administrator” option.

        A “session” is an instance of the Windows PowerShell execution Environment. A session can have one or more session state. By default, a session has only a global session state, but each imported module has its own session state. Session states allow the commands in a module to run without affecting the global session state.

        The “caller’s session state” is the session state into which a module is imported. Typically, it refers to the global session state, but when a module imports nested modules, the “caller” is the module and the “caller’s session state” is the module’s session state.

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

    C:\PS>New-ModuleManifest

    Path: C:\Users\User01\Documents\WindowsPowerShell\Modules\Test-Module\Test-Module.psd1
    NestedModules[0]: BackgroundModule.psm1
    Author: Jinghao Liu
    CompanyName: Fabrikam, Inc.
    Copyright: Copyright © 2009 Liu Jinghao. All rights reserved.
    ModuleToProcess: TestModule.psm1
    Description: Cmdlets to find common errors in scripts.
    TypesToProcess[0]: TestTypes.ps1xml
    FormatsToProcess[0]: TestFormat.ps1xml
    RequiredAssemblies[0]: Test.dll
    FileList[0]: Test-Module.psd1
    FileList[1]: Test-Module.psm1
    FileList[2]: BackgroundModule.psm1
    FileList[3]: TestTypes.ps1xml
    FileList[4]: TestFormat.ps1xml
    FileList[5]: Test.dll
    FileList[6]: TestIcon.ico

    Description
    ———–
    This command creates a new module manifest. The cmdlet prompts you for the parameters that it requires, including the Path parameter, and creates a manifest file in the specified location.

    The output of this command shows sample responses to the prompts. To use default values, press ENTER.

    The actual prompt, and its handling of quoted and non-quoted phrases, depends on the host program in which Windows PowerShell is running.

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

    C:\PS>New-ModuleManifest -PowerShellVersion 1.0 -AliasesToExport JKBC, DRC, TAC

    Description
    ———–
    This command creates a new module manifest. The command includes parameters that the cmdlet does not require (or prompt for). You can include other manifest key values at the prompt.

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

    C:\PS>New-ModuleManifest -RequiredModules FileTransfer,@{ModuleName=”BackgroundModule”;GUID=”486569a2-2784-48bf-af15-70ba837a64d0″;ModuleVersion=”3.5″}

    Description
    ———–
    This example shows how to use the string and hash table formats of the RequiredModules parameter value. Strings and hash tables can be used in the same command.

    This command commands creates a module manifest for a module that requires the FileTransfer module and a (fictitious) module named “BackgroundModule”.

    The command uses a string format to specify the name of the FileTransfer module and the hash table format to specify the name, a GUID, and a version of the BackgroundModule.

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