http://social.technet.microsoft.

com/Profile/anurag%20juneja%20%5Bmsft%5D/activity

Set-ExecutionPolicy Unrestricted -Scope CurrentUser

Import-Module Appvclient

Add-AppvClientPackage -Path "C:\Winzip\Winzip.appv"

Publish-AppvClientPackage -Name "Winzip" (-global for ALLUSER installation)

unPublish-AppvClientPackage -Name "Winzip" (No need -global)

Remove-AppvClientPackage -Name "Winzip" (No need -global)

To Create Sequenig Application Using powershell:

New-AppvSequencerPackage –Name <name of Package> -

PrimaryVirtualApplicationDirectory <path to the package root> -Installer <path to

the installer executable> -OutputPath <directory of the output path>

Set-ExecutionPolicy
Windows PowerShell 4.0
Other Versions

This topic has not yet been rated - Rate this topic

Updated: October 17, 2013

Applies To: Windows PowerShell 4.0

Set-ExecutionPolicy
Changes the user preference for the Windows PowerShell execution policy.

Syntax
Copy
Parameter Set: Default
Set-ExecutionPolicy [-ExecutionPolicy] <ExecutionPolicy> [[-Scope]
<ExecutionPolicyScope> ] [-Force] [-Confirm] [-WhatIf] [ <CommonParameters>]

Detailed Description
The Set-ExecutionPolicy cmdlet changes the user preference for the Windows PowerShell
execution policy.

The execution policy is part of the security strategy of Windows PowerShell. It determines
whether you can load configuration files (including your Windows PowerShell profile) and run
scripts, and it determines which scripts, if any, must be digitally signed before they will run. For
more information, see about_Execution_Policies (http://go.microsoft.com/fwlink/?
LinkID=135170).

NOTE: To change the execution policy for the default (LocalMachine) scope, start Windows
PowerShell with the "Run as administrator" option.

Parameters
-ExecutionPolicy<ExecutionPolicy>

Specifies the new execution policy. Valid values are:

-- Restricted: Does not load configuration files or run scripts. "Restricted" is the default
execution policy.

-- AllSigned: Requires that all scripts and configuration files be signed by a trusted publisher,
including scripts that you write on the local computer.

-- RemoteSigned: Requires that all scripts and configuration files downloaded from the Internet
be signed by a trusted publisher.
-- Unrestricted: Loads all configuration files and runs all scripts. If you run an unsigned script
that was downloaded from the Internet, you are prompted for permission before it runs.

-- Bypass: Nothing is blocked and there are no warnings or prompts.

-- Undefined: Removes the currently assigned execution policy from the current scope. This
parameter will not remove an execution policy that is set in a Group Policy scope.

Aliases none
Required? true
Position? 1
Default Value None
Accept Pipeline Input? true (ByValue)
Accept Wildcard Characters? false

-Force

Suppresses all prompts. By default, Set-ExecutionPolicy displays a warning whenever you

change the execution policy.

Aliases none
Required? false
Position? named
Default Value none
Accept Pipeline Input? false
Accept Wildcard Characters? false

-Scope<ExecutionPolicyScope>

Specifies the scope of the execution policy. The default is LocalMachine.

Valid values are:

-- Process: The execution policy affects only the current Windows PowerShell process.

-- CurrentUser: The execution policy affects only the current user.

-- LocalMachine: The execution policy affects all users of the computer.

To remove an execution policy from a particular scope, set the execution policy for that scope to
Undefined.
When the value of the Scope parameter is Process, the execution policy is saved in the
PSExecutionPolicyPreference environment variable ($env:PSExecutionPolicyPreference),
instead of the registry, and the variable is deleted when the process is closed. You cannot change
the execution policy of the process by editing the variable.

Aliases none
Required? false
Position? 2
Default Value LocalMachine
Accept Pipeline Input? true (ByPropertyName)
Accept Wildcard Characters? false

-Confirm

Prompts you for confirmation before running the cmdlet.

Required? false
Position? named
Default Value false
Accept Pipeline Input? false
Accept Wildcard Characters? false

-WhatIf

Shows what would happen if the cmdlet runs. The cmdlet is not run.

Required? false
Position? named
Default Value false
Accept Pipeline Input? false
Accept Wildcard Characters? false

<CommonParameters>

This cmdlet supports the common parameters: -Verbose, -Debug, -ErrorAction, -ErrorVariable,
-OutBuffer, and -OutVariable. For more information, see about_CommonParameters
(http://go.microsoft.com/fwlink/p/?LinkID=113216).

Inputs
The input type is the type of the objects that you can pipe to the cmdlet.
  Microsoft.PowerShell.ExecutionPolicy,
System.String

You can pipe an execution policy object or a

string that contains the name of an execution
policy to Set-ExecutionPolicy.

Outputs
The output type is the type of the objects that the cmdlet emits.

 None

This cmdlet does not return any output.

Notes
 When you use Set-ExecutionPolicy in any
scope other than Process, the new user
preference is saved in the registry and
remains unchanged until you change it. When
the value of the Scope parameter is Process,
the user preference is stored in the
PSExecutionPolicyPreference environment
variable
($env:PSExecutionPolicyPreference), instead
of the registry, and it is deleted when the
session in which it is effective is closed.

If the "Turn on Script Execution" Group

Policy is enabled for the computer or user, the
user preference is saved, but it is not
effective, and Windows PowerShell displays
a message explaining the conflict. You cannot
use Set-ExecutionPolicy to override a Group
Policy, even if the user preference is more
restrictive than the policy.

Examples
-------------------------- EXAMPLE 1 --------------------------

This command sets the user preference for the shell execution policy to RemoteSigned.

Windows PowerShell
Copy
PS C:\> Set-ExecutionPolicy RemoteSigned

-------------------------- EXAMPLE 2 --------------------------

This command attempts to set the execution policy for the shell to "Restricted." The "Restricted"
setting is written to the registry, but because it conflicts with a Group Policy, it is not effective,
even though it is more restrictive than the policy.

Windows PowerShell
Copy
PS C:\> Set-ExecutionPolicy Restricted
Set-ExecutionPolicy : Windows PowerShell updated your local preference
successfully, but the setting is overridden by the group policy applied to
your system. Due to the override, your shell will retain its current effective
execution policy of "AllSigned". Contact your group policy administrator for
more information.
At line:1 char:20
+ Set-ExecutionPolicy <<<< restricted

-------------------------- EXAMPLE 3 --------------------------

This command gets the execution policy from a remote computer and applies that execution
policy to the local computer.

The command uses the Invoke-Command cmdlet to send the command to the remote computer.
Because you can pipe an ExecutionPolicy (Microsoft.PowerShell.ExecutionPolicy) object to Set-
ExecutionPolicy, the Set-ExecutionPolicy command does not need an ExecutionPolicy
parameter.

The command uses the Force parameter to suppress the user prompt.

Windows PowerShell
Copy
PS C:\> Invoke-Command -ComputerName Server01 -ScriptBlock {Get-
ExecutionPolicy} | Set-ExecutionPolicy -Force

-------------------------- EXAMPLE 4 --------------------------

This example shows how to set an execution policy for a particular scope.
The first command uses the Set-ExecutionPolicy cmdlet to set an execution policy of AllSigned
for the current user. It uses the Force parameter to suppress the user prompts.

Windows PowerShell
Copy
PS C:\> Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy AllSigned
-Force

The second command uses the List parameter of the Get-ExecutionPolicy cmdlet to get the
execution policies set in each scope. The results show that the execution policy that is set for the
current user differs from the execution policy set for all users of the computer.

Windows PowerShell
Copy
PS C:\>Get-ExecutionPolicy -List

Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser AllSigned
LocalMachine RemoteSigned
Windows PowerShell
Copy
PS C:\>Get-ExecutionPolicy
AllSigned

-------------------------- EXAMPLE 5 --------------------------

This command uses an execution policy value of Undefined to effectively remove the execution
policy that is set for the current user scope. As a result, the execution policy that is set in Group
Policy or in the LocalMachine (all users) scope is effective.

If you set the execution policy in all scopes to Undefined and the Group Policy is not set, the
default execution policy, Restricted, is effective for all users of the computer.

Windows PowerShell
Copy
PS C:\> Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Undefined

-------------------------- EXAMPLE 6 --------------------------

This command sets an execution policy of AllSigned for only the current Windows PowerShell
session. This execution policy is saved in the PSExecutionPolicyPreference environment
variable ($env:PSExecutionPolicyPreference), so it does not affect the value in the registry. The
variable and its value are deleted when the current session is closed.

Windows PowerShell
Copy
PS C:\> Set-ExecutionPolicy -Scope Process -ExecutionPolicy AllSigned

-------------------------- EXAMPLE 7 --------------------------

This example shows the effect of the RemoteSigned execution policy, which prevents you from
running unsigned scripts that were downloaded from the Internet. It also shows how to use the
Unblock-File cmdlet to unblock scripts, so that you can run them without changing the execution
policy.

The first command uses the Set-ExecutionPolicy cmdlet to change the execution policy to
RemoteSigned.

Windows PowerShell
Copy
PS C:\> Set-ExecutionPolicy RemoteSigned

The second command uses the Get-ExecutionPolicy cmdlet to get the effective execution policy
in the session. The output shows that it is RemoteSigned.

Windows PowerShell
Copy
PS C:\> Get-ExecutionPolicy
RemoteSigned

The third command shows what happens when you run a blocked script in a Windows
PowerShell session in which the execution policy is RemoteSigned. The RemoteSigned policy
prevents you from running scripts that are downloaded from the Internet unless they are digitally
signed.

Windows PowerShell
Copy
PS C:\> .\Start-ActivityTracker.ps1

.\Start-ActivityTracker.ps1 : File .\Start-ActivityTracker.ps1 cannot be

loaded. The file .\Start-ActivityTracker.ps1 is not digitally signed. The
script will not execute on the system. For more information, see
about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .\Start-ActivityTracker.ps1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess

The fourth command uses the Unblock-File cmdlet to unblock the script so it can run in the
session.

Before running an Unblock-File command, read the script contents and verify that it is safe.

Windows PowerShell
Copy
PS C:\> Unblock-File -Path Start-ActivityTracker.ps1

The fifth and sixth commands show the effect of the Unblock-File command. The Unblock-File
command does not change the execution policy. However, it unblocks the script so it will run in
Windows PowerShell.

Windows PowerShell
Copy
PS C:\> Get-ExecutionPolicy
RemoteSigned
PS C:\>Start-ActivityTracker.ps1
App-V 5.0 Client PowerShell Deep Dive

Rate This
5

Anurag Juneja [MSFT]

Anurag Juneja [MSFT]

2,117 Points310

Recent Achievements

Blog Conversation StarterNew Blog RaterNew Blog Commentator

View Profile

3 Dec 2012 6:55 AM

 Comments3

written by - Robert Doverspike, Software Development Engineer

PowerShell allows system admins to perform a vast array of tasks, all while leveraging the
support of .NET’s extensive libraries. Microsoft Application Virtualization has added
PowerShell cmdlet support to its 5.0 release, giving system administrators a powerful tool for
interfacing with the App-V 5.0 client. This article will cover a variety of common tasks to get
you started on managing the App-V 5.0 client through PowerShell, and cover the basics of
mixing different cmdlets together for more advanced scenarios.

· Managing Packages

· Managing Connection Groups

· Managing Publishing Servers

· Advanced Scripting

· Getting Help
Setup

To get started with Poweshell cmdlets, open an elevated (running as Administrator) PowerShell
window on your App-V 5.0 client machine and type the following command to load the App-V
5.0 client module cmdlets.

Import-Module AppvClient

If App-V is installed on the machine, but PowerShell cannot resolve AppvClient, try typing
Import-Module "C:\Program Files\Microsoft Application
Virtualization\Client\AppvClient\AppvClient.psd1" instead. The path can vary based on
installation configuration.

App-V Client Nouns

Since the format of a PowerShell cmdlet takes the form of Verb-Noun, it is useful to see all the
available nouns to understand the capabilities offered by the cmdlets.

Below is a listing of available nouns:

AppvClientApplication – An individual application that exists in an App-V package.

AppvClientConnectionGroup – A connection group used to allow multiple packages to interact

with one another in the same virtual environment, while remaining isolated from the host
operating system. See Deploying Connection Groups in Microsoft App-V v5 or Connection
Groups Internals (App-V 5.0) for more information on connection groups.

AppvClientConfiguration – A configuration value for a setting of the App-V Client (E.g.

EnablePackageScripts, AllowHighCostLaunch, PackageInstallationRoot)

AppvClientMode – The current mode (normal or uninstall) of the client.

AppvClientPackage – An App-V package that is available for use on the App-V Client.

AppvClientReport – An XML formatted report to be sent to an App-V Reporting Server that

aggregates usage data from App-V Clients.

AppvPublishingServer – An App-V server that hosts metadata about the packages available to
the client over the network.

AppvVirtualProcess – An App-V virtual process running a virtual app on the App-V client.

All cmdlets associated with a given noun can be viewed by typing Get-Help, for example

Get-Help AppvClientPackage
Get-Help also accepts wildcards in the name parameter. Add the –Full parameter to see the full
documentation.

Managing packages

Add and publish a package

The most basic operations needed to begin using virtual applications are to first add an App-V
5.0 package to the client on your machine, then publish the package so the current user can see it.

# Add the package at the specified location

$Contoso = Add-AppvClientPackage \\appvpackages\Contoso\ContosoApp.appv
# Publish the added package to the current user
Publish-AppvClientPackage $Contoso

Packages can be published globally to all users of a machine or to the current user. See Get-Help
Publish-AppvClientPackage for details.

Querying packages

As its name implies, Get-AppvClientPackage returns a list of all the App-V packages currently
on the system. By combining different parameter sets such as -Name and -Version, -PackageId
and -VersionId, you can query the packages on the system based on their attributes.

By specifying the -All switch parameter, this cmdlet will return the union of all packages on the
system, either added or published. In the absence of the -All switch parameter, Get-
AppvClientPackage by default will return only the currently published packages.

# Explicitly look up package by package GUID and version GUID

Get-AppvClientPackage -PackageId 43703c67-dbdc-4da5-beb4-4f84cc028c02
-VersionId 614c9aa3-8964-468d-a8b2-8c65215910d9 -All

Note that Get-AppvClientPackage returns nothing if no packages are found.

You may also look up packages using a second parameter set, which is by Name and Version.

# Look up package with the Name parameter set using * as a wildcard

Get-AppvClientPackage -Name Contoso* -Version 2*

Be aware of types! Remain aware of the object types that each cmdlet parameter set expects
using Get-Help. Note that in the below example the first block will not work as one would
initially expect, because PowerShell will automatically convert what looks like a GUID into a
String for the Name parameter set.

# Will not work because the GUID is treated as a String for the -Name
parameter
Get-AppvClientPackage 43703c67-dbdc-4da5-beb4-4f84cc028c02
# Works because $GUID is a GUID type, which matches the –PackageId parameter
$GUID = [GUID]"43703c67-dbdc-4da5-beb4-4f84cc028c02"
Get-AppvClientPackage $GUID

Remove an existing package

We have already shown how to add and publish an App-V 5.0 package, and now we’ll show the
converse operations – unpublish and remove.

# Search for existing package by name

$Contoso = Get-AppvClientPackage -Name Contoso*
# Unpublish the package
Unpublish-AppvClientPackage $Contoso
# Remove the package
Remove-AppvClientPackage $Contoso

Managing connection groups

Combining packages into a connection group

Packages can be combined in App-V 5.0 into an entity called a connection group. A connection
group allows you to run all of the virtual applications as a defined set of App-V 5.0 packages in a
single virtual environment. Refer to the links earlier in this blog post for more information on
maintaining and creating connection groups. Here we’ll show how to enable a connection group
with two packages.

# Add and publish a package

$Contoso = Add-AppvClientPackage \\appvpackages\Contoso\ContosoApp.appv
Publish-AppvClientPackage $Contoso

# Add and publish another package

$ContosoUI = Add-AppvClientPackage \\appvpackages\Contoso\ContosoUI.appv |
Publish-AppvClientPackage

As shown above, the output of one cmdlet may often be piped as the input to another cmdlet (if
the first cmdlet returns a valid parameter for the second cmdlet).

# Add the connection group, providing the path to its xml descriptor file
$ContosoFull = Add-AppvClientConnectionGroup
\\appvpackages\Contoso\ContosoAppWithUI.xml
# Enable the connection group
Enable-AppvClientConnectionGroup $ContosoFull

Similar to packages, connection groups can be enabled globally to all users of a machine or to
the current user. See Get-Help Enable-AppvClientConnectionGroup for details.
Managing publishing servers

Add and sync to a publishing server

Publishing servers host package metadata that can be synchronized with a client. The most
fundamental operation involves adding an existing publishing server and synchronizing its
metadata with your local client.

# Add a publishing server

$pubServer = Add-AppvPublishingServer -URL https://appvpublishing.contoso.com
-Name Alpha
# Sync the local client with the added publishing server
Sync-AppvPublishingServer $pubServer

Conditional backup publishing server

This is an example script which adds a backup publishing server conditional on the name of the
main publishing server.

$mainPub = Get-AppvPublishingServer 1
if ($mainPub.Name -eq "Alpha") {
$backupUrl = "https://alpha.backup.contoso.com"
}
elseif ($mainPub.Name -eq "Bravo") {
$backupUrl = "https://bravo.backup.contoso.com"
}
$backupPub = Add-AppvPublishingServer -URL $backupUrl -Name Backup

Advanced Scripting

To illustrate the value of using PowerShell to expose and interact with App-V Client
dynamically, here is an example of App-V Client cmdlets being used in an advanced scripting
scenario. This script roughly counts the number of seconds taken for the package to be fully
downloaded from the network.

# Add and publish the package

$package = Add-AppvClientPackage "\\appvpackages\package.appv"
| Publish-AppvClientPackage

# Start the mount operation in the background, passing in the package Name as
an argument
Start-Job {Get-AppvClientPackage $args[0] | Mount-AppvClientPackage }
-ArgumentList @($($package.Name))

# Count the seconds until the package is fully loaded

$i = 0;
while (($percentLoaded = $package.PercentLoaded) -lt 100) {
Write-Output "PercentLoaded for $($package.Name) is $percentLoaded";
$i++;
sleep(1);
};
Write-Output "$($package.Name) loaded in $i seconds.";
Getting Help

These examples should be enough to get you started, and to convince you that performing
complex automated App-V tasks can be executed trivially using PowerShell. You can find more
information on the cmdlets mentioned here, as well as others, in the official documentation for
all App-V Client cmdlets, available through the built in PowerShell help infrastructure. There are
just a few PowerShell cmdlets you’ll need to know to access the documentation.

To get a list of all of the AppvClient commands use Get-Command.

Get-Command -Module AppVClient

Again, for help on a specific cmdlet or all cmdlets with a given phrase use Get-Help <phrase>,
and you can add the -Full switch parameter for additional details.