In this post:

 

 Dealing with Hidden File Extensions

Hey, Scripting Guy! Question

Hey, Scripting Guy! I hope you guys can help. I was trying to install a program that uses a .vbs script to install. When I opened the file, all I got was a Notepad listing of the file. It didn't run. On your blog, I tried the little test program in your FAQ and got the same result. Clicking the Notepad file just gave a listing; the program didn't run. I am running Windows XP Professional SP3. Can you help me to figure out what is wrong and how to fix it?

-- PN

 

Hey, Scripting Guy! Answer

Hello PN,

More than likely, your Windows Explorer is set to hide file extensions. This is the default setting on Windows XP and other versions of the operating system. Therefore, if you double-click your installer script, the file extension is hidden, and it is a .txt file, it would open in Notepad by default. Files in Windows can have things that look like multiple file extensions. This is because a period is allowable in a filename. For example: Myfile.vbs.txt. The file name is actually Myfile.vbs the extension is actually .txt. Therefore, in Windows Explorer (and elsewhere) where you look at this file, you will see Myfile.vbs, but when you double-click the file, it opens in Notepad because it is actually a .txt file.

When you went through the tutorial, and copied the sample script there into notepad, and when you saved it as sample.vbs, Notepad has the action set to save as a text file by default. You must change the Save As portion of the dialog from Text file to All files; otherwise, you will end up with helloWorld.vbs.txt. When coupled with the fact that Windows Explorer hides file extensions by default, you are almost doomed to frustration.

Image of file extensions in Save As dialog box

Go into Windows Explorer and reveal the file extensions, and you will more than likely see that you have Myfile.vbs.txt.

Incidentally, this was a favorite trick of hackers for years. They would send you by email a document called, say, coolstuff.doc that was actually a Trojan, because it was really named coolstuff.doc.exe. When people opened the supposedly safe .doc file, their computer became infected. The first thing I do after installing any operating system is go into Windows Explorer and turn on Show file extensions.

 

 

 How Can I  Programmatically Remove the Everyone Group?

Hey, Scripting Guy! Question

Hey, Scripting Guy! Is there any way to remove the Everyone group from all of the hard drives programmatically? If so, can you tell me how? I can’t find a solution to this problem anywhere. Any help will be greatly appreciated!

-- TG

 

Hey, Scripting Guy! Answer

Hello TG,

Of course, there is a way to do this. However, I would strongly encourage you to reconsider. The Everyone group in Windows 7 is basically present for compatibility purposes. It is not the same Everyone it was back in the old days. It is entirely possible you could break certain applications if you mess with this setting. If you are certain you need to do this, you can easily use Icacls to do this. We have a Hey, Scripting Guy! Blog post or two that talk about using Icacls. You may also wish to refer to some of the scripts in the Script Repository that deal with security. Here is a link to an article on TechNet also.

 

How Can I Stop a Script That Has Started Running? 

Hey, Scripting Guy! Question

Hey, Scripting Guy! I am at the "Scripting: Your First Steps" page and copied the script for the random number generator. I increased the size of i to 50, but found that after just a few numbers displayed, clicking on the X did not close the program but continued until I had 50 numbers generated.

So my question is: What do I need to do to close the program at any point when it is running?

-- TG

 

Hey, Scripting Guy! Answer

Hello TG,

At the beginning of the Scripting Your First Steps page, it talks about running a script. In there, you open the command prompt, type cscript, and provide the path to the script. When you have a script that has a large number of wscript.echo statements in it, this is a best practice or else you will end up with 50 dialog boxes being presented. What you did was double-click your script after you wrote (or copied) the code that creates the random number. Because you are in a loop, every time you close the dialog box, you are only closing that dialog box. You are not interacting with your script. In fact, your script is basically on cruise control, and the only way you can stop it is to go to Task Manager and kill the wscript.exe process.

If you run a script under CScript in the command prompt, and the script goes into a loop that is longer than you wish, you can usually break out of that script by typing Ctrl+C, which will "break" into the script and halt script execution. This is in many ways more convenient than having to open Task Manager and kill the wscript.exe process. In addition, there may be times when there are other scripts running, and you will in all likelihood not know which script process to kill.

Many commercial script editors offer scripting and debugging environments in a single console. These generally offer you the ability to run the script, edit the script, debug the script, and control script execution in the same interface.

Windows PowerShell, Microsoft's newest scripting language that ships with Windows 7 and is available for download and installation on Windows XP and later, comes with such an integrated scripting environment. For assistance in learning Windows PowerShell, refer to the Learn Windows PowerShell page.

 

 Troubleshooting a Script That Uses WMI

Hey, Scripting Guy! Question

Hey, Scripting Guy! I converted my add printer script to use Excel as its input source. When the script runs, it looks good until it gets to the end. There is an error being generated on the objPrinter.Put_ statement. The error is "SWbemObjectEx: Generic failure." I am confused by this because the script works fine as a standalone. All I did was replace the hard-coded statements with strVariables from the spreadsheet. I've used the same looping code (for the Excel part), so I am pretty sure that is not the issue. I put some echo statements in the places where the variables are being read (right before the printer creation statements) to make sure there wasn't an issue with how the data was being presented. No problems. I looked on the web and didn't really find anything enlightening about this error message. Any ideas?

-- WM

 

Hey, Scripting Guy! Answer

Hello WM,

SwbemObjectEx is the main object used to work with WMI. It is documented on MSDN and offers extended methods to the SwbemObject object. Because SwbemObjectEx inherits from SwbemObject, it includes all of the methods and properties of SwbemObject. For example, the Put_ method comes from SwbemObject, even though SwbemObjectEx is reporting the error.

Unfortunately, a generic failure is like a “generic go jump in a lake” kind of error message. It is not very helpful at all. There are a couple of things you could do to possibly obtain additional information. The first being to enable enhanced WMI logging. If you are running Windows Vista or later, you would enable ETL logging. If you are using Windows Server 2003 or earlier, you would need to go into the WMI control tool and enable diagnostic logging there. You would then run the script again, and when it fails, look in the diagnostic logs and look at the trace to see if you spot additional information.

My guess, however, is that the data type is getting transformed via Excel and your script. One thing to try is to go into Excel and add quotation marks around the printer name. I am not certain what you are actually doing, or what your data looks like, and do not get too carried away and screw up your spreadsheet. Perhaps make a test sheet and point your script to that to see what happens.

Well, this concludes another edition of Quick-Hits Friday. Join us tomorrow for the Weekend Scripter as we talk about exploring the Windows PowerShell ISE.

If you want to know exactly what we will be looking at tomorrow, follow us on Twitter and Facebook. If you have any questions, send email to us at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

 

Ed Wilson and Craig Liebendorfer, Scripting Guys