Jul 182014

A while back I wrote a MS SQL query to gather vitals for a PC Fleet in SCCM 2012. I have now updated it to include some more information like Make and information for the system partition (size/free/% used). I’ve also changed some of the columns to use the more Appealing Giga units of measurement instead of Mega.

This is so that if anyone ever asks what you have out there,  you can run a quick query and say “HERE YOU GO!” Enjoy! Written in Microsoft SQL Server Management Studio 2012.

NOTE: Search and replace {domain\} with your domain name or the query will fail, just FYI. Also, when you copy and paste, the lines will remain intact.

select distinct

CS.Manufacturer0 [Make],
CS.Model0 [Model],
CS.Name0 [Hostname], 
replace(CS.UserName0,'{domain\}','') [Primary User],
OS.Caption0 [OS],
OS.InstallDate0 [Image Date],
cast(CPU.MaxClockSpeed0/1000.00 as decimal(10,2)) [Speed (MHz)],
CPU.Name0 [CPU],
CPU.NumberOfCores0 [Cores],
CPU.IsHyperthreadCapable0 [Hyperthread],
DSK.Caption0 [HDD],
cast(DSK.Size0/1000.00 as decimal(10,2)) [HDD Capacity (GB)],
cast(LDSK.Size0/1000.00 as decimal(10,2)) [C Size (GB)],
cast(LDSK.FreeSpace0/1000.00 as decimal(10,2)) [C Free (GB)],
cast((LDSK.FreeSpace0 * 100.00)/(LDSK.Size0 * 1.00) as decimal(10,2)) [C %Free],
cast(OS.TotalVirtualMemorySize0/1000.000 as decimal(10,3)) [Virtual Memory (GB)],
cast(OS.TotalVisibleMemorySize0/1000.000 as decimal(10,3)) [Visible Memory (GB)]


left join v_GS_PROCESSOR CPU on CS.ResourceID = CPU.ResourceID
left join v_GS_DISK DSK on CS.ResourceID = DSK.ResourceID
left join v_GS_OPERATING_SYSTEM OS on CS.ResourceID = OS.ResourceID
left join v_GS_SYSTEM SYS on CS.ResourceID = SYS.ResourceID
left join v_GS_LOGICAL_DISK LDSK on CS.ResourceID = LDSK.ResourceID

SYS.SystemRole0 like 'Workstation'  and
LDSK.Caption0 like 'C:' and
DSK.DeviceID0 like '\\.\PHYSICALDRIVE0' 

order by Make, Model


Mar 112014

April 8th is fast approaching. On that date XP will end it’s 12 year run as a viable operating system. It will slip into the history books as a very successful Operating System of course, but it’s time for IT to move on to new and more capable operating systems.

XP will not go quietly into the night. It is still installed and used on a large number of PC’s and Point of Sale systems. What’s worse, because Microsoft will still be releasing security updates for NT 6.x (Vista/7/8/Server 2012), hackers will obviously be busy looking at those security updates to see if there are vulnerabilities in NT 5.x (2000/XP/Server 2003).

Unfortunately there are cases where, despite Microsoft’s insistence that we upgrade, it may not be possible to meet that April 8th deadline, so I’m publishing a list of things to do in order to harden the XP OS. The idea here is to make the XP OS difficult to exploit by anticipating problems with services and features that will no longer see updates from Microsoft.

Keep in mind this is my own list, there’s probably even better lists out there, but it’s a start:

  1. Kill unneeded services and disable them.

    Look for services that allow remote connections. For instance, if you can, kill and disable the server service. Here are a few. I’m also including a few that could be susceptible to MITM or other abuses later on in their life.

    Automatic Updates (Doesn’t make any sense to keep this running)
    Computer Browser (This will die anyway when the server service is stopped)
    Remote Desktop Help Session Manager (Potential for abuse)
    Remote Registry (Keep remote people/computers from breaking in to the registry)
    Routing and Remote Services (If automatic. Potential for abuse)
    Server (Keep people/computers from connecting)
    Shell Hardware Detection (Prevents autoplay, potential for abuse)
    SSDP Discovery Service (UPnP, Potential for abuse)
    System Restore Service (prevent viruses from hijacking restore points).
    Terminal Services (prevent remote people/comptuers from breaking in through RDP)
    Themes (prevent vulnerabilities with themes)
    Web Client (potential for abuse of WebDAV)
    Windows Time (May fall to MITM, potential for abuse)

  2. Windows Firewall

    Keep the Windows Firewall running and be sure that any old ports that were previously opened are closed. “Tighter than Fort Knox” applies here.

    If possible, configure “Don’t allow exceptions.”

  3. Enforce a “Do Not Connect To The Corporate Network” policy.

    The last thing you want is for an unsupported and infected XP machine to become an infection vector. While you can’t necessarily prevent this without some form of network gatekeeper like Microsoft NAP or Cisco ISE, getting your people to understand the dangers by enforcing a policy is the first step.

  4. Install a Stand-Alone Virus Scanner

    You should already have a virus scanner on your XP machines. But if you don’t want these machines connected to your network, a stand-alone scanner that receives updates from an internet facing server is the way to go . Microsoft Security Essentials is one product, but may not be supported on XP much longer. Third party may be your best bet, or open source.

  5. Disable Network Access

    If you do not need network access, disable the network adapters both in windows and through the BIOS.

  6. Back Up Everything

    Backup your documentation, your OS files, your discs. Support tools and support documentation are a must. Make disk images. XP is now a legacy OS and should be treated as such. 10 years later if you suddenly need access to an XP machine, you’ll be glad you captured everything.

  7. Have an End of Life Support Plan

    Obviously you’re not going to get much help from Microsoft after April 8th, without spending millions of dollars, so having an EoL Support Plan for Windows XP is a good idea.

    It does not have to be an involved plan. One simple method would involve re-imaging if something breaks (remember 6, backup everything).

  8. Keep Spares Around

    Manufacturers are moving away from supporting XP. It’s a good idea to keep spare kit around in case an XP machine malfunctions. No need to go overboard and save every single piece of equipment. “organ harvest” spare components from other machines and keep them in a marked box.

I could go on, but I think these 8 steps are the most important. I am in no way advocating the use of XP in a network setting after April 8th. In fact I think it is very dangerous from an IT security standpoint. But reality dictates there will be a need for XP in a legacy capacity for the next several years. It helps to be smart with how to implement that legacy use of XP.

And I bid thee farewell to a legendary OS.