Trawl AD for devices running Windows Server, pull out hardware details (Dell specific)

This is pretty much identical to the last script, but it filters the output to return only Dell servers. It’s just the extra chunk that starts “If($madeBy -eq “Dell Inc.”)”. This could be replaced with any manufacturer. I neede to send our live estate to our account manager.

Because WMI is a bit weird, this script has to pull data out of different classes so looks worse than it is. It has to use the NETBIOS name to get all this data. It’s based around an array that is created from the number of servers it find (“OperatingSystem=*server*”). The $mergeDetails looks complicated, but it’s the only way I could find of presenting the results neatly, so the details of each server is on a seperate line. It’s very easy to just output the array in a list format but is horrible to read.

The main “If” loop just determines whether the server is respoding- if not, it writes to the same file that it can’t retrieve any data.
————————————————–
Remove-Item .\Dell_Name_ST_Model.csv

[string]$serverList
[string]$serverNames
[string]$serverArray
[int]$xAxis
[int]$yAxis
[string]$mergeDetails

$serverList = Get-ADComputer -LDAPFilter “(&(ObjectCategory=Computer)(OperatingSystem=*server*))” | Select-Object Name | Sort-Object Name
$serverNames = $serverList.Name

$serverArray = New-Object ‘object[,]’ $serverList.Count,4
$xAxis = 0
$yAxis = 0

ForEach ($server in $serverNames)
{

$isAlive = Test-Connection $server -Count 1 -Quiet

If($isAlive -eq $true)
{
$madeBy = Get-WMIObject -Class Win32_ComputerSystem -ComputerName $server -ErrorAction ‘SilentlyContinue’ | Select-Object Manufacturer -ExpandProperty Manufacturer

If($madeBy -eq “Dell Inc.”)
{
$serverArray[$xAxis,$yAxis] = Get-WMIObject -Class Win32_OperatingSystem -ComputerName $server | Select-Object CSName -ExpandProperty CSName
$mergeDetails = $serverArray[$xAxis,$yAxis]
$yAxis++

$serverArray[$xAxis,$yAxis] = Get-WMIObject -Class Win32_ComputerSystem -ComputerName $server | Select-Object Manufacturer -ExpandProperty Manufacturer
$mergeDetails = $mergeDetails + “,” + $serverArray[$xAxis,$yAxis]
$yAxis++

$serverArray[$xAxis,$yAxis] = Get-WMIObject -Class Win32_ComputerSystem -ComputerName $server | Select-Object Model -ExpandProperty Model
$mergeDetails = $mergeDetails + “,” + $serverArray[$xAxis,$yAxis]
$yAxis++

$serverArray[$xAxis,$yAxis] = Get-WMIObject -Class Win32_SystemEnclosure -ComputerName $server | Select-Object SerialNumber -ExpandProperty SerialNumber
$mergeDetails = $mergeDetails + “,” + $serverArray[$xAxis,$yAxis]
$mergeDetails | Out-File .\Dell_Name_ST_Model.csv -Append
}
}
ElseIf($isAlive -eq $false)
{
$mergeDetails = $server + ” ,is not responding so I can’t retrieve any data” | Out-File .\Dell_Name_ST_Model.csv -Append
}

$yAxis=0
$xAxis++
}

Advertisements

Dell Open Manage Server Administrator 7.3.0.1 fault

Hmmm… can’t guarantee this is 100% correct, but it looks like there’s a problems with the above software when running against a Windows 2008 SP2 cluster. The storage part of OMSA doesn’t seem to get on very well with Windows Cluster.

Up until recently, our cluster had been behaving fine- reboot 1 node, the other picked up etc. However yesterday I installed OMSA 7.3.0.1, and this morning our SQL cluster fell over, badly. Not only that, but the nodes were taking forever to return from a reboot.

We spent a good 2 hours looking at this to get it working- the nodes would take ages to return but then wouldn’t even re-join the cluster properly until we restarted the cluster service, which isn’t ideal.

The Windows server faults were:

“FailoverClustering 1146: The cluster resource host subsystem (RHS) stopped unexpectedly. An attempt will be made to restart it. This is usually due to a problem in a resource DLL. Please determine which resource DLL is causing the issue and report the problem to the resource vendor.”

and

“FailoverClustering 1230: Cluster resource ‘Cluster Disk 1’ (resource type ”, DLL ‘clusres.dll’) either crashed or deadlocked. The Resource Hosting Subsystem (RHS) process will now attempt to terminate, and the resource will be marked to run in a separate monitor.”

There were a few bits and bobs on the web about 3rd party software, so I disabled all the OMSA services on the inactive node and rebooted… which was vastly quicker and didn’t flag these errors. Not having OMSA at all seemed extreme, so I just removed the storage part, rebooted and again, it rebooted much quicker, didn’t throw these errors and joined the cluster without needing the cluster service restarting. Just note that we have the full OMSA on a 2012 core cluster and it seems fine, so far this seems to be pointing at 2008.

Downloading Dell software

I try and keep up to date with things like Dell OpenManage Server Administrator but it can be tricky, so I rely a lot on their SUU tool. However, these downloads are now getting massive- the latest one is over 7GB, which promptly filled up the cache disk on our proxy server and caused the download to stop.

I knew the file name I needed (by going to support.euro.dell.com) and, as I have straight-through ftp access on our firewall thought I’d use FileZilla to search ftp.us.dell.com. Bad move. It might be well organised, but this site is just enormous. I couldn’t find any way of digging out the SUU ISO via ftp on the support website, so tried right-clicking and “View Source” whilst on the Driver Details page. Bingo! I found this bit of text- http://downloads.dell.com/FOLDER01529610M/1/SUU_721_x32_Q12013_A01.iso– which was still useless at that point, as I can’t use HTTP because it’ll just fill up the proxy’s cache disk again. However (and thankfully) Dell seem to mirror the download structure between their http and ftp sites, so it was just a case of browsing to FOLDER01529610M/1 in FileZilla and it’s now downloading direct from Dell without any proxies in the way, although it’s still going to take 5 hour s apparently.

Useful Dell SUU commands

I know suu.cmd has accepted various switched for a long time now, but this is the first time I’ve bothered to engage with it!

So, running SUU v 7.1.1.162:

\\some server\some share\suu.cmd -comparison

will generate a report telling you what can and can’t be upgraded. Most of the time you won’t care, but it’s worth remembering that this program will update network firmware, drivers and disk firmware etc so only run on critical systems after hours.

Then,

\\some server\some share\suu.cmd -upgradeonly

will ONLY upgrade components, never downgrade. It’ll do everything in one hit so you’ll probably need to reboot after this, and you may lose networking a lot as it runs so running suu either stood at the console or via remote desktop is recommended.

Dell OpenManager Server Administrator 6.4.0

Firstly I’ve only noticed this behaviour on a stand-alone server running the above version of OMSA, but it might apply to earlier versions.

I’ve been getting annoyed by OMSA requesting local admin credentials in a pop-up box before getting anywhere; I knew I was typing the right credentials in but the pop-up box keeps on appearing. The apparent fix is to “escape” out of this box and just wait for the credentials boxes to appear within the OMSA web page itself.

Dell SUU (Server Update Utility)

In the last week or so I’ve been struggling to get the SUU DVD to actually update some new Dell servers; basically, the update process never actually starts (I don’t know why- I suspect it’s an x64 v x86 issue?). However, the way around this is to click the hyperlink to the update(s) you need to apply from within the server-specific SUU window; once the page loads, not what the actual update is and switch from choosing x86 updates to x64 updates within support.euro.dell.com then just find the same named update (except this time you’ll be downloading the x64 version).