Category Archives: Server Core

Listing installed applications on Server Core

If you have SCCM installed, a WMI object is created that provides an inventory of applications installed on a particular machine (and can be retrieved using PowerShell):

get-wmiobject -class Win32Reg_AddRemovePrograms

If you don’t have SCCM installed, the most reliable way to get this information is directly from the registry at:




Though I don’t personally bother with using them, there are some places around the Interweb where others have rolled the registry walk into a ps script.

I would NOT recommend using Win32_Product as it forces re-registration of installed applications, which is slow and may lead to undesirable second-order effects.

It is unfortunate that M$ has yet to develop a simple command line (or PowerShell) option for retrieving information as basic as this…


McAfee Agent Status Monitor on x64/Server Core Systems

The McAfee Agent Status Monitor is normally launched from the system tray.  But if you have a 64-bit OS and/or Server Core installed, there is no icon.

Fret not!  You can still pull up the Agent Status Monitor from the command line:

c:\Program Files\McAfee\Common Framework\cmdagent.exe /s

Running SCCM 2007 Software Updates on Server Core

Updated 2/8/2016

Oh man, this is my best work in months!

Our network has several Windows Server 2008 (and now 2012 R2) Server Core installations.  We also run System Center Configuration manager 2007 to manage software updates.  As anyone who has used SSCM knows, advertised software updates show up as a notification in the system tray, which is fine, unless you’re running Server Core.  That’s because Server Core doesn’t have a system tray!

Now, I don’t know about you, but I’m a control freak when it comes to running software updates on my servers.  I only want them to run one at a time, when the server is offline for maintenance, and with me there watching the updates happen.  So that means a mandatory advertisement to my Server Core machines was out of the question.

I started searching the Interweb for solutions discovered by similarly-situated system administrators.  Unfortunately, this is what I found:

– People (trying to be helpful) answering the question (or posting snarky responses) when they didn’t even understand the question… this makes me absolutely crazy (c’mon folks… either help up or shut up)!
– Powershell scripts invoking other Powershell scripts invoking…
– Some weird thingy using Maintenance Windows to stagger updates across machines

Ugh!  I wanted a simple, elegant solution.  I didn’t want to do any of this.  So after I thought about this for a few days, I realized you could use a task sequence as a proxy to initiate updates (since control panels are still available in Server Core):

1. Create a Software Update deployment like you normally do and assign it to your Server Core machines.  Make sure the deployment is not mandatory.
2. Now, create a Task Sequence.  In it, add a single task: Install Software Updates.  Be sure All Software Updates is selected.
3. Advertise the Task Sequence you just created to your Server Core machines.  Ensure the advertisement has progress display checked.  Check the SCCM log to make sure the advertisement is pushed before continuing.
4. On each Server Core machine you want to update, perform the following:

a.  Open the SCCM control panel: c:\Program Files\SMS_CCM\SMSCFGRC.cpl (on 64-bit OS, this will be in Program Files (x86) [UPDATE: SCCM files on 64-bit machines may be located at c:\WINDOWS\SysWOW64\CCM instead].
b.  On the Actions tab, initiate a Software Updates Scan Cycle.  This can usually take a few minutes.  Check ScanAgent.log for status
c.  On the Actions tab, initiate a Machine Policy Retrieval & Evaluation Cycle.  Wait a few moments for this to complete.
d.  Open the Run Advertised Programs control panel: c:\Program Files\SMS_CCM\SMSRAP.cpl (again the path for 64-bit will differ)
e.  You should see your advertised task sequence to run software updates.  Initiate the task and watch it go!

Ha ha! No code and no weird settings!  And, I get to reuse it over and over again!

P.S. Be aware that there is no way to suppress a forced restart for a task sequence if the update package requires it.  So make sure your server is ready for a reboot when you start your updates!

Configuring Jumbo Frames on a Hyper-V/Server Core Virtual NIC

I was recently reading two excellent articles on NIC configuration for server core and virtual NICs.  The reason I happened upon these postings was because I was searching for a way to enable Jumbo Frames.  Unfortunately, I didn’t find anything that specifically addressed doing this work on vitrualized NICs in Hyper-V Server, which is slightly different than physical NICs. 

Using Michael Platt’s article, I discovered that it did not take into account multiple NICs with the same device name.  What I really needed was a way to reference the “Friendly Name” (the one you set in the Hyper-V Virtual Network Manager).  After doing a search of the registry, I found that the friendly names of the virtual NICs are stored in 


From there, one can search for the correct NIC as described in the article, using the “Driver” value.

As an aside, you can lookup the GUID for physical drivers by running a search of the friendly name in


The containing key will match the NetCfgInstanceId of the NIC you want to modify. 

Using these methods, you can be sure you’re configuring the correct NIC within the registry.

Server Core/Hyper-V Server specific Group Policies

In our little digital wonderland, we are compelled encouraged by our security department to apply some rather draconian Group Policy Objects.  It’s a PITA, but security doesn’t care.  Since I’ve been doing these for a while, I can usually see whether or not a particular setting will f*** us before it’s implemented.  But considering there’s like three quadrillon settings, sometimes even I can’t always predict what will happen.  Here’s a little ditty about one of those times:

I was logged in on a remote session to one of our Server Core installs.  If I remember correctly, I was trying to install an unsigned driver (it was a DSM for MPIO to our SANs, for all you standard nerds).  Well, just like that hot chick you bumped into at the bar last week… the promised call never came.  No error, no freeze, nothing.  Just a new command prompt line.

After much heartache, we found that the culprit was two UAC policy settings:
– User Account Control: Admin Approval Mode for the Built-in Administrator Account (Enabled)
– User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode (3)
(Both of these are found in Computer Configuration | Policies | Windows Settings | Security Settings | Local Policies | Security Options | User Account Control)

Now I can’t say whether it was the fact that the exe was unsigned, or that it expected UAC, but the installer was blocked from starting.  So how to fix this?  Easy!  With another GPO that overrides the offending settings to Disabled and Elevate without prompting, respectively.  Scope this GPO to apply only to the Server Core machine and you’ll make your SAs AND security happy!

Not content to leave well enough alone, I wasn’t satisfied with listing every single Server Core machine in the GPO scope.  Nope.  If you know me, you know I don’t like to half-ass anything; I’m a whole-ass kind of guy.  This is where WMI (where have you been all my life? I love you!) comes in.

In Group Policy Management, create a new WMI filter in the WMI filters node.  In this filter, give it a clever name (like Server Core Only).  For the query, use the default root\CIMv2 namespace and the following for the query text:

SELECT * FROM Win32_OperatingSystem
WHERE OperatingSystemSKU = 12
OR OperatingSystemSKU = 13
OR OperatingSystemSKU = 14
OR OperatingSystemSKU = 42

Assign this filter to your GPO and you can fuggedaboutit.  In case you’re wondering where I got the SKUs, they can be found here: (search for OperatingSystemSKU).  Note that SKU 42 is not listed; this is for Hyper-V Server.

Don’t say I never helped you out…