Posted by Adam Ruth on Fri, Jul 23, 2010
In PowerShell everything is a .NET object, each with a variety of different properties. You'll notice that most of the time the output you see from basic commands only gives you a small subset of what's available. This is because PowerShell has built-in rules for how and what to display for most of the standard objects. Usually this is done so that you normally only see what's most important and aren't overwhelmed with too much data. For example, the dir command returns a set of FileSystemInfo objects but only shows you a few of the 20+ properties that are available.
You can override the default output for any object and PowerShell provides a set of cmdlets for just this purpose: Format-Wide, Format-Table, Format-List, and Format-Custom. I'll cover Format-Custom in another post, so for now here's a brief description of the first 3.
Format-Wide
This cmdlet simple takes one property of each object and writes them out across the window. This is similar to the /w option when using dir in cmd.exe.
Notice that to use the cmdlet you need to pipe the output of the dir command to Format-Wide. Unlike the pipe command in cmd.exe, you aren't just sending the text from the first command but actual .NET objects which allows the second command to have full control when dealing with them.
With Format-Wide you can select the property to show with the -Property parameter. You can also adjust the width of the columns with -Column.
Format-Table
This cmdlet formats objects just like the default dir command, but you have control over what properties show up and how they are formatted. For example:
In order to adjust the widths of the columns independently you need to create a View and pass it to the cmdlet, but that's a topic for its own posting. You can even group the output by unique properties of the files.
Format-List
This cmdlet formats the output as a list of properties. It's similar to the table output, but rotated 90 degrees.
Just like Format-Table you can decide which properties to show. You can use wildcards to select multiple properties (this also works with Format-Table.)
If you just use * for the property list you'll see all of the properties of the object. This is handy while exploring objects to see what information you can work with.
Hopefully this quick overview will get you exploring the different ways to output data in PowerShell. In future posts I'll discuss more advanced topics such as Format-Custom, Views, and Calculated Properties.
Follow me on Twitter @AdamRuth.
Posted by Shane Corellian on Wed, Jun 16, 2010
Photo by Jean-Michel Folon
It still amazes me how many system administrators don't feel the need to understand the under-pinnings of Systems Management. I push a button and software gets installed on a remote computer. I run an inventory scan and suddenly I have a list of installed software.
I'm constantly reminded of the Sidney Harris cartoon "Then a miracle occurs". How did that software get installed? Where does SCCM extract the list of installed software on each machine? How does Admin Arsenal know if a laptop has a smart-card reader?
If I have a prayer of performing any meaningful troubleshooting when problems occur, then it is essential to understand the How, Where, and What of the my environment.
You can, very quickly, determine if a person troubleshooting a problem has a good understanding of their environment. If they don't understand what's going on under the hood, then their troubleshooting amounts to little more than memorization. If "problem A" occurs, then "solution A" is the answer. "See, it's clearly written in this KB article." But what happens when the correct answer isn't, in fact, "solution A" ? What happens when the problem doesn't even have a description in the knowledge base?
I know, for example, that Tivoli retrieves its Installed Software list from two sources: A) Data stored in the "Uninstall" key of the registry; and B) Signature data where software names, publishers and versions are mapped using a file name and its corresponding file size.
If some software that I am expecting to see listed as being installed doesn't show up in an inventory report, then I should know exactly WHERE (on the target computer) that data is supposed to be found. I will be able, therefore, to troubleshoot more effectively. If I know HOW the scanned data is expected to move from the registry of the target computer to its ultimate entry in a database, then I can more effectively determine when and where any errors are occurring during transit.
My next few blog posts will be about some of the under-workings of common systems management tools.
Follow me on Twitter @ShaneCorellian
Posted by Adam Ruth on Wed, May 12, 2010
Photo by mikebaird
The Simple-Talk blog has a recent article on
Troubleshooting Windows Blue Screen Errors which I found to be quite interesting. I've never really had to deal with BSODs much beyond simply rebooting the computer, that's always been someone else's job.
I never knew what kind of information is available to deal with such crashes, both on the blue screen itself and in the dump files. Using the debugger to analyze a dump file seems a bit intimidating but once you know what to look for and what you can safely ignore it's not that difficult. Normally an error code and a driver name is all you'll need to get started finding out what's wrong and how to fix it.
Luckily, system crashes in Windows are much less common than they used to be but they still do appear from time to time. With a little searching around I found quite a few other guides to help out with the dreaded blue monster, here are a few to get you started.
Need to remotely troubleshoot Windows problems? Admin Arsenal can help, get a
free trial today.
Posted by Adam Ruth on Fri, May 07, 2010
Photo by joebeone
Okay, now you've got some servers consolidated using virtualization (you are consolidating servers, right?) But what do you do with the old boxes? Sure, you could donate them to a charity or recycle them in an eco-friendly way. But where's the fun in that? Here are some other ideas.
- Cubicle space heater.
- Fill with sand for large zen garden.
- Add realistic wind noise to flight simulator game.
- Glue front panels on fridge to hide beer in server room rack.
- Boat anchor for CEO's new yacht.
- Add some tubing, Mentos and Diet Coke to win contract for new fountain sculpture outside courthouse.
- Landscaping for new miniature golf course in old server room.
- Build vacation shack and show up that beer can house guy.
- Pizza warmer.
- Advanced new "laptop" for that guy in sales who's always making fun of your conference t-shirts.
Follow me on Twitter @AdamRuth
Posted by Adam Ruth on Mon, May 03, 2010
Photo by gurdonark
This post is both a rant and a warning. Simplicity is a noble goal, but far too often adding simplicity actually creates more complexity (usually in unintended places.) As I talked about in my post on security tradeoffs, no analysis of a security improvement is complete without first identifying where it weakens security. The same is true with anything that simplifies a process: Somewhere down the line something is being made more complex.
What I'm talking about specifically is a part of Windows Presentation Founation which is the new framework for writing GUI software in Windows. (My apologies to those that aren't developers, or don't want to be, but I will try to word this for computer nerds of all stripes.) WPF is a really amazing piece of engineering, but not without some compromises. The thing that's really been bugging me lately is the Visibility property used on UI elements.
Prior to WPF elements had a property called Visible that was a Boolean type (boolean types are either true or false.) So that, for example, if you wanted a button to show or hide based on some value within a program it was pretty clear how to do it:
SomeButton.Visible = User.IsAdministrator;
SomeButton.Visible = Customer.OrderCount > 100;
WPF has a different concept of visibility which is due to the way that elements are designed to flow around each other. When a UI element is hidden it is either just invisible and still takes up space or it is completely gone so that other elements may take its space. The WPF designers decided to turn the 2 value Visible property into a 3 value property called Visibility. Visibility can be set to Visible, Hidden, or Collapsed.
Now, this decision seems to have been made for the sake of simplicity. The other option would have been to create a second Boolean property such as IsCollapsedWhenHidden. Taking two properties and making them a single property is a good idea, right? Well, it may have simplified the writing of the framework, but it made things more complex for us developers. Coding the same things as above now looks more like this:
SomeButton.Visibility = User.IsAdministrator ? Visibility.Visible : Visibility.Hidden;
SomeButton.Visibility = Customer.OrderCount > 100 ? Visibility.Visible : Visibility.Collapsed;
When a developer is showing or hiding components they need to spend extra energy thinking about whether the component is to be hidden or collapsed, something that rarely every changes during the run of a program and is a decision that should have been made earlier in the process. This seems like it's not such a big deal, but it's just a small piece of the pie. WPF has a concept called binding where properties of elements are tied to properties of objects so that a change to the object is reflected in the interface automatically. Here's the code if Visibility was a Boolean type:
[Button Visibility="{Binding Path=IsAdmin}"/]
Pretty simple. Here's the code with the current type of Visibility:
[BooleanToVisibilityConverter x:key="boolToVisibilityConverter"]
[Button Visibility="{Binding path=IsAdm[in Converter={StaticResource boolToVisibilityConverter}}"/]
The BooleanToVisibilityConverter, as its name implies, turns True into Visible and False into Collapsed. But what if you want False to be Hidden? There are a couple of ways to do it, here's one:
[Button]
[Button.Binding Path="IsAdmin"]
[Binding.Converter]
[con:MapConverter]
[con:Mapping From="True" To="{x:Static Visibility.Visible}"]
[con:Mapping From="False" To="{x:Static Visibility.Hidden}"]
[con:Mapping]
[Binding.Converter]
[/Button.Binding]
[/Button]
There are other ways to get there, but they're all about as complex. All of this could have been avoided if early in the piece someone stopped to think what the consequence would be of the new Visibility property.
Any time you think of an improvement that will simplify something, take a moment to ask what all of the effects are. Making something simpler almost always makes something else more complex. Be especially wary of things that make life simpler for you but more complex for your users.
Find out how to simplify with Admin Arsenal (with little added complexity!)
Posted by Adam Ruth on Wed, Apr 28, 2010
One of problems people run into when running any program written using Microsoft .NET is a corrupt .NET Framework (files missing or damaged.) We've seen this problem a number of times when administrators try to run Admin Arsenal (shameless plug.) Usually, it's difficult to tell exactly what went wrong, since the exact error conditions and error codes aren't always the same. One common error code is clr20r3, though this code may be related to other issues.
Repairing .NET is very easy, though, so it's the low hanging fruit you can try if you ever see strange errors related to .NET applications. How you repair .NET will depend on which version of Windows you are running.
On versions earlier than Vista, all you need to do is run the .NET installer, which can be accessed from the "Add or Remove Programs" control panel. You will see a repair option when you click the Change/Remove button:
On Windows Vista and later .NET is part of the operating system, so it doesn't have a separate installer. You'll need to run a command from an elevated command prompt:
sfc /scannow
This will replace any operating system files which are missing or corrupt (including .NET Framework files.) On the rare occasion that this doesn't make the repair, then you will need to perform a repair installation of Windows (run the Windows installer from the original installation disk but select Repair when prompted.)
I haven't yet seen a .NET corruption problem that isn't fixed by one of these techniques, so hopefully this should help you out.
Try Admin Arsenal to remotely run commands on computers. Free 30 day trial.
Posted by Adam Ruth on Mon, Apr 26, 2010
Photo by Fristle
A fascinating blog post by Keyboard Cowboy details his efforts to expose a flaw in the granting of SSL certificates. The summary of the story is that many CAs (Certificate Authorities) grant SSL certificates to domains by sending an e-mail to an administrator's e-mail account on that domain such as "administrator" or "postmaster." Some companies include "ssladmin" in the list of authoritative addresses and many free web mail services allow that particular address to be registered by anyone, making it possible to get yourself a certificate for the web mail domain.
This particular exploit strikes me as being almost social engineering. It's not, technically, because it doesn't involve interaction with a person but the hole exists because of a lack of communication between the web mail providers and the CAs. Imagine if CAs decided to add another address to the list of usable ones, such as "securityadmin?" Unless all web mail providers were informed, this would just re-open the hole.
It brings to mind the idea that all security systems are tradeoffs. Every system that increases security in one way reduces it in another. SSL certificates are certainly a boon to online security, they make web commerce possible. But the realities of issuing certificates makes it so that not all SSL certificates can be trusted. So that even if you are diligent in looking for the https: and a valid certificate, your trust may be misplaced and you'll be less secure than if you didn't trust any site.
It's important to keep this in mind when designing security solutions and policies. Always try to identify how this new policy will reduce security. Complex password requirements are more secure, but also more likely to be written down. Time consuming door entry procedures increase the likelihood of tail-gaters. Police radios help police to coordinate activities, but scanners let the criminals keep an eye on them. I would submit that if you are looking at a new security policy and haven't been able to identify the ways in which it harms security, then you haven't thought it through enough to implement.
Follow me on Twitter @AdamRuth
Posted by Shawn Anderson on Wed, Apr 21, 2010
Photo by Jeff Tidwell
A March 2010 article by Arstechnica ellaborated on a beyondtrust report (.pdf) which underscored the wisdom (or necessity) of assigning users non-administrative rights. From the article:
After tabulating all the vulnerabilities published in Microsoft's 2009 Security Bulletins, it turns out 90 percent of the vulnerabilities can be mitigated by configuring users to operate without administrator rights...
For example, most organizations don't want their users installing software or making configuration changes. Simply wanting this prohibition isn't quite enough, though.
To ensure that the correct versions of software are installed (and nothing else) organizations have gone to great lengths to provide a remote software deployment strategy (our product) which ensures that the right software is installed by administrators.
When it comes to granting standard vs. admin rights, it's a two-way street - where IT administrators must weigh the balance of usability and effectivness. It's not as easy as it sounds, but it's getting easier. For this we can thank... Vista?
OK, that's a bold statement (and is just begging to be flamed), so please allow me to modify that statement slightly. It's not so much Vista as it is UAC.
As discussed on this blog in 2009, UAC was designed not so much for users as it was for developers (see more on UAC from Mark Russinovich). To recap, UAC was an effort to get developers to write their applications to run without administrative rights.
The unfortunate outcome of UAC was that screams of outrage which should have been directed to software vendors were instead misdirected to Microsoft.
All is not bleak, however. By the time Windows 7 appeared there were many developers who were churning out products that didn't require elevated rights.
The report from beyondtrust and the subsequent write-up from Arstechnica will hopefully keep the industry focused on security. When an application unnecessarily requires admin rights, the IT department should communicate this to the vendor and let them know that corporate security policy will not allow their application to be used unless the necessary changes are made.
Unfortunately sometimes it's easier to move to another location rather than start a needed revolution where you stand. Hopefully software vendors will continue to develop using best practices, and heres hoping that IT departments worldwide hold their feet to the fire.
Need to deploy software to all your users? Get more info from Adam Ruth's
Unplugging the Sneakernet White Paper.
Follow me on Twitter:
@ShawnAnderson
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 Adam Ruth on Mon, Apr 05, 2010
Photo by mkis
Microsoft recently announced
Service Pack 1 for Windows 7 and Server 2008 R2. They didn't provide any dates, but they did say it was coming soon. There won't be many new features, mostly bug fixes, but that's what I've come to expect from service packs.
What I can see this meaning for most organizations is the removal of the last big objection to migrating to Windows 7. It is a prudent stance to wait for the first service pack before migrating to give time for any problems to be ironed out, but SP1 is usually the event that signals the end of that waiting period. With Windows 7 SP 1 available there really won't be many reasons left to not take that final step away from Windows XP.
One thing that I'm looking forward to trying is the new
RemoteFX remote desktop functionality in SP1 (pretty much the only new feature.) I don't think I'll have a lot of use for it myself since I mostly use remote desktop for administrative purposes, but I can see possibly using it for development work since the current remote desktop is a bit too sluggish for me to run Visual Studio on a regular basis. This may finally bring the potential of centralized computing to the masses.