While at MMS, I had a chance to submit a couple of feature requests to Jeffrey Snover and hope to get them into v2 on which they are working now. Of course my requests are related to PowerGUI and thus are probably not the same that command-line users would submit so I thought you might find them interesting:
- Provide meta-information about pipelining. You’d be surprised but right now there’s actually no way to automatically detect that results of, say, get-mailbox can be piped into move-mailbox, or get-group into get-groupmembership. If there were we could have PowerGUI automatically detect the links and actions existing in the system. Could be pretty cool!
- Have a Unique ID property for each object type. This requires a bit of explanation. Suppose you clicked Mailboxes and got a list of mailboxes displayed in PowerGUI. You select a few of them and then click one of the actions. Now here’s the question: What code should PowerGUI generate? If you applied a filter we would have just generated a where clause the conditions but manual selection is tough because you don’t know which properties to use to uniquely identify the selected objects for the code. Currently we use heuristics so for example if the objects are for Exchange 2007 the attribute to be used is Identity, etc.
Making cmdlets creators specify which attribute to use as the key would solve the issue. I don’t think it would be possible to make such a markup mandatory (backward compatibility and .net compatibility won’t allow that) but making it possible and a recommended best practice would be awesome.
Because of NDA (no-disclosure agreement) I cannot share information on the other work which PowerShell team is already doing. But it is all very impressive. I think by now everyone knows that one of v2 features would be remoting – something a lot of us want to have.By the way some kind of remoting are there already. For example:
- One could use WMI to manage remote computers. See the links and actions in the AD Computers PowerPack available from the PowerGUI.org Library.
- A lot of cmdlets already allow for remote capabilities: Exchange 2007 cmdlets and AD cmdlets don’t require you to install them on the actual Exchange server or Domain Controller (DC). You can put them (and PowerGUI) on any workstation and manage the system remotely.
- There are third-party implementations of PowerShell remoting.
Of course full implementation in the platform is going to be much easier and more consistent but the bottom line is that we are not entirely stuck here and that now is probably the best time to use blogs, newsgroups, and conferences to provide the PowerShell team with feedback and feature requests for v2. They are working on it and are listening.