Quick-Hits Friday: The Scripting Guys Respond to a Bunch of Questions (8/27/10)
In this post:
- How Can I Take Script Output and Use It in Other Scripts?
- Troubleshooting a Script That Reads from Excel
- Does Windows 7 Recognize VBScript Scripts?
- Can I Change the Path to the Profile Folder in Windows PowerShell?
Hey Scripting Guy! I’m trying to learn Windows PowerShell. I took your script for enumerating computers in the domain, and it worked like it was supposed to. That list of computers will be the cornerstone of almost everything I do with Windows PowerShell. However, I have one glaring issue. How do I take that list of computers and actually use it in other scripts? Would the computer script become a function in any subsequent script I write?
Microsoft Scripting Guy Ed Wilson here. You are in luck. I just finished a week of searching Active Directory posts and think this is what you will need. Especially see yesterday’s post that talked about searching Active Directory, returning a list of computers, and running a WMI query on each of the computers. I display the results as a formatted table and write the output to a text file as well. And by the way, you are correct: The search AD part is a function.
Hey Scripting Guy! I am helping a friend out with a script he is making.
The part I am having trouble with is reading from Microsoft Excel. I managed that with the code seen here.
$x = new-object -comobject excel.Application[void]$x.Workbooks.Open(“D:\My Documents\D5003100.xls”)$x.Cells.Item(6,7).Value()$x.Workbooks.Close()$x.quit()
Here is where it gets tricky. I need the script to run as a scheduled task. When no user is logged on, the script fails to read the Microsoft Excel file. Is there something that I can do to avoid that?
The problem is that you are trying to read an Excel spreadsheet that is in the My Documents folder. As you are no doubt aware, this is a virtualized location that is part of a user’s specific profile. Therefore, if the user is not logged on, the profile is not loaded and therefore the file is not accessible. The resolution is to store the file in a location that is accessible when the user is logged out.
Hey, Scripting Guy! We have a few scripts. They are VBScript scripts that we use to map network drives. We have a computer with Windows 7 Professional for testing in the company; the problem I have is that the scripts don’t run at logon time but they run in Windows XP without any problem. Does Windows 7 recognize VBScript scripts? We have Windows Server 2003 Standard edition for our domain controllers.
Yes, Windows 7 recognizes VBScript scripts. The issues you are seeing are due to changes in the security model that were introduced in Windows Vista and carried forward into Windows 7. It is possible that your scripts are performing privileged operations and therefore would need to be launched with elevated permissions. Normal users may not have permission to map drives or to unmap drives without modification of their rights. Testing of your scripts in a controlled environment will determine if it is in fact a rights or permissions issue.
Hey, Scripting Guy! I have a Windows PowerShell question I have been unable to find an answer for. At work we redirect the personal folder to a network drive. As a result, Windows PowerShell thinks my profile file should be kept there. This is a problem for my laptop. When I am off the LAN, I no longer have access to my Windows PowerShell profile file. My question is whether I can change the path to the profile folder in Windows PowerShell?
Yes, this can be done. There are, by the way, six different profiles in Windows PowerShell 2.0. They are located in different locations, and contain different functionality. There are profiles for the Windows PowerShell ISE as well as profiles for the Windows PowerShell console. This Hey, Scripting Guy! Blog post, which is partially based upon my Windows PowerShell Best Practices book, explains the profiles.
The reason for this “background” is that the $profile variable is simply a variable. You can modify it to point to a different location. I have, for example, modified it to point to a profile that was stored on a network and shared by multiple users and computers. Pretty cool, but not supported.
If you use the Get-Variable cmdlet, you will also notice that there are other automatic variables that you may wish or need to modify. For example, the $home variable points to my user directory, and you may wish to modify it in the profile, or even create a new variable called $myhome that points to a local resource. This is shown in the following image.
In reality, I do not use my Windows profile directory. In my Windows PowerShell profile, I immediately change the working directory to c:\ so that I have more space on the Windows PowerShell command line. This is because the default location, inside the profile, takes up half of the command line. In addition, I never rely on any relative path, and I use a c:\fso folder for my scratch directory. This is a short path that is easy to type and remember, and a relic from my old fashioned VBScript days (fso standing for filesystemobject, which I still use in Windows PowerShell from time to time because of its extreme speed).
Well, this concludes another edition of Quick-Hits Friday. Join us tomorrow for the Weekend Scripter as we delve into the mysteries of Windows PowerShell ISE.
We would love for you to follow us on Twitter and Facebook. If you have any questions, send email to us at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson and Craig Liebendorfer, Scripting Guys