Posts Tagged ‘PowerShell’

Running Windows PowerShell scripts.

Few notes before, I wrote about finding the HP product number of any of your HP servers using PowerShell. First time, when I tried to do this, I double-clicked a .PS1 file (.PS1 being the file extension for Windows PowerShell scripts), sat back, and waited for the magic to happen.
As it turned out, however, this is what happened:
Instead of running, my script opened up in Notepad. Interesting, but not exactly what I had in mind. Oh wait, I thinked, I got it: I probably have to run Windows PowerShell before I can run a Windows PowerShell script. OK, that makes sense. And so, with that in mind, I opened up Windows PowerShell and typed the path to the .PS1 file at the command prompt. Pressed ENTER and waited for the magic to happen.
As it turned out, however, this is what happens:
Why did I get weird error messages when I try to run a script? That’s easy. The security settings built into Windows PowerShell include something called the “execution policy” – the execution policy determines how (or if) PowerShell runs scripts. By default, PowerShell’s execution policy is set to Restricted – that means that scripts – including those you write yourself – won’t run. Period.
How to verify the settings for your execution policy? By typing the following at the PowerShell command prompt and then pressing ENTER:


Now, admittedly, this might seem a bit severe. After all, what’s the point of having a scripting environment if you can’t even run scripts with it? But that’s OK. If you don’t like the default execution policy (and you probably won’t) then just go ahead and change it. For example, suppose you want to configure PowerShell to run – without question – any scripts that you write yourself, but to run scripts downloaded from the Internet only if those scripts have been signed by a trusted publisher. In that case, use this command to set your execution policy to RemoteSigned:

Set-ExecutionPolicy RemoteSigned

Alternatively, you can set the execution policy to AllSigned (all scripts, including those you write yourself, must be signed by a trusted publisher) or Unrestricted (all scripts will run, regardless of where they come from and whether or not they’ve been signed).
After I changed execution policy settings it’s possible to run scripts. However, there is a little trick that might run you into problems. For example, suppose you change directories from your Windows PowerShell home directory to C:\scripts (something you can do by typing cd C:\scripts). As it turns out, the C:\scripts folder contains a script named script.ps1. With that in mind I typed the script name, pressed ENTER and waited for the magic to happen.
As it turned out, however, this is what happens:
I know what you’re thinking: didn’t we just change the execution policy? Yes, we did. However, this has nothing to do with the execution policy. Instead, it has to do with the way that PowerShell handles file paths. In general, you need to type the complete file path in order to run a script. That’s true regardless of your location within the file system. It doesn’t matter if you’re in C:\Scripts; you still need to type the following:


Now, I said “in general” because there are a couple of exceptions to this rule. For example, if the script happens to live in the current directory you can start it up using the .\ notation, like so:


And while PowerShell won’t search the current directory for scripts it will search all of the folders found in your Windows PATH environment variable. What does that mean? That means that if the folder C:\Scripts is in your path then you can run the script using this command:


But be careful here. Suppose C:\Scripts is not in your Windows path. However, suppose the folder D:\Archive is in the path, and that folder also contains a script named script.ps1. If you’re in the C:\Scripts directory and you simply type script.ps1 and press ENTER, guess which script will run? You got it: PowerShell won’t run the script in C:\Scripts, but it will run the script found in D:\Archive. That’s because D:\Archive is in your path.
Just something to keep in mind.

How to run scripts without starting Windows PowerShell?
As a security measure you can’t start a PowerShell script by double-clicking a .PS1 file. So apparently that means that you do have to start PowerShell before you can run a PowerShell script. However, that doesn’t mean that you can’t start a PowerShell script from a shortcut or from the Run dialog box; likewise you can run a PowerShell script as a scheduled task. The secret? Instead of calling the script you need to call the PowerShell executable file, and then pass the script path as an argument to PowerShell.exe. For example, in the Run dialog box you might type a command like this:
There are actually three parts to this command:
Powershell.exe, the Windows PowerShell executable.
-noexit, an optional parameter that tells the PowerShell console to remain open after the script finishes. Like I said, this is optional: if you leave it out the script will still run. However, the console window will close the moment the script finishes, meaning we won’t have the chance to view any data that gets displayed to the screen.
Incidentally, the -noexit parameter must immediately follow the call to the PowerShell executable. Otherwise the parameter will be ignored and the window will close anyway.
C:\script.ps1, the path to the script file

Categories: MS Windows, OS Tags: ,

Finding the HP product number of any of your HP servers using PowerShell.

You can easily find the HP product number of any of your HP server by looking on the server itself or on the warranty card. The HP product number is nice to have if you want to easily find that date your HP server will be out of warranty. This product number is no longer mandatory if you are using warranty check tool, but in some case you will still need it.
If your HP server was built using HP SmartStart (or the newer HP Intelligent Provisioning) the product number could be found in the windows registry:


Here is how to use PowerShell to read this information:

$reg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', "NameOfServer")
$regkey = $reg.OpenSubkey("HARDWARE\\DESCRIPTION\\System\\BIOS")
$SystemSku = $regkey.GetValue("SystemSku")

This could easily be part of a small script that would allow you to get more information about your servers:

$Servers = Get-content "C:\server_list.txt"

foreach($Server in $Servers){
#Read HP product number from registry
$reg = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey('LocalMachine', $Server)
$regkey = $reg.OpenSubkey("HARDWARE\\DESCRIPTION\\System\\BIOS")
$SystemSku = $regkey.GetValue("SystemSku")

#Get Manufacturer, Model, SerialNumber from WMI query
$HardwareInfo = Get-WmiObject win32_computersystem -ComputerName $Server
$SerialNumber = Get-WmiObject win32_bios -ComputerName $Server

#Create a CSV file with Inventory information
$Server + "," + $HardwareInfo.Manufacturer + "," + $HardwareInfo.Model + "," + $SerialNumber.SerialNumber.Trim() + "," + $SystemSku | Add-Content C:\inventory.csv

Remove-Variable REG, regkey, SystemSku
Remove-Variable HardwareInfo, SerialNumber, Server
Remove-Variable Servers

-put all your HP servers names (or IP addresses) running MS operating systems in c:\server_list.txt
-run the script (Copy/Paste) saved in a PS1 file
-output will be in C:\inventory.csv

It turns out that above script works even if your HP server was installed without HP SmartStart or HP Intelligent Provisioning. Moreover – the script works with every HP laptop/PC with MS Windows.