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 Adam Ruth on Fri, Apr 16, 2010
Photo by *yasuhiro
I find myself having to deal with Windows services quite a lot, probably more than the average system administrator. The two most common tools administrators use are the services.msc MMC snap-in and net.exe (net start and net stop, in particular.) One more tool that I keep close is sc.exe because it gives capabilities that you can't find in the other tools.
It provides pretty much everything that a developer can do when programming directly to the Service Control Manager. The commands that I use most often are create and delete. These are particularly useful when I'm writing a service and I need to test it on one or more machines.
Creating a Service
The create command has the following syntax:
sc.exe <server> create [service name] [binPath= ] <option1> <option2>…
Run "sc.exe create" to see all of the options. The ones you'll use most are:
- start= (auto, manual, disabled)
- obj= (account name)
- password= (password)
- DisplayName= (friendly name)
There are some gotchas that you may run into (I know I have!):
- If using PowerShell you need to use sc.exe instead of just sc since sc is an alias for the built-in cmdlet Set-Content.
- If you get the syntax wrong you won't get an explanation of what why, you'll only get the usage description so it can be difficult to track down typos.
- All of the options follow the same syntax of "binPath= path." Note that there is no space before the equal sign and a space afterwards. That's caught me many times, the command will choke on "binPath = path" and "binPath=path."
- You'll most likely need quotes in the binPath= parameter. For example if the service path is "C:\Program Files\Company\Name\Service.exe" -service you'll need to escape the quotes. This is done differently if you're using PowerShell or cmd.exe:
- PowerShell: sc.exe create name binPath= '\"C:\Program Files\Company\Name\Service.exe\" -service'
Note the \ before the double-quotes and the whole thing is wrapped in single-quotes. - cmd.exe: sc.exe create name binPath= """"C:\Program Files\Company\Name\Service.exe""" -service"
Note that it's wrapped in double-quotes and the inner quotes are three sets of double-quotes.
Editing a Service
There is a config command that lets you change all of the service's settings without re-creating it. It has the same options as the create command.
Deleting a Service
Deleting a service is a lot simpler:
sc.exe <computer> delete [service name]
If the service is still running when you do this, it will be "marked for deletion" which is a kind of limbo state where the service can't be controlled any more (can't be stopped.) If that happens, most of the time you can flush the delete by killing the service's process. In the rare case where that doesn't work, a reboot will be required.
Services on Other Computers
In order to work with services remotely on other computers you need to have File Sharing turned on and opened through a firewall. If you can get to a file share on the computer, you'll be able to modify its services.
Posted by Shawn Anderson on Fri, Feb 26, 2010
Photo by dybarber
Msiexec is a good friend to many an admin who deploys software remotely. It has great arguments (or switches) that can make your life as a Windows administrator much easier.
One of these is REBOOT=REALLYSUPPRESS
msiexec /i < your_msi_file > /q REBOOT=REALLYSUPPRESS
It does what it implies; it stops not only a reboot but any dialog that the user might see telling them that a reboot is necessary. If you absolutely don't want the system to reboot after an installation, I suggest making this a default argument for your remote deployments.
Now for my Billy Mays impersonation...
"But wait! There's more..."
Actually, there really is more. The error code.
Too often the error codes can be merely glanced at, or worse, outright ignored. It's a good idea to verify that they are a 0 value (meaning no errors detected). However, not all non-zero error codes are created equally. (Note: Error code and Exit code are synonomous).
3010 is an important code to detect. It's official definition:
3010 - The requested operation is successful. Changes will not be effective until the system is rebooted.
If your deployment requires a reboot and you suppress you may feel that you don't need this error code, but I would ask you to reconsider. The fact that this code was generated is further evidence that your package was installed the way that you expected it to be.
Any administrator who has been deploying for awhile will certainly have seen instances where an error code of 0 (successful) is returned on a remote software installation when upon further investigation it is determined that the software wasn't installed at all, or worse yet, wasn't installed correctly.
So... Really suppress the reboot. Evaluate the exit code. Move on to more important tasks (they're starting to pile up).
Windows Administrator? Follow me on Twitter @ShawnAnderson
Want to
deploy software remotely to all of your windows systems? Do it for free with our fully functional 30-day trial.
Posted by The Admin Arsenal Team on Fri, Dec 18, 2009
I've been playing with Sunbelt Software's CounterSpy lately. I think the product does what it claims to do fairly well however the management console is somewhat lacking.
I ended up writing my own CounterSpy inventory scanner to extract CounterSpy configurations from target systems. I can use this scanner to easily determine which systems need to be updated with either a new client or new C0unterSpy definitions.
I admit that I was excited when I came across the SBAMCommandLineScanner.exe utility. I thought, "Sweet, I can just use this little guy to find out the agent version, definition version, apply new updates, etc". Unfortunately I froze the CounterSpy service on two of my lab systems when I attempted to use this utility to A) extract the definitions version, and B) apply new definitions.
Anyway, I digress. Here is an easy way to extract the following information from CounterSpy agents.
To find out which CounterSpy Policy Service Server is assigned to a target go to the Registry path HKLM\SOFTWARE\SBAMSvc. The value of "PolicyServiceMachineName" will be your CounterSpy server.
To find out the version of the CounterSpy agent go to HKLM\Software\Sunbelt Software\Sunbelt Enterprise Agent and select (no surprise) "Version". I also use this location to extract the Install path of Sunbelt.
To find out the current definitions version I append the "Definitions" directory to the InstallPath value I extracted from the registry. For most of my systems the value is
C:\Program Files\Sunbelt Software\SBEAgent\Definitions
I parse the DefVer.txt file to extract the Definitions version as well as the date the new defs were applied.
You can also run the utility "SBAMCommandLineScanner.exe" and then extract the output however, as I mentioned earlier, I ran into problems where this very simple command wouldn't return at all and within a few minutes the CounterSpy service was hanging. Since I ultimately want to have this data extracted automatically via an inventory scan the last thing I want is to run an external process (SBAMCommandlineScanner) that doesn't return control.
Here is the very simple output of my utility. (I actually have it output into XML which ultimately goes into my database however I modified the output for this example). It gives me a one stop shop for my desired data.
CounterSpy really has proven to be a great product for finding and killing Adware and Malware. I just needed to streamline the available management capabilities a little bit.
Posted by The Admin Arsenal Team on Mon, Nov 30, 2009
Photo by foxtongue
Windows Server 2008 Server Core has always intrigued me and it's become one of those things that keeps simmering on my back burner waiting for me to find the time to dive in. But I could never figure out where to dig my teeth in. I installed it once (just to see it and be able to say that I did) and I was left staring at a blinking cursor and the realization that it was as far as I was going to get.
The main problem was that as much of a keyboard jockey as I am, there's so much to manage in Windows that I fall back on the GUI most of the time. I just don't have the time to learn all of the command line administrative tools. (It's not entirely my fault, Windows has always had a GUI so its command line tools are not front and center they way they are in the UNIX world.)
But now, I don't need to stumble around in the dark because I stumbled on a new white paper that elucidates all of remote admin options for Server Core. The paper is a joint project of Sander Burkouwer and Joachim Nässlander.
Server Core is now closer to coming off my back burner because I can chop hours off the learning curve. Thanks, guys!
Get the paper here.
Posted by The Admin Arsenal Team on Fri, Nov 13, 2009
Photo by Redvers
PowerShell, however, does have an equivalent. You can redirect to the built-in variable $null to get the same effect.
PS C:\> dir > $null
In addition to the $null variable you can also pipe output to the out-null cmdlet.
PS C:\> dir | out-null
This second version also has a little trick up its sleeve. Normally when running a GUI app from PowerShell, control is returned immediately to the command line and PowerShell doesn't wait for the GUI app to exit. This may not be what you want. For example, in my build scripts I have a program that generates the documentation, it's actually a GUI app that takes parameters and writes out the help files. I want my script to wait for this process to finish, so the normal behavior doesn't work for me. But, by piping the output of the GUI app to out-null then PowerShell will wait for the app to finish. You can see this yourself by running notepad.
PS C:\> notepad | out-null
Posted by The Admin Arsenal Team on Mon, Oct 26, 2009
Last week Microsoft released about 14 patches. I didn't want to distribute 14 different deployments to all of my computers so I went old school and just deployed using a single batch file.
- Contents of my batch file
- Directory of the deployment files. The batch file will call each of these patch files in succession.
I then opened up Admin Arsenal and chose to deploy to my Windows 2003 (x86) collection.
Pay particular attention to my deployment window. I check the "Include entire directory" checkbox. This way I can be certain that all the patch files (listed above) will ready for my batch file.
- Admin Arsenal Deployment window
Since I placed the the Command Line arguments in the actual script I didn't need to add them on the deployment window. I could have passed the arguments via the deployment window and have the deployment script reference the %1, %2 and %3 variables.
This is a simple and effective method for deploying applications and/or patches in rapid succession. This method is great for installing an application and then successive Service Packs or Updates.
Posted by The Admin Arsenal Team on Mon, Sep 28, 2009
Photo by Qfamily
The workstation component would only access the server on a mapped drive letter, the drive letter couldn't be local. No problem, I thought, I'll just map to the server share locally, as though I'm running off a normal workstation. No go, the workstation actually had the temerity to check if the map was to a shared volume on the local computer.
I wasn't sure what to do, my dad didn't want to buy another computer just for this one program. After some Googling (it may have actually been AltaVista-ing back then) I found the subst command. Subst is short for substitute (I guess, the documentation doesn't say.) It lets you create a drive drive letter that points to a local directory, it's like mapping to a local share but without having to share. That did the trick, it was enough to fool the workstation software into thinking it was talking to a remote server.
I've found this command useful over the years when I need to access a directory in a deep hierarchy multiple times, and it saves me from having to constantly navigate down into it. It was particularly useful back in the day when I spent most of my time on the command line and having to cd back and forth between 10 directory deep paths got really tedious.
Posted by The Admin Arsenal Team on Fri, Aug 28, 2009
Photo by shawncampbell
A command-line tool that I have found very useful lately is reg.exe, the command-line registry editor. It is particularly useful to make changes to computers remotely using Admin Arsenal's batch file deployment or remote command.
It has a number of different commands (see them by running reg /?) but the ones I use most are ADD and DELETE. It is available on all current versions of Windows so you don't need to worry about deploying it. It's particularly helpful to make a configuration change to a number of computers at a time without using a GPO and waiting for it to be applied. Recently I needed to enable unsolicited Remote Assist on a bunch of computers and reg.exe came to the rescue.
I created the following batch file:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fAllowUnsolicited /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fAllowUnsolicitedFullControl /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v AllowTSConnections /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fAllowToGetHelp /t REG_DWORD /d 1 /f
The using Admin Arsenal's software deployment, I pushed the batch file out to the computers and voilà Remote Assist was enabled.
Next time you need to make registry changes on more than one computer, keep this option in mind.
Posted by The Admin Arsenal Team on Mon, Aug 10, 2009
I've been a fan of Cygwin for a long time, it gives me access to some of my favorite tools from UNIX. I've been using it for years to get open source packages that work on Windows without much fuss.
What is Cygwin?
Cygwin is a UNIX layer on top of Windows, allowing many tools for UNIX to be ported to Windows. It's very common for open source projects to include a port to Cygwin which is pretty similar to porting over to another version of UNIX. To make matters even easier, the Cygwin distribution includes most of the popular open source programs pre-compiled and easy to install.
- Cygwin installer and a small handful of its available packages.
Here's a quick rundown of the tools in Cygwin that I use on a regular basis. I'm sure I can get versions of all of these native for Windows, but it's just too easy to install and update them with Cygwin.
ssh
I use SSH all of the time to connect to my servers over the Internet. Using its port forwarding to create secure tunnels that I can use for remote desktop or pretty much anything else I want, such as database connections. I wouldn't be caught on the Internet without it.
rsync
Rsync is, without a doubt, the best way to copy files over a slow WAN connection. I use Robocopy whenever I'm on my fast LAN, but rsync is my tool of choice when the link is slow because of the amazing way it sends only differences within a file. I can copy massive database backups in only a few seconds as it seeks out only the changed 20 MB in a 10 GB file.
grep
Whenever I need to find some text in file on my disk, I fall back on grep. I find it to be much more reliable and accurate than the Windows Explorer search, and it's very fast to boot.
bzip2/zip
I use these two compression tools depending on what I want to do with the file. I use zip in scripts to create files to send to others or to make public on our site (when I'm doing it one-off I typically use Windows Explorer's Send to Compressed folder.) I use bzip2 when I'm archiving for myself, since it compresses so much better than the standard zip. I hear good things about 7zip, though, and it may one day replace bzip2 in my toolbox.
less
Can't be beat for viewing text files on a command line.
tail
I quite often have to deal with text log files, usually as debugging output from a program. Using tail to see the last few lines or with the --follow option to watch the file as it changes is invaluable.
bash
I used to use bash all the time to make up for the scripting deficiencies of CMD.EXE, but I've switched over toPowerShell now.
Paths, the caveat.
One thing to be aware of is how paths work in Cygwin. Since it's essentially a UNIX clone on Windows it uses the UNIX path conventions. There are no drive letters and the path separator is / instead of \. This doesn't often come up much with the tools I use, but it can bite you occasionally if you're not aware. To get around the drive letter incompatibility Cygwin creates directories for the root of each of your drives under /cygdrive. So, using grep on your whole D: drive would look like this:
grep -rli "cygwin rocks!" /cygdrive/d