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
}
}
}

SAP Single Sign On Issues with Windows Server 2008 R2 Domain Controllers

By default, Data Encryption Standard (DES) encryption for Kerberos authentication is disabled  in Windows Server 2008 R2, this is a change from Windows Server 2003. If you are running an application which uses DES encryption for Kerberos application, such as SAP, then you may see issues authenticating users against 2008 R2 DCs. You will see errors in the System Log like the below for the users in question:

“While processing a TGS request for the target server %1, the account %2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of %3). The requested etypes were %4. The accounts available etypes were %5.”

To resolve this issue you need to make the Group Policy change to allow DES encryption for Kerberos authentication on the DCs, documented in this KB http://support.microsoft.com/kb/977321.

1. In the Group Policy Management Console (GPMC), locate the following location:
   Computer Configuration\ Windows Settings\ Security Settings\ Local Policies\ Security Options
2. Click to select the Network security: Configure encryption types allowed for Kerberos option.
3. Click to select Define these policy settings and all the six check boxes for the encryption types.
4. Click OK. Close the GPMC.

To be able to make this change, you need to have first installed the following hotfix, http://support.microsoft.com/kb/978055 . This fix is included in Windows Server 2008 R2 SP1, so if you have installed that you are already good to go.

A good discussion of this issue and further steps you may need to take with service accounts can be found here:

http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/ecf15eb9-26cf-483b-b1e3-1b1c7e4901e8/

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

New Simple-Talk Article: An Introduction to PowerShell Modules

A new feature in PowerShell V2 is modules. In this article for Simple-Talk I give you an introduction to PowerShell modules and how you might use them.

http://www.simple-talk.com/sysadmin/powershell/an-introduction-to-powershell-modules/

PowerShell ISE: Not Installed By Default in Windows Server 2008 R2

PowerShell 2 is installed by default in Windows Server 2008 R2. However, the other day I went on to a server with this OS and went to use the PowerShell ISE (which I switched to as my default console a year ago) and found that it wasn’t there:

Turns out that the ISE is not installed by default and needs to be added as a Feature:

This is different to a manual install of PowerShell 2 on Windows 2008 / 2003 where the ISE is included as part of the Windows Management Framework Install.

The reason I hadn’t noticed this earlier was that most of the Windows Server 2008 R2 servers I have been working with recently all had Exchange 2010 installed which seems to include the ISE as part of the installation.

Update 19/02/11:

Thanks to the reminder in the comments from Osin Grehan about the ServerManager module in Windows Server 2008 R2, you can get this feature installed via PowerShell.

Import-Module ServerManager
Add-Windowsfeature PowerShell-ISE

Upgrading vCenter Server to 4.1 fails with the error: boolean storageIORMSupported

I had the following issue when upgrading vCenter from 4.0 to 4.1. Whilst the database upgrade and install appeared to complete successfully, the vCenter service would not start once the install was complete.

In the vpxd.log located at C:\Documents and Settings\All Users\Application Data\VMware\VirtualCenter\logs, you see errors similar to:

[2010-07-27 13:42:26.837 03204 error 'App'] [VpxdMain] Failed to initialize: Not initialized: boolean storageIORMSupported
[2010-07-27 13:42:26.837 03204 error 'App'] Failed to intialize VMware VirtualCenter. Shutting down…
[2010-07-27 13:43:17.509 03204 info 'App'] Forcing shutdown of VMware VirtualCenter now

This issue seems to be well known on the communities site and is a bug in the install which should be fixed in a later release. It particular it seems to affect those running vCenter 4.1 in Windows Server 2008 R2, which is quite a common OS people migrate to as part of a 4.1 upgrade because of the 64bit requirement of vCenter 4.1.

Until the updated release comes out there is a workaround using dbuHelper.exe to make a change to the database that will then allow the vCenter service to start – it is documented in this KB article.

Important: Before starting this process you should take another backup of your vCenter database, in addition to the one taken before the initial upgrade.

Once downloaded you need to determine the following parameters to run with dbuHelper.exe

dbuHelper.exe <DB_VERSION> <DB_DSN> <DB_USERNAME> <DB_PASSWORD>

These parameters should be easy to find: <DB_DSN> <DB_USERNAME> <DB_PASSWORD>

<DB_VERSION> can be found with the following SQL query:

select ver_id from vpx_version

If upgrading to 4.1 and you are stuck at this point then you should get a value of 410 returned:

So you can now run dbuHelper:

dbuHelper.exe 410 DSNname Username password

Once successfully complete you should be able to start the vCenter service.

——————————————————————————————–

Note: for some great resources on upgrading vCenter to 4.1 check out Gregg Robertson’s page.

Update 11/02/2011:

This is fixed in vCenter 4.1 U1; from the release notes:

• After an upgrade to vCenter Server 4.1, vCenter Server fails to start and issues an error message

  When this issue occurs, the following error message is logged in the vpxd.log file:

  Failed to initialize: Not initialized: boolean storageIORMSupported

  This issue is resolved in this release.