Posted by Shane Corellian on Wed, Aug 25, 2010
We have added some sick features to Admin Arsenal in version 1.5.
My favorite is the ability to extend the Admin Arsenal Tools menu by adding your own Custom Tools. A Custom Tool is a command that exists on the Admin Arsenal console machine. When the Custom tool is selected (either from the Tools menu or a keyboard shortcut that you assign) the command is executed along with any respective command line arguments.
Want to be able to automatically go to the C$ of a target computer? Go to your Admin Arsenal Preferences and, in the Custom Tools pane, add the following line:
Open C$ Share=explorer.exe "\\%TARGET%\C$"
The syntax for a custom tool line is
Name [;keyboard shortcut]=command [ARGS]
Admin Arsenal will contain the computer name in the %TARGET% variable.
If you use DameWare Mini Remote Control, you can have initiate a Remote Control session from within Admin Arsenal by adding a custom tool entry like this:
DameWare Remote Control;CTRL+ALT+Z="C:\Program Files (x86)\DameWare Development\DameWare Mini Remote Control\dwrcc.exe" -m:%TARGET% -a:1
See additonal arguments that can be passed to DameWare Mini Remote Control.
Would you like to automatically connect to a network registry? Feel free to download one of our free utilities called StartReg.exe. Place this file on your Admin Arsenal console machine and add the following line to your custom tools:
Connect Remote Registry;CTRL+SHIFT+E="StartReg.exe" %TARGET%
In the above example I didn't pass the Path for StartReg.exe because I put it in my System32 directory which is, obviously, included in my PATH variable.

See a Video example on Admin Arsenal's YouTube Channel
Note: Any download from our Free Utilities is not supported and is provided without warranty of any kind.
Posted by The Admin Arsenal Team on Wed, Dec 30, 2009
This is a phrase that you never want to hear when discussing a completed remote software deployment project.

Actually, due to its horrific grammar, this is a phrase that you never want to hear under ANY circumstance. Oh, and Yes, this is an actual quote.
No, the quote isn't from Deadwood or any other show which depicts uneducated ignoramuses getting by in a cruel world.
Yes, that quote was spoken by a man in his mid thirties who happened to be 2 months away from getting his grubby hands on his Master Degree (from a reputable university).
Why yes, it was missing a freeway exit outside of King Of Prussia, Pennsylvania that prompted my then co-worker to utter the words "Was that where we was supposed to went?" How'd you know?
About 5 months ago I wrote about how happy I was with Dameware Mini Remote Control. While I am still very happy with the product I did break a deployment rule that I know well. Basically I screwed up.
What did I screw up? I will sum it up with another quote (this one is actually famous): "Plan your dive and dive your plan." I learned this when I was getting certified for SCUBA. It basically means that we need to plan what we intend to do and then do what we actually planned.
I didn't actually do the due diligence that I should have when helping a customer with rolling out Dameware and as a result I made the management of the application a little more labor intensive. You see, in Dameware Mini Remote Control there are two methods for storing Remote Control configurations on target systems. The default and, apparently, most common method is via the file DWRCS.INI located in the %WINDIR%\System32 directory. The other method which I should have pursued was to store all the configuration data in the Windows registry.
This decision was really bad because I already have a method for collecting the values of certain registry keys from target systems and storing the data in an Inventory database. I could have, with a simple SQL query, been able to view ALL the Dameware remote control configurations for ALL of the customer's computers.
The fix is not as bad as you may think, but it does require that I rebuild the Dameware Mini Remote Control agent (for future deployments) and make file modifications to all of the computers that currently have the previously deployed agent.
I can do this quietly so as to not disturb the end users but I despise doing anything to production computers that isn't necessary. Deploying the agent with the correct* configuration in the first place would have been, ahem, much better. Needless to say, I am ready for the Windows Admin Drinking Game.
OK, so I did "dive my plan", but diving a crappy plan still sucks. I should have taken more time with my decision. I should have anticipated that modifications to the configuration were inevitable. While we can't necessarily anticipate WHICH configurations will be changed in any project we should know that SOME configurations will most assuredly be modified. Planning an efficient modification process is integral to any successful deployment.
So, when I fully realized my error I found myself muttering "Was that where we was supposed to went?"
* - Correct configuration depends on time, money, quality and blood alcohol content.