Windows Powershell makes it relatively easy to collect performance counter information via the Get-Counter cmdlet. Because I’m assuming you want to collect more than a few seconds of performance information, you’ll need to take advantage of PowerShell background jobs if you want your prompt back. Of course, you can always open a second session, but I like the background job approach. Here’s how I’ve been experimenting with this. Continue reading
Category Archives: Windows Server
New Petri Author
New Petri Author
I trust many of you are familiar with the Petri web site. This has long been a very valuable site for IT Pros. You can always find a wealth of reliable and practical information. Starting in December, I will be adding my voice to the mix. I will be contributing content that I hope you find valuable and worth your time. I expect my articles will be wide ranging, and not limited to Windows PowerShell. With the impending arrival of Windows 8 there will be much to write about. I hope you'll join me for the ride.
One of the world's leading MCSE and IT related knowledge bases with thousands of Windows, Exchange, and Virtualization related tips, tricks and how-to articles.
Running Remote Processes Here is a video…
Running Remote Processes
Here is a video clip from my upcoming course for TrainSIgnal, "Windows Server 2008 PowerShell Training". This clip shows how to work with processes on remote computers.
Managing WSUS from a Non-Domain Member
I run a lot of test machines in my home office network and rely on WSUS. However, my primary desktop is a stand alone system, that is not a domain member. This has always meant that I needed a remote desktop connection to the WSUS server to approve updates. The latest remote management tools from a Windows 7 client were proving problematic. I was always getting an error message that the server wasn’t listening on port 80 and to use port 443, when in fact the real problem was authentication.
My solution, so I could avoid the cumbersome RDP route was to take advantage of pass-through authentication. On my Windows 7 desktop, I created an account with the same name as a domain account that could administer the WSUS service. Because I have RSAT installed, I now navigate to the Windows Server Update Services management console menu link, hold the shift key and right click. I select “Run as different user” and enter the local user account and password, which is the same as my domain account. Because they are the same, I am authenticated and no error messages.
I should disclaim that my WSUS server is running Windows Server 2003 R2 but as far as I know there’s no reason passthrough authentication shouldn’t work for newer server versions as well.
TechEd Berlin Paradigm Shift Demos
I had a great time in Berlin at TechEd and want to thank everybody who came to my presentation. I hope you found it valuable and worth your time. As promised, you can download my demo files here. The .txt files are my demo files which are really just a list of PowerShell commands. They are not meant to be run as complete PowerShell scripts. Some of the demos call the other VBS and PS1 scripts.
Here’s the recording of my session. (visit TechEd site)
Finally, Oskar S. was the winner of a free ebook of Windows PowerShell 2.0: TFM.
Friday the 13 Script Blocks
In celebration of Friday the 13th and to help ward off any triskaidekaphobia I thought I’d offer up 13 PowerShell scriptblocks. These are scriptblocks that might solve a legitimate business need like finding how long a server has been running to the more mercurial such as how many hours before I can go home.
A scriptblock is any small piece of PowerShell code enclosed in a set of curly braces. I say small, but there’s really no limit. You can even pass parameters to a script block. In this way they are like functions but without the function key word. Save the script block to a variable and when you want to execute, use the invoke operator, the & character. For example, here’s one of my luck 13 script blocks.
[cc lang="powershell"]
#1. Get running services
$running={Param ([string]$computername=$env:computername) get-service -computername $computername |
where {$_.status -eq “Running”}}
[/cc]
To invoke it:
[cc lang="powershell"]
PS C:\> &$running
[/cc]
Because this particular script block takes a computername as a parameter I could also do this:
[cc lang="powershell"]
PS C:\> &$running Server01
[/cc]
I won’t post the complete script here, but these are the goodies:
#1. Get running services
#2. Get logical disk information
#3. Get day of the year
#4. Get top services by workingset size
#5. Get OS information
#6. Get system uptime
#7. get a random number between 1 and 13
#8. How old are you?
#9. get %TEMP% folder stats
#10. Get event log information
#11. Get local admin password age in days
#12. Get cmdlet summary
#13. How much time before I can go home?
I wrote many of the script blocks so that you could use them in your own functions and scripting and tried to make them re-usable as possible. They have no error handling and assume you have all the necessary permissions. Think of them as quick and dirty PowerShell snippets. The script file is simply defines the 13 script blocks. After each one is a commented example of how you might run it.
Again, I’m not promising anything life-changing but I hope you’ll have fun with them today. Download the script file 13ScriptBlocks.ps1.
Windows Update Module
I don’t have a large environment to manage, but I do have a number of test boxes I try to keep up date using Windows Software Update Server (WSUS). Occasionally I’ve needed to manage things client-side. Unfortunately, there aren’t a lot of good tools, and nothing PowerShell-related that I’ve found so I wrote my own. At the end of this post you’ll be able to download a zip file with a self-extracting exe file to install my Windows Update module. Once installed, open an elevated PowerShell session and import the JH-WindowsUpdate module.
The module consists of the following commands:
- Get-WindowsUpdateLog
- Backup-WindowsUpdateLog
- Clear-WindowsUpdateLog
- Get-WindowsUpdate
- Install-WindowsUpdate
The first challenge I tackled was finding an easier way to work with the client side event log. This text file, WindowsUpdate.log can get quite unwieldy very quickly. What I wanted was an object-based solution so I could find information. Get-WindowsUpdateLog takes the current log and turns each line into an object. Any lines that are just comment characters are stripped out. You end up with an object like this.
[cc lang="PowerShell"]
Component : Report
Message : Reporter successfully uploaded 2 events.
PID : 1100
Computername : SERENITY
TID : 17c0
Category : Normal
Datetime : 8/3/2010 7:47:26 AM
[/cc]
The function can also query remote computers and has a parameter to run as a job, which I typically do because processing the log file can take some time. I typically use it like this:
[cc lang="PowerShell"]
PS C:\> $wu=Get-WindowsUpdatelog
PS C:\> $wu | select DateTime,Component,Category,Message
[/cc]
When the file gets too big or whenever you feel like it, you can clear the log using Clear-WindowsUpdateLog. This will require restarting the WUAUSERV service. You can manage remote computers as well via WinRM. But you might want to first make a backup copy with Backup-WindowsUpdateLog. Be sure to look at command help and examples for everything.
The next part of the puzzle are the updates themselves. Fortunately there is a COM object that can be used to find and download Windows Updates.
[cc lang="Powershell"]
#create session objects
$updateSession = New-Object -ComObject “Microsoft.Update.Session”
$updateSearcher = $updateSession.CreateUpdateSearcher()
[/cc]
The Get-WindowsUpdate command will find all recommended updates needed on the local computer. Or you can use -All.
The command doesn’t directly support remote computers, but you should be able to run it in a remote session. Installing updates uses almost the same approach with Install-WindowsUpdate. The default is to install Critical updates only. But you can install by severity, title or all.
If the update requires a reboot, the computer will not automatically reboot unless you specify -Reboot.
Unfortunately, installing updates must be done locally in an interactive session. There is a well known bug with this COM object that nobody has yet to find a way to beat. The best thing you can do for remote computers is to use SCHTASKS.EXE and remotely create a scheduled task to run the function on the remote computer. Of course you need to copy the module to the remote computer or at least load the function.
Please find a way to test all of this in a non-production environment. You can download the zip file with the self-extracting exe file here. Please post any followups, bugs or comments to this post.
Finally, and I’m trying something new here, but if you feel this module (or anything I’ve ever published for that matter) is of value to you or your organization, I hope you’ll consider adding something to my Paypal tip jar. Any contribution would be appreciated and allows me to continue developing solutions like this along with all my other PowerShell endeavors. Thank you.
UPDATE: I’ve already made an update. I’ve tweaked a few of the functions to fix a few bugs and hopefully improve performance. The original zip file with the self-extracting archive has been update. However, for people with mapped home drives the default install path will be a problem. You can always manually specify where to install per user, but anyone just clicking through will run into problems. Therefore, I’ve also created a simple zip file which you can download here. Manually extract the contents to a folder in your PSModulePath which you can check by looking at $env:PSModulePath.