iTripoli Response

I want to thank Michael Otey for his review of iTripoli’s Admin Script Editor (“Pair of PowerShell Editors Pack a Punch,” March 2010, InstantDoc ID 103483). I'm compelled to point out a couple things. Unlike with development languages, we don't feel administrators should be concerned with “projects” and collections of files, so we've worked to remove the requirement. ASE lets you store all the script-specific settings you want in the script so that you aren't concerned with multiple files. For example, our ScriptForm Designer writes and reads code directly from the script and doesn't require a separate file that must be used to open saved forms for editing.

Often, when you see a long list of supported languages, the offered feature is simple keyword highlighting. We provide much more than this by focusing on the languages that matter to administrators. For example, our many code wizards support PowerShell, VBS, KiXtart, and AutoIt.

ASE 3.5 supports everything on Windows 7 except the PowerShell debugger. We have hundreds of users running ASE on Windows 7 today. But our official support for Windows 7 and 64-bit systems will be out soon, including native 64-bit script packaging.

We have indeed received feedback that our "special" icons aren't always appreciated. Therefore, we include a second set of icons that can be easily selected in options. To make sure everyone can make ASE look the way they like, we've provided several customization options for adjusting colors, layout, and icons, and users can even group or eliminate windows. We've posted a YouTube video ( that runs through these settings.

It's unfortunate that Michael had concerns with ASE reformatting his code. This is another feature we've invested heavily in that's typically considered an asset: The ScriptFormatter automatically inserts tabs and spaces according to fully customizable rules. Any of these rules can be edited or disabled, and the entire feature can be turned off.

If a window is inadvertently closed, it can be quickly restored by selecting Restore Default Layout from the formatting section of ASE Options or by choosing the specific tool you're looking for from the Window menu at the top of the screen.

I urge readers that quick comparisons tell only a fragment of the story. To truly understand differences between products, you need to get your hands on those products. For example, our Logon Script Builder is an extensible drag-and-drop environment whereas other solutions might offer no more than a simple wizard that provides limited functionality.

—Bob Kelly



Thanks for your comments! You have a great product. I liked all the things it does to make scripting easier and more approachable for the administrator. Regarding multiple file projects, I meant projects that are composed of multiple related script files grouped together under a project name. You open the project, and that opens all the related files so that you work on them as a group. I wasn't referring to your ScriptForm Designer. I liked the way that worked.

Regarding languages, your point is well taken. The product has full support for the languages you list. However, for marketing purposes, I would suggest listing the broader set, even if most users will use only a subset of them.

About the formatting, I've inherited scripts from all over and they're formatted every which way. I don’t want to even attempt to apply a standard to them. I just want to edit them as they are and go on to the next thing. ASE seems to always want to reformat the scripts rather than just follow the formatting that's present.

ASE is a good product. I especially appreciate the information about the icons. I wasn't aware I could change them. When you offer Windows 7 debugging support, I'm there. I'm sure we'll revisit this topic in the future.

—Michael Otey


Exchange Storage

I enjoyed Le Dumas’s article, “Exchange Storage: DAS vs. SAN vs. iSCSI” (January 2010, InstantDoc ID 103013). In the section about RAID levels, he mentions, “The performance of RAID 5 is about a third of that of RAID 1 and 0+1, because each write to the OS requires three writes to disk.” I agree with that statement with regard to writes, but it should be emphasized that RAID 5 has another important performance benefit.

I’ve worked with ISAM, Pervasive (formerly Betrieve), and Microsoft SQL Server accounting software databases for many years in the SMB market space. Generally, data table lookups, reporting, and backups (i.e., reads) are the most common disk-intensive activities in these applications. Common knowledge—that is, Wikipedia—says that RAID 5's read performance (i.e., striping with parity) is almost as good as that of RAID 0 for the same number of disks. Except for the parity blocks, data distribution over the disks follows the same pattern as RAID 0 (i.e., simple striping). RAID 5 is slightly slower with writes only because the disks must skip over the parity blocks.

Given the major benefit of data-loss protection that RAID 5 provides over RAID 0, RAID 5 is highly recommended in certain environments for database files (not including transaction logs).

—Bret Bennett


Monitoring Uptime

Frank Bernard’s letter (IT Community Forum, April 2010) in response to my FAQ “What's a fast way to find how long my system has been running?” (February 5, 2010, InstantDoc ID 103540) suggested using Task Manager’s System Idle Process counter as a solution.

I was curious about this suggestion, so I did some testing. I found that the System Idle time is essentially the amount of time the CPU has been idle. On a busy box, this counter wouldn't be accurate. However, the results are even worse than that in a multicore machine because the counter considers each core’s time. So if I had four idle cores, the System Idle time would increase four seconds for each second. (Make sure you enable the Show processes from all users option to see System Idle.)

Figure 1 shows results from my 16-core server (well, eight hyperthreaded), which is showing a much longer System Idle time than it has actually experienced. Every second, the System Idle increased by 16 seconds (idle server). You can see that the idle time shows the server as being up for 53 days (1272 hours). In reality, it had only been three days.

—John Savill


Figure 1: Task Manager Results
Figure 1: Task Manager Results



Setting the Bar for Windows 8

I just finished reading Mark Minasi’s "Windows 8 Goals: A Few Modest Suggestions" (February 23, 2010, InstantDoc ID 103616). Mark shows us, with clear and clever wording, some of the concerns that—if addressed in the next Windows release—will surely enhance user productivity. This line of thinking encourages us to rethink about many Windows computing nuisances. The perspective is truly refreshing and raises the bar for bringing products to a far better finish level.

—Mike Stelmach

Product Manager, Zinstall


IPv6 Implementation

Mel Beckman’s "IPv6 Hands-On Lab Setup Guide” (March 2010, InstantDoc ID 103361) is great. I hope everyone takes advantage of it—if only to increase the traction that IPv6 so desperately needs in the real world. IPv6 needs all the awareness it can get.

—Michael Dragone


PowerShell Tips

It's nice to see more and more useful articles about PowerShell, such as Bill Stewart’s “Running PowerShell Scripts Is as Easy as 1-2-3” (InstantDoc ID103427). I found out many of these things the hard way. I'm still a newbie, but I figured out one very useful method.

I've chosen to leave my security at the "restricted" level on my PC and all the PCs I support in my department. It's actually simple to reduce security to "unrestricted," run a script, and then set it back to "restricted." It requires running PowerShell from a regular Cmd wrapper, as you see in Listing 1.

The two variables for preferred workDrv and workDir need to be set. From there, all you have to do is run it. It prompts for the name of the script. I always copy the name beforehand. When prompted, I simply right-click to paste (Cmd QuickEdit feature), and hit Enter. The pause at the end lets me verify that the "restricted" policy has been reinstated properly. This can be tailored to run scripts on remote machines also./content/content/104645/CommunityForum0410Fig1.jpg

—Jeff O'Reilly

Listing 1: Running PowerShell from a regular Cmd wrapper

Set workDrv=D:
Set workDir=Scripting\\Powershell
Cd %workDrv%\\%workDir%
Powershell -command "& \\{Set-ExecutionPolicy -Scope LocalMachine Unrestricted -Force\\}"
@Set /p ScriptName=What's the name of your PowerShell script? :
Powershell -command .\\%ScriptName%
:: Return the security policy to the defaults.
Powershell -command "& \\{Set-ExecutionPolicy -Scope LocalMachine Restricted -Force\\}"
Powershell -command "& \\{Set-ExecutionPolicy -Scope CurrentUser Undefined -Force\\}"
Powershell -command "& \\{Set-ExecutionPolicy -Scope Process Undefined -Force\\}"