Graphical front ends for PowerShell? Here's a couple for you For many sysadmins Hyper-V Server is an area where Microsoft's TCO and ROI documents - built around the "Hyper-V Server is free" market-speak - fails to align with reality. If you're a PowerShell guru – or willing and able to use Windows 8 – then Hyper-V server mostly lines up with the Microsoft pitch. If you're a PowerShell …
Having the option for PowerShell commands (DOS Shell) is a decent idea, but forcing people to use PowerShell exclusively is a huge mistake. The reason GUI interfaces took off is they work nicely. As an Admin I would rather right click and change a check box on an Exchange mailbox than type a 240 character string where a single wrong switch invalidates the account.
I need technology to make me more efficient as an admin, not less.
Oddly I was reading a year-or-two-old article the other day on this, which was indicating that command line .. err .. commands (or more correctly, use of scripts to make sure all the options and flags are correct) *are* more effective and efficient than GUIs, the reasoning being that people are human and make mistakes, forget to set options, click the wrong tick box (particularly if an update moves things around). The main synopsis was "if it can be scripted, script it. If it can't be scripted, make a check list".
I've written bulk user import scripts in Powershell and in Perl and certainly a lot simpler, quicker and less prone to errors to run that, fed from a CSV file or database, than to sit around manually creating a couple of hundred users with point-and-click.
Not that anyone is taking the GUI away, but is nice that more and more features are being exposed to the command line.
Personally I quite like this way of working. I can still do most things via the GUI and the majority of wizards show the actual Powershell command that they're going to execute at the end.
Having a GUI present you with the Powershell is a great way to get a feel for it (and also see if the shell command might be quicker and easier next time). I'm no scripting expert but I'm building up a bank of scripts / commands which is, slowly, improving my skill.
Ultimately you should end up with the flexibility of both systems - GUI and shell - and hopefully the skill to use whichever is most appropriate.
Powershell is great they should force that down the shoulder of admins. It is worth it and it is so much easier to use the older alternatives (vbscript and accessing com objects).
Unlike the situation with the start menu for regular users people who are being paid to manage stuff should be forced to do it in an efficient manner. (Otherwise they won't).
Thing> Hello
Human> Hello thing
Thing> Hello human
Human> I'm tired of typing all these words
Thing> Here, have a GUI
Human> I'm restricted in my ability to access the lower level functions of this machine
Thing> Here, have a command line interface
Human> I'm tired of typing all these words
Thing> ...
"As such, most require you to run "Set-ExecutionPolicy Unrestricted" on the target server before launching the GUIs. Otherwise they won't work."
Needless to say but doing that is a very dumb idea. The problem is that PowerShell has many networking capabilities and by default is also capable of executing remotely located scripts. Not the behaviour you want if you can't trust the remote source.
Even so, I think Unrestricted wouldn't cope here because if you execute an unsigned script from the Internet under this policy then you'll get prompted before execution. The only policy which doesn't block anything nor gives you warnings or prompts is Bypass.
Either way; using both is a bad idea. There is a good reason why 'Restricted' is the default behaviour.
"There is a good reason why 'Restricted' is the default behaviour."
That may be, but you've not explained the reason particularly well. The author says you have to Set-ExecutionPolicy Unrestricted, or the gui tools don't work. Are you saying that's not the case? Or are you saying that generally running in that mode isn't advisable?
Saying something is "a very dumb idea" isn't particularly helpful if you don't explain why. You seem to imply that Unrestricted will run remotely located scripts if you set the policy to "Unrestricted", then change your mind in paragraph 2, and say you'll be prompted in advance.
I for one am unclear what you're trying to tell us.
Interestingly, Corefig doesn't set it to Unrestricted, it corrects that behaviour from the previous tool for the previous o/s that it's ported from.
From the Corefig docco - "WSF file sets PowerShell Execution Policy to "RemoteSigned" instead of "Unrestricted""
http://www.altaro.com/hyper-v/corefig-for-hyper-v-2012-is-released/
http://corefig.codeplex.com/
OK, I'm not an expert, but I'll try to (briefly) explain.
By default, Powershell is very restricted. It will not run scripts or anything, meaning you have to enter commands at the prompt (as the Bearded Gods intended).
Remoting is part of the Management Framework, so basically PS uses the built-in security mechanisms, not some separate tool.
By setting the execution-level to 'RemoteSigned' ,which you can only do as an Admin, you are only allowing scripts UP TO that level to run. AFAIK that means no double hops. Choosing 'Unrestricted' might be a QAD way to get your scripts to run, but best to use this only in a walled-off demo VM.
Hope this helps
Good to see that MS learned nothing from 2008/r2 - that to actually use the product you actually needed to go and find some 3rd party tools.
Snover's idealism is that everyone should love his warped Monad twisted language. I don't mind the API improvements and my ire is not aimed at those who liked to script, but it is at people who think that deep level scripting should be the default.
Snover and his team either believe - or have been led to believe that going forward they will run azure alike structures, and so will the customer. Based on this, everyone will have deep powershell skills.
As for "Set-ExecutionPolicy Unrestricted" - yes, well, it doesn't take much of an imagination to see what havoc can come from that. Get owned at a rate never before seen. It comes from the people who made autorun deafault - so its hardly a surprise.
What I will say is that I think its possible they put together the best API level for management yet, and that it should be a ground work for producing powerful UI tools and utiliites. Sadly, MS got this wrong as well. Instead of making great UI's - they focused on 'everyone learn Powershell' - instead of focusing in on the API for excellent UIs.
HyperV server 2008 was laughable in its poor state and only core configurator saved it. Having a core product so poor and only saved by a third party should have been a lesson. Instead its turned into an instruction manual.
It doesn't matter. The direction of the world is large upscale data centres and services. I can bitch and moan, but that doesn't change anything. The SME IT guy is being evolved out for a lower cost idea. The services may be worse, they may have bigger gremlins, but they will provide a solution at lower cost. This is really what MS is aiming at and its what its building for with Azure.
On premise people like me have become the enemy. All the stuff you see like powershell and the elimination of technet is a message. Its a fuck you middle finger to the bulk of microsoft customers and techs and admins. Well, Fuck you right back MS, now Win 8 / 81 is likely to go out here, and thus no likely move to 2012 / 2012r2.
DS
While I do see your point in some ways, the fact is sometimes a GUI is easier, sometimes a CLI is easier. See further up thread for a good example, changing a couple of settings on one machine, GUI>CLI, change settings on hundreds of machines, or repeatedly on one machine, CLI > GUI.
While not an admin myself I see this often in even single user windows sessions (I expect a downvote just for that admission!). Some tools are just easier to use in one mode than another. Nobody's forcing anyone to use a GUI front end, but it's making one available. More choice, I always see as positive.
An excellent justification for both. Which means that the ideal GUI tool would always offer the option to show the actual CLI commands being issued. Is that the case with these tools?
With that you'd follow Martin 71's example of "getting it right" via the GUI on one machine, then take the CLI output, parametrise it and copy&paste it into a CLI wrapper - for, while, whatever loops for N machines, M disks, and X files (har!).
I'm a Windows admin and have been through all sorts of automation work, from batch files to VBScript to PowerShell. The fact that people are developing front ends for PowerShell is very telling.
The concepts behind PS are great, and indeed, when you plan your scripts carefully, they save you time. For example, I don't have to write tons of wrapper functions to do things like processing the output of a command -- you have to do that in VBScript, but PowerShell allows you to feed the output of one command into another.
The idea is great, but in my mind the implementation could be better. My personal opinion of the actual language is that it's like Perl, bash, the .NET libraries, WQL and VBScript all managed to procreate and came up with PowerShell as the result. It has syntax concepts from all of these sources in it. Plus, with the length of cmdlet names, it's akin to the old OpenVMS commands that spanned several lines with 50 different switches.
Every Windows admin needs to come to terms with PowerShell. It's actually not awful once you learn how to think the way it wants you to. Remember all the WMI voodoo incantations that had to be done to get WSH scripts to do useful stuff? It's kind of like that, but less confusing. But definitely learn it. With Microsoft pushing the whole cloud thing, they're just going to get further and further away from tools that act on a single server and expect admins to know this stuff.
I'll agree with you that typing one cmdlt can take quite a while, but I find the syntax pretty forgiving.
Couldn't be bothered to define a variable? No worries says PS, I'll just create something that works.
Want to define your own variable? Go for it! Give it a starting value and type while you're at it.
The whole beauty of powershell is that it's dripping with CLI speed and flexibility? Why fire up ADU&C/Exchange, scroll or search through to find the object, double click, go to the tab, edit what I need, OK it, etc, etc - when I can just type a line of powershell? Oh, you want to do the same edit to another object? Press up to bring it back and edit the name? To a whole group? No problem.
I unashamedly <3 powershell...
Er, what? The fact you're working with structured objects rather than having to parse text output doesn't change the fact that it's often quicker to type a command line version of a complex operation than it is to do it visually with the GUI. Try deleting all xml files older than three days and larger than 4mb with a GUI, for example, it's a pain in the ass whereas it's trivial via a command line tool like Powershell.
I am not a coder/scripter by any means. I just wanted an easier way to do things. If you are a real coder/scripter and want to join me in making PSHVM a real polished powershell GUI then contact me James_Stephan @yahoo.ccom. If you got the skills lets see them, more action and less whining.
I've used powershell for non sys admin things such as creating unique build numbers on a shared project every time a build was executed. I ran into the execute script privilege problem. I found however I could run a batch file With a single line contains the whole script. Is this a security issue otherwise why prevent me executing the script in the first place.
The main reason for disabling scripting by default is to avoid PowerShell scripts running when clicked on from emails etc, it's a simple safety net. It doesn't cross a security boundary, so it's not technically a vulnerability (in any case if you can get a user to run a batch file, that could do anything PowerShell could do without ever running PowerShell)
"The actual utility of the application is hard to understate" probably isn't what you meant to say. "It's completely useless" would understate it.
Actually you can easily overstate it too. "It also makes peace in the Middle East and a really good cup of coffee, even if you don't like coffee" would be an overstatement. But if statements are limited to things that a sysadmin may want to do on servers, well, that is what this tool is made of.
Unix Admins have been doing it this way for decades. Write a script once, test it thoroughly, use it often, maybe give it a pretty GUI front end to launch it.
The Windows way requires you to do everything in a GUI - including remembering to check this, select that - no wonder Windows Admins are always firefighting.
I really quite heavily despise PowerShell. As a very experienced *nix admin I find it's mixture of super-verbose commands and lack of easy-access manual a real pain in the neck to use.
It's not helped by the fact that MS like to use mega-long alphanumeric IDs for all kinds of things which means your shell commands are often hundreds of characters long.
This is fine for scripting, but as an interactive user environment it utterly sucks.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
