With the approach of the holiday season I feel that I must warn you about the infamous FFTC (Friends and family totting cameras). The FFTC seem to appear at all family gatherings like moths drawn to a flame, and their work can be as destructive to ones sense of well being and reputation.

What am I talking about? Pictures of course—but not any picture … consider some of the following examples.

1. Pictures taken in low light without the flash- many cameras now have various scenes or modes that allow for low light pictures. When the exposure becomes too long, and the camera is not completely held rock steady, the image “smears.” These smears then distort facial features making ones nose appear as long as a broom stick, or transforming your hair into something that would make Marge Simpson green with envy.
2. Pictures taken at the “worst possible moment.” It goes without saying that people often eat at family gatherings. Part of eating, is taking bits out of and chewing food. But when one is in the process of ruminating, their facial features are often distorted into some hideous caricature of ones former self. Political photographers use this technique to their advantage to destroy ones opponent—clearly no one wants to vote for such a sinister individual. But WHY do we do it to our friends and loved ones?
3. Pictures taken from the “worst possible angle..” General MacArthur required all photographers to take pictures from a low angle. Why? Because it made him seem taller and more commanding. Like the person viewing the picture is “looking up to him.” I am not saying we want all of the FFTC to shoot from a lower angle, but certainly pictures taken from a side view angle that would make twiggy seem fat should be avoided. Indeed one should always be respectful with the camera angle. If you have a friend or loved one who is loosing a bit of hair on the top side, try not to feature it by using a top down shot, unless, of course, that friend or loved one is actually proud that they have achieved the sort of maturity that typically goes along with vanishing hair.
4. Watch out for physical body distortions such as arms that seem to stretch into infinity due to their proximity to the camera lens, or heads that could ride upon Macys Thanksgiving Day floats. One should always check the angle of the camera back plane when taking pictures.
5. Speaking of checking the angle of the back plane … most digital cameras have a preview window you should always check before you shoot. Look especially for things like lamps growing out of peoples heads, and plants that replace body parts. Remember you are taking a three dimensional object and turning it into a two dimensional object. The lost dimension is that of perspective. 

Why is it important to watch out for the FFTC? Because with all the online services, such as Facebook, Twitter, Flickr, Myspace, and Windows Live spaces, a picture can go from phone to being viewed by a million people in less than 60 seconds. Your reputation can vanish with similar speed…

In the old west, it was common to require the cowboys (at least according to the John Wayne movies – and we all know those are historically accurate) to check their guns at the door. In modern times, professional performers have a similar edict. The reason the music groups ban cameras from their performances is not because they want to sell pictures of the group, nor is it because they are concerned with the bright lights, I am convinced it is because they do not want a bunch of bad pictures showing up on the Internet that portray them in an unflattering light.

Of course most families in the United States get together so seldom, that banning cameras from family gatherings would be cruel, short sighted, and in the end unenforceable. So rather than ban cameras, maybe you can at least attempt to improve their use. Use my top five guide as a starting point, or better yet, check out Microsoft's guide to better holiday pictures, it is not that we do not like getting our picture taken, it really is that we do not like bad pictures getting taken.

Take care, and have a wonderful holiday.

My Friend Rajan is attending the Professional Developers Conference this week in LA. He sent some notes about the exciting things happening out there. Here they are…

Steven Sinofsky (President, Windows Division), Scott Guthrie (VP, Microsoft Developer Division) and Kurt DelBene (Sr. VP, Office Business Productivity Group) were the top speakers and headliners for today’s (day# 2) keynote at PDC2009 in Los Angeles, CA today. The PDC is historically quite important for announcements, this year was no different.

· Biggest applause of the day# 2  comes from Sinofsky when he mentioned about a partnership project with Acer where it puts its own team through the process of actually building a laptop computer, just to see how one is built - what laptop engineers actually go through. In learning the system that Acer goes through, Microsoft built its own limited editions for PDC'09 laptops. They (i.e. Acer machine with Microsoft’s preferred software image, resistive multi-touch, accelerometer) will be giveaways to all PDC attendees!!

· In terms of pure wow factor from the announcements, Silverlight 4.0 steals the show!  The big news today is Silverlight, specifically the beta of version 4.0. Silverlight continues its march towards providing more and more of the functionality of .net, almost full WPF and Windows. Silverlight 4.0 is incredible, that’s what you’ll hear from anyone that watched the day 2 keynote and demos.

(Background, Silverlight 3 released just over a year ago and here we are with yet another release full of features that our developer community has been asking for. This beta release is a developer release.)

Rajan has more information on his blog.

As someone who has written or contributed to 16 book projects, people often seek me out to solicit advice on writing a book. More often than not, the conversation begins “I think I would like to write a book about … (fill in your own obscure technology) because I really know a lot about it…” They then begin to describe how much they know about their obscure technology.

The problem is that people have never written a book have no idea of the timeline that is involved. Here is an example from my most recent book, Windows PowerShell 2.0 Best Practices …

• First draft of proposal was dated Jan. 31, 2008
• First chapter on Aug. 25, 2008
• Last chapter on Aug. 28, 2009
• Cover approval Nov. 13, 2009

This does not account for the fact that while in the writing phase, I generally have a deadline of some kind every week. This means I have to work every night, every weekend … for a year. Once I begin to explain this to people they generally change their mind. Over the last decade I have counseled more than two dozen prospective writers … to date … they are still prospective writers.

 

Whenever a group of IT Pros get together the discussion invariably turns to user stories. While some are amusing, and others tell more about the IT Pro than the user in the story, there is one class of stories that knows no cultural boundaries … the story where the user walks up to the IT Pro and begins his tale with the infamous six words … “I have this computer at home.”

If you have been following me on Facebook, you know that I recently attended a family reunion. While at the family reunion I was … wait before the family reunion, the first thing I had to do was fix my mothers computer. Then at the family reunion, I spent most of the day giving tech support and computing advice, instead of learning the latest scholastic achievements of little Johnnie … (maybe it is not such a bad thing after all.)

A few years ago, my wife had to take me to the emergency room. While I was being admitted, the person at the receiving desk was looking at my health insurance card, and this exchange took place:

“You work for Microsoft?”

“Yes,” I moaned in pain.

“I have this computer at home …”

A recent survey states that Windows 7 just broke the 4% market place adoption rate (something that took Windows Vista 5 months to do). Everyone is interested in upgrading to Windows 7. This past weekend we took a friend with us to the Columbia Zoo, and one of the major conversations that took place was not the eating habits of Brown Bears, rather it the hardware requirements for running Windows 7 (in her case, it was easy because she is already running Windows Vista. In most cases if your computer is running Windows Vista, it will run Windows 7 – only better). When we got home, Teresa logged onto Facebook, and was immediately accosted by a friend who is running Windows XP and was seeking upgrade advice.

To upgrade from Windows XP to Windows 7 one needs to be a bit more careful. In most cases if you have a relatively new computer there should be no problems … but if you have a four or five year old computer, you may need to be a bit more careful. I searched Microsoft.Com looking for the system requirements page for Windows 7 we could send, but because I have been an IT Pro for nearly 20 years, I know how the conversation would go. Something like this:

“You need either a 32 bit or 64 bit CPU that runs at a speed of at least 1 gigahertz,” I would say.

“What is a CPU?” the friend would say.

While I was conducting my Bing search for system requirements  to run Windows 7, I ran across the Windows 7 Upgrade Advisor. I tested it on an old computer I had laying around, and it works great. With the approach of the holiday season in the United States, it is all but inevitable you will be accosted by well meaning friends and loved ones seeking upgrade advice. Keep the Windows 7 Upgrade Advisor handy (a Bing search for “upgrade advisor” returns the download page as the #1 search result) and maybe you will even get to taste some of the wonder holiday food that is sure to be waiting for you.

Introduction

So your manager has decided you need to create some Zune casts. The first thing you need to decide is do you wish to do a video or audio only presentation. If you wish to do an audio only presentation, you can get away using a digital microphone. When you have completed talking, you post your Zune cast, and you are finished. If you wish to do some editing, or add other features to your Zune cast, you will need some editing software and perhaps additional tools as well.

Choosing your style

Audio Zune casts work well for interviewing people, expounding about poetry, or history, but in the technology world, video Zune casts are where the rubber meets the road. The ability to quickly show someone the graphical interface of an application and walk them through various scenarios is what makes this medium really shine.

Selecting your tools

Microsoft Expression Suite 3.0 contains a number of tools that are of interest to Zune casters. The Microsoft Expression Encoder 3 Screen capture tool can be used to record a desktop as well as the mouse movements. You can also use an external web camera, and microphone to allow you to be seen while you are making your presentation. A low cost web cam and a medium cost digital microphone when used with Microsoft Expression Encoder 3 Screen Capture can produce good results.

Once you have produced the recording, you will want to use the Microsoft Expression Encoder 3 to encode the recording for different display formats. Using the Encoder, you can splice together different pieces of video, add additional audio, and perform all kinds of additional post processing. One of the nice things about using the Microsoft Expression Encoder is that it can produce a Silverlight ready video.

Creating a specific plan

So much for generalities; what about the specifics of your presentation? What do you say? How long do you talk? How do you gauge success?

One of the most common questions that people ask me about video Zune casts, is how do you know what to say? If you ever run into the Scripting Wife, she will tell you that I never run out of things to say. For your first topic I would suggest that you choose something you have delivered to your team, or to customers. Choose something that you know really well, and then practice it before you begin recording. I can tell you from experience that mastering the editing controls in your video encoding software will take you until the next release of the software. It is a very powerful and confusing piece of software. It will be much better to record it perfectly the first time, than to try and edit it later on. Here are some hints that will make the recording go smoothly.

Choosing a target length

If the most common question I get from people is "What do I talk about?" the second most common question I receive is "how long do I talk." This question is one that is currently greatly disputed, if not even hotly disputed by many of the experts. The reason is that many experts state outright that people are not interested in long pod casts, and that a good target length is 20 minutes or less –with emphasis on less.

Personally, I think that you should talk as long as you are interesting. You should bring your Zune cast to a nice conclusion before you cease to be interesting. If you find yourself yawning while you are making your Zune cast, your poor audience doesn't stand a chance. Here are some considerations for determining the appropriate length of your Zune cast.

1. How is it hosted? If you require your audience to sign in, register, fill out surveys, download special software and jump through other hoops to receive your content, you had better make it worth their time.

2. What is the subject matter? If the title of your Zune cast is "Three reasons for upgrading to Windows 7" and the length of the Zune cast is 10 minutes, I might click on the link to watch it if it will immediately stream to my desktop easily. On the other hand, if the title of the presentation is "Advanced Kernel Mode Debugging on Windows 7" and it is a 10 minute presentation, I will not even bother with it, because the subject demands a more involved treatment.

3. What is your audience makeup? Is your audience IT Pros, Developers, Management, Sales professionals, or home users? Each of these audience groups has a different level of tolerance for streaming media in general, and for Zune casts in particular.

4. How will the Zune cast be displayed? Will it be downloaded to a portable media playing device, or will it be watched via a Silverlight control embedded on a web page. (See Script Center 101 for an example of a Silverlight media control).

Best Practices for Video Zune casting

1. Practice your demonstration completely. Perform it several times until it is flawless.

2. If the software you are demonstrating takes a few minutes to completely load, launch it prior to beginning the recording.

3. If your demonstration will entail typing from the command line, or from within a Windows PowerShell console, make a cheat sheet of complex commands, or populate a notepad with the commands. This will enable you to cut and to paste your commands if you are not comfortable with typing. Please remember that you are on camera. If your cheat sheet is beside your keyboard, your video will feature the top of your head instead of your face. I like to use an old fashioned typist's copy stand to hold to hold my cheat sheet off camera.

4. Download and practice using the ZoomIt utility; version 4 was just released and is available from TechNet. ZoomIt will allow you to zoom in on a certain portion of the screen while you are making your presentation. This enables you to focus the attention on the action you are trying to perform.

5. Make sure your desktop is clear of all distracting icons, and program shortcuts. Too many items on the desktop will cause the audience to spend their time trying to figure out what programs you use, instead of paying attention to what you are saying. You can use the desktop properties to turn off the icons for my computer, Internet Explorer and other commonly used desktop icons. The best desktop is one that is completely barren except for a shortcut to your demonstration files.

6. Make sure you protect company secrets and customer data by not inadvertently revealing too much information during the recording process. In reality, you should not be using live data or production machines for demonstration purposes.

7. If possible use a freshly installed computer, or virtual machine to perform the demonstration. This is also a great way to make sure that you know exactly what pieces are required to actually make your demo work. If you use a virtual machine, you can elect to not save changes when you are finished practicing.

8. When you are recording, pay close attention to the background area that will be picked up by the video camera. If it is distracting, consider hanging a light blue sheet or something similar as a background.

9.

Reflector

When you are recording, pay attention to the lighting. If your face is dark on one side, and washed out on the other side, you need to balance the lighting. Consider making a cheap diffuser by hanging a piece of white poster board on the dark side of your face. Place it up and away from the light source. This is seen here.

10. Pay attention to your microphone placement. If it is too close to your keyboard tray, the clicks will be really loud and distracting.

11. Remove your watch and any large heavy rings because they will make loud thumps when they bang against the desktop or your keyboard. Depending on the microphone you are using and its placement, these sounds will carry through to your recording and will be extremely distracting.

12. Place your microphone in the direct line with both your camera and your computer monitor. If the monitor is to one side, and your camera is on the other side, you will feature the side of your head. If the microphone is somewhere else, the volume will be really uneven when you move your head away from the direction of the microphone towards the direction of the monitor. This is seen here.

13. When you talk begin your presentation at least one octave lower than your normal speaking voice. This is because when people become nervous their vocal cords contract, which makes their voices rise. Be intentionally beginning at a lower pitch, as you become nervous your voice will rise to its normal level.

14. When recording consider using the wind shield for the microphone. This will dampen the noise created by the pronunciation of the labials.

15. Read the manual that comes with your digital microphone. Many feature multiple pickups that can be either enabled, or disabled via the controls. You probably only want to use one bank of transducers when making your recording if you are the only speaker. If you do disable one bank on the microphone, make sure you point the disabled bank away from you.

16. When you set the microphone sensitivity, make sure you are seated in your chair with the keyboard placed in the same location you will be recording from. Begin your presentation. If you cannot observe the meter from your normal recording seated position, have a helper watch the meter. A normal sensitivity meter ranges on a scale from 0 to 10. Your goal is to be in the upper green range as shown here. It is ok to stray into the red occasionally, but your sound will be distorted if you consistently peg the meter.

0-1-2-3-4-5-6-7-8-9-10

17. Pay attention to your apparel and general appearance when making the Zune cast. You do not need to wear a suit, or dress clothes, but you should at least appear presentable. In addition, certain colors of shirts will tend to wash out (white is really bad) and your video will lack definition. In addition, if you do hang a light blue background, do not wear a light blue shirt of the same color unless you really do want to appear as a "talking head." Watch your playback carefully to ensure that nothing unintended can be seen in the video.

18. When you are recording, place signs around the outside of your office to help to ward off interruptions. Disable all phones, and close Outlook prior to recording. When I am recording at home, I have small boxes that I have made up that I place over the door bell. In addition, I have a message displayed nearby that includes the current date and states "I am recording and not accepting any visitors." When you have completed your recording, don't forget to remove the signs. You might also need to corral pets, and alert any resident homo sapiens in your domicile as to the need for total silence.

If you have friended me on Facebook, you know that I recently spent a week in the Great Smokey Mountains attending a woodworking school. The class was taught by a guy who has more than 30 years experience making fine furniture, and more than 20 years experience teaching woodworking.

While I was not particularly interested in his resume, I was interested in learning to make hand-cut dovetails. I also have been woodworking for nearly 30 years, but prior to this experience, I had never taken a woodworking class—all of my instruction had come from watching television shows, and reading magazines and books on the subject.

While it is relatively easy to use a router to create a dovetail, it is more complicated to use a hand saw, a chisel, and a hand plane to do so. This is because the process is more complicated than merely installing a bit and turning on a router. Before attending the class in the Great Smokey Mountains, creating a hand cut dovetail was a skill I had failed to master.

So, how did the master craftsman teach the complex task? He broke it down into two small tasks—that that was it—two small tasks. The first task was saw to a line, and the second task was chisel to a line. We spent the entire day on Monday learning how to saw to a line … not how to split a line, but how to saw right up next to the line. We came back and on Tuesday, we spent the entire day learning how to chisel to a line … not how to split the line, but how to chisel right up next to the line. Needless to say, by Tuesday evening I was a bit discouraged. Saw to a line, chisel to a line … it is like the Karate Kid with “wax on” and “wax off”.

Then it dawned on me … it was like the Karate Kid … On Wednesday, we finally began to cut dovetails … the master craftsman said “Remember, saw to the line, don’t split the line.” I knew what he meant, because I had had 8 hours of “saw to the line”. Then came the time to make the matching board for the dovetail … the master craftsman said “Remember, chisel to the line, don’t split the line” and once again I knew what he meant, because I had had 8 hours of “chisel to the line”.

By Wednesday evening our hand-cut dovetailed drawer was complete, and by the end of the week I had also completed a beautiful hand made table as well. When I apply the finish, maybe I will try a little “wax on … wax off” as well.

One of the fun things about being the Microsoft Scripting Guy is the ability to read all of the e-mail that gets sent to the Scripter@Microsoft.Com e-mail address. Each week, I attempt to answer the several hundred e-mails that I get, at times with varying success. One common form of e-mail I get goes something like this: I need a WMI script to swap the mouse buttons on 100 computers at work … or words to that effect. The easy answer to that particular question is, it cannot be done. You can detect if you have a right handed mouse, or a left handed mouse, but the handedness property is read-only on the Win32_PointingDevice WMI class.

The long answer to the question of the mouse, is that while you cannot use WMI to solve the problem, you can write a script that uses P-Invoke and some of the new features of Windows PowerShell 2.0. The SwapMouseFunction.ps1 script illustrates this technique.

# ------------------------------------------------------------------------
# NAME: SwapMouseFunction.ps1
# AUTHOR: ed wilson, Microsoft
# DATE: 2/13/2009
#
# KEYWORDS: Add-Type, user32.dll, mouse, pinvoke
#
# COMMENTS: This script uses Add-Type to create a
# function from user32.dll that allows you to swap the
# mouse button.
#
#
# ------------------------------------------------------------------------
#Requires -Version 2.0
Function Add-User32Mouse
{
$signature = @"
[DllImport("user32.dll")]
public static extern bool SwapMouseButton(bool fSwap);
"@

Add-Type -memberDefinition $signature -name "Win32SwapMouseButton" -namespace  Win32Functions -passThru
} #End Add-User32Mouse

# *** EntryPoint to script ***
#$SwapMouse = Add-User32Mouse
#[void]$SwapMouse::SwapMouseButton($False)
[void](Add-User32Mouse)::SwapMouseButton($False)

You see, the thing is, the person who sent the e-mail asking for a WMI script to change the mouse buttons assumed that because they used WMI to detect the primary and secondary mouse buttons, that they should also use WMI to change the mouse buttons. Such an assumption when working with scripting leads to tunnel vision, and convoluted scripts at best, and to misleading and inconsistent results at worst. Rather than assume what technology you will use to solve the problem in a script, it is best to clearly define the problem, and then choose the best approach from the available technology to solve your problem.

Contrary to building buildings, in programming the form dictates which function you will use and not vice versa. Now we have both the long answer, and the short answer to the problem of the mouse.

One of the things that I often discuss with people who write VBScript code is the process of translating VBScript code to Windows PowerShell code. In fact, several years ago, I was approached about writing a utility that would automate the process. I thought about it long and hard, and in the end decided to forgo developing such a tool.

In my Windows PowerShell Step by Step book, that was published by Microsoft Press, I have an appendix that is called the VBScript to Windows PowerShell conversion guide (there is a similar document on the TechNet Script Center). The conversion guide is useful from a getting started perspective, but should not be taken as best practice, or even as authoritative.

I even wrote a series of Hey Scripting Guy! articles that talk about converting VBScript to Windows PowerShell (one such example is here).  But in all actuality, I have translated less than 1% of the more than 10,000 VBScripts I have written in my lifetime.

There are several reasons for not translating VBScript to Windows PowerShell:

1. Waste of time. If the VBScript works, leave it alone.
2. Better way of doing things. Many VBScripts wrestled with things such as opening files, retrieving property values of objects and writing output to the console. These types of tasks are nearly automatic in Windows PowerShell.
3. There are too many new things to script using Windows PowerShell. Many things that were impossible to do using VBScript are now possible using Windows PowerShell. There is a seemingly endless list of new things to script. I simply do not have time to go back and translate VBScript code.

Reasons to translate VBScript  to Windows PowerShell:

1. You are just learning how to script, and would like to have an example to follow along with.
2. You have a rather complicated COM based script, such as Word or Excel automation, that will not be significantly different when written in Windows PowerShell.
3. You are in the process of phasing out VBScript from your network, and you need to quickly migrate your existing scripts.

Probably the biggest reason not to translate from VBScript to Windows PowerShell is because you will want to take advantage of the new features that Windows PowerShell offers. Often the difference between a 50 line VBScript and a Windows PowerShell script can be as many as 49 lines of code. You can save yourself an awful lot of work once you learn how to allow Windows PowerShell to do the work for you.

Yesterday was labor day in the United States, and many people had the day off (including yours truly). I spent the day in my wood working shop practicing making hand cut dovetails. Because Americans do have the amount of time off from work as people in Europe do, we tend to prepare for our days off so as to maximize our time. Before my time in the wood shop, I had read a book on how to make hand cut dovetails and felt I had already mastered the technique. I even took 12 pages of notes on the technique.

I would love to be able to report that the dovetails came out looking like … well dovetails. Instead I succeeded in turning several nice looking boards into nothing more than firewood. Fortunately, I have a class scheduled in a few weeks where I will finally be able to master this hallmark of woodworking craftsmanship. But I was hoping to get a jump start on the process.

When a technique is particularly complicated, and has a huge number of dependencies, the ability of a book to effectively teach the skill is hampered. A skill such as making hand cut dovetails is made up of a number of component skills or sub skills. Each of the sub skills must be mastered before attempting the larger skill.

The only way to develop a new skill is to practice it. But practicing doing something wrong does not help one to learn the new skill. There must be checkpoints, or guidelines that help one to know if the skill is being practiced correctly. With each of the component skills there should be a practice session, or step by step exercises. Some multimedia content might also be helpful.

I am not saying that it is impossible to learn how to create hand cut dovetails from a book, but that the process of creating such a book is extremely difficult, and requires much more than a few fuzzy black and white pictures to successfully impart the skills.

I finished writing my Windows PowerShell Best Practices book for Microsoft Press. I do not have all of the statistics available (number of words, number of figures, number of scripts and those type of numbers) but one value stands out clearly in my mind—one year. The Windows PowerShell Best Practices book has taken one full year (actually closer to 1 year and two weeks … but who is really counting) to write. I still have the re-writes to do, and I still have the appendix and the front matter to complete, but for all intensive purposes the book is finished.

After having worked on nearly two dozen book projects, the end of a book project is nearly always the same—what do I do now? For an entire year, every single weekend has been consumed with working on the book. During the week in the evenings, I have chipped away at the book; little by little, bit by bit, sentence by sentence; until I arrive at the day when there is nothing left to write.

Some might think it is a time to go out for a celebration; take Teresa out to eat, maybe take in a show; but book completion is not really that type of event. The book is finished, but in some strange sort of way, a constant companion has left. For an entire year, I knew what I would be doing every evening, and every weekend—I was working on a book. With that book finished, I am now adrift without direction. The search begins for new project.

Because I write to a very tight schedule, this weekend did not sneak up on me, and I am not left completely without direction. For example, I am going to study for the new Microsoft Certification Exams that are being released for Windows 7, and for Windows Server 2008 R2. That will be a fun project. I am also going to do some wood working, and will therefore spend a little time taking a class, and building a couple of small items in my wood working shop. I will spend some more time swimming and running because in the last two months I have been derailed from my goals in that arena …. but what do I do for this specific weekend?

As it turns out, I spent it reading. Teresa and I went to the public library, brought home a huge stack of books (not one of the books were about computers) and we sat in the living room and read the entire weekend. I read 5 books … in the end, the best way to celebrate finishing my book … was to enjoy the efforts of other authors who had reached the completion stage of

their book project as well.

As we have been busy at the TechNet Script Center with our migration to a blog, and bringing the TechNet Script Center Gallery on line, I have been giving a lot of thought to organizing the keywords / tags that are used to provide quick links to groups of topics. The problem is the world of scripting is huge. Forget for a minute the dozens of scripting languages, but consider the sheer number of things that can be “scripted.”

For those of you who might not know, a script is computer code that is not compiled. This means that it can be easily written in something as simple as Notepad—it is a plain text file with a special file extension. Most people never see file extensions because they are hidden by default in Windows Explorer. But a VBScript has a vbs file extension that causes Windows to execute the code in the file instead of displaying it in Notepad. A Word document has a doc (or docx) file extension that tells Windows to open the file with Word.

Anyway, many things on a computer can be scripted. For example, I can write a script that will create a Word document. This in itself might not seem too exciting, unless you think about running a script to find information such as the name of the computer, the programs that are installed on the computer, the amount of free disk space on a computer, the amount of memory installed in the computer, and the speed of the Central Processing Unit (CPU) for the computer. If you would like to write that information in a Word document it will save you a little bit of time. Suppose that you need that information from each of the 50,000 computers on your network because you are planning to upgrade to Windows 7 … now you can see that it would take a considerable amount to do all of this stuff manually.

Here is the problem … how do I file the above script that gathers the computer inventory information and writes it to a Word document? I can file it under WMI (which will be the technology used to gather the information from the computer) I can file it under Word because I write to a Word document, I can file it under Word document, because it creates a Word document, I can file it under Word.Application, Word.Document, Word.Range … and other such obscure things because those are the Objects I will need to create in my script to make the “magic” happen.

I recently read a book with the name of “Glut: Mastering Information through the Ages” by Alex Wright in this book, Mr.  Wright talks about how different societies wrestled what is sometimes referred to as information overload, or the information glut. How do you develop a taxonomy to organize, to categorize, or to systematize information retrieval?

At the TechNet Script Center what I have been doing is creating a Script Center Taxonomy (SCT) or perhaps Script Center Advanced Taxonomy (SCAT) that applies to the Hey Scripting Guy! blog, and the TechNet Script Center Gallery, this organization pattern is replacing five different methods of organizing the same information. It is a bigger project than I originally thought, and I have to take into account the legacy systems that were set in place nearly a decade ago. But it is also fun work. Oh, by the way, the information gathering script I talked about that writes upgrade information to a Word Document, I would probably file it under Desktop Management / Basic Computer Information.

At long last we have a real code gallery for the Script Center. This was a project that was in the planning stages for nearly a year. The great thing about the new code gallery is the way it fosters community involvement. The people who best know the needs of the IT Professional, is the community—because they live, eat, and breath corporate IT on a daily basis. The community gets the help desk calls on Monday morning at 8:00 AM, or the emergency alerts on Friday night at 2:00 AM, and therefore the community knows some of the pain points involved in being an IT Professional.

In the past when someone from the community wanted to share a script, they had to write an e-mail to Scripter@Microsoft.Com, I would then paste the script into a web page template, and submit it to the Scripting Editor. He would convert the page to XML, and post it to a staging server, where a background job would pick up the change and replicate it to the production servers. This was a process that in the best of times took several days … when things were busy … well lets just say, there are still nearly 100 script submissions that have yet to be converted.

With the new script repository, the community is in charge of submitting their own scripts. They provide the tags, summary and description when they submit the script. Once submitted, the script is immediately available. This feature, in and of itself, would be a great improvement over the old process. However, as they say on late night television, “But wait there's more …”

The new code gallery has community ratings, rankings, and discussion. These features will foster collaboration. One thing I learned a long time ago when I was just starting out in IT, is that no one knows everything. Since that time, I have learned that lesson again and again. I may spend 8 hours on a script, and be really proud of it. When I share my script with another scripter, as often as not, I will receive feedback very quickly that point towards improvements. This should not be surprising, given the old saying “two heads are better than one” especially when the other heads are also scripting gurus.

Full disclosure time, there is one significant downside to the new Technet Script Center Gallery … it is highly addictive! I spent more than 8 hours this week playing with the search feature, experimenting with the tag system, and finding all kinds of really cool scripts to examine. I was like a kid in a candy store (ok more like a fat old man in a candy store, but lets not get technical). In a word, it is awesome! Check it out.

Well today it is foggy, gray, and gloomy outside. The temperature is expected to rise above 90 again, and currently the humidity is nearly 90%. Clearly a day like today was made to spend inside, enjoying a good book, an ice cold cola and a bit of air conditioning. Of course for me the good book will be Windows PowerShell Best Practices (the book I am writing for MSPress), and the enjoyment to be had will be in the completion of the writing of a chapter, rather than the more cerebral activity of reading the chapter.

I decided that today I would drink coffee instead of my usual hot beverage of choice—tea for the simple expedient that the caffeine from coffee seems to wake me up faster, and I feel that I will need a jolt to complete the two chapters that are on my agenda for today. Because I do not drink much coffee, I tend to enjoy it more, and I want it to be a good cup of coffee, rather than an expedient cup of joe. Therefore, I got out the bag of Peaberry Kona beans I brought back from Hawaii, ground them in my coffee grinder, heated a pot of fresh spring water, and warmed my cup and milk in the microwave. I then carefully extracted the finely ground Kona coffee and placed it into the bottom of my French Press, and poured the near boiling spring water over the dark powder that covered the bottom of the glass beaker. After allowing the coffee to steep for about 15 minutes, I depressed the plunger about an inch and allowed the liquid to settle for a few seconds before pouring the near black coffee into the warmed cup. I sprinkled half a tea spoon of Turbinado over the café con leche and sipped. Coffee was made to be enjoyed, not gulped like so many liquid caffeine tablets.

I recently finished writing all 200 Windows PowerShell scripts for the Windows 7 Resource Kit. When I turned them in, the lead editor Mitch Tilloch, tested them and wrote up a detailed analysis of each script. Keep in mind that prior to turning in the scripts I had tested them and I had a peer test the scripts as well. While I expected to see a few comments such as “this error message could be clearer” or “it would be better if the output were formatted in this manner” I did not expect to see as many errors reported as Mitch reported back to me. Some of the things I found out that I had not checked are listed here.

1. The status of the Windows Firewall
2. Whether the script is run in the Windows PowerShell Console or if it is run in the Integrated Scripting Environment
3. Is the computer in a domain environment or is it in a workgroup
4. What is the version of the operating system the script is run upon

Here are some things that I did check when I was testing the scripts:

1. Is the script running as a normal user, or elevated
2. Is the required module loaded
3. What is the version of Windows PowerShell that is running
4. Is the targeted remote computer available
5. Is a required parameter supplied

I just finished reading an old book I found at our public library: “Glenn Miller and His Orchestra” by George T. Simon. It was an excellent read … although it did not have a happy ending (he died in a plane crash on his way to Paris). Glenn Miller was born into a poor family but at an early age he developed an insatiable desire to succeed. He became extremely competitive and simply had to be the best at everything he did—whether it was playing baseball, or learning to play the violin he never settled for second place.

The interesting thing about his story, is that Glenn Miller was not a particularly talented musician, he was merely adequate. But he made up for his lack of ability with drive, determination, and refusal to settle for mediocrity. In the end, he invented what has become known as the “Glen Miller Sound” in which the melody of a song is repeated through the use of a special combination of woodwinds.

Glenn Millers lasting contribution came through his orchestra, and his unique arrangements of songs.  Because of his drive and determination he was the consummate organizer. His rehearsals were prodigious, but the Glenn Miller Orchestra evolved into a well oiled machine that was able to enter a recording studio in the morning, and depart in the afternoon having completed 8 successful takes. Contrast this with the months of studio time it takes the average rock band  of today.

One of the things I have enjoyed about not traveling every week, is going to the library. In the past, when I would fly home on Saturday evening, and leave on Sunday morning, there was no time to do much of anything, and a trip to the library was out of the question. Now however, the scripting wife and I take weekly trips to the library. Our public library has a great collection of Rex Stout novels. Rex Stout is most noted for creating the detective Nero Wolfe. One of Nero Wolfe’s trademarks is that he never leaves his house. Instead he has an assistant named Archie Goodwin  who goes out and gathers the information. Nero has Archie relay all of his findings, mulls over the information and then has a big meeting with all the suspects (and often the police as well) where he solves the case. The amazing thing in all of the novels I have read to date (maybe 1/3 of his collection) is that in nearly every case, everyone connected with the case arrives at the wrong conclusion.

I believe we can all learn from Nero Wolfe when it comes to troubleshooting. Often when I was in consulting, I would be called to a customer to solve a problem that they had worked on for weeks. The difference between my approach and theirs is they generally started with what they could see. I remember one problem where the customer was having problems printing from their Word document. She had wrestled with the problem for weeks, even to the point of uninstalling Word and reinstalling it. When she came to her desk, I was updating her video driver and she got upset and yelled, “What are you doing? The problem is with Word not my video driver.” To which I calmly replied, “the print subsystem uses the video subsystem in conjunction with the WYSWIG print functionality of Office Documents.” The network administrator had focused on the problem and had assumed the solution. “I can’t print from Word, obviously the problem is with Word.” I on the other hand, looked at the environment: what components are part of the print subsystem.

This is the same thing that Nero Wolfe does. He looks at seemingly unrelated aspects of the case, and finds the relationship between them. He does not leap to the first seemingly obvious solution. In fact, he does not arrive at the solution until all inconsistencies  have been ironed out. Once that is done, the case solves itself. In troubleshooting, once all the dependencies of a subsystem have resolved, the component that sits upon top of the subsystems will generally begin to work. As computing solutions become more intertwined, and complex is is more important than ever to begin troubleshooting by examining the components of the system in a systematic manner.

Often when writing a script I follow a multistep process. The first thing to do, of course, is to come up with a bit of code that will do what I am after. For example, if I want to obtain information about the BIOS on a computer, I will first figure out how to do this. In general everything in the script is “hard-coded” meaning that no variables are used. Here is an example:

Get-WmiObject –class win32_Bios –computername “localhost”

The next step is to put the value for the comptuername parameter into a variable, and then to move it into a function. To do this, I use the function keyword, and create a function. It looks like this:

Function Get-Bios ($computer)

{

  Get-WmiObject –class win32_Bios –computername $computer

}

The problem with this approach, is that if I know ahead of time I plan to put my code into a function, and to supply input from outside the script I can skip the first step and immediately write my code as a function. This will save a bit of time. In addition, if I know that I will be supplying more than one value, I may decide to change the name of the variable I use.

Once I have a variable to hold my input, I can then use whatever method I wish to assign a value to that variable. I can read a text file, I can query Active Directory, read a database, or do other things as well.

On Monday, we begin looking at designing input for a script over at the Script Center. It will be a cool series of articles.

Yesterday I had a conference call that lasted all day long. It was not nearly as bad as it might sound. I was attending a meeting that in the past would have required me to fly to Seattle. From Charlotte, there is one flight a day to Seattle. If you are lucky enough to get this flight, and if you can afford the premium price tag the airline places on the flight, it will take five hours of flying time to get out there. If you catch one of the other flights you will go through Dallas, Chicago, Atlanta, or Phoenix with a very real possibility of missing the connection or having your luggage lost. Those flights take anywhere from 8 1/2 hours to 10 1/2 hours depending on connections. But wait that is not all, because you cannot just magically appear at the airport. From my house in South Carolina it takes 45 minutes to get to the airport in Charlotte, and then you need to be there two hours in advance. So even if I caught the five hour flight, and the flight was on time, it would require 7 hours and 45 minutes … not counting the time it takes to get a rental car and drive from SEATAC to Redmond.

All this will presuppose one day to fly out to Seattle. Then you spend the day in the meeting, and if you are lucky you can catch an evening flight out and arrive back in Charlotte around 7:30 AM the following day … jet lagged, and exhausted due to no sleep on a cold uncomfortable plane, and starving to death due to no food. In general, I prefer to spend the night in Seattle and arise at a normal time, and arrive back in Charlotte reasonably rested. Still it takes three days for a one day meeting. This does not take into account the toll on your health. Spending 10 to 18 hours cramped in an air plane causes me to ache … my legs cramp, my back hurts, and my sinus throb at the end of such a flight … not to mention the risk of catching strange and exotic diseases from your fellow travelers. All of which put a cramp in my productivity as well.

I could go on about the risk of getting your laptop stolen, your luggage lost, missing the meeting all together due to missed connections, and canceled flights. What about the food they serve at these kinds of meetings? Generally pizza or cold sandwiches … it was a working meeting after all. Neither of these ubiquitous foods are on my low carb diet. Speaking of diet, when I travel like this, it is generally impossible to get my workout scheduled. So traveling impacts my health as well as my mental well being.

What is the alternative? For my meeting this time, we had set up Live Meeting. I was completely integrated into the meeting. I clicked the invitation, it opened up the PowerPoint slide deck, called my land line, and I was in the meeting. Total commute time … 30 seconds. Yes, but what about the discussion? Dude, we used Office Communicator. I had a designated person who way my question proxy. When we broke up into small groups, Ralph and I chatted. He relayed my questions and my contributions to the meeting to the small group. The added bonus was he had a complete transcript of our conversation. Incidentally, there was a guy from Germany in our virtual meeting, and a lady who at home recovering from surgery. We all shared the same Office communicator session … with a group chat.

Oh for food? While they were munching on pizza, Teresa brought a nice bowl of Gazpacho, and a plate of Ceviche. After the meeting? I commuted another 30 seconds, and got on my tread mill for an hour. This morning, I am not jet lagged, not bloated, not sore, not sick, and am raring to go for an exciting and productive day. Live meeting, where were you 10 years ago! Life is good.

The 2009 summer scripting games are nearly half over, or still have half to go depending on your perspective. They have been absolutely awesome regardless of your disposition. I have enjoyed reading over the scripts submitted by the participants, as well as those written by the guest commentators. It has been an excellent learning opportunity and I feel my skills have improved during the process. In fact, I used a new technique I learned during the scripting games yesterday to answer a question I received via Scripter@Microsoft.Com.

We are in the process of recruiting new moderators for the Official Scripting Guys forum. The cool thing is the number of people who are willing to take the time to help other people learn often confusing task of scripting. This is the thing that makes the IT Profession unique, the feeling of community, and the willingness to keep plugging away far into the night. In general, I believe IT Pros work more hours than about any other group of professionals. You do not see accountants buying books on Excel and staying up to all hours of the night trying to get an Excel macro to work just so. You do not see crane operators bring home the big rig, or setting up a big rig in the back yard so they can practice their skills? While there are certainly forums and email lists for other professions, none are as robust as the ones in the IT community. Try finding a personal blog written by a plumber that covers all the plumbing repairs you can do by yourself! You may find such a beast, but typically it is run by a home hardware center, or a do it yourself magazine.

Today we begin the third day of the 2009 Summer Scripting Games. One thing has become clear to me as I have been reviewing hundreds of scripts, all of which are designed to do essentially the same thing, is that there is not a single way to accomplish a given task. When I designed the events for the 2009 Summer Scripting Games, I wrote “solutions” for each event. This was how I decided if an event was a beginner or an advanced event.

For problems that required a great amount of thought, or perhaps a great deal of code, I decided that was an advanced event. For problems that I solved quickly, or required a minimal amount of code, I labeled the event as a beginner event. This is, of course, a fool proof approach.

The reason is that we all approach problems in a different manner. Some of the advanced events have been solved quickly, and using a minimum amount of code. Why? Because the person writing the script used a different approach than the one I envisioned. Some of the beginner entries have been horribly convoluted and complex for exactly the same reason.

The one thing I believe I did right in crafting the events for this years Summer Scripting Games is I deliberately left the tasks a little vague (and in some cases really vague), I was able to do this because this year the games are not a competition, rather they are a show case. It has been extremely fulfilling to see how different people approach the same set of guidelines.

This is where collaboration comes into play. It is obvious that no single person has all the answers, or all  the best approaches to a task. Clearly experience exposes one to a variety of disciplines, methodologies, and insights that can be gainfully employed in a judicious manner to craft novel approaches to mundane problems. However, the naivety of inexperience can likewise play a significant role when  the simple question, “Why can’t we just …” is raised at the appropriate time in the planning process. Experience often rules approaches out of hand without serious consideration because such a solution has failed to meet our needs in the past. It is the gift of inexperience that allows for a fresh examination of previously tried and discarded approaches.

What would be cool for next years Scripting Games would be to have the events written way ahead of time, and to farm them out to a group of people and have them rate the event as beginner or advanced. Of course having 40 people work on a single project instead of a single person does not make the project go 40 times faster … it is not exactly like 40 times slower, it just seems that way.