Sometimes a break is what you need...

Its been a few months now since I said I was close to releasing the toolkit to general public.  You may now commence producing the 100 lashings I deserve.

I'll wait.

No really.

Go -- I'll be right here waiting for you to get back to punish me.

Well for those of you who decided to stick around I have a few pieces of news regarding the toolkit - a few excuses and a few things that sound like excuses but really are not.

First thing first.  

Toolkit has moved onto the 3.4 version mark from 3.3.  A few optimizations have found there way in as well as a new outlookless email system through SMTP (and part of the reason for the delay) as well as a few new ways on how various items (external applications) were handled and streamlined more.  As part of this process I learned some new powershell techniques, was humbled by Don Jones through his books/web instruction on the correct design functions for powershell functions and learned a few lessons from Jon Acuff (release stuff that is good, not perfect - you will never release an item if you strive for perfection).

So that being said here is my commitment to the internet and to anyone who wants this tool released to them.

In its current version the toolkit will be uploaded to this site on Saturday 4/27/2013 sometime.  As part of this, I will HAVE to write some information on how to setup the toolkit in your environment - its fully configured as is now for my jobs environment and I have had the luxury of almost a year of use to fine tune everything - and an intimate knowledge of the logic behind the code as well.

You will not be so lucky at first.

You will be struggling to figure out how the inner logic of my brain works - hence why I need to write some documentation for you. That is why I am waiting until Saturday for you to get your hands on it.

What will happen after the saturday release?

  1. Documentation updated on a frequent and regular basis
  2. More and more and more and more and more of the code will be commented
  3. Code cleanup (yeah.....) this is needed as I review my old code and see stupid things I did that should be cleaned up
  4. Potentially some functions will move away from quest and to the native microsoft ad cmdlts (hey - I love quest - they are a lot easier in some things than microsoft and a lot more troublesome in others)
  5. Full compiled exes of the application will be available - most of the application will allow you to overwrite the functions so this will not be an issue provided you have an idea/know what you want to do with that section of code - and each time I update the code for work (in the main EXE) I will release an update to the website.
  6. Examples of how to customize the toolkit released here on a somewhat frequent basis to show how it can be extended easily (and really - it is really easy to extend it - I made it easy for you to extend and I will not even use that extension ability half of the time)
  7. A new support site just for the toolkit through - I'm serious about this toolkit
  8. I'll answer questions as fast as I can - although I provide no warranty on the toolkit and what it will/can do to your environment - that is your responsibility to test it out before moving into production (I can make this promise: I will not go all Bobby Tables on you on purpose at least)

So that is my commitment.  Saturday is close at hand.  

Caffeine come to me!

Toolkit | Get-Architecture | Select Part 2

Its been a little while since I was last able to update anything on the toolkit.  The holidays (and some other things) got all mixed up at once preventing me from doing what I wanted to do.  Because of these delays, I am a little behind in my plans to release the toolkit "out in the wild".

But not all is bad news.

Due to this delay, this has given me the chance to think about how to execute a feature that has been requested by someone in my company as well as someone who I used to work with.  Combining powershell's ability to dot execute along with the flexible config file architecture of Toolkit 3 allows for (with just a few lines of code in the toolkit) the ability for customized data to be placed on the Toolkit's screen. 

Since this is a relatively new feature and I'm still vetting it fully - I won't go into explaining how everything works quite yet with it - but once it's done I'll be sure to explain that information.

With that in mind I will now continue with the overview of the architecture of the toolkit.


If you understand scoping in powershell you will have no issues with the toolkit.  

Except for locally defined/used variables - almost all variables in the toolkit are defined at the scope level.  This allows you to easily grab and use the same variables that the core functions of the toolkit use in your external files which extend the application.  For the most part, this means you will not need to try to figure out a way to "hook" into the application to get the data to either display of manipulate, just call the variable and you have full access to it the same as the core toolkit would. 

[Architecture]::Function Overrides

One of the newer features of the toolkit is that it allows you to override almost all of the native functions built into the application.  Currently this is established in about 30% of all functions/events and as time permits the rest of the functions/events will be updated to allow for them to be overridden.  Every time the toolkit enters a function/event it checks to see if the corresponding override file exists.  If the override file exists, then the code in this override file is run instead of the native function.  This has multiple advantages - one being that if a native function does not do something you need it to do, you can take the native function and alter it to perform the tasks you need (and thanks to all the core variables being of the $script scope you can access all the core data) the function to do as well as manipulate the forms as needed.  This also allows you to tailor the application to your specific needs without having to re-deploy the application (if installed locally) or compile the PS1 files into EXE.

To be able to document what functions call what files  I am currently working on a wiki page listing all the native functions as well as the override files the application looks for.  The code for each function will be provided so you can use as much or as little of each function as needed.

While I originally intended (and still at some point may do so) include a utility for you to be able to pull up the latest code directly from the toolkit, I have found that devoting time to keeping the data up to date on a wiki may be the most beneficial way to keep this information update.

[Architecture]::Custom external EXE files with parameters

Perhaps the newest feature of the toolkit which made its way into production recently was the ability to add application buttons on the main screen of the toolkit to launch external applications and provide a method for passing parameters to these external applications.  This grants the toolkit some new power, as before the only way to extend it was using EXE files which were launched from the custom applications section - which passed no parameters to the launching application - or through hooking into the various custom hooks to add new features.  There was no way to launch one of the custom EXE files AND pass data to it.  To accommodate this the toolkit was recently expanded so that if various items in the main configuration file were filled in (see wiki for information once the wiki is online) up to three buttons would be displayed on the users tab screen with the ability to launch the exe and pass to the exe data through customized parameters established in the configuration file.  I'm currently looking to see if it is feasible to add this function (optional) to all of the externally launched applications - but for now three dedicated buttons/hooks have been created to accommodate this.

As things slowly start to return to normal, I plan on putting in a little more time/effort to get the toolkit released.  The next blog post I post on this will be related to the initial setup/configuration of the application to get it running with most (not all) of the options configured.  As soon as this is done and the core features documented in the wiki I will be ready to release the EXE and the source files for the toolkit to the general public.

Until next time.