Dec 222014
 

This is an experimental PowerShell script that looks at all the physical network adapters on a machine and verifies that they are at or above an arbitrary link speed set in the script. It works by querying the MSNdis_LinkSpeed class in WMI, filtering out non-physical adapters, and then checking each one to make sure the link speed is above the $MinSpeed value that you set. It then returns TRUE or FALSE.

I believe it is useful to use a greator than or equal to comparison instead of saying that all links must equal the minimum speed, especially in server environments where you may have a mixed environment of some servers with gigabit links for instance, and then another set of servers or virtual machines with 10gig links.

I don’t see this being useful in a PC environment because you have less control over what a desktop is hooked in to at any given point in time. Though it may still be useful if you want to enforce such a policy, like trading floor must be at gigabit or higher, and you want to catch non-compliance.

Obviously I can’t account for every InstanceName that isn’t a physical adapter. If there is a better way, by all means let me know and I’ll modify the script, but here it is!

# Robert's experimental NIC speed compliance script. 
# Emphasis on EXPERIMENTAL. 
# It will not break anything but it may not give back a sane result. 
# Manually check suspect compliance, bad compliance will probably come
# from non-physical nics where I didn't account for the InstanceName
# below when it came from MSNdis_LinkSpeed. 

# Minimum allowed speed in megabits. 
$MinSpeed = '1000' 

# This is used for compliancy.
$NonCompliant = 0

# Get link speed for all physical network adapters. 
$nics = Get-WmiObject -Namespace root\wmi -Class MSNdis_LinkSpeed | where {`
$_.InstanceName -notlike '*miniport*' -and `
$_.InstanceName -notlike '*WAN*' -and `
$_.InstanceName -notlike '*1394*' -and `
$_.InstanceName -notlike '*ISATAP*' -and `
$_.InstanceName -notlike '*Bluetooth*' -and `
$_.InstanceName -notlike '*RAS*' -and `
$_.InstanceName -notlike 'Direct Parallel' -and `
$_.InstanceName -notlike '*tunnel*' -and `
$_.InstanceName -notlike '*6to4*' -and `
$_.InstanceName -notlike '*Deterministic*' -and `
$_.InstanceName -notlike '*miniport*' -and `
$_.InstanceName -notlike '*kernel*'
}

# Go through list of NICS and make sure speed is above $MinSpeed
foreach ($nic in $nics) {
    
    #Make the link speed in megabits instead of bits.
    $LinkSpeed = $nic.NdisLinkSpeed/10000

    #See if this NIC is compliant.
    if ($LinkSpeed -lt $MinSpeed) {
        $NonCompliant++
    }
}

# Am I compliant?
if ($NonCompliant -eq 0) {
    write-host TRUE
    } else {
    write-host FALSE
}
Mar 142014
 

UPDATE: I’ve been clued in that Windows Performance Recorder is now capable of controlling the paging executive from its command line. https://msdn.microsoft.com/en-us/library/windows/hardware/hh448229.aspx (thanks Jeff Stokes)

Here is the registry change required to disable the paging executive for use with Windows Performance Recorder, but you can do it much easier with WPR now.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"DisablePagingExecutive"=dword:00000001

Alternatively, you can download the registry file as a ZIP here. disable_paging_executive.zip

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.

Dec 122013
 

Here’s a helpful tip, see here for more details.

I was working on a script to remove specific Modern packages from Windows 8.1 and I needed a quick way to see what was installed. “get-appxprovisionedpackage -online” yielded the following useless results.

PS C:\windows\system32> get-appxprovisionedpackage -online

DisplayName  : Microsoft.BingFinance 
Version      : 2013.809.632.3676 
Architecture : neutral 
ResourceId   : ~ 
PackageName  : Microsoft.BingFinance_2013.809.632.3676_neutral_~_8wekyb3d8bbwe

DisplayName  : Microsoft.BingFoodAndDrink 
Version      : 2013.820.258.2561 
Architecture : neutral 
ResourceId   : ~ 
PackageName  : Microsoft.BingFoodAndDrink_2013.820.258.2561_neutral_~_8wekyb3d8bbwe

The list is longer, but you get the idea. Anyway it’s completely useless to me. The solution is to use select-object to pick out the PackageName value from the collection of objects. Simple really, just use a pipe along with the “select-object” cmdlet then specify the name of the value you want.:

PS C:\windows\system32> get-appxprovisionedpackage -online | select-object PackageName

PackageName
-----------
Microsoft.BingFinance_2013.809.632.3676_neutral_~_8wekyb3d8bbwe
Microsoft.BingFoodAndDrink_2013.820.258.2561_neutral_~_8wekyb3d8bbwe
Microsoft.BingHealthAndFitness_2013.813.243.3760_neutral_~_8wekyb3d8bbwe
Microsoft.BingMaps_2013.809.2206.5385_neutral_~_8wekyb3d8bbwe
Microsoft.BingNews_2013.809.636.2800_neutral_~_8wekyb3d8bbwe
Microsoft.BingSports_2013.809.637.2803_neutral_~_8wekyb3d8bbwe
Microsoft.BingTravel_2013.809.639.25_neutral_~_8wekyb3d8bbwe

Ahh. Much better. Now I could take that output and figure out which Modern apps to delete. I will probably start with Bing.

May 072013
 

This PowerShell script uses Dism to find all OEM entries and then parses them into a text file. Run as administrator.

###########################################################################
#
# Get-Drivers.ps1
#
# Use Dism to create a list of OEM driver entries. This can also be 
# changed to output other entries as well. Run as administrator.
#
# by Robert Hollingshead
# Contributed to the public domain. Do with it what you will. 
#
###########################################################################

$fileStream = [System.IO.StreamWriter] "C:\Drivers.txt"

[array]$arrayDismParsed = @()

$arrayDismParsed = "Parsed output from Get-Drivers.ps1"

# Populate the array. 
$arrayDismOutput = & dism /online /get-drivers /all /format:table

$arrayDismParsed = $arrayDismParsed + $arrayDismOutput[11]
$arrayDismParsed = $arrayDismParsed + $arrayDismOutput[12]
$arrayDismParsed = $arrayDismParsed + $arrayDismOutput[13]

for ($arrayPos=0;$arrayPos -le $arrayDismOutput.length;$arrayPos++)
{
    if ($arrayDismOutput[$arrayPos] -like "*OEM*") # Find the OEM entries. ;
    {
        $arrayDismParsed = $arrayDismParsed + $arrayDismOutput[$arrayPos]
    }
}

for ($arrayPos=0;$arrayPos -le $arrayDismParsed.length;$arrayPos++)
{
    $fileStream.WriteLine($arrayDismParsed[$arrayPos])
}

$fileStream.Close()
May 072013
 

This script will take a list of print servers and then query each individual server on the list for the installed print drivers. It will then output a report in csv format of all drivers encountered.

###########################################################################
#
# Query listed print servers and report on all drivers discovered.  
#
# by Robert Hollingshead
# Contributed to the public domain. Do with it what you will. 
#
###########################################################################

# Place your server list CSV file here, including path. 
$ServerCSV = "{output csv and path}"

# Place the output CSV file here, including path. 
$OutputCSV = "{output csv and path}"

#Change nothing below this line. 

$credential = Get-Credential
$driver = ""
[system.array]$report = $null

$servers = Import-Csv $ServerCSV

foreach ($server in $servers) 
{

    Write-Host ' ' 
    Write-Host $server.Servername -NoNewLine

    $drivers = Get-WMIObject -class Win32_PrinterDriver -computer $server.Servername -credential $credential

    foreach($driver in $drivers) 
    {

        Write-Host "." -NoNewLine

        $path = $driver.DriverPath.Substring(0,1)

        $output = New-Object PSObject
        $output | Add-Member -membertype noteproperty -Name Servername -Value $server.Servername
        $output | Add-Member -membertype noteproperty -Name Drivername -Value $driver.Name

        $servername = $server.Servername

        $output | Add-Member -membertype noteproperty -Name Driverversion -Value (Get-ItemProperty ($driver.DriverPath.Replace("$path`:","\\$servername\$path`$"))).VersionInfo.ProductVersion

        $report = $report + $output

    }

}

$report | export-csv $OutputCSV -notype
May 072013
 

The following PowerShell script will delete drivers from the driver store that match a keyword. It will also ignore a specific driver if need be. Use to prune older sets of drivers that are no longer needed. Use at your own risk, of course.

###########################################################################
#
# Use pnputil to delete drivers (in this case Xerox) from the driver store. 
#
# by Robert Hollingshead
# Contributed to the public domain. Do with it what you will. 
#
###########################################################################

# Populate the array. 
$arrayPnpOutput = & pnputil -e

for ($arrayPos=0;$arrayPos -le $arrayPnpOutput.length;$arrayPos++)
{
    if ($arrayPnpOutput[$arrayPos] -like "*Xerox") # Find matches for xerox as the publisher. ;
    {
        if ($arrayPnpOutput[$arrayPos+2] -notlike "*11/23/2011 5246.700*") # Do not kill this version..
        {
            $arrayPnpOutput[$arrayPos-1] = $arrayPnpOutput[$arrayPos-1] -replace "Published name :            ",""
            Write-Host "Erasing: " $arrayPnpOutput[$arrayPos-1]
            pnputil -d $arrayPnpOutput[$arrayPos-1]
        }
    }
}