Powershell cmdlets on client machines
Currently, PS cmdlets are only available on machines where the Console is installed. However, there are many things that an admin may want to do that would be made a lot easier if a large subset of those commands where available on the client machines. This would especially be helpful when running scripts during a Compliance Item, but would also make an impact during OSD Task Sequences, or Packages that deploy and run scripts to perform actions, etc.
Examples would be to query/modify collection membership during a script on the client, set primary user from client based on some criteria in a script, access software inventory FileID from client during Compliance, etc.
Certainly, I wouldn't expect the full set of cmdlets, but many of the "Get", and some of the "Set" cmdlets would be extremely helpful. For example, I wouldn't think it would be necessary to create a collection from the client, but I can see instances where I may want to check the membership of a collection, or to add the computer to a collection based on some local criteria that is not available via simple WQL queries.
I’m marking this as declined to return votes back to folks.
This isn’t something we plan on addressing. The main problem as mentioned before is that the PowerShell cmdlets require SMS Provider connectivity to work, and that in turn requires having a certain level of trusted site server access for the account executing the cmdlets.
We do support PowerShell remoting so you can run cmdlets from another machine that has the administrator console installed without having to install the console on the client machine that you’re currently connected to.
Thank you for the feedback. I think there are possibilities in some scenarios where this could be helpful, especially during OSD and Compliance. I would think that an account to use in these situations could be created, similar to the "Network Access Account", etc.
PowerShell Remoting is not an option, because when running scripts in such tasks as OSD and Compliance, you would have to hard code a password. Even encoding it with PowerShell is not a good idea, because anyone would have access to it.
Thank you for your work, and I look forward to the continued improvement of the product.
Sean Kearney commented
Actually here's a great post on a workaround from DexterPosh on doing the Cmdlets remotely - Interactive scripting against the SMS provider works fine.
Sean Kearney commented
Actually it SHOULD work right now. Using PowerShell Remoting which would allow you to work on the Remote Machine uses all of it's resources on your local system. The other solution is to use Implicit remoting in PowerShell which creates a copy of the Cmdlets locally but still points to all the resources remotely.
An additional thing to improve the Cmdlets is making them Discoverable on the Configuration Manager server. Here's a script I wrote on the Technet Gallery that will aid in this.
AdminAdam Meltzer (ConfigMgr Product Team) (Software Engineer, Microsoft Endpoint Configuration Manager) commented
These are interesting ideas but there's some sound technical reasons why this isn't feasible today. The main one is that the PowerShell cmdlets work against the SMS Provider, just like the administrator console. This means the account or credentials running the cmdlet must have access to the SMS Provider and the rights to perform the specific action. There's no concept of anonymous access to the SMS Provider.
You could potentially work around limitation this by having a web service that exposes this information that calls out to the cmdlets in its underlying implementation.
We hear you loud and clear that you'd like to be able to run the cmdlets without having the administrator console. Today, the cmdlets are also deeply intertwined with admin console code which is why it's a dependency.
We've been working on decoupling the cmdlets from the console and it's my hope that eventually you will be able to run the cmdlets completely standalone but this is some ways off. It is in our backlog and is a goal we are working toward.
Thanks again for your feedback and keep it coming!
Agreed!! This would help with client troubleshooting as well.
Christopher - I agree. This is an example of what I was envisioning.
It would be handy to have the ConfigMgr PowerShell module installed along with the client. We have a handful of deployments (OSD, Applications, and Packages) and use vbs to pull the device out of the collection after the installation. I'd very much prefer to use native PowerShell cmdlets to achieve this.