|
Powershell on itself does have really nice design decisions, but does not interact well with the whole system, leading to interoperability, portability issues and being clunky to use, in my view. It looks like PS is designed more towards DevOpsing (let developers do some administrative tasks in a familiar environment) than systems administration. Some of the rough edges I have encountered in the past: The whole point about piping objects (.NET class instances, sort of) around is really awesome, except that even on 8.1 (did not check on 10) standard utilities like ipconfig output wall of text, which has to be string-parsed. To be fair, there are cmdlets for most if not all subsystems, except that wrappers are sometimes too shallow, e.g. System.ServiceProcess.ServiceController returned by Get-Service does not expose delete(), so you have to resort to WMI. I have not used PS extensively enough, but would not be surprised if some tasks would require one to resort to wmic, netsh or similar tools. Powershell is not automatically updated, so you can find anything between 1 to 5 and anything portable has to be written for 1. e.g. Get-Service, which is in global namespace, is available since 3. IIRC W7 ships with 2. Powershell allows to use .NET directly, e.g. spawn process with [System.Diagnostics.Process]::Start, except as with above, you have no idea which version of .NET is available on target system. I found no other way to gain administrative privileges except for relaunching itself in administrative context. PS ISE could be used to incrementally write and debug scripts by directly fine tuning each command, except that it is non-interactive, so utilities asking for password are kind of painful. |