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