Search results for 'app:weblogs' matching tags 'Scripting Guy!' and 'services'

Send an Email Message with Service Status Via PowerShell

Anonymous — Wed, 19 Dec 2012 06:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use Windows PowerShell to send an email message with service status info.

Hey, Scripting Guy! I have a number of services on a remote server that I would like to monitor. I would like to see the status of these services and receive these status updates via an email message. I have looked around on the Internet and not found a satisfactory script—everything looks too complicated. Can you help me?

—DB

Hello DB,

Microsoft Scripting Guy, Ed Wilson, is here. Well, it is sort of cold and rainy down here in Charlotte, North Carolina. But tomorrow is supposed to be a beautiful sunny day. So, at least there is hope. If the weather is good, the Scripting Wife and I are planning on heading out to the Columbia Zoo in Columbia, South Carolina, tomorrow. They have a very nice zoo there, and we always enjoy spending a few hours there. Combine that with lunch out at a nice restaurant, and we end up having a great day.

DB, monitoring the status of your services and sending you an email message does not have to be a zoo, it can be a really simple solution—in fact, it is a single line of code.

Checking the status of services on a remote server

To check the status of services on a remote computer, I can use the Get-Service cmdlet (assuming I have rights, and the appropriate ports in the Windows Firewall are open). In fact, it can be really easy. Suppose I want to check on the status of services associated with my SQL Server. In this case, it is really easy because the services begin with MSSQL. Therefore, I can use this bit of information, and do something like the following (gsv is an alias for the Get-Service cmdlet):

gsv -cn sql1 -Name mssql*

One thing to keep in mind is that the Get-Service cmdlet returns an object, or in this example, a series of objects. The ultimate goal is to write the information to an email message—I cannot write an object to an email message. Therefore, I will need to convert the output to a string. Luckily, Windows PowerShell contains the Out-String cmdlet. The code to retrieve SQL service information from a remote server named SQL1 and to return that information as a string is shown here, along with the associated output.

14:57 C:\> gsv -cn sql1 -Name mssql* | out-string

Status Name DisplayName

------ ---- -----------

Running MSSQL$SHAREPOINT SQL Server (SHAREPOINT)

Running MSSQLFDLauncher SQL Full-text Filter Daemon Launche...

Running MSSQLSERVER SQL Server (MSSQLSERVER)

Stopped MSSQLServerADHe... SQL Active Directory Helper Service

Running MSSQLServerOLAP... SQL Server Analysis Services (MSSQL...

Sending an email message

Windows PowerShell 2.0 introduced a very cool cmdlet—the Send-MailMessage cmdlet. The Send-MailMessage cmdlet permits me to, well, send an email message. One of the great things to do is to create default values for this cmdlet—such as the From field and the SMTPServer field. In Windows PowerShell 3.0 this is easy to do, but for my one-liner today, I will not create default values. The key fields I need to populate are From, To, Subject, Message, and SMTPServer. For the message, I use the command I populated earlier to get the remote service information to a string. The resultant command appears here—keep in mind, it is a single-line command that spans two lines on the blog.

Send-MailMessage -To edwilson@contoso.net -From "ed@iammred.net" -SmtpServer ex1.contoso.net -Subject "Service Status SQL1" -body ((gsv -cn sql1 -Name mssql*) | out-string)

The email message is shown here.

DB, that is all there is to using Windows PowerShell to retrieve the status of services on your remote server. You can easily plug this sort of one-line command into the Task Scheduler to send you a status message every hour, or as often as you feel you need the status update. I have written quite a bit about using Windows PowerShell and the Task Scheduler. Join me tomorrow when I will talk about more cool Windows PowerShell stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell to Find Non-Starting Automatic Services

Anonymous — Tue, 18 Dec 2012 06:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to troubleshoot non-starting automatic services.

Hey, Scripting Guy! I have this server in a remote office that is running SharePoint. I do not know what version, but I am not certain that is a problem because it used to work. The problem is the workers in this remote office use this SharePoint server every day—they update copies of an Excel spreadsheet that tracks their daily business activity. Anyway, the server is sort of old, and routinely runs with nearly 100 percent of the memory utilized, and 90 percent of the CPU utilized. Today, I got a call from the office manager saying that they cannot access SharePoint. I tried to make a remote desktop protocol (RDP) connection to troubleshoot the machine, but to be honest, with the limited bandwidth and hardware constraints on the machine, RDP creeps me out, and I want to give up in frustration. What I think I need to do is check the status of the services to see what is started, what is not, and if there are any error codes.

—DD

Hello DD,

Microsoft Scripting Guy, Ed Wilson, is here. Well today, the weather is balmy … at least I think it is balmy, though not sure exactly what balmy is, so it may not actually be balmy. What the weather does do is remind me of when I was growing up in Florida. The weather outside is 60 degrees Fahrenheit with a humidity of nearly 80 percent. It is not raining, but after spending a bit of time outside, it feels like it will rain. The Magnolia tree in my front yard even has a couple of bloom buds on it, but whether those will turn into flowers or not remains to be seen. So why am I talking retro here? Well DD, it is because to check what you need to check will require you to take a retro-type of approach.

Obtaining service startmode and exit code information

I love using the Get-Service Windows PowerShell cmdlet. In fact, the Get-Service cmdlet is one of the cmdlets I refer to as a “demo” cmdlet. Why demo? Well, because it is so easy to use, and because it returns so much good information. I use it every time I am doing a demonstration of Windows PowerShell for network administrators who have never before seen Windows PowerShell. Luckily, that particular audience pool is rapidly shrinking, and I only occasionally speak to an audience where no one has seen Windows PowerShell previously.

But, three pieces of information commonly required for troubleshooting Windows services are not returned by the Get-Service cmdlet. These three pieces of information are the service StartMode, the service StartName, and ExitCode. To find these three pieces of information requires using the Win32_Service WMI class.

Finding started and stopped services

DD, you stated that you want to see the StartMode, StartName, and the ExitCode of the services. You also say you want to see what is started and what is not. You can easily get what is started and what is not from the Get-Service cmdlet—in fact, the Get-Service cmdlet takes a ComputerName parameter, and therefore, it might work, depending on the firewall configuration.

By using the Windows PowerShell 3.0 Get-CimInstance cmdlet, the following command returns the service state (what is started and what is not) on a remote computer.

Get-CimInstance win32_service -computer sql1 | Sort state | select name, state

The command and its output associated are shown here.

By using the Windows PowerShell 2.0 cmdlets, the only change required is to change from using the Get-CimInstance cmdlet to using the Get-WmiObject. This command is shown here.

Get-WmiObject win32_service -computer sql1 | Sort state | select name, state

Note When converting a Get-WmiObject command to Get-CimInstance, keep in mind that the Get-WmiObject cmdlet uses –Class, and Get-CimInstance cmdlet uses –ClassName. But using –Class (or even using it positionally as done in my previous example) works— the problem would be converting a Get-CimInstance cmdlet that had spelled out –ClassName to Get-WmiObject.

Finding start up accounts, exit codes, and startup type

To find information that is more directly related to troubleshooting, it is better to filter out information more directly related to why the service did not start. I am interested in, first, seeing if the service is set to start up automatically and to see if it is, in fact, running. I use the following filter:

-Filter "startmode = 'auto' AND state != 'running'"

Next, I select the name of the service, the startup account used by the service, and the exit code. The command using the Get-Ciminstance cmdlet (along with output associated with the command is shown here.

15:42 C:\> Get-CimInstance win32_service -Filter "startmode = 'auto' AND state != 'running'" -ComputerName sql1 | select name, startname, exitcode

name startname exitcode

---- --------- --------

FIMSynchronizationService Administrator@iammred.net 1066

MSSQLServerADHelper100 NT AUTHORITY\NETWORKSERVICE 1066

RemoteRegistry NT AUTHORITY\LocalService 0

sppsvc NT AUTHORITY\NetworkService 0

SQLAgent$SHAREPOINT NT AUTHORITY\NETWORK SER... 0

On Windows PowerShell 2.0, the command is the one showing here.

Get-WmiObject win32_service -Filter "startmode = 'auto' AND state != 'running'" -ComputerName sql1 | select name, startname, exitcode

If a service has an exitcode value of 0, then it means that no error generated when the service exited. For some services, they start, and then stop, and then do not start back up again until they are needed (not all the time, mind you, just some of the time). If I want to hone in on services that do not have an exit code of 0, then I add one more bit of code to my filter. The revised filter is shown here.

-Filter "startmode = 'auto' AND state != 'running' AND Exitcode !=0 "

The complete command is shown here (note, this is a one-line command that is wrapped to display on the blog).

Get-CimInstance win32_service -Filter "startmode = 'auto' AND state != 'running' AND Exitcode !=0 " -ComputerName sql1 | select name, startname, exitcode

Using the Windows PowerShell 2.0 cmdlets, the command is shown here.

Get-wmiobject win32_service -Filter "startmode = 'auto' AND state != 'running' AND Exitcode !=0 " -ComputerName sql1 | select name, startname, exitcode

Both commands and their output are shown here.

DD, that is all there is to using Windows PowerShell to check on the status of Windows Services. Join me tomorrow when I will talk about some more cool Windows PowerShell stuff.

Ed Wilson, Microsoft Scripting Guy

Three Cool PowerShell Service Tricks

Anonymous — Mon, 27 Aug 2012 05:00:00 GMT

Summary: Ed Wilson, the Microsoft Scripting Guy, talks about three cool Windows PowerShell tricks for working with services.

Microsoft Scripting Guy, Ed Wilson, is here. It does not matter what ones role is, whether an Exchange Server admin, a Group Policy guru, or even an ordinary every day power user, one eventually needs to work with services. Today I will show three cool tricks that involve using Windows PowerShell to work with services.

Stop multiple services at once

One of the nice features of the Get-Service cmdlet is that it accepts an array. Therefore, I can find information about specific services by supplying the name of multiple services. This technique is shown here.

PS C:\> Get-Service bits,wuauserv

Status Name DisplayName

------ ---- -----------

Running bits Background Intelligent Transfer Ser...

Running wuauserv Windows Update

The Stop-Service cmdlet accepts an array of ServiceController objects (the type of object returned by the Get-Service cmdlet). Therefore, I can pipe the results of the Get-Service cmdlet to the Stop-Service cmdlet to stop the array of services. This command is shown here.

Get-Service bits,wuauserv | Stop-Service

To see what a command does prior to the actual execution of the command, use the WhatIf switch. In the image that follows, the use of the WhatIf switch to prototype the command appears, followed by the actual command to stop the services.

Start multiple services

The Start-Service cmdlet also accepts an array of ServiceController objects as pipelined input. This means that I can use Get-Service to look at my service status, and then pipe the objects to the Start-Service cmdlet if required. This command is shown here.

Stopping and disabling services in one command

A cool thing is that I can use the Get-Service cmdlet to check on a group of services. If I want to stop them, I can pipe the returned ServiceController object to the Stop-Service cmdlet. But what if I also do not want the services to start up on the next reboot? Here is where some really cool stuff comes into play…

I use the PassThru switch, and the ServiceController objects will pass along the pipeline. I can then use those objects with the Set-Service cmdlet and change the startup type of the services to Disabled. Here is the command to accomplish this task.

Get-Service bits,wuauserv | Stop-Service -PassThru | Set-Service -StartupType disabled

Unfortunately, although Set-Service permits setting the startup type of the service to Disabled, the Get-Service cmdlet does not report the startup type of the service. To check on the results of our command, I need to use WMI. Here is the WMI command that I use to check the start mode of the services.

gwmi win32_service -filter "name = 'bits' OR name = 'wuauserv'"

The command and the associate output from the command are shown in the image that follows.

Join me tomorrow when I will talk about more way cool Windows PowerShell stuff.

Ed Wilson, Microsoft Scripting Guy

The Scripting Wife Uses PowerShell to Find Service Accounts

Anonymous — Wed, 15 Feb 2012 06:00:00 GMT

Summary: The Scripting Wife interrupts Brahms to learn how to use Windows PowerShell to find service accounts and service start modes.

Microsoft Scripting Guy, Ed Wilson, is here. One of life’s real pleasures is sitting around a fireplace, listening to a Brahms concerto, and sipping a cup of chamomile tea. I like to add a bit of local honey, and drop in a cinnamon stick. So here I am…mellow and as relaxed as a cat lying in a bay window on a warm summer afternoon. The Charlotte SQL User Group meeting tonight was awesome. We had not seen Chris Skorlinski (the speaker) since the Raleigh SQL Saturday, so we were excited to go. The Scripting Wife and I had a great time, and it was a nice chance to see some friends we had not seen for a while.

Anyway, work finished, now it is time for a warm fire, a little Brahms, and a cup of warm (but not boiling) tea. About to nod off, I was suddenly startled back into reality as the overhead light suddenly switched on.

“How can you see in here in the dark,” the Scripting Wife exclaimed.

“There was nothing to see—I was listening to Brahms,” I began.

“You need to turn that racket down. The neighbor’s dog is beginning to howl. I think he prefers Trace Adkins to that classical stuff anyway,” she continued, “As long as you are awake, I have a problem with a Windows PowerShell command.”

“I see. I think it is you who likes Trace Adkins.”

“Yep, but don’t sidetrack me with talk about Trace Adkins, I need to be prepared for the 2012 Scripting Games so I do not embarrass you or me. Now back to what I came to ask you. I am trying to figure out what account a service uses to start, and I don’t see it. “

“And…”

“And nothing. I type Get-Service, and I do not see anything about service user accounts.”

“Show me your command,” I wearily asked.

“It is right here. Nothing hard…see?”

She plopped down beside me on the sofa and showed me her laptop. She had typed the single command shown here.

Get-Service

The command and the output from the command are shown in the image that follows.

“You know that there is more information don’t you?” I asked.

“Well, duh,” she said. “OK, I will clear the screen and send the output to the Format-List cmdlet.”

Here is what the Scripting Wife did to clear the screen and to obtain all the information available from the Get-Service cmdlet.

She cleared the screen by using the Clear-Host command. But instead of typing Clear-Host, she used the cls shortcut command instead.
Next, she pressed the Up arrow one time to retrieve the previous Get-Service command.
She then typed a space <space> by tapping the Space bar one time, and then she typed a pipe character (the pipe character | is located above the Enter key on my keyboard).
She then typed a space and Format-List * after the pipe character.

The complete command is shown here.

Get-Service | Format-List *

The command and the associated output from the command are shown in the image that follows.

“OK. I am looking at this output, and I still do not see anything about the service account that a service uses to start up,” she complained.

“Well, I did not say it was there, did I? I just asked you if you had looked at all of the information that the Get-Service cmdlet provides,” I stated. “To find the service account start-up information, you need to use WMI. Remember yesterday when we talked about Using PowerShell to Get Hardware Information? You can use the same technique today as you used yesterday.”

The Scripting Wife thought for a few seconds, and then she typed the following command.

Get-WmiObject –list *service*

“Wow, that is a lot of information,” she exclaimed. She turned the laptop monitor so I could look at the display. Indeed, as is shown here, it is a lot of information.

“Use the same technique that you used yesterday to find the WMI class you need to work with services,” I prompted.

Within a few minutes, the Scripting Wife was pointing at Win32_Service.

“Now use the Get-WmiObject cmdlet to query that WMI class,” I said.

It did not take her long to modify her command line to query the Win32_Service WMI class. Here is the command she composed.

Get-WmiObject Win32_Service

The command and the associated results are shown in the image that follows.

“OK, so where are the service accounts?” she asked.

“Remember, you need to use the same technique that you used with the Get-Service cmdlet to retrieve all the information,” I said.

She thought for a bit, then pressed the Up arrow to retrieve the previous command. Then she added a pipeline character and the Format-List cmdlet. The revised command is shown here.

Get-WmiObject win32_service | format-list *

The command and its associated output are shown in the image that follows.

“So where is the service account name?” she asked.

“Look closely at the output. See where it says StartName? That is the service account. See where it says StartMode? That is the way the service starts,” I said, “Why don’t you create a table with just the Name, StartName, and StartMode.”

This time the Scripting Wife did not hesitate. She first cleared the screen, then used the Up arrow to retrieve the previous command. She then edited it by changing it to a Format-Table command. The command that she arrived at is shown here with its associated output.

“That’s cool,” she said.

And with that, she was gone. Just in time for the Andante movement in D-major. Brahms may not have had Windows PowerShell in mind when he wrote, but somehow it seems to fit.

Ed Wilson, Microsoft Scripting Guy

Speed Up Excel Automation with PowerShell

Anonymous — Wed, 01 Feb 2012 06:00:00 GMT

Summary: Microsoft PFE, Georges Maheu, optimizes the Windows PowerShell script he presented yesterday.

Microsoft Scripting Guy, Ed Wilson, is here. Our guest blogger today is Georges Maheu. Georges presented a script yesterday to gather Windows services information in an Excel spreadsheet. Although the script did an adequate job for a small number of computers, it does not scale well for hundreds of computers.

Note: All of the files from today, in addition to files for the entire week are in a zip file in the Script Repository. Georges’ team blog can be found at PFE Blog OpsVault.

Take it away Georges...

Today, we look at scaling up yesterday’s script. As seen, the script makes an inventory of all services running on your servers and identifies those that are using non-standard accounts. The inventory is presented in an Excel spreadsheet.

The first version of the script was linear and simple but somewhat slow; it works well for a small to mid-size environment, but it does not scale well for larger environments.

When doing security assessments, most of the time, only a subset of computers is considered. The objective of an assessment is to locate a few examples of items to correct, not to make a complete inventory. However, when doing remediation planning, a complete inventory is required to evaluate the potential impact of applying modifications to the environment. The script presented yesterday is fine for doing assessments or complete inventory of smaller environments. To make a complete inventory of a larger environment, the script performance needs to be optimized.

Unfortunately, I am not aware of profiler tools for Windows PowerShell. A profiler is a tool that enables you to compute the time spent in each line of code when running a script. There are other ways of estimating where most of your script spends its time. One of them is to create your own timers and track time at various locations.

Another option is to use the Measure-Command cmdlet.

After you instrument the original script, the following statistics are generated:

WMI query: ~ 0.25 seconds for responding local computer

WMI query: ~ 1.00 seconds for responding remote computer

WMI query: ~ 20.00 seconds for non-responding computer

Ping dead computer: ~2.5 seconds

Writing sheet headers: ~ 1.5 seconds

Writing sheet data: ~ 120 seconds

The two main pain points are making a WMI query on a non-responding , which takes about 20 seconds, and writing the data to Excel. If the target computers are servers, these should be few and far apart. However, if these are workstations, investing more time may be needed to address the non-responding computer issues.

In any case, the big gain is obviously with writing data to Excel. After doing some research, the fastest way to write to Excel seems to be to write a range of data rather than writing it cell by cell. Several techniques could be used to achieve this data transfer. Let’s explore two of them…

First method: CSV files

The result of the WMI query can be exported into a CSV file with the Export-CSV cmdlet, and then read directly from Excel with the $excel.workbooks.open() method. Although this looks simple, there is some gymnastics and plumbing involved to get this working. We will look into this further later this week.

Second method: Clipboard

The result of the WMI query can be copied to the clipboard and then pasted into each spreadsheet. This method also avoids having to write the spreadsheet header.

The first step is to load the clipboard class:

Add-Type -Assembly PresentationCore

Warning: The PresentationCore class is pretty fussy about its housing. It needs to know in which state its apartment is!

if ($host.Runspace.ApartmentState -notlike "STA")

{

powershell -STA -file $myInvocation.myCommand.definition

}

Then the original code is modified with the following lines:

$services = Get-WmiObject win32_service `

-ComputerName $computerName

if (($error.count -eq 0))

{

$data = ($services `

| Select-Object $properties `

| ConvertTo-Csv -Delimiter "`t" -NoTypeInformation) `

-join "`r`n"

[Windows.Clipboard]::setText($data)

#Const xlPasteAll = -4104

$computerSheet.range('a1').pasteSpecial(-4104)

[Windows.Clipboard]::setText(””) #clear the buffer

$computerSheet.usedRange.entireColumn.autoFit() `

| Out-Null

. . .

The WMI query is the same as before. The new element is the $data transformation. This step is required to allow pasting the services data to an appropriate format for Excel. If $services is pasted directly as follows:

[Windows.Clipboard]::setText($services)

Only partial data is copied and not parsed into columns. Excel understands the CSV format; therefore, the $service data is converted into the CSV format with the ConvertTo-CSV cmdlet. The CSV data is then converted into one big string with the –join method. Et voilà, the script is done. Well almost…

The static method SetText from the Windows.Clipboard class is used to copy data to the clipboard and then the office automation PasteSpecial method is used to paste it into Excel.

A neat trick that my good friend, Ed Wilson, showed me some time ago is how to find static methods with the Get-Member cmdlet. If [Windows.Clipboard] is sent to get-member, only a subset of the methods available is obtained. But if the Static parameter is used; the following additional methods will be displayed:

The Select-Object cmdlet is used to change the order in which the columns are output. If you remember, in the original script, variables like $columnCaption were used to determine column position.

$computerSheet.cells.item($row,$columnCaption) = $service.Caption

In this script, an array combined with the Select-Object cmdlet is used. Thereby, another modification has to be made:

$properties = `

"Name",`

"StartName",`

#removed some properties for brevity

"WaitHint"

Using an array this way avoids printing the headers as needed in the previous version of the script. To change the column order, simply change the order of the properties in the array.

As you may recall, a test run in my home lab gathered data from 50 computers in 90 minutes with the original script. This new and improved version does the same 50 computers in less than three minutes, and it is 43 lines shorter!!

But wait, there is more…

The next challenge will be to scale this script from 50 servers to thousands of servers. Tomorrow, we will explore how we can again dramatically improve the performance of this script from three minutes down to 45 seconds by leveraging some Windows PowerShell 2.0 features.

~ Georges

Once again, thank you, Georges, for sharing with us today. The zip file you will find in the Script Repository has all the files and scripts from Georges this week. Please join us tomorrow for Part 3 in the series.

Ed Wilson, Microsoft Scripting Guy

Beat the Auditors, Be One Step Ahead with PowerShell

Anonymous — Tue, 31 Jan 2012 06:00:00 GMT

Summary: Microsoft PFE, Georges Maheu, opens his security assessment toolbox to discuss a Windows PowerShell script he uses to look at Windows services.

Microsoft Scripting Guy, Ed Wilson, is here. Our guest blogger today is Georges Maheu. Georges is one of my best friends, and I had a chance to work with him again during my recent Canadian tour. While I was there, I asked him about writing a guest series, and we are fortunate that he did (you will love his four blogs). Here is a little byte about Georges.

Georges Maheu, CISSP, is a premier field engineer (PFE) and security technology lead for Microsoft Canada. As a senior PFE, he focuses on delegation of authority (how many domain admins do you really have?), on server hardening, and on using his scripts to perform security assessments. Georges has a passion for Windows PowerShell and WMI, and he uses them on a regular basis to gather information from Active Directory and computers. Georges also delivers popular scripting workshops to Microsoft Services Premier Support customers. Georges is a regular contributor to the Microsoft PFE blog, OpsVault.

Note: All the scripts and associated files for this blog series can be found in the Script Repository. Remember to unblock and open the zip file.

Take it away, Georges…

When premier customers call me, it is either because they have been compromised or because they are being audited. In either case, the first step is always the same: make an inventory. To assess risk, you need to understand what you are managing. Many customers have fancy gizmos to detect intrusion, but they often fail to look at the most simple things.

Hey, if the barn doors are wide open, why look for mice holes!

So, what does all of this have to do with auditors? Well, auditors (read accountants) have investigated hundreds of attacks and concluded that several of them were done by using generic accounts as penetration vectors. Therefore, being accountants (read very organized); some auditors are now assessing generic accounts as part of their auditing.

Here is a common scenario: An IT Pro created a generic account in 1999 to perform backups. Back then, the backup software required this service account to be a domain admin account. The password policy was six characters without complexity. Today, the account is still active; the password has never been changed.

Auditors come along and provide you with a list of accounts with “no password required” and a list of accounts with obsolete passwords. Your manager tells you to investigate where these accounts are being used and wants you to create a remediation plan to change the passwords on these accounts.

Generic accounts can be used by people (guest and administrator are two examples), used by applications, or used to run services. My security tool box contains several small scripts, an approach that I prefer to a Swiss army tool that tries to do everything.

Today, we will look at one of my tool box scripts. This script will make an inventory of all services running on your computers and will identify which ones are using non-standard service accounts. The inventory is presented in an Excel spreadsheet (accountants and managers love spreadsheets, so this is a bonus).

When you write scripts, always consider two factors: complexity and capacity (or performance). This first version of the script is linear and simple, but slow; it will do the work for a small to mid-size environment. Depending on your environment, it may take up to 15 minutes per server.

The first step is to read the list of targeted computers. You could get this list directly from Active Directory, but most people prefer to have control over the computers that are being queried. In any case, a simple Windows PowerShell command can be used to create such a list:

([adsisearcher]"objectCategory=computer").findall() |

foreach-object {([adsi]$_.path).cn} |

out-file -Encoding ascii -FilePath computerList.txt

Check the results with:

get-content computerList.txt

Now that a list of computers has been created, let’s open the tool box and look at portions of this first version script. Not always knowing where the script is run from, the path is stored programmatically in the $scriptPath variable instead of being hard-coded. Because performance is important, time is also tracked.

clear-host

$startTime = Get-Date

$scriptPath = Split-Path -parent $myInvocation.myCommand.definition

Creating an Excel spreadsheet is done with office automation. The DisplayAlert property is set to $false to avoid the file-overwriting prompt when the file is saved at the end of the script. If the Visible property is set to $true, make sure not to click inside an Excel spreadsheet while the script is running because this will change the focus and generate a Windows PowerShell error.

$excel = New-Object -comObject excel.application

$excel.visible = $true # or = $false

$excel.displayAlerts = $false

$workBook = $excel.workbooks.add()

Let’s move on by initializing our environment. The computer list is stored in an array automatically with the Get-Content cmdlet, as shown here:

$computers = Get-Content "$scriptPath\Computers.txt"

$respondingComputers = 0 #Keep count of responding computers.

The properties returned by a WMI query are not necessarily in the desired order. To simplify the layout, variables that will be used to define the columns for the data in Excel are initialized here. Notice the service Name and StartName are in the first two columns. The presentation order can be rearranged based on specific requirements.

$mainHeaderRow = 3

$firstDataRow = 4

$columnName = 01

$columnStartName = 02

$columnDisplayName = 03

#removed some properties for brevity.

$columnSystemName = 24

$columnTagId = 25

$columnTotalSessions = 26

$columnWaitHint = 27

Names are then given to individual Excel spreadsheets and headers are added. The first sheet is used to keep statistics; the second one is really the core component of this report where all the exceptions will be recorded. These will be the accounts that the auditors will want you to manage.

$workBook.workSheets.item(1).name = "Info" #Sheets index start at 1.

$workBook.workSheets.item(2).name = "Exceptions"

#Delete the last sheet as there will be an extra one.

$workBook.workSheets.item(3).delete()

$infoSheet = $workBook.workSheets.item("Info")

$infoSheet.cells.item(1,1).value2 = "Nb of computers:"

$infoSheet.cells.item(1,2).value2 = $($computers).count

$infoSheet.cells.item(1,2).horizontalAlignment = -4131 #$xlLeft

$exceptionsSheet = $workBook.workSheets.item("Exceptions")

$exceptionsSheet.cells.item($mainHeaderRow,1) = "SystemName"

$exceptionsSheet.cells.item($mainHeaderRow,2) = "DisplayName"

$exceptionsSheet.cells.item($mainHeaderRow,3) = "StartName"

$exceptionsSheet.cells.item($mainHeaderRow,1).entireRow.font.bold = $true

A nice trick-of-the-trade is to write a message that might get overwritten. In this case, if data is found, this line gets overwritten by the data.

#The next line will be overwritten if exceptions are found.

$exceptionsSheet.cells.item($firstDataRow,1) = "No exceptions found"

The script can now start to process each computer. A new Excel tab is created for each computer and renamed with the computer name, a header is written, WMI is used to get the data, and the data is written to the Excel spreadsheet. Notice that the current spreadsheet is selected with $computerSheet.select(). This is not required, but it will show some activity on the screen. Again, do not click in the spreadsheet because this will change the selected cell and generate an error.

forEach ($computerName in $computers)

{

$computerName = $computerName.trim()

$workBook.workSheets.add() | Out-Null

"Creating sheet for $computerName"

$workBook.workSheets.item(1).name = $computerName

$computerSheet = $workBook.workSheets.item($computerName)

$computerSheet.select() #Show some activity on screen.

$error.Clear()

$services = Get-WmiObject win32_service -ComputerName $computerName

The script performs very basic error handling. If no errors are found by the WMI query, data is written to the spreadsheet; otherwise, the error is logged in a text file. The order in which the data is written is irrelevant because variables are used to indicate in which column each field is being written.

if (($error.count -eq 0))

{

Write-Host "Computer $computerName is responding." -ForegroundColor Green

$row = $firstDataRow

#Write headers

$computerSheet.cells.item($mainHeaderRow,$columnCaption) = "Caption"

#removed some properties for brevity.

$computerSheet.cells.item($mainHeaderRow,$columnWaitHint) = "WaitHint"

$computerSheet.cells.item($mainHeaderRow,1).entireRow.font.bold = $true

forEach ($service in $services)

{

$service.displayName

$computerSheet.cells.item($row,$columnAcceptStop) = $service.AcceptStop

$computerSheet.cells.item($row,$columnCaption) = $service.Caption

$computerSheet.cells.item($row,$columnCheckPoint) = $service.CheckPoint

#removed some properties for brevity.

$computerSheet.cells.item($row,$columnWaitHint) = $service.WaitHint

$row++

The following section is where the crucial action occurs. The non-generic service accounts are identified here. This is done with an if statement and by writing the exceptions to the exception sheet.

################################################

# EXCEPTION SECTION

# To be customized based on your criteria

################################################

if ( $service.startName -notmatch "LocalService" `

-and $service.startName -notmatch "Local Service" `

-and $service.startName -notmatch "NetworkService" `

-and $service.startName -notmatch "Network Service" `

-and $service.startName -notmatch "LocalSystem" `

-and $service.startName -notmatch "Local System")

{

$exceptionsSheet.cells.item($exceptionRow,1) = $service.systemName

$exceptionsSheet.cells.item($exceptionRow,2) = $service.displayName

$exceptionsSheet.cells.item($exceptionRow,3) = $service.startName

$exceptionRow++

} #if ($service.startName

} #forEach ($service in $services)

Then, the current spreadsheet is formatted and the responding computer counter is incremented.

$computerSheet.usedRange.entireColumn.autoFit() | Out-Null

$respondingComputers++

}

If the remote computer does not respond, a comment is added to the spreadsheet and additional information is provided in a log file.

else #if (($error.count -eq 0))

{

$computerSheet.cells.item($firstDataRow,1) = "Computer $computerName did not respond to WMI query."

$computerSheet.cells.item($firstDataRow+1,1) = "See $($scriptPath)\Unresponsive computers for additional information"

$error.Clear()

Test-Connection -ComputerName $computerName -Verbose

Add-Content -Path "$($scriptPath)\Unresponsive computers" -Encoding Ascii `

-Value "$computerName did not respond to win32_pingStatus"

Add-Content -Path "$($scriptPath)\Unresponsive computers" -Encoding Ascii `

-Value $error[0]

Add-Content -Path "$($scriptPath)\Unresponsive computers" -Encoding Ascii `

-Value "----------------------------------------------------"

Write-Host "Computer $computerName is not responding. Moving to next computer in the list." `

-ForegroundColor red

} #if (($error.count -eq 0))

} #forEach computer

At this point, the script is almost done. The information sheet needs to be updated with our stats, and a few things need to be formatted and cleaned up before exiting.

$exceptionsSheet.usedRange.entireColumn.autoFit() | Out-Null

$infoSheet.cells.item(2,1).value2 = "Nb of responding computers:"

$infoSheet.cells.item(2,2).value2 = $respondingComputers

$infoSheet.cells.item(2,2).horizontalAlignment = -4131 #$xlLeft

$infoSheet.usedRange.entireColumn.autoFit() | Out-Null

$workBook.saveAs("$($scriptPath)\services.xlsx")

$workBook.close() | Out-Null

$excel.quit()

Com objects require special attention; otherwise, they remain in memory and do not release the calling program. Some coders keep track of all the objects that they create, and release them one by one. I prefer to use a generic approach such as:

#Remove all com related variables

Get-Variable -Scope script `

| Where-Object {$_.Value.pstypenames -contains 'System.__ComObject'} `

| Remove-Variable -Verbose

[GC]::Collect() #.net garbage collection

[GC]::WaitForPendingFinalizers() #more .net garbage collection

Now that the script is done, let us see how long it takes to run. I always do benchmarks with a limited number of computers, and then estimate how long it will take to gather data from all the targeted computers.

$endTime = get-date

"" #blank line

Write-Host "-------------------------------------------------" -ForegroundColor Green

Write-Host "Script started at: $startTime" -ForegroundColor Green

Write-Host "Script completed at: $endTime" -ForegroundColor Green

Write-Host "Script took $($endTime - $startTime)" -ForegroundColor Green

Write-Host "-------------------------------------------------" -ForegroundColor Green

"" #blank line

A test run in my home lab gathered data from 50 computers in 90 minutes. That is less than two minutes per computer. Not bad, considering we have a nice Excel spreadsheet as a final report.

Having an inventory is the first step in closing one of the barn doors.

The next screen capture shows all the services that are using nonstandard service accounts.

This information helps to evaluate the impact of changing the password on the SRVAccount and BobTheGreat before the auditors start asking. This is also a good opportunity to determine if that xyz service really needs to run as Administrator.

I ran this script in some customer environments where it took more than 15 minutes per computer. This could be a serious limiting factor. Tomorrow, we will explore how the performance of this script can be dramatically improved from 90 minutes to less than three minutes.

Remember, all the scripts and files for this and for the next three blogs in the series can be found in the Script Repository. Simply open the zip file.

~Georges

Thank you, Georges, for the first installment of an awesome week of Windows PowerShell goodness.

Ed Wilson, Microsoft Scripting Guy

PowerShell Community and the Windows System Administration Tool

Anonymous — Fri, 06 Jan 2012 06:00:00 GMT

Summary: See how guest blogger, Rich Prescott, leveraged the Windows PowerShell community as he built his popular ArPosh Client System Administration tool.

Microsoft Scripting Guy, Ed Wilson, is here. We are really starting the new year off correctly. We have another very strong guest blogger today. Rich Prescott, is currently working as an infrastructure architect and Windows engineer at a large media company, with his main areas of focus on automation and Active Directory. The automation responsibilities allow him to work with a wide-range of technologies including virtualization, storage, and monitoring. He started learning Windows PowerShell in 2009 while he was working as a desktop engineer, and he is the lead scripting guy for his organization. He is also a moderator on the Official Scripting Guys Forum, and was recently rewarded as a Microsoft Community Contributor.

Blog: Engineering Efficiency: Scripts, Tools, and Software New in the IT World
Twitter: @Rich_Prescott

Take it away Rich…

When I first joined the IT world, I was working at the Help desk for a large company. Being new to IT and troubleshooting, I always wondered why there was no single tool for troubleshooting remote computers. I would receive a call about a computer being slow, and I would have to go through four tools to try to diagnose the issue. I began searching for an easy solution, and that is when a coworker introduced me to Windows PowerShell. After reading blog posts from Hey, Scripting Guy! and the Scripting Wife, I was writing basic scripts to gather the information that I needed for troubleshooting. This is an example of a basic script I wrote back then.

$PC = “PC01”
Get-WmiObject Win32_OperatingSystem –ComputerName $PC
Get-WmiObject Win32_StartupCommand –ComputerName $PC
Get-WmiObject Win32_Process –ComputerName $PC

After the underlying issue was targeted, I needed a way to remediate the issue, such as removing a hung process. This was possible remotely by querying the Win32_Process class on a remote computer, filtering for the process that was causing an issue, and invoking the Terminate method. Here is an example of using the Terminate method to stop a process on a remote computer.

(Get-WmiObject Win32_Process –ComputerName $PC |
Where-Object {$_.Name –eq “HungProcessName”}).Terminate()

At last, I was able to efficiently troubleshoot issues remotely and even resolve some of them without ever having to leave my desk. As I became more familiar with Windows PowerShell, I thought, “Wouldn’t it be cool if I could share the efficacy of Windows PowerShell with others, even if they don’t know any scripting?” After a few months of researching, scripting, and testing GUI creation with Windows PowerShell, the Arposh Client System Administration tool (ACSA) was released.

As with any technology that you learn rapidly, when you look back on what you were doing a year ago, you think to yourself, “What was I thinking when I wrote that? I could write that in half the code and make it twice as fast.” So I set out to find resources to help me rebuild the script from scratch, and I used this opportunity to remove some of the prerequisites, make it compatible with servers, and improve the overall user experience.

PowerShellGroup - #PowerShell chat room

One of the advantages of using Internet Relay Chat (IRC) is that there are chat rooms for almost any topic you can think of and when you are learning a new technology, having a live discussion can be really helpful. While revamping the ACSA tool, one of the user-experience features that I wanted to add was to give the user the ability to decide which feature sets to use through a configuration file.

I joined the #PowerShell chat room on PowerShellGroup.org, and I asked about an easy way to give users configuration options. Jaykul, a Windows PowerShell MVP, responded with a way to read settings from an XML file. By using the following XML code and three lines of Windows PowerShell, a user is able to set a default domain to connect to when using the GUI. To have the GUI use the current domain of the logged on user, simply update the Enabled option of the default domain to “False” in the XML configuration file.

<?xml version="1.0" standalone="no"?>
<Domain Default="LDAP://DC=RU,DC=lab" Enabled="True"/>

In the first line of code, we use Get-Content on the XML configuration file and specify that it is XML code by using [XML]. We then check to see if the default domain option is enabled, and if so, we set the Domain variable to what is specified in the XML. If the option is disabled, the GUI sets the Domain variable to the currently logged on domain.

[XML]$XML = Get-Content “AWSA.Options.xml”
if($XML.Domain.Enabled –eq $True){$Domain = $XML.Domain.Default}
else{$Domain = ([DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).Name}

TechNet Wiki

My next task was to make the GUI easy to use, and this meant removing any unnecessary pre-requisites included in the original release. My first stop was the TechNet Wiki to find a way to query Active Directory for computers without the need to import a Windows PowerShell module that was not freely available on all systems. After a quick search, I landed on a wiki contribution from Richard Mueller, another MVP, for ADSI searches, which showed me the syntax necessary to build my custom function.

function Get-RPADComputer{
if($ComputerName -match "."){$ComputerName = $ComputerName.Split('.')[0]}
$searcher=[adsisearcher]"(&(objectClass=computer)(name=$ComputerName*))"
$Properties = $XML.Options.Search.Property
$searcher.PropertiesToLoad.AddRange($Properties)
$searcher.FindAll()
}

This function checks the $ComputerName parameter that is specified in the textbox of the GUI, and if a fully qualified domain name (FQDN) is specified, it translates it to a short name. It then creates a query that will search for any computers that match the new $ComputerName variable. The third line reads a list of properties that the user specifies in the XML settings file and adds them to the list of properties to load. The final line of the function executes the query and returns the results.

TechNet forums

After adding in the ability to set a default domain when launching the GUI, the user needed a way to change domains without having to edit the XML file and relaunch the script. I was not familiar enough with the ADSI scripting techniques that I found on the TechNet Wiki, and I decided to head over to the Official Scripting Guys Forum on the TechNet Forums and ask for some assistance.

I posted my question with some examples of the input and output that I wanted, and within four hours, I received multiple responses from the community. And what do you know—Richard Mueller again came to the rescue with a way to prompt for a domain and then convert the response into the LDAP path for that domain. By slightly tweaking his code, I was able to add the ability to search alternate domains to my custom Active Directory computer search function.

TechNet ScriptCenter

There are many new features in this update of the GUI, but I want to highlight one that many administrators will find very useful and sigh at the mention of: local administrator rights. Every system administrator has received a request along the lines of, “I need to install XYZ software right now!” or “I am using VPN from home, and I need to add a local printer.” One way to get around this (not always the best way) is to grant the user temporary local administrator rights. To find out how to do this the Windows PowerShell way, I headed over to the TechNet ScriptCenter Repository to search for some examples.

Using the Categories listing in the left pane, I drilled down into Local Account Management, and I immediately saw what I was looking for: Local User Management Module. I clicked through to the details page and looked through the included functions. I was in luck! By using ADSI code in the Set-LocalGroup function, I morphed it into my own function as shown here.

Function Add-LocalAdmin {
  [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic') | Out-Null
  $Input = [Microsoft.VisualBasic.Interaction]::InputBox("Enter a username to add (Domain\Username)", "Add Local Admin", "")
  $Group = [ADSI]("WinNT://" + $ComputerName + "/Administrators, group")
  $Group.Add("WinNT://" +$Input.Replace(‘\’,’/’)
}

The first line of the function loads the Visual Basic assembly; this allows me to create a custom input box, which prompts the user for the username to add to the local administrators group and then stores it in the $Input variable. The function then binds to the Administrators group on the remote computer using ADSI. Now we call the Add method of ADSI to add the desired user account to the administrators group. But there is a snag, the username is specified as Domain\Username, whereas ADSI requires a forward slash. To get around this, we use the Replace method to turn the back slash into a forward slash.

Arposh Windows System Administration tool

Whether you are new to Windows PowerShell and only need a simple script to get you going or you are a Windows PowerShell guru and need a nudge in the right direction, there are numerous resources for everyone. Thanks to all of these resources, I was able to take a simple GUI that I created for myself to make tasks easier and improve it enough to where the Windows PowerShell community would also find it useful. Without further ado, here is the Arposh Windows System Administration tool.

~Rich

Ed Wilson, Microsoft Scripting Guy

Use a PowerShell Script to Start Non-Running Automatic Services

Anonymous — Mon, 12 Dec 2011 06:00:00 GMT

Summary: Guest blogger, Karl Mitschke, discusses a Windows PowerShell script to start non-running services that are set to start automatically.

Microsoft Scripting Guy, Ed Wilson, is here. Our guest blogger today is Karl Mitschke, one of the authors of the Windows PowerShell 2.0 Bible. Here is a little bit about Karl.

Karl Mitschke is an IT veteran with over 20 years of experience. He has specialized in messaging since the early 1990s. Karl has been automating tasks with script since moving to Microsoft Exchange 5.0, starting with WinBatch. He started using Windows PowerShell in 2007 when he moved to Exchange Server 2007. When he’s not writing Windows PowerShell scripts, or writing about Windows PowerShell scripts, Karl enjoys spending time with his bride, Sherry, and their two dogs.
Blog: Unlock-PowerShell
Windows PowerShell 2.0 Bible

Starting services on remote servers

In the “Performing Advanced Server Management” chapter in the Windows PowerShell 2.0 Bible, I presented a script that would start services on remote servers that are set to start automatically and were not started. Due to the constraints of the book, the script was severely limited. That script is shown here.

$Computers = “FileServer01”,”FileServer02”
$WmiObject = @{
Class = “Win32_Service”
Filter = “StartMode=’Auto’ and State!=’Running’”
}
foreach ($Computer in $Computers)
{
foreach ($Svc in Get-WmiObject @WmiObject -ComputerName $Computer)
{
Write-Host “Starting the” $Svc.DisplayName “service on $Computer”
$Svc.StartService() | Out-Null
}
}

This was fine, but the script could really use some improvement. For one thing, you needed to hard code the server names. In addition, it did not accept credentials, you could not simulate the action, and there was no Help.

The concept was sound, however, so I decided to extend the script to put it into production at work, where I use it to verify that services are running after performing updates on our Exchange Server infrastructure. Unfortunately, extending the script makes it too long for the book and too long for this blog. The complete script is available in the Scripting Guys Script Repository, but I will discuss highlights of the script in this blog post.

Extending the script with Help

The first several objections are easy to overcome with advanced parameters. The final objection is overcome with comment-based Help. Windows PowerShell even includes a method to add Help. I am referring to the built in Get-Help cmdlet. In fact, you can potentially get more Help than you will ever need by typing the following script into your Windows PowerShell console:

Get-Help -Name functions_advanced_parameters

Get-Help -Name about_comment_based_help

The Help about advanced parameters is too verbose to summarize, so I would suggest that you read it and familiarize yourself with the content.

The Help for comment-based Help shows that for script-based Help, comment-based Help can appear in two locations:

At the beginning of the script file. Script Help can be preceded in the script only by comments and blank lines. If the first item in the script body (after the Help) is a function declaration, there must be at least two blank lines between the end of the script Help and the function declaration. Otherwise, the Help is interpreted as being Help for the function, not Help for the script.
At the end of the script file. If the script is signed, place comment-based Help at the beginning of the script file. The end of the script file is occupied by the signature block.

As I sign the scripts that I use at work, I include comment-based Help at the beginning of the file.

I also choose to use the comment-block syntax as opposed to using the comment character (#) in front of each line, because I find it to be more readable. An example of the comment-block syntax is shown here.

.SYNOPSIS

Invoke-StartService - Start all essential services that are not running.

.DESCRIPTION

This script finds services that are set to start automatically, and starts them.

Therefore, Help is out of the way with the comment-based Help. Next, I tackle the parameters.

Adding arguments

I wanted to allow the script to accept server names from the command line or from a pipeline, so I used the ValueFromPipeline argument when I declare the ComputerName parameter for the script. I also want to allow the script to target multiple computers, so I declared the ComputerName parameter as an array of strings as shown here.

[Parameter(

Position = 0,

ValueFromPipeline=$true,

Mandatory = $false,

HelpMessage = "The computer to start services on"

)]

[string[]]$ComputerName = $env:ComputerName

As you can see, I set the ComputerName parameter to not be required by using the local computer name if it is not specified. I also set the parameter to be positional—that means that you do not need to use the name of the parameter as long as the computer name(s) are specified as the first-passed parameter to the script.

I wanted the script to accept credentials so that I could start my Windows PowerShell session with a non-administrator account. I added the optional parameter Credential to handle these credentials.

Finally, I wanted to emulate the WhatIf functionality in so many of my favorite cmdlets, so I added the optional switch parameter WhatIf. The entire parameter declaration is shown here.

param (

[Parameter(

Position = 0,

ValueFromPipeline=$true,

Mandatory = $false

)]

[string[]]$ComputerName = $env:ComputerName,

[Parameter(

Position = 1,

Mandatory = $false

)]

$Credential,

[Parameter(

Mandatory = $false

)]

[switch]$WhatIf

)

Using $PSBoundParameters

I wanted to avoid If statements as much as possible, so I take advantage of the automatic variable $PSBoundParameters, which is a hash table of the parameter names and values that are passed to the script.

You can pass the $PSBoundParameters to the Get-WmiObject cmdlet as a splatted hash table as shown here:

Get-WmiObject -Class Win32_Service @PSBoundParameters

The parameters ComputerName and Credential can be passed directly to the Get-WmiObject cmdlet. However, that cmdlet does not accept the WhatIf parameter, if present, which would cause the error message shown here.

This can be resolved by using the Remove() method of the hash table. You can check for the existence of the parameters with an If statement, or you can pass the command to the Out-Null cmdlet to avoid the If statement as shown here.

$PSBoundParameters.Remove("WhatIf") | Out-Null

I also have to handle the two methods of passing credentials to the script. The parameter Credential is not typed, so it accepts a string or a credential object as shown here.

$cred = Get-Credential -Credential "mitschke\karlm"

.\Invoke-StartService.ps1 -Credential $cred

When it is supplied like that, the $PSBoundParameters hash table passes a credential object to the Get-WmiObject cmdlet. However, if you supply the Credential parameter with a string, allowing the script to prompt for a password, the $PSBoundParameters hash table passes the string to the Get-WmiObject cmdlet and prompts for a password on every service that needs starting.

This is resolved by once again using the Remove() method of the hash table, and then using the Add() method to add the valid credential object to the $PSBoundParameters hash table as shown here.

if ($Credential -ne $null -and $Credential.GetType().Name -eq "String")

{

$PSBoundParameters.Remove("Credential") | Out-Null

$PSBoundParameters.Add("Credential", (Get-Credential -Credential $Credential))

}

I modified the Filter parameter for the Get-WmiObject cmdlet to find only the services that I was interested in. Specifically, I am not interested in starting the Microsoft .NET Framework Runtime Optimization Services, which may be set to start automatically. The service would start and then stop because it finds that no action is needed. It is not really a problem starting these services, I just wanted to avoid the time it takes to start them, and avoid event log entries that show they had started and stopped.

These services have a service name starting with clr_optimization_. The filter I use is shown here.

Filter "startmode='auto' and state='stopped' and (name > 'clra' or name < 'clr')"

The filter isn’t perfect—I suppose there could be a service with a name that starts with clra, but I have not seen one, so the filter serves my purposes. A better filter could use the grave accent character (`). The grave accent character is also the escape character for Windows PowerShell, so you would need to use two grave accents as “name > 'clr``’”. You could also use a client-side filter by using the Where-Object cmdlet as shown here:

Get-WmiObject -Class Win32_Service | Where-Object -FilterScript {$_.Name -notmatch "clr_*" -and $_.StartMode -eq "Auto" -And $_.State -ne "Running"}

That is perfectly valid; however, using the Filter parameter of the Get-WmiObject cmdlet performs server-side filtering, which should be quicker because only the objects we are interested in are passed back to the client. The complete server-side filtering example is shown here:

Get-WmiObject -Class Win32_Service –Filter "startmode='auto' and state='stopped' and (name > 'clra' or name < 'clr')"

So now we have a working filter, working parameters, and working Help. It is now time to test the parameters with the WhatIf switch. The command line and its associated output are shown here.

When I see what the script will do, I run the script without the WhatIf parameter. The output from the command appears in the following image.

As mentioned, the entire script is available in the Scripting Guys Script Repository. The output of the script follows the script. I believe the script is pretty well written; but as always, I am open to suggestions. You can reach me at:

-join ("6B61726C6D69747363686B65406D742E6E6574"-split"(?<=\G.{2})",19|%{[char][int]"0x$_"})

Thank you Karl, for a very useful and interesting blog post. Join me tomorrow for more Windows PowerShell goodness.

Ed Wilson, Microsoft Scripting Guy

Expert Solution for the 2011 Scripting Games Beginner Event 4: Use PowerShell to Identify Non-Standard Windows Service Accounts

Anonymous — Thu, 21 Apr 2011 05:00:00 GMT

Summary : Microsoft Windows PowerShell MVP Tobias Weltner solves 2011 Scripting Games Beginner Event 4 and finds nonstandard Windows service accounts. Microsoft Scripting Guy, Ed Wilson, here. Our expert commentator for Beginner Event 4 is Dr. Tobias...(read more)

Expert Solution for 2011 Scripting Games Advanced Event 4: Use PowerShell to Find Services Hiding in the SvcHost Process

Anonymous — Thu, 21 Apr 2011 05:00:00 GMT

Summary : Microsoft research software developer, Chris O'Prey, solves Windows PowerShell 2011 Scripting Games Advanced Event 4 and finds services that are running in the SvcHost process. Microsoft Scripting Guy, Ed Wilson, here. With us today with his...(read more)