Using the Problem Steps Recorder in Windows…

Using the Problem Steps Recorder in Windows 7 #SMBIT

Problem Steps Recorder for Windows 7 Troubleshooting

Problem Steps Recorder for Windows 7 Troubleshooting. SEP 27. By Jeffery Hicks 17 days ago under Help Desk Management. Tweet. Save. Often, the first challenge in solving a problem is understanding it….

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.

Friday Fun Virtual Demos

I’ve been prepping my demo scripts for Techmentor using the ubiquitous Start-Demo, and realized I could take things further. I mean, why do I have to do all the talking? Windows 7 has a terrific text to speech engine so why not take advantage of it. With a little work I could create a virtual demo that doesn’t require a real person, other than to kick it off. Thus was born Start-VirtualDemo.

My function relies on the SAPI.SPVoice COM object and works best on Windows 7. The voice isn’t perfect but much better than previous versions and at least in my tests more than adequate. The function needs a text file “script”. In this file, write the text you want to be read putting a # at the beginning of the line. Then type any PowerShell expressions you would like to demonstrate. For now, the command must be all in one line. Here’s a sample text file.

The function will strip out any blank lines so put in as many as you want to help visually organize your script. You might have to experiment and tweak some words or phrases using phonetic-like alternatives to get the correct pronunciation. The script itself is pretty straight forward.

To run the script all you need to do is specify the text file. Or use the default value from the parameter. The script will store your current location and return to it at the end so if you change locations in your demo nothing will have changed when your demo ends. The script will display the demo command in a pseudo prompt, using your current location.

I have to say I thought this turned out quite nicely. Here’s a video demo.

By the way, I was only kidding about not having to talk and actually do the demos. Still, there are some intriguing possibilities that come to mind with this.

You can download a zip file with the Start-VirtualDemo script any my demo text file here.

New Event Report Revised

Last year I posted an update to an old Mr. Roboto script that was an update to an even older VBScript. Still with me? My last revision leveraged the new Get-WinEvent cmdlet to create an HTML report of recent error activity on one or more computers. The problem was that I didn’t account for older computers that don’t support Get-WinEvent. I finally have a version that does. Continue reading

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”}}
To invoke it:
[cc lang=”powershell”]
PS C:\> &$running
Because this particular script block takes a computername as a parameter I could also do this:
[cc lang=”powershell”]
PS C:\> &$running Server01
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.