Admin Arsenal Blog

PowerShell Tips for System Administrators: Format Views

In two recent posts I went over the PowerShell formatting cmdlets and calculated properties. Today I'm going to cover Views. You'll notice that when you display a normal object (such as the built-in FileInfo objects when you run dir) you don't see all of its properties. This is because PowerShell is using a View, which is selected based on the type of object you're outputting and which type of output is being used (table, list, or wide.)

The views are stored in XML files in the PowerShell directory which you can examine to see how the formatting is being performed. Not only that but you can add your own views and even override the default views used by PowerShell.

The standard views are stored in %systemroot%\System32\WindowsPowerShell\v1.0 in a files with the extension format.ps1xml. There are several files, but the one we'll be looking at is FileSystem.format.ps1xml. This file holds the formatting for the various file system objects, such as FileInfo and DirectoryInfo.  The section that defines the normal file system table output is this:

<View>
  <Name>children</Name>
  <ViewSelectedBy>
    <SelectionSetName>FileSystemTypes</SelectionSetName>
  </ViewSelectedBy>
  <GroupBy>
    <PropertyName>PSParentPath</PropertyName>
    <CustomControlName>FileSystemTypes-GroupingFormat</CustomControlName>
  </GroupBy>
  <TableControl>
    <TableHeaders>
      <TableColumnHeader>
        <Label>Mode</Label>
        <Width>7</Width>
        <Alignment>left</Alignment>
      </TableColumnHeader>
      <TableColumnHeader>
        <Label>LastWriteTime</Label>
        <Width>25</Width>
        <Alignment>right</Alignment>
      </TableColumnHeader>
      <TableColumnHeader>
        <Label>Length</Label>
        <Width>10</Width>
        <Alignment>right</Alignment>
      </TableColumnHeader>
      <TableColumnHeader/>
    </TableHeaders>
    <TableRowEntries>
      <TableRowEntry>
        <Wrap/>
        <TableColumnItems>
          <TableColumnItem>
            <PropertyName>Mode</PropertyName>
          </TableColumnItem>
          <TableColumnItem>
            <ScriptBlock>
              [String]::Format("{0,10}  {1,8}", $_.LastWriteTime.ToString("d"), $_.LastWriteTime.ToString("t"))
            </ScriptBlock>
          </TableColumnItem>
          <TableColumnItem>
            <PropertyName>Length</PropertyName>
          </TableColumnItem>
          <TableColumnItem>
            <PropertyName>Name</PropertyName>
          </TableColumnItem>
        </TableColumnItems>
      </TableRowEntry>
    </TableRowEntries>
  </TableControl>
</View>

If you're not used to XML this may appear a bit daunting, but you can get a quick sense of how it works. There are four main sections of the file.

1. <ViewSelectedBy> indicates which object types are used by this view. In this case, the name FileSystemTypes refers to another section in the file that lists the types. That section is <SelectionSets>. The individual type names can be listed instead, but this reference makes the code shorter.
2. <GroupBy> tells the table of files to be grouped by thier parent path. This also refers to another section of the file called <Controls>.
3. <TableHeaders> sets up not only the titles that appear on the table columns, but also their width and alignment.
4. <TableRowEntry> the actual values to show in the table. Three of the colums just pull out a property by name, but the LastModifiedTime uses PowerShell code to format the date in a particular way. Any PowerShell code can be used which gives a great deal of flexibility.

There are a lot of possibilities for how to create views and the documentation is a bit limited. To learn about formatting it's best to look at the included format files to see how things are done.

To make a custom view you will need to create your own format.ps1xml files since you can't edit the built in ones. If there is more than one view for an object then the first one found will be used. Otherwise they can be selected by name using the -View parameter of the format cmdlets. Once you have a file created you import the formats using the Format-UpdateData cmdlet. As an example of a new format, I've create a format file that adds a CreationTime column in addition to LastWriteTime. Download the file, save it with the extension .format.ps1xml and run the following command:

Format-UpdateData -PrependPath [filename]

Now when you list the contents of a directory you will see the new column. Alternately you could have used -AppendPath to put the file after the built in formats and then you would need to use the view by name:

dir | Format-Table -View MyFormat

To make the custom format persistent between sessions, add the Format-UpdateData command to your PowerShell profile. One of the principles of PowerShell is the ability for you to configure it to your tastes and Views are a very powerful, if somewhat complex, way to get just want you want.

---

Need help using formats (or anything else) in PowerShell? Post a question in our PowerShell forum to ask one of our engineers.

System Administrator Concerns: It's the Static, Stupid

This article on Tech Republic showing a computer that was the victim of a lightening strike got me thinking. (WARNING: if you're squeamish about graphic computer carnage, don't view the photos.) What it got me thinking about was static and computers. Back when I first got into IT I constantly heard about the dangers of static electricity. It was only the most daring soul who would breach the hermetic seal of the computer case without guaranteeing they were properly grounded. 

It didn't take me long to start thinking that there was more hype than substance to the claims of static damaging computer components. I have no doubt that are plenty of components lying in pauper's graves that were killed by an errant arc from someone's fingertip. But how many times was static the go-to scapegoat when something went wrong that no one wanted to bother explaining? I remember very early in my career when I accidentally dropped a screw onto the motherboard of a running computer, so I am certain why that ISA slot was broken (I did say it was early in my career.) However, there was a time when the mysterious death of a component almost required that static be the first straw grasped.

It hardly seems that way anymore. "You must have static-ized it," is very rare these days. Have we System Administrators gotten better at dealing with static or do we know better that static is usually just an easy excuse? I'm sure it's still possible to build up enough of a charge to fry some modern components, but how likely is it while standing on a tiled floor after touching metal racks and server casings? I'm sure that if your server room is located in the middle of a cotton-ball factory carpeted with 1970s era shag and your company uniform is a corduroy jumpsuit with fuzzy bunny slippers you may want to slip on a grounding strap. Otherwise, we've learned to be less paranoid.

So what does that tell us about modern computing concerns? Are there things today that are like the static of yesteryear where blame seems to automatically go in a knee-jerk fashion? It seems to be when some new, and not yet fully ripe, technology starts to get adopted it continues to be blamed for problems long after those problems have been ironed out. That makes sense, because there was a time when the problems were real, so the knee-jerk reaction was probably right.

Windows instability seems like one of those historical issues. There was a time when a BSOD was almost certainly a bug in the OS and a reboot was the fix. Nowadays, though, a BSOD is more likely to be a hardware problem that isn't going to go away with a simple reboot. I'm sure you can think of some others.

---

Follow me on Twitter @AdamRuth

Learn or Burn. A lesson for Sys Admins

Part III of my "Understanding or Memorizing" series. In 2006 a friend and former co-worker came into our offices and saw Adam reading about some new Systems Management technologies that were in the early phases of acceptance. Our mutual friend went up to Adam and, interrupting his studies, said "Why are you studying? I thought you were a wizard!" I still love Adam's reply (paraphrased) "If I am a Wizard then it's only because I actually do study." 

Touché. (By the way, Adam IS a wizard. Ask anyone who has ever worked with him...that dude is siiiick.)

Keep sharp. Be constantly learning about new and evolving technology, especially if it has to do with your career. Do you know where to go when you have questions? Have you signed up with the SysAdmin Network? What about ServerFault and The Nubby Admin?

I live and die by O'Reilly books. Mine are dog-eared, written on, highlighted, and some pages have tea or coffee stains.

Eric Sink wrote a fantastic book called "Eric Sink On The Business Of Software". This was one of the best books that I read in 2007. On Page 108 he gives some recaps related to hiring qualified developers (easily translated to Sys Admins). The first three points are of special interest to me:

1. Can this candidate bring something to the team that nobody else has?
2. Is this candidate constantly learning?
3. Is this candidate aware of his/her weaknesses and comfortable discussing them?

I love being around people who are self-aware. Know your weaknesses as well as your strengths! One of the best statements made by Mr. Sink is found on page 125. "...Worrying about how others perceive your [aptitude/intelligence] is a waste of time. The key to a great career is to focus on [learning]..."

Learn or burn. 

Follow me on Twitter @ShaneCorellian

Trouble in Patchland - the System Administrator Perspective

The ongoing battle between Google and Microsoft recently heated up with a Google employee going public with details of an unpatched exploit in Windows XP only 5 days after notifying Microsoft of the vulnerability. There appears to be some politics (for want of a nicer word) going on behind the scenes of this episode, and there's plenty of analysis of that out in the blogosphere. What interests me, though, is how this highlights the difficulty that patching poses for the system administrator.

Patches are unavoidable, unfortunately, and there is a conflict between the need to get a patch out quickly and the need to ensure that patches are fully tested before they break things. Vendors cannot test patches with every application out there, especially in-house software, and so there will always be a percentage of patches that break things. This conflict is one of the reasons that Microsoft started Patch Tuesday. They have received some criticism for no longer issuing patches as they become available, but I think that it's actually a fairly good compromise. Large sites need a more predictable release cycle to deal with the flood of patches that have become a security reality. It would be nice of Microsoft could also deliver patches more quickly to smaller customers, but once a patch is released an exploit can be reverse engineered out of it leaving the others exposed. Once a month seems to work pretty well, all-in-all.

Now administrators have gotten in the cross-fire in what appears to be a battle between two behemoths. Dealing with patches is hard enough as it is, it's unfortunate that this eruption could probably make things worse. Would we have been worse off had Microsoft dragged its feet in releasing a patch (which is what Google seems to claim would have happened had they not gone public) or could sites be affected in the time before the patch comes out? I honestly don't know, but I tend to lean towards Google's actions making things worse. Luckily these types of public disclosures don't happen very often, so I really hope we're not seeing the start of a trend.

In the end it still comes down to the lowly system administrator. Patches need to be tested and deployed, no way to get around it. Hopefully these kinds of issues can lead to better patching processes, but in the mean time it's us admins that really on the line.

---

Deploying patches? Read our white paper on software deployment.

Understanding vs. Memorizing Systems Management Part 2

To continue from my last article...

The difference between an entry level computer support technician and a seasoned, trained and efficient Systems Administrator can be summed up with three simple words:

Understanding vs. Memorizing

In 1995 my boss (and technical mentor), Tom Mann, asked me to network the office computers (running Windows 3.11 for Workgroups). He purchased Novell NetWare 3.12 and told me get the network up within two weeks. I had never done such a thing and I asked him, "Um, how do I do that?" His response will be forever etched in my mind. 

"Figure it out."

I went right out to Barnes and Noble and purchased Using Netware 3.12. I started reading at work. Remember that episode of The Simpsons where Homer wants to keep his job at the bowling alley so he decided to come up with a brilliant marketing scheme? You see him reading a book called Advanced Marketing which then fades into him reading another book called "Beginning Marketing" which then fades into him reading the dictionary and looking up the word "Marketing". Well, that was how I felt. I didn't understand a lot of the concepts so I had to read and re-read. I ended up buying several books to answer new questions that I had. I built the 3.12 server at least 6 times before going into production with our small office. I began to understand via simple cause and effect. I was eventually able to correctly predict behavior if I changed configuration settings on the server or clients. 

By building that little network I began to truly understand the "problems" that would eventually pop up. When Beth complained that the printer wasn't "working" I was able to quickly deduce if the problem was caused by the server, the network, the local computer configuration or, in this case, the user Beth.

Your "Beth" doesn't have to understand how a document on her computer gets successfully sent to a printer. She just knows that if she hits the Print button then her document will print. That is fine. But if it is your job to make sure the users can print and access important files on the network then you had damn well better understand what's going on under the hood.

Remember, Google is your friend. It is inevitable that many Sys Admins have encountered your same computer problems and very likely that some of them have documented what went wrong, why, and what can be done to fix it.

Also, whatever you do, don't say you won't "fix" something just because you don't understand it. I think we often fall into this trap. About 8 years ago I remember data calls would come down from my corporate office. These calls were usually accompanied by some SQL code that we (the local administrators) would run against our respective databases. I started realizing that I was simply memorizing the queries but that I truly didn't have an understanding how they worked. I didn't know a Union from Join. Normalization? I could spell it but that was as deep as my understanding went.

Figure it out.

It's OK to not know the answer. Just figure it out. So, I began studying and using SQL. I frequently picked Adam's brain. I googled and bought some books. Once I jumped on it I realized how easy it actually was to understand. I was hooked.

The best way to understand how something works is simply to USE it. 

10 Tips to Boost Network Performance for System Administrators

Infoworld has a great article entitled 10 Tips for Boosting Network Performance that I found fascinating. Two tips in particular struck me, numbers 7 and 8. These address a problem that we ran into recently when setting up a virtual lab, that is disk speed. It was a real surprise to me just how much disk speed (RPM and bus throughput) affects the performance of virtual machines. It makes sense, once you understand the reasons behind it, but it was still quite shocking to have it bite me in the butt. It's tempting to try to save money with cheaper SATA drives and while there are times that's appropriate, a virtual server isn't one of those times.

The whole article, though, is full of some great ideas. Some of which you may be aware of, and some probably not as much. There should be something there for everyone to learn from. 

---

While you're reading about network performance you may want to learn how to use software deployment to Unplug the Sneakernet.

Finding Your System Administration Balance

I was on a long haul international flight a few days ago, trying to endure 14 hours in a metal tube. As my troubleshooting mind usually does, it was thinking of ways to make the flight more comfortable and efficient. I had all kinds of wonderfully impractical ideas about ways to speed up baggage collection and deal with the poor sucker in the window seat needing to use the lavatory with two sleeping people blocking the path (one reason I always get an aisle seat.) As I was thinking of my brilliant plans, I kept discovering problems with them in the real world. The laws of physics can be really inflexible, for some odd reason.

It really highlighted to me why I like software development so much, because I get to be mostly freed from those laws. If I want the seats in my abstract airplane cabin to be able to move around in 3 dimensions, why that's not a problem. I can even have them pass through each other like a poorly programmed video game. That's not to say that the software version of my jetliner is of any real value, but at least I can "break" all of those pesky laws all I want if it makes sense to do so.

The real world just isn't so flexible, unfortunately. System administrators have to deal with the friction between the physical and electronic worlds even more than us software developers. Computers and users are real, tangible things for the system administrator while they are more abstract concepts for a developer. Now, a good developer will do as much as possible to treat the people as real in order to more fully create software to meet their needs, but unless the software is in-house then there is a disconnect between flesh-and-blood users and their abstract counterparts.

This friction between cyber and meat space requires a delicate balance for the typical system administrator. Server rooms require refrigeration, keyboards break, and users make angry voices on the other end of the phone. But at the same time shared folders can be on in another city, login scripts can be easily duplicated, and password policies can be exceedingly simple or complex. The best administrators are those who can find and keep this balance working, and one reason that software developers don't necessarily make the best system administrators and vice versa. Understanding the differences will help you to know where you will be the happiest. 

People outside the industry don't really understand the subtle but important differences between various computer specialities. Especially relatives looking for help installing camera software they got for Christmas, for them a computer expert is a computer expert. There are administrators who love the hardware, those who love building scripts and automating things, and those who love working directly with people. Finding what speciality you like and then following it can be a very rewarding experience. It may seem really easy to identify what it is about your chosen profession that you really enjoy, but sometimes it's not so obvious. Take some time and really think about what it is you love about what you do. Once you do, you'll be able to see what kind of balance you need to strike, and what changes you need to make to achieve it.

If all else fails try out the System Administration Drinking Game to at least identify what it is you don't like.

Sweet! Track Sys Admin events from Standalone Sysadmin Calendar

Matt Simmons, creator of Standalone-Sysadmin.com has created a Sys Admin event calendar. The purpose of this calendar is simply to provide a "one-stop" shop for you to find Sys Admin events in which you may wish to participate.

You may also submit events to be be posted. Don't worry about spam or other noise on the calendar as there are some good ground rules to prevent the calendar from becoming cluttered or just an advertising dumpster.

Also, as I have mentioned in other posts, I strongly suggest that any sys admins out there become a member of the Sys Admin network. It's nice to have a great resource of like minded social outcasts if you love, as I do, all things sys admin.

Fulfill your Sys Admin duties with Admin Arsenal. Remote Software Deployment, Inventory, Monitoring and more. Check us out.

Windows Admin Tools - Not Every Challenge Is A Nail

Slashdot writes on the downfall of rewriting applications from scratch. The article references an older article (Things You Should Never Do) from Joel Spolsky written in 2000.

If you're not familiar with Joel I highly suggest bookmarking his blog, JoelOnSoftware.com. 

Though Joel's article focused on developing applications, I'd like to apply it to our jobs as system administrators. Specifically, the tools that we use everyday. 

Too many system admins take the do-it-yourself approach when managing their systems. They have a few tools on which they rely, but as new challenges arise they simply use their old tools. 

When all you have is a hammer everything looks like a nail

I first heard that statement when consulting for an new company. They handled almost all systems management via batch logon scripts. The logon process was several minutes, and the patches did everything from verifying proper hostname to patching systems (this was before WSUS and Active Directory). 

The organization was screaming for a new tools, yet they had one solution for every problem. More logon scripts. 

Hit the pause button (or at the very least the 1/2 speed button) and take a moment to ponder if there aren't faster ways to do your tasks more efficiently. Then find solutions, remembering that you don't need to create from scratch.

You'll find everything from COTS (Commercial Off The Shelf) products, to freeware point solutions. (If scripting is in your arsenal of tools then you can even make a go at automating some of these  solutions.)

Use Joel's logic to your benefit. Make these products work for what you need, or make them better. Just don't remake them from scratch. 

Pstools from Sysinternals are some of my favorite admin tools. They're a free way to get a lot of things done that system admins need. 

Which tools have become indispensable in your daily work?

---

Follow me on Twitter @ShawnAnderson
Admin Arsenal - a tool for every Windows Administrator.

 

 

UAC Keeps on Giving to Windows Administrators (Headaches)

Admin Arsenal has a feature to run some of its functionality as a service in the background. This is handy, for example, if an administrator wants to keep their systems' inventory scanned and up-to-date without leaving their workstation logged on all day.

For more information on the value of computer inventory, read our white paper

Normally, this service is set to start automatically with the computer so there's minimal interruption to the tasks it runs. Some users noticed that it wasn't starting up with the computer even though it could be started manually after the computer was running. It was a bit puzzling until we discovered that they were all machines with UAC enabled. A little more investigation showed that the service was starting, but taking longer than the 30 second time limit to come alive and was being terminated.

New to Windows is an option to set services to start with a delay. This was added in Vista and Server 2008 as a performance option to speed up the boot process by reducing the contention for system resources early in the boot cycle. We're not certain why UAC slowed down the loading of our service, but it may have to do with the .NET Framework which does take quite a while to load for the first time. It's possible that UAC introduces a delay in the .NET Framework and subsequently any service that uses it.

So our latest build of Admin Arsenal sets the delay start option automatically. If you have noticed this problem, then simply switch to delay start and you should be good to go.

Follow me on Twitter @AdamRuth