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, Jul 09, 2010
It's a question that has been on the minds of system administrators for a long time. As the number of laptops (and now slate devices and even phones) continues to grow and displace desktops, so does the management headache. At some point, it seems, that desktops themselves will become extinct leaving only servers and portable devices left to manage.
Farhad Manjoo proclaims the imminent death of desktops at Slate, he makes some very good points. Eric Raymond makes some good counter-points about how peripherals (especially screens and keyboards/input devices) will always keep people tied to a desk. I think that they may be talking past each other, at least from the perspective of IT folks.
From the standpoint of managing computers, there isn't much (if any) difference between a truly portable computer and one that can be moved between office and home. It's the fact that the computer is used in different environments and at different times that creates the management friction. Even if a user lugged their big, boxy desktop computer between home and work (I've known people to actually do this) it's still a greater burden on system management than a truly portable computer that never leaves the office.
So, while the death of the desktop PC may be exaggerated in the sense that there will continue to be a "desk" involved most of the time, we are soon to see computers moving from desk to desk as the standard and the static workstation becoming the specialized, niche product.
Also, I'd like to add that I can envision a world where screens and keyboards will become unnecessary. I can see wearable computers become more and more practical over time. For those that scoff, I remind them that people scoffed at the ideas of laptops after seeing the first portable computers. I would love to be able to look up IMDB to win bets without even moving out of my hammock or so much as picking up anything. That's when my Homer-Simpson-esque dreams can finally come true.
Posted by Shane Corellian on Fri, Jun 11, 2010
In the course of our duties as Sys Admins I'm sure we've all "pushed the wrong button" a few times. If you haven't yet, you probably haven't been a Sys Admin very long.
About 10 years ago while working on a project which was wrought with political and technical paranoia I decided to prepare my own "Lysine Contingency" in the event that the political hailstorm became too much for me to handle. I first heard the term Lysine Contingency (LC) from Jurassic Park. I was always intrigued by the idea that Samuel L.'s character introduced. Certain destruction to the park's dinosaurs if a problem occurred that was simply unmanageable.
A Lysine Contingency is not your normal Change Management Rollback plan. It is basically you screaming "MISSION COMPROMISED! ABORT ABORT".
So, I want to offer some things I have learned about Lysine Contingency plans.
Points to consider:
- How was the change implemented?
- Were there multiple execution points such as Group Policy, Software Deployment, Login Scripts, Manual Installations, cron jobs or other local schedulers?
- Which execution point can be used to produce the greatest yield on your rollback? If you can hit 80% of your computers in 20 minutes with Software Deployment vs. 1 day with Group Policies then it's obvious where you should place your focus.
- Can the change be rolled back or otherwise mitigated without affecting other production systems, users or applications?
- Does your change require a reboot of the target system or application?
- What, if any, are the dependent services or applications?
- Will any data be lost? Are there other methods of removing the change that may take longer but save the data?
- Do you need the cooperation of any external entity?
- Are you allowed to deploy software but you're not allowed to modify GPOs? Are the GPOs part of your LC?
- The best Lysine solutions are the solutions that don't require anyone else but you. In a serious do-or-die situation you don't want to rely on the guy who's always on a smoking break or the lady who has more drama in her life than the evening lineup on Lifetime.
I want to stress: I'm not talking about proper Change Management procedures here. You should always have a rollback plan for major changes in your computing environment. I have had to rollback many changes to my various environments over the years, however, I have only had to enact a Lysine Contingency once and this came over two years AFTER the changes were introduced! Remember, the issues that often require your Lysine Contingency are just as easily going to be political as they are technical.
In the case I mentioned earlier I had my entire LC whittled down to one script. When the alarm sounded I knew that I had prepared for this scenario and there was no need to script some uninstallation routine or quickly write a new GPO or even to hold a meeting. This script set one flag which my verification utility read as "get the hell out of here!". With this flag, no more new verifications or installations would take place via GPO. The next section of my script deployed a Tivoli Software Package which immediately uninstalled the utility on all Windows computers. The next section added some log files to a central server. These files detailed the actions taken and would, ultimately, record the success rate of the Lysine Contingency.
Within 30 minutes the only traces of the original changes were contained in logs which I promptly gave to my manager. The Lysine Contingency went off without a hitch so that when the musical chairs music stopped I wasn't the one left standing.
Follow me on Twitter @ShaneCorellian
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, Mar 19, 2010
A common problem that users encounter when using agentless tools to manage their computers is that they have the RemoteRegistry disabled.
Since Admin Arsenal is one of these agentless tools, RemoteRegistry must be enabled in order to perform many essential Windows Administrator tasks.
After enabling RemoteRegistry you'll be able to see what software is installed on your computers.
Admin Arsenal runs five tests on each system to ensure that is has the necessary settings and privileges to allow you to manage efficiently.
- DNS Lookup
- Ping
- ADMIN$ Share
- RemoteRegistry
- WMI
Have questions? Visit our forum at support.adminarsenal.com for answers to common questions.
Follow me at Twitter
@ShawnAndersonRolling out software? Do it for free with our 30-day fully functional trial.
Posted by The Admin Arsenal Team on Mon, Feb 08, 2010
Author: Adam Ruth
DCOM, or Distributed Component Object Model, is a technology in Windows allowing remote communication between programs. WMI, in particular, uses it to communicate. A lot of business oriented server applications use it, as well, to communicate between layers. If you've ever spent any time with DCOM you probably have come to understand just how fragile it can be. When it works, it's like magic, but when it doesn't it can be a serious hair pulling experience.
One of the more fragile bits of DCOM is its security. There are are four different areas of DCOM each with their own ACLs (Access Control Lists) and a problem in any one of the four can lead to hard to track down problems. To make matters worse, many applications that use DCOM will alter the security settings, potentially breaking DCOM access for other programs on the same computer. Sometimes it's necessary to just reset DCOM security to its default state, just as it was when Windows was installed.
Last week I found a quick way to do this, but it does require editing the registry so the standard warnings and "do not try this at home" apply. However, if you're stuck fixing a problem down in the guts of DCOM security, editing the registry is the least of your worries.
You can view the DCOM ACLs by running dcomcnfg.exe and navigating to Component Services > Computers > My Computer > Right-click > Properties > COM Security tab.
The ACLs are stored in the registry under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole, in the following binary values:
- DefaultAccessPermission
- DefaultLaunchPermission
- MachineAccessRestriction
- MachineLaunchRestriction
To reset them, all you need to do is to delete these values. If DCOM doesn't find any ACLs here, then it will use its defaults. Any changes you make will then re-create the values. Of course, you'll want to back them up before you delete them, or you could just rename them to be safe.
Posted by The Admin Arsenal Team on Mon, Jan 11, 2010
Photo by Brad & Ying
Author: Adam Ruth
Our goal at Admin Arsenal is about helping administrators work remotely by getting them to unplug their sneakernets. System security can sometimes make it difficult to achieve this goal. It would be great to live in a world without the need for security, not least because of its delicious gumdrop houses, use of sparkling rainbow wishes for currency, and ruler Princess Yum-yum-tum-tum of the Rose Scented Flatus. Unfortunately, we don't live in that world (which is a shame because the dollar to rainbow wish exchange rate is at its highest ever.)
Like most things in life there is a trade-off between the security of assets and their availability for use (or administration, as the case may be.) We've found that security issues tend to be the biggest roadblocks in achieving remote administration nirvana. So in that vein, I present the 5 biggest security roadblocks that we encounter regularly.
Firewall
This one should be obvious. If a computer doesn't allow inbound connections to its remote administration facilities, then it's not going to work. With the advent of the Firewall in Windows XP more and more people are seeing their remote administration break. It's been a while since the Windows Firewall entered the scene so this problem, and its cure, are quite well known now. The simplest fix (short of disabling the firewall) is to enable the
remote administration firewall exception, the file sharing exception (for remote access to the file system) and the ICMP echo exception (for ping.)
DCOM Security
WMI (Windows Management Instrumentation) is one of the primary methods of remotely administering computers. It uses DCOM (Distributed Component Object Model) as its method of communication. If the rights for DCOM aren't properly set, then WMI isn't going to work correctly, if at all. WMI, for all its power, seems to be quite fragile or brittle. One of the reasons behind this is its reliance on DCOM which seems to be the target of well meaning but misguided security experts and tools. We see this problem so often that we created a tool called DCOMAcls which allows for the remote setting of DCOM security settings.
System Time
Windows security has trouble coping with computers with clocks that are out of sync. This is actually for a good reason, since security tokens use timestamps and expirations to prevent their misuse. Depending on the settings of your authentication scheme (such as Active Directory's implementation of Kerberos) a clock that is out of sync by only a few minutes can cause connectivity problems. Usually, though, it takes clocks off by a few hours (such as reversing AM/PM or being on the wrong day.) Troubleshooting this problem can be difficult because the connectivity issues don't usually indicate that it's a time sync problem.
DNS/DHCP
WMI's authentication validates the host name being used to access the computer (unless a raw IP address is used.) If there are DNS or DHCP problems causing the wrong computer name to be used for connection, WMI will quite often fail. Windows DNS is notorious for stale records and it takes some effort and planning to ensure that a good DHCP setup prevents the same addresses being reused often. Then throw NetBIOS into the mix and once your name resolution is compromised then all bets are off.
The Double-Hop Problem
This problem only affects a certain type of remote administration, so while it's not generally encountered by most administrators, those who use this type of administration will almost always run into it. The
double-hop problem is, to put it simply, the inability for a security token to hop twice between machines. If you connect from computer A to computer B to execute a task (such as start a remote software install) and that task needs files on computer C then the security token can't hop again from B to C and access to those files will be denied. There are three solutions to this problem, the first is to configure a level of trust called "delegation" between computers, but this requires some high-level settings in Active Directory and is usually discouraged. The second solution is to send a user name and password from computer A to computer B so that a new token can be created to hop between B and C, but this is also problematic because it involves sending a password over the wire (possibly encrypted, but out in the open) and there aren't any native Windows tools that work that way. The third solution is to figure out a way to not need files on computer C, but this may not always be possible. So, while you may never run into this problem, when you do it can be a bear to deal with.
Hopefully this list will help any of you having security problems in your remote administration daily lives. Personally, I've filled out the immigration paperwork for the the land of gumdrop houses...
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.
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 Adam Ruth, Shane Corellian, and Shawn Anderson on Mon, Jul 13, 2009
I have been playing with Dameware's Mini Remote Control program for over a month. Having been a huge fan of various flavors of VNC I was a little skeptical that I would find Dameware useful enough to purchase.
Well, I purchased it. I actually purchased it after about 1 hour of testing. The User Interface is sleek and very intuitive. I can run Dameware from a Command Line which is important to me as I want to be able to initiate a Dameware session from another application. The available Command line arguments are not as good as VNC BUT Dameware works natively with Vista as well as Smart Card Logons. Here is a standard command line that I use to initiate a Dameware session on a Vista machine called Homer:
dwrcc.exe -h: -m:homer -a:3 -x:
While I can choose different authentication methods the "-a:3" option select Smart Card Logon.
If your target machine does not have the Dameware agent already installed then you are prompted by Dameware to install the agent. The installation is quick and, so far, painless. You can also configure your Dameware console to automatically install the agent (and/or start the service) without a prompting you. This is done via the View menu, "Local Global Options..."
Target behavior can be customized by editing the DWRCS.INI file which resides in the %WINDIR%\System32 directory. For the most part, all Dameware settings can be modified in this file.
One feature that I would love to see would be the ability to automatically perform some custom actions after the session closes. This became apparent to me when attempting to use a Smart Card via the Smart Card Logon feature in Dameware. When using this feature your certificates will be made available to applications (Internet Explorer, Outlook, etc). This can be confusing for users who see the certificates of different administrators. I simply wanted to be able to run a custom built script that removes the certificates.