Photo by edanley

I admit that I'm excited for Windows 7*. Maybe I'm just a victim of all the recent good press, but I can't wait for Windows 7 to be released. I'm a nerd, I admit, but I like new operating systems - they're like new toys. Back in the day when I was a Linux admin, I always got excited when Red Hat or Suse came out with something new. Currently I get a tingle whenever Apple drops a new version of OS X. But there's something even more special about Windows 7. 

I think the reason is because it's been so long since Microsoft released a client OS that's worth getting excited about. I love Server 2008, I think it's really done right, but that's only the server side of things. XP wasn't that much better than 2000 and was so long ago and let's face it, Vista just didn't deliver. It feels kind of like those heady days when NT or Windows 95 first came on the scene. Not only were they "new" but they delivered some real potential. I think that Windows 7 is going to be the same. I've tried using Vista as my main development box, but I've always gone back to XP. I am hopeful that I'll be able to transition to Windows 7 smoothly.

What I'm most excited about is that I it appears Microsoft has really learned from Apple. My favorite part of OS X is that it does a good job of just getting out of my way. There was a time when I was a tweaker. I would change every setting I could find not because it helped me out, but because it was there. But I'm past that now. I have work to do, and I want a system that just lets me do it with no fuss. Vista wasn't that system, Windows 7 appears to be. 

It's entirely possible that I'm wrong about all this, and it's that same hopeful nature of mine that had me stick with Vista as long as I did. I guess the proof in the pudding will be the eating. So serve me up.

* This is not a paid ad, I swear. I wouldn't mind getting some Microsoft Astroturfing money, but I'll settle for a decent replacement for XP.

Jane Lewis has a good piece on best practices for modifying your AD schema. It's a good list. The only addition that I would make is to ensure that you have a roll-back plan documented and tested.

Give it a read and be sure to let Jane know if you agree or disagree.

http://blogs.technet.com/janelewis

    Photo by Steve Keys

I've spent most of my programming career working with system administrators, usually writing tools to automate one process or another. I've worked with many tools to accomplish these tasks, from the simply mundane to the hellishly complex. Here's a survey of some of the more common tools for Windows system administrators. Each has their own strengths and weaknesses, and they're as individual as administrators themselves.

Batch

Most, if not all, administrators at one time or another have worked with the built in batch language of the Windows shell. Batch files are simple text files that have the extension .bat or .cmd. They are executed by the Windows command prompt executable, command.exe or cmd.exe. The batch language itself is very limited (to put it mildly.) It does have looping and branching, but these are rarely used. Most people use it as a way to store a set of commands that they need to run repeatedly, possibly with a few variables thrown in for good measure.

One of its greatest strengths is how easy it is to create a very simple script, another is that these scripts can run on virtually any Windows machine. However, the learning curve grows extremely steep once you get past the world of the "very simple." It's a good idea for all administrators to get a thorough grasp of using variables and simple if & for loops. Not only are they handy in a pinch, but you may find yourself needing to change someone else's script.

VBScript

Microsoft's first attempt to grow past the limitations of batch was VBScript. Not only is it a better language to work with than batch but it has access to the myriad of COM objects which were popping up everywhere. Many applications had COM interfaces that could be used by VBScript giving access to features that weren't availble on a command line. There are many very powerful scripts floating out there. I've worked with some that are over 30,000 lines long (worked *with* not *on*, I don't think I'd dare venture into that mess.)

VBScript was quite successful in the system administrator community, though it's not the most powerful language in the world. It's a simple language, and one that would still behoove most admins to at least get familiar with. Its one drawback nowadays is that it doesn't have any decent access to the newer .NET interfaces coming on the market.

PowerShell

PowerShell is an intended replacement for both batch and VBScript. Not only can it do everything its predecessors can, it is also tightly woven within .NET giving access to the interfaces of the future. It's a very powerful language in its own right, with some very advanced features. No longer can hard core developers snicker behind the backs of their sys-admin brethren and their "toy" languages. PowerShell is a full-fledged member of the "Yeah, but can your language do this?" family.

PowerShell is only now starting to get spread out in the world enough to make it useful. It ships with all Windows 2008 servers, though strangely it's not installed by default. If you're looking to keep up with the cutting edge, spending some time learning PowerShell would be a great investment.

C# and VB.NET

While these may not be considered scripting languages in the strictest sense, they're still something to consider. Microsoft provides free Express versions of each which can be used for a variety of automation tasks. Particularly useful if the task involves creating a user interface. This is really blurring the lines between administration and development, but it would be beneficial for a lot of system administrators to get some exposure to this side of the fence.

WinBatch

WinBatch is a product which provides some very comprehensive access for scripting Windows. Its real strengths are in its ability to manipulate the Windows interface (pushing buttons, filling out forms, standing in line) and accessing low level details such as security and file system information. Its language isn't quite as powerful as VBScript, but it makes up for it with the extreme depth and breadth of what you can access. It is a commercial product, with a somewhat overbearing license scheme, but with a loyal following.

AutoIt

AutoIt is an open source product for automating the interface, similar to WinBatch. I'm not terribly familiar with it, having not used it and only hearing about it second hand, but apparently it's very powerful. Many administrators swear by it, and it would be something worth taking a look at if you have the need to manipulate the interface.

Bash

Perhaps not too surprisingly there are versions of Bash for Windows. Bash is the Bourne Again SHell, and is the most popular scripting shell in the UNIX world. The version I've used the most comes with Cygwin (which is another tool every admin should have in their box.) If you've come from the UNIX world or if you keep a foot there, this would be a good option to consider.

Other Scripting Languages

Most popular scripting languages have Windows versions available, such as Python, Ruby, Tcl, and Perl. These provide varying levels of functionality for administrators and may be good choices if there are readily available resources, such as within a company that uses one of the languages extensively for other purposes. Any one of them can make a good choice for an administrator to pick up.

Well, there you have it. I'm sure I've left something out, so feel free to put in a comment about your favorite automation tool.

I have been a huge fan of WinBatch since 1997. WinBatch, a fantastic scripting utility provided by Wilson WindowWare, is based on the Windows Interface Language (WIL).

I have gotten out of more than one tight spot with WinBatch. I intend to use this forum to post scripts which I have used through the years which have helped me with my systems management duties.

The following script is designed to open up the Registry via Regedit.exe. It will then connect to a remote machine (based off of the Argument passed). In other words, if I wanted to open the registry of a remote computer called Homer, I would simply just have to run

StartReg.exe homer

Below is the WinBatch script

; This script will open a separate window for Regedit and connect to the target machine
ErrorMode(@Off)

systemroot=Environment("SystemRoot")

if isDefined(param1)
param1 = strTrim(param1)
if FileExist(StrCat(systemroot,"regedit.exe"))
run(StrCat(systemroot,"regedit.exe"), "-m")
winCheck = WinWaitExist("Registry Editor", 5)
if winCheck == @False then exit
IgnoreInput(@TRUE)
GetWindow = DllHwnd("Registry Editor")
ID=WinIdGet("Registry Editor")
winActivate(ID)
SendKeysTo(ID, "!FC")
scCheck = WinWaitExist("Select Computer", 4)
if scCheck == @False
IgnoreInput(@FALSE)
display(5, "Error", "Error connecting to Remote Registry")
exit
endif
SCID = WinIdGet("Select Computer")
SendKeysTo(SCID, "!E")
SendKeysTo(SCID, param1)
SendKeysTo(SCID, "!c")
MouseClickBtn(SCID, "", "OK")
IgnoreInput(@FALSE)
endif
else
message("Error", "Please pass name of remote computer as argument (e.g. StartReg.exe homer)")
endif

There you go. Unfortunately I have NOT found a better way to automatically connect to a remote registry without having to automate the key strokes. Oh well, it may be kludgy but it works.

Here's a tip for you Windows Command Shell command line jockeys.

Occasionally you find that you need to pass a full command line to another command as an argument, such as when writing a full command line into the registry. This can get a bit tricky, because you may need to embed both quotes and special characters within a single argument. Consider the following:

reg add HKLM\Software /v Test /t REG_SZ /d Up&Down

Since & is the command terminator, you get an error. To fix this, you can wrap the argument in quotes:

reg add HKLM\Software /v Test /t REG_SZ /d "Up&Down"

This works fine, even if you decide to add some spaces:

reg add HKLM\Software /v Test /t REG_SZ /d "Up & Down"

If you need to pass quotes into the command, you need to escape them. The normal way to embed quotes inside of other quotes is to triple quote them:

reg add HKLM\Software /v Test /t REG_SZ /d "The Command Line is """Fun and Fast!""""

But this will un-escape any special characters in the quotes. This will fail:

reg add HKLM\Software /v Test /t REG_SZ /d "The Command Line is """Fun & Fast!""""

There are two ways to get the & to work correctly, and which you use will depend on the exact nature of the text you're escaping. One is to re-quote the &:

reg add HKLM\Software /v Test /t REG_SZ /d "The Command Line is """Fun "&" Fast!""""

The other is to use the escape character which is the carat:

reg add HKLM\Software /v Test /t REG_SZ /d "The Command Line is """Fun ^& Fast!""""

You may even need preserve the carat itself:

reg add HKLM\Software /v Test /t REG_SZ /d "The Command Line is """Fun ^^^& Fast!""""

You may need to experiment a bit to get the right combination of quotes and escapes.  Hopefully these tidbits will help you next time you need to escape, re-escape, and escape again.

This is probably my most hated error in Windows administration. It is, I have concluded, a boneyard or "catch all" error that can mean just about anything. I finally ran across a solution which, commonly, seems to fix the problem in XP and 2003 (I'm still looking for a good solution for Vista and Windows 7). You do need to run a command on the target machine. I use the Remote Command feature in Admin Arsenal, this way I don't have to actually visit the target system(s). Here is the command you need to run and NO, there isn't a typo.

SC sdset SharedAccess D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)

If anyone has any other suggestions for the dreaded catch-all RPC Server error, PLEASE let me know.

How is Windows 7 security holding up? After reading a few articles on the topic I've come to the conclusion that there is, shall we say, some low-hanging fruit that Microsoft has failed to pluck. In short, Microsoft has failed to correct the file extension security issue in Windows Explorer.

F-Secure - "...virus writers would change the icon inside the executable to look like the icon of a text file or an image, and everybody would be fooled..."

Computer World - "This has been used for years by virus writers..."

C/NET - "Microsoft has failed to remove a long-recognized Windows Explorer security risk from Windows 7"

On the surface Microsoft would appear to be highly motivated to remove this issue, but they've had a ton of time before now. I guess it is possible to get pushed to the back burner, but ignoring this seems to be more of a fallen-behind-the-stove issue.

Time for some spring cleaning in Redmond. C'mon guys, don't let Windows 7 get slaughtered while still in the womb. We're still reeling from Vista's issues.

Still, we're holding out hope...

We've all been there. You're deep in thought troubleshooting issues or debugging code and you finally get in the groove. Then you hear it...

The WORST noises you can hear while working:

10 - Voice mail messages played over speaker phone from 4 cubes away

9 - Mastication of potato chips

8 - Someone clipping their fingernails

7 - The right-wing nut blaming the U.N.

6 - The left-wing wimp blaming the U.S.

5 - A.M. Radio

4 - Celine Dion in any form other than being strangled

3 - Anyone describing their dream from the night before

2 - The break room TV that no one is watching but everyone can hear

1 - A deep nose snort quickly followed by a swallowing sound

The BEST noises you can hear while working

10 - Any episode of the Skeptoid podcast

9 - Any Johnny Cash playlist

8 - The Fratellis - Whistle For The Choir

7 - Penn Jillette's laugh

6 - Yes - Drama

5 - In My Tribe - 10,000 Maniacs

4 - Any sound from George Carlin

3 - White Noise (not the movie, the noise)

2 - Tom Waits playing the live Hokey Pokey version of Pasties and a G-String. Actually, ANYTHING from Tom Waits.

1 - The sound of the last co-worker leaving for the day

This past week a joint announcement was made by Microsoft and U.S. Air Force stating that Microsoft was releasing a more secure version of XP for the Air Force.

This isn't actually true in the sense that Microsoft is releasing something specific to just one customer. They aren't. The benefits of this "new" package are available to anyone and everyone.

The effort began with the Air Force utilizing Microsoft Consulting Services (MCS) to hammer down security and other policy settings. The effort resulted into what is now known as the "Federal Desktop Core Configuration" (FDCC).

The FDCC is simply a set of security settings that are not exclusive nor secret and are available to anyone who chooses to utilize them. You can get more information here.

We can learn from this effort. Each organization has an opportunity to streamline its IT expenditures without sacrificing availability and security. Standardization in large organizations, if done right, can reduce total cost of ownership while increasing these two vital pieces in the IT puzzle. And you won't need a custom piece of software from Microsoft to do it. You already have it.

Admin Arsenal provides two methods for getting information about computers into the database: Heartbeat and Inventory Scan. The question in some peoples' minds is "Why two methods, what's the difference?" But, wait, that's two questions, you might say. Yes it is, but I'll forgive the imaginary person that I'm having a conversation with, because I don't want to make him mad. The answer to these questions revolves around performance.

It would be great if Admin Arsenal could grab all information from all your computers in an instant, but the reality is that it takes time. It's also reality that some data change more often than others and is therefore more time sensitive. Balancing these two realities in a way to give administrators the best experience, we decided to split the data gathering into two processes. Heartbeat is intended to run more often and to get information that is both quick to gather and changes more frequently. Typically, inventory scans run once a day, so heartbeats get information that is likely to change more often than that. To that end, heartbeat gathers the following:

• Online/Offline Status. This comes from a standard ICMP ping.
• Current User. Users log into and out of computers during the day, so this is quite volatile data.
• Boot Time/Uptime. Computers are also rebooted during the day, so their uptime may change frequently.

Inventory scans, on the other hand, gather the following:

• Everything else.

We'd love feedback from users if this is a good balance. Should more be added to the heartbeat? Should we make it so that you can move data back and forth between them? Should we add a third method somewhere between the two? Just who is my imaginary friend and why do I fear him?

Windows administrators can learn much from the career of John Madden. Like many in my generation I do not remember when John Madden wasn't behind the microphone. Though I have faint memories of Howard Cossell, it's the larger than life Madden who reigns supreme. His approach was simple. He believed that the average sports fan was smarter than his colleagues gave them credit for.

Granted that there is abundant stupidity in some organizations, however the days of spending five hours trying to teach Rodney the fine art of double-clicking is by and large in the past. Around us lie some intelligent people who aren't in our field of choice, and in honor of the Maddster I think we should recognize them and do what he did; teach.

When I say teach I don't mean that you train the user to someday take over your job. After all, Madden wasn't training us to be sports broadcasters. He was teaching in a way that allowed us to better understand the game and as a result, better enjoy it.

For those who didn't know Madden's style, he would explain to them what the coaches and players were doing, why they were doing it, and what the ramifications could be. The rest was natural. The fans understood the game and actually walked away smarter than when the game started. Imagine the joy if your customers not only understood what you did for them, but why you were doing it and what would happen if you didn't do it.

He was also humble. He wasn't in your face reminding you that you first learned about scrimmage strategy from him. When the game was over he quietly got into the Madden Cruiser and went to the next assignment.

Way to go, John. Enjoy the retirement. You've earned it.