With little effort you can extend the hardware inventory so you will get to know

• The total amount of DIMM-Slots
• The free amount of DIMM-Slots

To get your hands on this information, you have to modify the SMS_DEF.MOF on your primary sites. There are two WMI queries that need to run on the client. The first one gets detailed information about every installed module and the second one is used to determine the total and used slots on the mainboard. This is inspired by some wise guy from the myITforum.

The MOF-File in question is located in the following location: <smsinstalldir>\inboxes\clifiles.src\hinv

Be sure to make a backup and, to be on the safe side, do not test this in a productive environment. It’s unlikely that it causes trouble, but we should always fear Murphy’s Law!

Just add the following code at the bottom of the MOF-File and save it.

//**************************************************************************
//* Class: Physical Memory
//* Derived from: (nothing)
//*
//* Auslesen der Speicherinformationen pro installiertem Modul
//*
//**************************************************************************
[SMS_Report (TRUE),
SMS_Group_Name ("Physical Memory"),
SMS_Class_ID   ("Microsoft|Physical_Memory|1.0")]

class Win32_PhysicalMemory : SMS_Class_Template
{
[SMS_Report (TRUE)] string BankLabel;
[SMS_Report (TRUE), SMS_Units("Megabytes")]  uint64 Capacity;
[SMS_Report (TRUE)] string Caption;
[SMS_Report (TRUE)] string DeviceLocator[];
[SMS_Report (TRUE)] uint16 FormFactor;
[SMS_Report (TRUE)] string Manufacturer;
[SMS_Report (TRUE)] uint16 MemoryType;
[SMS_Report (TRUE)] uint32 PositionInRow;
[SMS_Report (TRUE)] uint32 Speed;
[SMS_Report (TRUE),Key] string    Tag;
[SMS_Report (TRUE),Key] string    CreationClassName;
};

//**************************************************************************
//* Class: Physical Memory Array
//* Derived from: (nothing)
//*
//* Auslesen der verfügbaren Speicherslots
//*
//**************************************************************************
[SMS_Report (TRUE),
SMS_Group_Name ("Physical Memory Array"),
SMS_Class_ID   ("Microsoft|Physical_Memory_Array|1.0")]

class Win32_PhysicalMemoryArray : SMS_Class_Template
{
[SMS_Report (FALSE)] string Caption;
[SMS_Report (FALSE)] string CreationClassName;
[SMS_Report (FALSE)] string Description;
[SMS_Report (FALSE)] uint16 Location;
[SMS_Report (FALSE)] string Manufacturer;
[SMS_Report (TRUE), SMS_Units("Megabytes")] uint32 MaxCapacity;
[SMS_Report (TRUE)] uint16 MemoryDevices;
[SMS_Report (FALSE)] uint16 MemoryErrorCorrection;
[SMS_Report (FALSE)] string Model;
[SMS_Report (FALSE)] string Name;
[SMS_Report (FALSE)] string OtherIdentifyingInfo;
[SMS_Report (FALSE)] string PartNumber;
[SMS_Report (FALSE)] boolean PoweredOn;
[SMS_Report (FALSE)] boolean Removable;
[SMS_Report (FALSE)] boolean Replaceable;
[SMS_Report (FALSE)] string SerialNumber;
[SMS_Report (FALSE)] string SKU;
[SMS_Report (FALSE)] string Status;
[SMS_Report (TRUE), Key] string Tag;
[SMS_Report (FALSE)] uint16 Use;
[SMS_Report (FALSE)] string Version;
};

As you can see, you can gather much more details if you switch some of the “FALSE” values to TRUE. The next time the client updates his policy, the new code will be compiled on the client. The next scheduled hardware inventory will execute the new queries and report the results back to the assigned site server. When this happens, two new tables will be created in the CfgMgr-Database. In this case, this would be:

• v_gs_physical_memory_array
• v_gs_physical_memory

Of course, this alone won’t help us so much. To make the data readable, we can create a report. I have created a report that combines both tables to show you the details of each installed module, enriched with the information how many slots there are and how much of them are still unused. Feel free to change the SQL statement to your needs.

Report Example

To make things easier, you can download the report’s .MOF-file for quick import into the CfgMgr.

Download: CfgMgr RAM Report MOF

Our company tries very hard to use the newest software available, so customers see it in action when our consultants work with them. But in the “real world”, the clocks don’t tick as fast. Most of the time we face companies that are now migrating to Windows XP and Office 2003… oh my. In order to stay “compatible” with their workflows, it can be very complicated to maintain both worlds in one notebook.

To ease this pain, I looked into the Microsoft Desktop Optimisation Pack, short MDOP. The MDOP is available for companies that have Microsoft Software Assurance. One part of it is App-V. It virtualizes a software package in order to let it run on systems where compatibility issues due to other installed software would occur. It is not a full operating system virtualization, it’s just the application itself, running in a sandbox. So the software has still the prerequisite to be compatible to your target machines.

This step-by-step guide shows you the basic workflow to create a virtual software package and distribute it to a client with the ConfigMgr, in this case Microsoft Office 2003.

The following environment was used:
“Test Client”
Windows 7 Enterprise x64
Virtual Guest (Hyper-V)
App-V Sequencer installed

“Productive Client”
Windows 7 Enterprise x64
LenovoT61 Notebook
App-V Client and ConfigMgr Client installed (as well as a bunch of other stuff)

“ConfigMgr Server”
Windows Server 2008 R2 Enterprise x64
Virtual Guest (Hyper-V)
System Center Configuration Manager 2007 R2 installed

Be warned, this is a very long, screenshot-heavy post. To view the pictures correctly, click on the little button on the top right corner of the header to increase the column width.

Let’s start up the App-V sequencer. I already copied the Office 2003 sources to the “clean” test client.

Click “Create a Package”

Name the package as you wish and click “next”. In this case we skip the advanced options. Please excuse the fact that some buttons are in German.

Please use a dedicated, cleanly installed machine. Any extra service or program that works in the background will but irrelevant data into the monitoring process. You may already know this problem if you ever have repackaged software. When you have all the data you need for the setup in place, click “Begin Monitoring”.

The wizard will ask you where you will install the software to. I created a 8.3 format compatible directory here and selected it.

Still, it bugs about an incorrect naming, I don’t really know why. In any case, this could only become a problem if you have multiple virtualized apps that have similar 8.3 directory names (you might want to double check on this information). Click “Ignore” here.

The sequencer will now scan the system state for later comparsion.

When it’s done, it will show the dialog below. You can now start the Office 2003 setup!

I don’t want to bore you with the Office setup, so I keep it to the important details. Be sure to choose the directory you created earlier in the process and select custom installation.

Choose every component the user will need later, as you cannot use the “install on first use” feature here”.

Wait until the setup is completed. After completion, you may patch the application. I installed the Office 2003 SP3 at this point. When you are done, click “Stop Monitoring”.

The Sequencer will analyse all changes made to the system. When it’s done, click “next”.

Now you can configure what monitored applications you want in the package and most importantly, what file type associations. In this case I removed all of them, so that the user only starts the old Office version when it is needed. Click “next” when you are done.

In the next step click “Launch All” to start all applications in the package. The sequencer will detect any additional dependencies.

When you’re done, all applications will be “checked” and you can continue by clicking “next”.

The wizard will now sequence all collected data for you.

You can now edit the package as needed.

You can preset the server path (not needed for SCCM deployment) and compatible operating systems here. Additionally you might want the sequencer to create a MSI and compress the package. Both options I do recommend.

No need to change anything here…

or here…

or here…

or here…

or here!

Finally, you have to save the package. In my case I created a share on the ConfigMgr Server for this purpose.

After the saving in complete, switch to your System Center Configuration Manager and create a new “Virtual Application Package”.

Click “Browse…” and point the dialog to your package’s manifest XML file. Click “next”.

Fill out the form as needed. Click next.

You now have to provide an UNC path where the package will be copied to. This location must be accessible by client computer agents, like your other distribution points. Click “next”.

Take note of this message and click “yes”.

Click “next”.

Click “next”.

And finally, click “close”.

If you never deployed virtual packages via ConfigMgr, you need to allow the Client Agents to do so. Open the properties for the “Advertised Programs Client Agent”.

Enable “Allow virtual application package advertisement” and click “ok”. It may take some time for you clients to get the new policy, depending on your environment.

You may now create an advertisement for the virtual package.

The distribution wizard is similar to the one for normal software. Advertise it to a collection of your choice.

A few “moments” later, it should appear at your client.

Download and start the advertisement…

and start your application!

Congratulations! You made it!

I really hope you could learn something from this and enjoy the benefits of virtualized applications!

So far, so good. This works well, until you upgrade to service pack 2! This will update the Client Agent and render it incompatible with the MSP file. Unfortunately, if you didn’t touch that software package for several months, you may forget about the MSP file. As a result, all your deployments will fail at the “Setup windows and ConfigMgr” task. Pretty simple: removing the MSP will solve the issue. The way to this solution took me a little longer than just a quick bing’ing, anyone who debugs System Center products knows what I’m talking about.

Here are screenshots from the smsts.log, which was logged on the failing client:

MP Error Log

We set up a VM and tried booting into PXE… with no response of the server. Restarting the WDS service didn’t do the trick. So I dug a little deeper and took a look at the logs in %programfiles%\Microsoft Configuration Manager\Logs. Interesting files to look at: mpcontrol.log and pxecontrol.log (use SMS TRACE to

PXE Error Log

view these logs, if you don’t have any other preference). The PXE log didn’t tell me anything interesting, it even logged successful self-tests! Funny, because the log in the ConfigMgr-Console told me otherwise: the PXE service was not responding. It also told me the Management Port was giving a HTTP 500 error.

After a lot of rebooting and error-hunting I came up with a “solution” to this problem. It seemed the service pack installation didn’t properly update the PXE and management point and caused the unresponsiveness of both service roles.

WARNING: You may already know it, but just to be clear on this: the Configuration Manager takes some time to do it’s work. So be calm and watch the application log for MSI events, stating a successful (de)installation before rebooting. This is true for both the ConfigMgr Roles and Client Agent.

I did the following to solve it:

• Removed the Management Point Role (in ConfigMgr)
• Reboot
• Reinstalled the Management Point Role
• Removed the ConfigMgr Client Agent (ccmsetup /uninstall)
• Removed the PXE Role (in ConfigMgr)
• Reboot
• Removed the WDS Role (Windows Server)
• Reboot
• Reinstalled the WDS Server Role (no configuration after that of course)
• Reinstalled the PXE Role
• Reinstalled the CCM Client Agent
• Reboot

Yes I know: lots of lots of reboots. You may skip them if you dare, please drop me a line if it work anyway.

After that, all components went to green in the system state view and the PXE service started to respond as expected.