This Sunday at midnight PST marks the closing of our second annual PowerPack Challenge contest. The rules of this contest are very simple: create a new PowerPack or modify one of your existing PowerPacks and submit it to the contest folder in the PowerPack Library for a chance to win some cool prizes. Now you might be thinking: "Sunday, but that’s just three days away…I don’t have time to put together an entry between now and Sunday. Besides, I want my weekend to myself!" Well, you’re in luck my friend because you don’t need three days…you only need 10 minutes (well, 10 minutes after you watch a screencast showing what you can do with PowerShell, the PowerGUI Admin Console, and 10 minutes of your time). That’s not even going to take up your whole lunch hour on Friday, and if you plan to go out for lunch you could make your PowerPack during your afternoon break instead!
Here’s all you need to do:
1. Bookmark the PowerPack section of the wiki. I published a big update to our wiki earlier this week and it should be able to answer a lot of questions you might have. Don’t read the whole thing right now though, that might take too long and what you really want to do right now is explained in the next step.
2. Watch this screencast (also shown below on YouTube) that shows how I created a cool Windows Server Roles and Features PowerPack from scratch earlier today and published it to the PowerPack Library in only 10 minutes. The PowerPack even has dynamic nodes generated from 4 script nodes, which used to be quite a lot of work but thanks to the AdminConsole module they are much, much easier now. In fact, if you pay close attention to the screencast, you’ll see that all of the functionality in the PowerPack itself is done with only 7 lines of PowerShell script plus one basic node and two basic actions — that’s pretty amazing. The entire screencast is longer than 10 minutes because I needed to explain a few things before and after the demonstration, but the creation and publishing of the PowerPack itself is done in only 10 minutes during the screencast.
Now that I’ve armed you with the wiki documentation and the screencast demo, I’ll be looking forward to seeing your PowerPacks in the PowerPack Library after your lunch or afternoon break! 😉
Good luck with your PowerPacks!
Kirk out.
| Share this post: |  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Poshoholic 
[…] PowerGUI PowerPack development is quite fast and easy. You can refer to Kirk Munro’s post on http://poshoholic.com. This is just the initial release and I will update this with more […]
[…] As a background, PowerGUI Admin Console was designed with extensibility in mind and has a notion of PowerPacks. Basically, the console is simply displaying and executing the PowerShell code supplied in the PowerPack add-ons you load. Kirk has created a great PowerPack step-by-step tutorial/reference, and shot a ten-minute screencast on that topic. […]
Nice job guys!
This is really nice, but some functions seems to work only for properly defined types (C# types).
The Add-AdminConsoleDynamicNodeAssociation -Type … will not work with a Type manually added to a custom PSobject (by using $obj.Psobject.typenames.insert() ), because the casting $type = [Type]$typeName in the function will raise an exception.
Is there a work around this that does not involve creating a C# class for the object and doing an Add-type?
I had a look at the AdminConsole.psm1 file and it seems that it’s using the [type]$type only as a key for the hashtable. can we remove the cast so that we can have it either as a string or as a type without affecting the functionality?
Or am I simply missing someting obvious?
Any help / direction would be much appreciated!
Thanks.
I’m glad you like it. This was a step towards what I hoped would become a feature in the PowerGUI Admin Console at some point, but Quest pulled back on its investment in PowerGUI before we could make that happen.
I haven’t looked at this PowerPack in a long time (since I left Quest in August 2011), and I don’t have time to dig into it right now so I can’t provide you an easy answer to this right off the top of my head. If I recall correctly how it worked though, what you’re saying sounds about right, so instead of keying on [type], it could do two things: if the type is a an ETS type name (which you could tell by trying to convert it to a type using -as [Type] instead of a direct typecast), then use the string as the key; otherwise use the type as the key. I think you need to use string or type because this module supports both specific (base) types and derived types, and if you switch to just string you’ll only get support for the base types. I would give that a try and see if that fixes your problem.
Don’t forget that you’ll have to fix it in multiple places though: when the key is created and added to the hash table as well as whenever the key is looked up in the hash table. In both places you want to be consistent with whatever is defined as the key. You could probably create a helper function that determines the key based on the object as I described already, and then use that helper function to get the key from the object instead of typecasting.