Using PowerShell To Check That Windows Server Services Set To Automatic Have Started

Following on from the blog post Testing TCP Port Response from PowerShell  which provided a means to check that servers had fully rebooted after a patching and reboot cycle, I needed to take this one step further and check that all of the Windows Services set to Automatic successfully started after the reboot.

This should be pretty straightforward since we have a Get-Service cmdlet. Unfortunately however, this cmdlet does not return a StartMode parameter, i.e. it’s not possible to tell whether the Startup Type has been set to Automatic, Manual or Disabled. This is quite a large gap in my opinon – if you agree with me you can vote to get it included in a future release here. Of course with PowerShell there’s usually another way to achieve the same objective and using Get-WMIObject it is possible to find out the Startup Type of the service.

Get-WmiObject Win32_Service -ComputerName $ComputerName -Filter "StartMode='Auto' AND State='Stopped' AND Name!='SysmonLog'"

Notice that we filter out the Perfmon service (SysmonLog) since it is rarely in a started state.

One other thing to watch out for in this script is that the section

catch [System.Exception]

which is there to catch any WMI queries that fail, e.g. the server hasn’t rebooted properly or the correct permissions do not exist to make the WMI query, will not pick up any of these failures. This is because try / catch will only catch terminating errors and the WMI failures are non terminating. We can work around this by setting:

$ErrorActionPreference = "Stop"

and then back to normal afterwards:

$ErrorActionPreference = "Continue"

The script accepts pipeline input, so for example you could run it like:

Get-Content servers.txt | ./Get-AutomaticServiceState.ps1

Here it is:

<#
.SYNOPSIS
Retrieves any Windows services set to Automatic and are not running

.DESCRIPTION
Retrieves any Windows services set to Automatic and are not running

.PARAMETER  ComputerName
Name of the computer to test the services for

.EXAMPLE
PS C:\> Get-AutomaticServiceState -ComputerName Server01

.EXAMPLE
PS C:\> Get-Content servers.txt | Get-AutomaticServiceState

.NOTES
Author: Jonathan Medd
Date: 11/01/2012
#>

[CmdletBinding()]
param(
[Parameter(Position=0,Mandatory=$true,HelpMessage="Name of the computer to test",
ValueFromPipeline=$True,ValueFromPipelineByPropertyName=$true)]
[Alias('CN','__SERVER','IPAddress','Server')]
[System.String]
$ComputerName
)

process {

try {

# Set ErrorActionPreference to Stop in order to catch non-terminating WMI errors
$ErrorActionPreference = "Stop"

# Query the server via WMI and exclude the Performance Logs and Alerts Service
$WMI = Get-WmiObject Win32_Service -ComputerName $ComputerName -Filter "StartMode='Auto' AND State='Stopped' AND Name!='SysmonLog'"

}

catch [System.Exception]

{
$WMI = “” | Select-Object SystemName,Displayname,StartMode,State
$WMI.SystemName = $ComputerName
$WMI.Displayname = "Unable to connect to server"
$WMI.StartMode = ""
$WMI.State = ""
}

finally {

$ErrorActionPreference = "Continue"

}

if ($WMI){

foreach ($WMIResult in $WMI){

$MYObject = “” | Select-Object ComputerName,ServiceName,StartupMode,State
$MYObject.ComputerName = $WMIResult.SystemName
$MYObject.ServiceName = $WMIResult.Displayname
$MYObject.StartupMode = $WMIResult.StartMode
$MYObject.State = $WMIResult.State
$MYObject
}
}
}

Running AD Schema Update for 2008 R2 in a 32-bit DC Environment

To upgrade Active Directory from Windows Server 2003 to Windows Server 2008 R2 requires the usual AD schema upgrade first of all. Windows Server 2008 R2 is 64-bit only, so if you try running the usual command to upgrade the schema from a 32-bit Domain Controller:

adprep /forestprep

you get the following result, “adprep.exe is valid, but if for a machine type other than the current machine.”:

An alternative is to try running it from a 64-bit machine that is not a DC, but then you discover that this process absolutely must be run from a DC:

So what do you do? The answer is that you run adprep32.exe, a 32-bit version of adprep, which is included in the same folder:

adprep32 /forestprep

Tivoli Monitoring, WMI and Server Buffers Full

If you run Tivoli Monitoring 6.2 to monitor Windows Server systems and use other applications to query WMI, e.g. PowerShell and Get-WmiObject, then you may receive the error ‘Server buffers are full and data cannot be accepted’.

Restarting the WMI service will temporaily clear it, but the issue is liable to come back again. This can occur because of a file handle leak in the ITM Windows OS agent when collecting “Processor Information” attribute group.

There is a fix for this issue available from the below website.

http://www-01.ibm.com/support/docview.wss?rs=2292&context=SSRM2J&dc=DB550&uid=swg1IZ51505&loc=en_US&cs=UTF-8&lang=en&rss=ct2292tivoli

Windows 2003 Password Policy – Complexity Requirements Message

Doing a lot of investigation into password policies available in Windows Server 2003 and 2008 at the minute, plus some of the third-party solutions available around this area.

One of the reasons I’ve never myself recommend using the ‘Complexity On’ feature in Windows Server is the sheer difficulty in trying to explain to users that you need to use characters from at least three of the following four groups:

• Uppercase
• Lowercase
• Digits
• Special Characters

They typically switch off as soon as you get to the …at least three…. part of the above sentence and to be honest I don’t really blame them.

Even if you do head down this solution (good luck to you!) the message a user gets back when they fail to change their password successfully is fairly generic and does not even mention the fact that complexity is in use.

However, today I was made aware of a hotfix for Windows 2003 (and associated clients) where the user will now see mention of complexity requirements in the message they receive back. Since I’ve never heard or seen anyone else using this before I thought it was worth mentioning since it might make your deployment a bit smoother.

I’ve yet to test this out myself, but I guess you gotta trust the KB article