Jan 08, 2015 - 0 Comments - Virtual Vibes -

Running App-V 5.0 Commands on a Remote Machine with or without PSRemoting

Since the introduction of App-V 5.0 and the PowerShell commands which we have come to know and love there has always been the question around ways we can execute these commands remotely. As more and more organisations start to look at how they go about supporting their App-V environments and build up their own tooling, whether it be for desktop support activities or cache maintenance, the question about remote management arises.

Now the obvious answer for running PowerShell commands on a remote endpoint is enabling and leveraging PSRemoting however I have found certain organisations tend not to allow this feature to be enabled over security concerns. Lets take a look at the options either way:

With PSRemoting

PSRemoting is very powerful allowing us to run PowerShell commands on a remote machine as if it was being run locally. First thing to do is enable PSRemoting:

1. Enable PSRemoting

There are various ways to enable PSRemoting which basically needs the WinRM service, the easiest way to do it across multiple machines is via Group Policy:

Just open: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service 

Enable the Allow Remote Server management through WinRM policy setting.

winrm1

Alternatively if you are just testing you can enable it on a particular machine using the Enable-PSRemoting cmdlet.

enablepsr2

Click here to read more on TechNet about the Enable-PSRemoting cmdlet.

You can test connectivity from a remote machine using Test-WsMan COMPUTERNAME

testpsr

Now all you need to do is run your commands!

2. Use PSRemoting

There are two main ways you can run your commands, either by issuing a single command or via an interactive PowerShell session.

To issue a command use the following syntax:

Invoke-Command -ComputerName COMPUTERNAME -ScriptBlock { COMMAND} -credential USERNAME

For example here I have remotely removed a package from cache:

psr1

We can do the same thing from an interactive console if we wanted to run more than one command:

Enter-PSSession -ComputerName COMPUTERNAME -Credential USERNAME

psr2

Above you can see how I am using an interactive session to interact with my remote client by querying a package and then removing it. To be honest this is just the tip of the iceberg, there is so much more you can do. I have seen some organisations write their own custom tools which use PSRemoting to enable them to support and maintain their environment. If your in the same position hopefully you can leverage the same techniques, better yet why not check out some of the toolsets already out there, my favourite is Bram Wolfs App-V Scheduler – which amongst other features includes much more user friendly way to query remote endpoints using its Central View console.

Without PSRemoting

So what if PSRemoting is disabled in your environment and restricted due to organisational policies? Well all is not lost! Recently someone from a large insurance company contacted me about this scenario and was kind of enough to share how they worked around not having PSRemoting enabled (Thanks Gyan!).

The workaround involves invoking PowerShell via WMI using the Create method of Win32_Process:

1. Assign to Variable

First thing we need to do is assign the WMI Class Win32_Process of the remote machine to a variable from our local machine:

$Process = [WMICLASS]”\\COMPUTERNAME\root\cimv2:Win32_Process”

wmiclass

2. Invoke Process

So now all we need to do is utilise the Create method of Win32_Process to invoke whatever we want. In this case we want to use PowerShell to remove a package from cache on a remote machine:

$Process.Create(“PowerShell.exe Remove-AppvClientPackage PACKAGENAME”)

wmiclass2

What the above will go and do is go invoke PowerShell on the remote machine and run my specified command, so one minute I have my package and next minute it’s gone! The great thing about all this is it doesn’t need PSRemoting enabled as its all done over WMI. The not so great thing is the feedback, as you can see from above the returned information once issuing the command isn’t that meaningful.

We can however query WMI to find out if the package is there:

Get-Wmiobject -ComputerName COMPUTERNAME -NameSpace Root\APPV -Class AppvClientPackage | where-object {$_.Name -eq “PACKAGENAME”}

wmiclass4

Above is the output you can expect when the package is present, you will get a null return if the package isn’t there. There is a lot more you can do with the WMI provider for App-V to query and execute commands however it probably just needs a bit more investment of time compared to using remote PowerShell.

So in summary if PSRemoting is enabled in your environment you can very easily begin to put together your remote support solutions or even look at some of the third party tools out there already. If PSRemoting is restricted in your environment then WMI is your answer, it may be a little harder to get familiar with but it does offer a lot of potential to act remotely.