Monthly Archives: October 2010

Removing Failed Machines from System Center Virtual Machine Manager 2008 R2

Following an issue with our five node Server 2008 R2 Hyper-V cluster I was left with two entries for one virtual machine (VM) in System Center Virtual Machine Manager 2008 R2 (SCVMM).  One entry listed the VM as running, the other as failed, despite the fact that there was nothing wrong with the VM.  I was unable to remove the failed entry for the VM using the SCVMM GUI, so used the steps outlined in this KB article http://support.microsoft.com/default.aspx?scid=kb;EN-US;983839 This article is for removing missing VMs, rather than failed ones, so I altered the SQL that is run in step 5.  First I ran the SQL below to retrieve the object state of the failed VM

SELECT ObjectState
FROM dbo.tbl_WLC_VObject
WHERE Name = ‘VMName’

I then ran this code to ensure that I wasn’t going to remove any other VMs.  Only the failed VM should be returned by the code below.  Change the ObjectState value to the value returned by the code above

SELECT Name
FROM dbo.tbl_WLC_VObject
WHERE ObjectState = X

As only one VM was returned, I updated the code at the beginning of step 5 of the KB article and replaced the ObjectState value of 220 with the ObjectState for my failed VM.  I also applied the hotfix here http://support.microsoft.com/kb/2308590 to guard against similar future issues.

Retrieving Dell Service Tags using System Center Configuration Manager 2007 R2

I needed a list of the Dell service tags from all our desktops and laptops.  Dell have a product called the Dell Management Console (DMC) http://dell.symantec.com/dmc-tech which can do this, but as we have System Center Configuration Manager 2007 R2 (SCCM) I wanted to use that.  Below is the SQL I used to create the report in SCCM.  The important column is v_GS_PC_BIOS.SerialNumber0

select  distinct v_R_System_Valid.Netbios_Name0 AS [Computer Name],
v_GS_COMPUTER_SYSTEM.Model0 AS [Model],
v_GS_X86_PC_MEMORY.TotalPhysicalMemory0 AS [Memory (KBytes)],
LastBootUpTime0,v_GS_lastsoftwarescan.LastScanDate,v_GS_PC_BIOS.SerialNumber0 AS [Service Tag]
from v_R_System_Valid
inner join v_GS_OPERATING_SYSTEM on (v_GS_OPERATING_SYSTEM.ResourceID = v_R_System_Valid.ResourceID)
inner join v_GS_COMPUTER_SYSTEM on (v_GS_COMPUTER_SYSTEM.ResourceID = v_R_System_Valid.ResourceID)
inner join v_GS_X86_PC_MEMORY on (v_GS_X86_PC_MEMORY.ResourceID = v_R_System_Valid.ResourceID)
inner join v_FullCollectionMembership on (v_FullCollectionMembership.ResourceID = v_R_System_Valid.ResourceID)
left join v_Site on (v_FullCollectionMembership.SiteCode = v_Site.SiteCode)
join v_GS_lastsoftwarescan on  v_GS_lastsoftwarescan.resourceid = v_GS_OPERATING_SYSTEM.ResourceID
join v_GS_PC_BIOS on (v_GS_PC_BIOS.ResourceID = v_R_System_Valid.ResourceID)
Where v_FullCollectionMembership.CollectionID = @CollectionID
and (lower(v_R_System_Valid.Netbios_Name0) like @ComputerName or @ComputerName=”)
and (v_R_System_Valid.Resource_Domain_OR_Workgr0 = @Domain or @Domain=”)
and (v_GS_OPERATING_SYSTEM.Caption0 = @OperatingSystem or @OperatingSystem=”)
and (v_GS_COMPUTER_SYSTEM.Manufacturer0 = @Manufacturer or @Manufacturer = ”)
and (v_GS_COMPUTER_SYSTEM.Model0=@Model or @Model = ”)
Order by v_R_System_Valid.Netbios_Name0

Reporting on installed software using System Center Configuration Manager 2007 R2

Leave a reply

I recently needed to discover how many computers had Office 2000 installed.  System Center Configuration Manager 2007 R2 (SCCM) includes a report called “Computers with specific software registered in Add Remove Programs”, but  I wanted to know when the computer was last inventoried and also the specific application version.  I cloned the report and updated it to include these additional fields as below

The SQL for the report is:

Select sys.Netbios_Name0, sys.User_Name0, arp.DisplayName0, Version0, LastScanDate
FROM v_R_System sys
JOIN v_Add_Remove_Programs arp ON sys.ResourceID = arp.ResourceID
JOIN v_FullCollectionMembership fcm ON sys.ResourceID = fcm.ResourceID
JOIN v_GS_LastSoftwareScan lss ON lss.ResourceID = sys.ResourceID
WHERE DisplayName0 = @displayname and fcm.CollectionID=@CollID

Backup Exec and Autonomy IDOL

Autonomy IDOL enables you to scheduled a backup of its index to local disk.  I wanted to use Backup Exec to backup the Autonomy backup.  The Backup Exec agent was installed, but the service was refusing to start.  By default the Backup Exec agent service communicates on port 10,000, which was being used by IDOL.  Changing the Backup Exec agent port enabled the service to start.  See here for details: http://www.symantec.com/business/support/index?page=content&id=TECH24256 

The case of the failed SQL backup

I enabled a maintenance plan on a SQL server which creates a full backup of all databases.  When checking the job history I noticed that the job had failed.  Upon further investigation I could see that although the job had failed, all the databases had been backed up.  Opening the job log revealled the following error:

Failed:(-1073548784) Executing the query “BACKUP DATABASE [master] TO  DISK = N’I:\\Microsoft SQL Server\\MSSQL.1\\MSSQL\\Backup\\master\\master_backup_201010260000.bak’ WITH NOFORMAT, NOINIT,  NAME = N’master_backup_20101026000019′, SKIP, REWIND, NOUNLOAD,  STATS = 10
” failed with the following error: “Transaction (Process ID 580) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
Could not insert a backup or restore history/detail record in the msdb database. This may indicate a problem with the msdb database. The backup/restore operation was still successful.

I checked the SQL job schedule and noticed that another “Cleanup History” maintenance plan was set to run at the same time.  In order for this maintenance plan to cleanup the job history is needs to access MSDB, which caused the deadlock.  Re-scheduling the Full Backup plan to run 5 minutes later cured the problem

Partition above extends beyond the end of disk

I was recently trying to backup a server using Symantec Backup Exec System Recovery (BESR) 2010.  Unfortunately, BESR was refusing to create a backup.  A support call to Symantec pointed us to the PartInfo.exe tool, located in C:\Program Files\Symantec\Backup Exec System Recovery\Utility.  Running this tool creates a text file called partinfo.txt in the same folder.  When PartInfo was run on this particular server it logged the error “Partition above extends beyond the end of disk”.  This machine was a virtual server running on Windows Server 2008 R2 and had converted from a physical machine.  I was able to resolve the error by shutting down the VM and increasing the size of the disk by 1GB (the smallest amount permitted by the System Center Virtual Machine Manager 2008 R2 GUI).  I restarted the VM, re-ran PartInfo and the error was resolved and BESR was able to take backups of the server.