Mar 142014

UPDATE: I’ve been clued in that Windows Performance Recorder is now capable of controlling the paging executive from its command line. (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]

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

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.

Feb 262014

Here’s a nifty little query that will return the physical memory configuration of each computer registered in SCCM 2012. I’m excluding the System ROM (where layeth the BIOS) because we don’t really care about that here. We want the RAM! Written in SQL Server Management Studio 2012.


v_GS_PHYSICAL_MEMORY.DeviceLocator0 as [Slot],
v_GS_PHYSICAL_MEMORY.Capacity0 as [Size],
v_GS_PHYSICAL_MEMORY.Manufacturer0 as [Manufacturer],
v_GS_PHYSICAL_MEMORY.PartNumber0 as [Part Number],
v_GS_Computer_System.Model0 as [Model],
v_GS_Computer_System.Name0 as [Hostname],
v_GS_Computer_System.UserName0 as [Username]



/* We don't care about the system rom. */
where v_GS_PHYSICAL_MEMORY.DeviceLocator0 not like 'SYSTEM ROM'

/* Sort by hostname. */
order by v_GS_Computer_System.Name0
Feb 242014

Here is a SQL Query to generate a list of each Computer System in the SCCM 2012 Database, and then list CPU/Memory/Disk information. I wrote this to display Physical Disk 0. There are two different where clauses. The first one, commented out, can be used to pull up specific computers based upon the conditions you set. The second one just uses Physical Disk 0 as a condition. Written using SQL Server Management Studio 2012.

select distinct

v_GS_COMPUTER_SYSTEM.Model0 as [Model],
v_GS_COMPUTER_SYSTEM.Name0 as [Hostname], 
v_GS_COMPUTER_SYSTEM.UserName0 as [Primary User],
v_GS_PROCESSOR.MaxClockSpeed0 as [Speed],
v_GS_PROCESSOR.Name0 as [CPU],
v_GS_PROCESSOR.NumberOfCores0 as [Cores],
v_GS_PROCESSOR.IsHyperthreadCapable0 as [Hyperthread],
v_GS_DISK.Caption0 as [HDD],
v_GS_DISK.Size0 as [HDD Capacity],
v_GS_OPERATING_SYSTEM.TotalVirtualMemorySize0 as [Virtual Memory],
v_GS_OPERATING_SYSTEM.TotalVisibleMemorySize0 as [Visible Memory]


left join v_GS_DISK on v_GS_COMPUTER_SYSTEM.ResourceID = v_GS_DISK.ResourceID

/* where (v_GS_COMPUTER_SYSTEM.Name0 like '{yourstringhere' ) and
v_GS_DISK.DeviceID0 like '\\.\PHYSICALDRIVE0' */

where v_GS_DISK.DeviceID like '\\.\PHYSICALDRIVE0'

order by [Visible Memory]
Jan 212014

I admit that as far as technical support experience goes I’m somewhere in between, having worked in the IT industry since 2004, roughly a decade now. But I have seen it all, I might be bold in saying that I have done it all. I have made mistakes and have witnessed mistakes with customers over the phone. I have learned that even the most irate user on the phone can be singing your praises, but not without battle scars.

Here are my “Golden Rules” for technical support:

1. You are the expert, act like one.

You’re in control over the phone. The user has attempted within the bounds of their own knowledge to resolve their issue, but they’ve given it their last keystroke and now they want someone else to take control of the situation and fix their problem. By virtue of a phone call, they have given control to you, a person whom they know to be an expert.

Hint: Even if you’re not an expert at what you are troubleshooting, you can be an expert in finding out the answer.

2. The user you are working with is not an idiot.

If the user is an idiot, then why are they calling you? What’s idiotic about calling you? Resist the temptation to put the phone on hold and say something about the “ID10T error on the phone” in order to share what really is just their ignorance with your co-workers. Your moment of arrogance will bleed through the phone like a snake, and it will end up biting you in the end.

3. Never say: “I don’t know” or “that’s impossible”

User’s don’t like to hear this. It gives them the impression that they have hit a dead end and will have to do more work to resolve the issue. It also gives them the false assumption that you’re not an expert. After all, you’re the expert. Remember rule 1.

4. Your user’s time is ALWAYS more valuable than your own.

In the IT support industry, more often than not you’re working in a cost center, not a profit center. Because of this, your time costs the company money. The more you do within a given amount of time saves money for the company, and if you put things off, or blow off a customer, you’re wasting time and therefore costing more money.

I like to argue that there really isn’t any good way to get a quantitative metric on something so variable as rendering IT support, given that every single problem always has something that sets it apart from others, even password resets. So what I like to follow is to err on the side of caution and make my users time more valuable than my own. Sure, in practice we all slip, so treat this as a guideline. It cannot hurt.

5. Never place blame in front of a user.

It’s important to present a united front to your customers, be it internal or external. We all make mistakes, there are decisions made that we don’t agree with, and from time to time these will make it harder to support our user base. The right way to deal with this is within your own IT organization. Don’t complain to your users. Chances are this will not effect the change you are looking for, instead it will alienate your user base.

Hint: Your user’s don’t care that you have to go through a lengthy process to request access to a widget, they only care that you get their widget access approved in a timely fashion.

6. Never assume.

It’s said that “assume makes an ass of you and me.”

We work in a field where objective information is the rule. There can never be an opinion about how a computer or piece of software works. Because of this, IT affords you a luxury of never having to assume something. Computers work on true and false, never a “maybe.” If you don’t know a fact, you can look it up.

Assumptions are dangerous in IT, because when they prove to be incorrect, something happens that can be catastrophic. For instance, I assumed once that I was on a different print server and ended up deleting all the printers off of a mission critical server. We recovered, but because I was going by assumptions, it made an “ass of me.”

7. Take notes.

When you’re on the phone with lots of users on any given Monday, having notes to fall back on is a good thing, whether it be in the ticketing system or in a spiral notebook. I prefer the ticketing system because it creates an instant troubleshooting log. Be thorough and collect any information you can no matter how useless it seems. This is because of one of your colleagues are helping you and the see a pattern in your notes that you didn’t see,  you just saved yourself a lot of time.

8. Know your toolkit. Use it.

No one ever expects us to be “computer whisperers.” One cannot solve a computer by laying hands on it and yelling “heal thyself…”

…Unless there’s a grounding problem and you’re completing a circuit by doing such, but realistically, aside from the fact that such a thing will probably kill you, you have a toolkit.

Software like the Sysinternals Suite or GRC’s Spinrite, are examples. There are many more tools, too many to list, but if you’ve read this far you already have a toolkit that you use on a daily basis. It’s good to know those tools and the information they provide. They will save you time and make you the expert, so know your toolkit.

9. Be thorough. Never leave out information because it is “obvious.”

What’s obvious to you may not be obvious to a colleague no matter how technically proficient they are. I believe this is the chief cause of effort duplication. If two technicians find the same setting, and the first one made an assumption (there’s that word) that it was a known condition and left it out of their notes, while the second realized it was the root cause but it took them hours to get there, then time was wasted.

10. This is not magic. You are not a wizard. Don’t be arrogant.

It is so easy to become elitist in IT. You learn things that your users may not know. I’ve had users tell me I must be really smart since I’m able to solve their problem. These are people who have intimate knowledge in their own fields. They know things about their own fields that I would never hope to understand. My usual reply to them is “You wouldn’t want me doing your job.”

The answer is that we are specialists in our own field, we are computer experts, we are not financial exports, nor are we doctors. This is not wizardry, this is just a profession.

11.  Never “cold hold” a user on the phone.

This is rude, and no, saying “please hold” does not give you a pass. Always give the choice to the user. More specifically I am talking about the pesky mute button. If I ever ran a call center, I’d give the mute button a timer and call it a cough button.

People are psychological creatures. When you hear someone on the other end of the line it has better psychological impact than whenever the person on the other end of your line is met with a wall of silence. Plus, if they speak up and you forget your mute button is on its pretty embarrassing.

So unless you get permission from the user, no mater how odd this sounds, don’t mute.

12. There are no problems, only opportunities.

This may be the most important. Take responsibility for resolving the problems you are presented with and treat them as an opportunity. This allows you to prove yourself, and this is where the pay raises and promotions come from.

Always go above and beyond in doing technical support. It seems like a mundane job that lacks the real meat and bones of working with servers and configuring databases, but in the end you are the conduit between the user and the rest of IT. Treat that time as an opportunity, and good things will come.

I know some of this sounds like a self help guide, and perhaps some of it is. Perhaps I should write a book on it. 🙂

If you have additional rules or something you’d like to add, just comment, and perhaps I will edit them into this post.

Jan 212014

Recently I encountered a little trap with the VB Replace() function. Beware that if you only use the required parameters, like…

strString = Replace(strString,"{find}","{replacewith}")

…it does a binary only comparison. This can muck up instances where you intend to replace a known string, but some instances may come up with mixed case.

W3 Schools has an excellent reference page on replace() here.

Binary only is case-sensitive. The solution is to use textual, which is case-insensitive:

strString = Replace(strString,"{find}","{replacewith}",1,-1,vbTextCompare)

The parameters 1,-1,vbTextCompare is as follows:

  • 1 means “start at position 1”
  • -1 means “find all instances”
  • vbTextCompare is a constant (literally 1), that tells the function this is a text comparison. It’s alternate is vbBinaryCompare.

This can save a headache later on when you’re dealing with an scenario where case in strings are questionable, I would assume it’s always questionable unless you are looking explicitly for a binary match.

But I didn’t make VB. Oh well.

Jan 152014

If you’re working with SCCM 2012 Desired Configuration Management and want to create a CI for local machine certificates, here’s part 1 of a 2 part equation that is evolving. The remediation script is still in the works, but for right now, here’s a script that does the following.

  1. Query the Local Machine for a list of certs assigned to it.
  2. Check the list of certs for a valid machine certificate.
  3. Verify that the certificate has not expired.
  4. Verify that the certificate has the proper template (that you specify).
  5. And finally, verify that the certificate has the proper subject (again, that you specify).
  6. If items 3, 4, and 5 are all in agreement, echo “True” back to SCCM, or “False” if no machine certs are valid.

Note that there are a few strings you need to specify. $template and $subject need to be set or this isn’t going to work. You can also set $hostname to your hearts content. There’s obviously a lot of different ways you can modify this script, but for creating a CI in SCCM 2012 DCM this is a good start. Have fun!

### Check for existence of valid machine certificate ###
# By Robert Hollingshead
# Contributions by Steven Buck
# Transform function for Template property from
# Checks the certificate store for a valid machine
# certificate then outputs True.

# Function to get Template.
function Transform-Certificate {
 [Parameter(Mandatory = $true, ValueFromPipeline = $true, ValueFromPipelineByPropertyName = $true)]
    process {
        $temp = $cert.Extensions | ?{$_.Oid.Value -eq ""}
 if (!$temp) {
            $temp = $cert.Extensions | ?{$_.Oid.Value -eq ""}
        $cert | Add-Member -Name Template -MemberType NoteProperty -Value $temp.Format(1) -PassThru

# Assume the store doesn't contain a valid cert.
[bool]$ValidCert = $false # Assume false.

# Get hostname+fqdn
$hostname = []::gethostbyname(($env:computername)).Hostname

# Put the template string to match here. * is wildcard
$template = "*{a chunk of your template name to verify}*"

# Put the subject string to match here.
$subject = "CN=$hostname"

# Analyze each certificate in Local Machine.
foreach ($Certificate in (get-childitem -Path Cert:\LocalMachine\My | Transform-Certificate))
    If ($Certificate.Subject -eq $subject)  # If certificate has a proper subject.
        If ($Certificate.NotBefore -le (Get-Date)) # If certificate has not expired.
            If ($Certificate.Template -like $template) # If cert has proper template.
                $ValidCert = $true # It's true!

If ($ValidCert -eq $true)
        write-host "True"
        write-host "False"