Posted by The Admin Arsenal Team on Fri, Feb 12, 2010
Author: Shane Corellian
Tobias Weltner wrote this article on the Powershell.com site. It is definitely worth the read. For those of you planning on implementing Powershell Version 2, pay special heed.
An excerpt:
"When you search for PowerShell V2 downloads, you will find tons of articles and download links. Only some of them point to the correct final "RTM" link. A lot of people are still blogging about "CTP" versions which really were beta versions with limited functionality. Even worse, it turned out that these out-dated PowerShell versions are still up for download from the Microsoft Download center, so when you follow the "wrong" link, you could get the impression that these CTP versions really were official and up-to date releases."
I have been playing with V2 now for about 3 weeks and so far I am pretty excited. Extending Admin Arsenal with a good CLI is important and Powershell will definitely be the foundation on which it is built.
Posted by The Admin Arsenal Team on Mon, Jan 25, 2010
Photo by Tim Morgan
I was recently bitten by a PowerShell quirk that took me quite a while to find. It has to do with how PowerShell deals with the current directory when making .NET function calls. I created a script to make changes to an XML file that looked similar to this:
cd c:\some-directory
$xml = [xml](get-content "file.xml")
$xml.Parent.Node.Id = [system.guid]::newguid().tostring()
echo $xml.Save("file.xml")
When I ran the script, the file didn't change. I couldn't for the life of me figure out why. This was the first time I was working the XML libraries in PowerShell and I was certain it must be due to how I was using the library. Finally, after about a half hour of searching I discovered that the change file was being saved to the original directory, not to the directory I had changed to. It turns out that when you change directories in PowerShell, you don't change the current directory in the environment and so the .NET libraries think you're still in the original directory. Since I read the file using PowerShell with get-content and saved using the .NET XML library, I was properly reading the file, but saving it in the wrong place.
This quirk is apparently deliberate, having something to do with enhancements in a future version of PowerShell which will allow suspending of jobs in the background. I'm not sure that this is the best way to deal with that eventuality, but there you go.
There are two ways around this problem. The first, and simplest is to use the resolve-path cmdlet:
echo $xml.Save(resolve-path "file.xml")
This will ensure that the full path to the file will be sent to the .NET class, ensuring that the file is saved in the correct location.
The second option, which may be preferable in some situations, is to change the directory using the .NET Directory class:
[IO.Directory]::SetCurrentDirectory("c:\foo")
This will change the current directory in the environment. It's probably safer to use resolve-path, but it will not be sufficient if a .NET class must work on the current directory and you can't pass in another path.
Posted by The Admin Arsenal Team on Fri, Nov 13, 2009
Photo by Redvers
PowerShell, however, does have an equivalent. You can redirect to the built-in variable $null to get the same effect.
PS C:\> dir > $null
In addition to the $null variable you can also pipe output to the out-null cmdlet.
PS C:\> dir | out-null
This second version also has a little trick up its sleeve. Normally when running a GUI app from PowerShell, control is returned immediately to the command line and PowerShell doesn't wait for the GUI app to exit. This may not be what you want. For example, in my build scripts I have a program that generates the documentation, it's actually a GUI app that takes parameters and writes out the help files. I want my script to wait for this process to finish, so the normal behavior doesn't work for me. But, by piping the output of the GUI app to out-null then PowerShell will wait for the app to finish. You can see this yourself by running notepad.
PS C:\> notepad | out-null
Posted by The Admin Arsenal Team on Wed, Oct 14, 2009
Want to deploy Windows PowerShell to your all your organization's computers? You can deploy PowerShell using Admin Arsenal. (A free, fully functional trial version is available.)
First things first: Go download Windows PowerShell. (note: PowerShell is included with Windows 7)
In the example below, I used Admin Arsenal to deploy PowerShell to all of my Windows 2003 x86 servers.
Make certain to use the appropriate installation for your OS (XP, Vista, 2003)
The installation will automatically add the PowerShell directory in your System Path.
Posted by The Admin Arsenal Team on Mon, Oct 12, 2009
If you aren't using Windows 7 and you haven't installed Windows PowerShell yet, then go here to download and install.
Here are a couple of useful PowerShell examples for common tasks:
- Example of Extracting the Total Physical Memory from WMI
- Use PowerShell to directly query WMI
The two examples above show how you can use the "-filter" cmdlet to narrow down the results. In this case we filtered out any device where the DeviceId wasn't "C:". The second example shows how you can pass a WMI query using the "-query" cmdlet. In this case we only returned disks that are registered as Fixed Disks ("DriveType = 3")
- You can also query remote computers
Using the "-ComputerName" cmdlet you can specify a remote system. This should work for any object under the "get-WmiObject" cmdlet.
Posted by The Admin Arsenal Team on Fri, Jul 03, 2009
If you have delayed getting into PowerShell, or if you have installed it but only piddled around a little, then please take note.
There is a PowerShell quick start guide available from Robert Sheldon. It provides six lessons which all build upon each other to get you comfortable using the tool and on the path to incorporating it into your daily tasks.
I recommend it for the beginner (don't worry, there are a lot experienced Windows admins who are new to this type of administration). The book is a bargain US$15.95 and is a quick read. It is provided as a .pdf file.
Unix-turned-Windows admins have waited a long time for a powerful cmd tool like PowerShell. Microsoft has delivered, however like anything worthwhile, Windows admins will need to meet Microsoft halfway and really learn the usefulness of this tool.
Remember, if you are repeatedly performing tasks, then automation is up your alley. PowerShell will help you achieve this.
Posted by The Admin Arsenal Team on Wed, Apr 29, 2009
For those of us who use WMI everyday here is a great blog at MSDN to learn tips and tricks with accessing WMI via PowerShell.
I found a tip to help me start using PowerShell to traverse my WMI database.
Give 'er a look.
Posted by Adam Ruth, Shane Corellian, and Shawn Anderson on Fri, Feb 27, 2009
Sometimes you need to know either the name of a service or its display name. What can be frustrating is when these two names, which refer to the same service, are so completely different that there is no resemblance between the two.
For instance if you wanted to see if the wuauserv service was running, you could run a net start and get a list of all running services. But net start only shows running services. What's if it's stopped or disabled? Worse yet, what if you don't know its display name? This is where PowerShell comes in.
The Display Name for wuauserv is "Automatic Updates". If you know at least one of these "names" you can easily see both using PowerShell command:
get-service -displayName "Automatic Updates"
or:
get-service -Name wuauserv
Both provide the same output, which gives you more information than our old friend net start does. You can see the state of the service and make changes on the fly.
For more information on PowerShell, I suggest visiting Microsoft's PowerShell blog.