Browsed by
Tag: Windows

Actual Installed Application Reporting from SCCM

Actual Installed Application Reporting from SCCM

Having worked on SCCM for many years now I have lost count of how many times I have been asked, “Since you guys have an agent on all of the computers can I get you to provide me a list of ALL software that is installed on all of the computers?” after which there is a long draw out discussion explaining that when SCCM returns the information from Programs and Features it doesn’t discriminate between System install applications which are not visible in Programs and Features in which you will typically end up with double the amount of applications per computer, then what actually appears in Programs and Features. To this end I’ve had some spare time recently, so I have done some investigating, and found that with a simple update of the MOF we can typically get within +/-98% accuracy of only the applications that appear in Programs and Features appearing in the SCCM reports, which for me it a huge win.

As we know the Registry is the master of what appears in the Programs and Features list, so for example you can change the Display Name of applications in Programs and Features by changing the following registry Item:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\|DisplayName

This Key also includes such things as the Publisher, Version numbers, and Uninstallation strings. The Item’s which we are interested in for this solution are the following:
SystemComponent
ParentDisplayName

The SystemComponent item will appear as 1 if the application is to be hidden from Programs and Features, so for example the SCCM Client will have SystemComponent = 1 which appears to hide it from Programs and Features, if this item is not defined it is assumed to be a 0 (This is also used by Microsoft Office to hide each of the components from Programs and Features).

Whereas the ParentDisplayName item is used for patches to applications and Operating system, an example of can be seen in Windows XP where you could select the check box to hide updates. When not referring to the install Operating System it will refer to the DisplayName of the parent, for example “Microsoft .NET Framework 4 Client Profile” will have all of the updates that are dependent upon it.

Now we have explained what we are doing and why let’s step through the process of actually capturing the details in SCCM.

  1. Browse to \\<SCCMSERVER>\SMS_<SITECODE>\inboxes\clifiles.src\hinv
  2. Copy Configuration.mof to c:\data\mofs
  3. Open Configuration.mof with Notepad
  4. Find the Follow:
    class Win32Reg_AddRemovePrograms
    {
    [key]
    string ProdID;
    [PropertyContext(“DisplayName”)]
    string DisplayName;
    [PropertyContext(“InstallDate”)]
    string InstallDate;
    [PropertyContext(“Publisher”) ]
    string Publisher;
    [PropertyContext(“DisplayVersion”)]
    string Version;
    }
    and Replace with the following:
    class Win32Reg_AddRemovePrograms
    {
    [key]
    string ProdID;
    [PropertyContext(“DisplayName”)]
    string DisplayName;
    [PropertyContext(“InstallDate”)]
    string InstallDate;
    [PropertyContext(“Publisher”) ]
    string Publisher;
    [PropertyContext(“DisplayVersion”)]
    string Version;
    [PropertyContext(“SystemComponent”)]
    string SystemComponent;
    [PropertyContext(“ParentDisplayName”)]
    string ParentDisplayName;
    }

  5. Then find the following directly below:
    class Win32Reg_AddRemovePrograms64
    {
    [key]
    string ProdID;
    [PropertyContext(“DisplayName”)]
    string DisplayName;
    [PropertyContext(“InstallDate”)]
    string InstallDate;
    [PropertyContext(“Publisher”) ]
    string Publisher;
    [PropertyContext(“DisplayVersion”)]
    string Version;
    }
    and Replace with the following:
    class Win32Reg_AddRemovePrograms64
    {
    [key]
    string ProdID;
    [PropertyContext(“DisplayName”)]
    string DisplayName;
    [PropertyContext(“InstallDate”)]
    string InstallDate;
    [PropertyContext(“Publisher”) ]
    string Publisher;
    [PropertyContext(“DisplayVersion”)]
    string Version;
    [PropertyContext(“SystemComponent”)]
    string SystemComponent;
    [PropertyContext(“ParentDisplayName”)]
    string ParentDisplayName;
    }

  6. Close and Save Configuration.mof
  7. In an elevated command prompt run the following commands:
    1. Mofcomp c:\data\configuration.mof
      the result should look like this:
  8. Browse back to: \\<SCCMSERVER>\SMS_<SITECODE>\inboxes\clifiles.src\hinv and rename the existing file to match this naming convention:
    1. configurationYYYYMMDD.mof
  9. Copy configuration.mof from c:\data to \\<SCCMSERVER>\SMS_<SITECODE>\inboxes\clifiles.src\hinv
  10. Open SCCM 2012 Console and browse Administration à Client Settings
  11. Right click on Default Client Settings and select Properties
  12. Select Set Classes under the Hardware Inventory tab on the Default Settings Form
  13. Select Export on the Hardware Inventory Classes form
  14. Save the exported file to c:\data\export.mof
  15. Open C:\data\export.mof in notepad
  16. Find the following:
    class Win32Reg_AddRemovePrograms : SMS_Class_Template
    {
    [SMS_Report (TRUE), key ]
    string ProdID;
    [SMS_Report (TRUE) ]
    string DisplayName;
    [SMS_Report (TRUE) ]
    string InstallDate;
    [SMS_Report (TRUE) ]
    string Publisher;
    [SMS_Report (TRUE) ]
    string Version;
    };

    and replace with:
    class Win32Reg_AddRemovePrograms : SMS_Class_Template
    {
    [SMS_Report (TRUE), key ]
    string ProdID;
    [SMS_Report (TRUE) ]
    string DisplayName;
    [SMS_Report (TRUE) ]
    string InstallDate;
    [SMS_Report (TRUE) ]
    string Publisher;
    [SMS_Report (TRUE) ]
    string Version;
    [SMS_Report (TRUE) ]
    string SystemComponent;
    [SMS_Report (TRUE) ]
    string ParentDisplayName;
    };

  17. Then find the following directly below:
    class Win32Reg_AddRemovePrograms64 : SMS_Class_Template
    {
    [SMS_Report (TRUE), key ]
    string ProdID;
    [SMS_Report (TRUE) ]
    string DisplayName;
    [SMS_Report (TRUE) ]
    string InstallDate;
    [SMS_Report (TRUE) ]
    string Publisher;
    [SMS_Report (TRUE) ]
    string Version;
    };

    and replace with:
    class Win32Reg_AddRemovePrograms64 : SMS_Class_Template
    {
    [SMS_Report (TRUE), key ]
    string ProdID;
    [SMS_Report (TRUE) ]
    string DisplayName;
    [SMS_Report (TRUE) ]
    string InstallDate;
    [SMS_Report (TRUE) ]
    string Publisher;
    [SMS_Report (TRUE) ]
    string Version;
    [SMS_Report (TRUE) ]
    string SystemComponent;
    [SMS_Report (TRUE) ]
    string ParentDisplayName;
    };
  18. Close and Save c:\data\export.mof
  19. On the Hardware Inventory Classes form select Import
  20. Review the Message to ensure everything is correct, and Select Import.
  21. On the Hardware Inventory Classes form search for Win32reg_addremoveprograms and ensure that SystemComponent & ParentDisplayName are selected, then click on OK, and OK, back to the SCCM Console

To test ensure that you have completed a Policy refresh on a targeted computer, wait a few minutes then trigger a hardware inventory, you can see if the policy has updated by reviewing the InventoryAgent.log on the client computer and filter with CMTrace for Win32reg_addremoveprograms, you should see something like this:

And on the server side you can confirm the new inventory has been loaded by reviewing the DataLdr.log file on the Site server, looking for the line
“Done: Machine=(GUID:) code=0 (1473 stored procs in .MIF)”
to ensure that the data has been loaded into the SQL database.

From here we can create a report using the following example SQL query:
Count of all applications installed on all computers:

SELECT
*
FROM
(

SELECT
DISTINCT

v_GS_ADD_REMOVE_PROGRAMS_64.DisplayName0 AS “Product Name”, v_GS_ADD_REMOVE_PROGRAMS_64.Publisher0 AS “Publisher”,
count(*)
as
‘Install count’

FROM v_GS_ADD_REMOVE_PROGRAMS_64

INNER
JOIN v_R_System_Valid ON v_R_System_Valid.ResourceID = v_GS_ADD_REMOVE_PROGRAMS_64.ResourceID

JOIN v_GS_OPERATING_SYSTEM ON v_GS_ADD_REMOVE_PROGRAMS_64.ResourceID = v_GS_OPERATING_SYSTEM.ResourceID

WHERE v_GS_ADD_REMOVE_PROGRAMS_64.SystemComponent0 is
null
and v_GS_ADD_REMOVE_PROGRAMS_64.parentdisplayname0 is
null
and
not v_GS_ADD_REMOVE_PROGRAMS_64.Displayname0 is
null

group
by v_GS_ADD_REMOVE_PROGRAMS_64.DisplayName0, v_GS_ADD_REMOVE_PROGRAMS_64.Publisher0

UNION ALL

(


SELECT
DISTINCT

v_GS_ADD_REMOVE_PROGRAMS.DisplayName0 AS “Product Name”, v_GS_ADD_REMOVE_PROGRAMS.Publisher0 AS “Publisher”,count(*)
as
‘Install count’


FROM v_GS_ADD_REMOVE_PROGRAMS


INNER
JOIN v_R_System_Valid ON v_R_System_Valid.ResourceID = v_GS_ADD_REMOVE_PROGRAMS.ResourceID


JOIN v_GS_OPERATING_SYSTEM ON v_GS_ADD_REMOVE_PROGRAMS.ResourceID = v_GS_OPERATING_SYSTEM.ResourceID


WHERE v_GS_ADD_REMOVE_PROGRAMS.SystemComponent0 is
null
and v_GS_ADD_REMOVE_PROGRAMS.parentdisplayname0 is
null
and
not v_GS_ADD_REMOVE_PROGRAMS.Displayname0 is
null

    group
by v_GS_ADD_REMOVE_PROGRAMS.DisplayName0, v_GS_ADD_REMOVE_PROGRAMS.Publisher0

))
AS u

ORDER
BY “Product Name”, Publisher

Installed applications on a Single Computer:

DECLARE @compname VARCHAR(MAX) = ‘Computer Name’

SELECT
*
FROM
(

SELECT
DISTINCT

v_GS_ADD_REMOVE_PROGRAMS_64.DisplayName0 AS “Product Name”, v_GS_ADD_REMOVE_PROGRAMS_64.Publisher0 AS “Publisher”, v_GS_ADD_REMOVE_PROGRAMS_64.Version0 AS “Version”

FROM v_GS_ADD_REMOVE_PROGRAMS_64

INNER
JOIN v_R_System_Valid ON v_R_System_Valid.ResourceID = v_GS_ADD_REMOVE_PROGRAMS_64.ResourceID

JOIN v_GS_OPERATING_SYSTEM ON v_GS_ADD_REMOVE_PROGRAMS_64.ResourceID = v_GS_OPERATING_SYSTEM.ResourceID

WHERE v_GS_ADD_REMOVE_PROGRAMS_64.SystemComponent0 is
null
and v_GS_ADD_REMOVE_PROGRAMS_64.parentdisplayname0 is
null
and
not v_GS_ADD_REMOVE_PROGRAMS_64.Displayname0 is
null

and v_R_System_Valid.Netbios_Name0 = @compname

UNION ALL

(


SELECT
DISTINCT

v_GS_ADD_REMOVE_PROGRAMS.DisplayName0 AS “Product Name”, v_GS_ADD_REMOVE_PROGRAMS.Publisher0 AS “Publisher”, v_GS_ADD_REMOVE_PROGRAMS_64.Version0 AS “Version”


FROM v_GS_ADD_REMOVE_PROGRAMS


INNER
JOIN v_R_System_Valid ON v_R_System_Valid.ResourceID = v_GS_ADD_REMOVE_PROGRAMS.ResourceID


JOIN v_GS_OPERATING_SYSTEM ON v_GS_ADD_REMOVE_PROGRAMS.ResourceID = v_GS_OPERATING_SYSTEM.ResourceID


WHERE v_GS_ADD_REMOVE_PROGRAMS.SystemComponent0 is
null
and v_GS_ADD_REMOVE_PROGRAMS.parentdisplayname0 is
null
and
not v_GS_ADD_REMOVE_PROGRAMS.Displayname0 is
null

and v_R_System_Valid.Netbios_Name0 = @compname

))
AS u

ORDER
BY “Product Name”, Publisher

You will notice that we are not using the “v_add_remove_programs” view, this appears to be a derived view which doesn’t appear to be updated when new columns added to the Class, but we can get around this by using the Union function in SQL.

Good Luck

Steve

Troubleshooting like a Boss (not a real Boss tho)

Troubleshooting like a Boss (not a real Boss tho)

Recently I have been doing some informal training sessions with some junior staff members and realised that there is quite a few things we do in the this industry that can be very hard to pick up without prompting from the guys that have been around for a while. As such I figured I would take a few hours and detail some of the processes I use to troubleshoot issues.

From a troubleshooting point of view, let’s review a scenario that recently I have been involved in resolving.

Scenario:

When logging on to a computer post ADMT on a few computers we were receiving the follow error message when attempting to log onto the computer with an account that hadn’t previously logged onto the computer:

User Profile Service Service Failed the logon. User Profile cannot be loaded

When this came to me there had already been 2 tech’s looking into this error, and were blaming it on the Domain migration, we could log onto the machine as Local administrator and I could connect remotely to it via the SCCM 2012 Remote tools.

Trouble Shooting Steps:

The first steps to investigate this issue would be to start in the event log, I know it sounds daunting to look in the event log it’s huge and there is so much information in there, which is exactly why this is perfect for the task at hand.

We looked in the Security event log and there was no issues with the computer or the user authenticating, right away at a high level we can start ruling out the ADMT component of the changes to the system, as there would be authentication issues between the machine and the domain if there was.

We then moved to the Application event log and right away we started seeing warning events like this every time a new user attempts to logon:

Windows cannot copy file C:\Users\Default\AppData\Local\Microsoft\Windows Live\SqmApi\SqmData720896_00.sqm to location C:\Users\Guest\AppData\Local\Microsoft\Windows Live\SqmApi\SqmData720896_00.sqm. This error may be caused by network problems or insufficient security rights.

DETAIL – Access is denied.

And:

Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off

And:

Windows cannot copy file C:\Users\Default\AppData\Local\Microsoft\Windows Live\SqmApi\SqmData720896_00.sqm to location C:\Users\TEMP\AppData\Local\Microsoft\Windows Live\SqmApi\SqmData720896_00.sqm. This error may be caused by network problems or insufficient security rights.

DETAIL – Access is denied.

And:

Windows cannot log you on because your profile cannot be loaded. Check that you are connected to the network, and that your network is functioning correctly.

DETAIL – Only part of a ReadProcessMemory or WriteProcessMemory request was completed.

So we browse to “C:\Users\Default\AppData\Local\Microsoft\Windows Live\SqmApi” and sure enough when we looked at the permissions on SqmData720896_00.sqm we found that the user’s security group didn’t have access to the file thus it was causing the User Profile Service to fail as it couldn’t copy this file into the new user profile nor the Temp profile. Once the permissions we replicated from the parent folder the issue was resolved. I know it sounds simple when you see it like this, but this whole troubleshooting took around 20-30 minutes, with much searching around the internet and discussion with the techs on site to find out the extent of the issue and alike, and keeping them informed throughout the trouble shooting phase.

Wrap up:

The biggest piece of advice I can provide anybody just starting out and wanting to impress around there troubleshooting ability, is to use the KISS method,

K eep

I t

S imple

S tupid

Always think that the simplest answer is the correct one, this methodology can be used for creating the fix for the issue, if it’s for the issue above where it was impacting lest than 5 users it doesn’t make sense to script or even automate the issue, this is something that you hand the solution back to the support teams with the comment if you see this issue check this event message and confirm it is the exact issue then run the remediation steps. If this issue was impacting a large percentage of my fleet I would look at creating a fix to remediate it proactively, be it with a simple Group Policy as this one could be covered with, or a compliance setting from SCCM it can be automated if need be.

In the heat of an issue it can be very hard to keep calm especially when you need to be able to quickly and confidently rule out idea even if everybody else working on the issue keeps pointing at that being the issue, I recommend setting your IM to Busy or Do Not Disturb so only the people you can control the flow of information coming in, let’s face it being told for the 10th time that there are users unable to logon to their computers gets a bit grating when you are trying to focus on how you are going to resolve the issue, in saying that being able to bounce ideas of co-workers is just as invaluable as they might have made a change to the system or alike that you are not aware of.

The next thing to start looking at is the log files be it the event log or application specific logs, now days most good applications log almost everything, this is where you will find out more information about the goings on of your system then randomly clicking around the OS to try to just resolve the issue like a lot of admins now days do so often, with the goal of, I just have to fix the issue and if I try this it might fix the problem. In some cases you can resolve or at least Band-Aid a solution by doing this, but it normally takes a lot longer to come to the root cause and in most cases you don’t know the root cause as you have just found the fix and moved on to the next fire. I can’t say that logs will provide the answer for everything problem but it is a fantastic place to start.

Another simple thing you can do if the machine is blue screen is to get the Debug tool kit from Microsoft for you OS and run the dump check application over the memory.dmp/mini.dmp file which typically will return the offending component of the OS just confirm dates before you do it as it might have been from a blue screen 2 weeks/months/years earlier.

I know a lot of what I’m saying is common sense to most of us but the number of people I deal with now days that gloss over these troubleshooting steps it staggering, the other thing that makes a great troubleshooter is somebody who has the confidence to sit there and state their case and back it up, there is no point working out the problem, then raising the ticket to a senior resource without a hand over because you are not quite sure about the answer. The senior resources have typically made it to those roles because they have back themselves and ask the right questions to build trust with the management teams.

Good Luck and Happy trouble shooting,

Steve

Why could SCCM Compliance Settings replace Group Policy?

Why could SCCM Compliance Settings replace Group Policy?

My hope with this post is to plant an idea in your mind on what could be done with SCCM Compliance Settings over using Group Policy. Let’s start off with an over view of the 2 options we will be discussing today.

Group Policy (GPO)

You can trace Group Policy all the way back to the first version of Active Directory in Windows Server 2000, the use of ADM files can be traced back even further into NT4, and windows 95/98 using the System Policy Editor which was part of the NT 4.0 Resource Kit which you can download here for those of you still using NT as your domain. Don’t get me wrong along the way Microsoft has added more features into Group Policy, for example Group Policy Preferences which was part of the acquisitions of Desktop Standard in 2006 originally called PolicyMaker. This alone has made group policy quite a powerful tool since Server 2008, the centralisation of the task like Printer and Drive Mapping which previously the easiest way to deploy these settings was Logon Script. The addition of the Advance Group Policy Management tool in the MDOP was great for those large companies which had SA and then also know about it, and admins didn’t know a password for a domain admin account, but a step in a very good direction none the less. Let’s face it most vendors that are doing large-scale deployments provide ADM/x files to configure the application as it still is a very easy way to empower the admins.

One of my biggest gripes with Group Policy was very noticeable in Windows XP, and less so in the new Windows Versions is that it is a set and hope solution, what I mean by this is that if I define a policy to my whole fleet without completing a process which is not out of the box I have to hope that the settings have applied, and typically I find out a month later when somebody raises the issue that was meant to be resolved.

Compliance Settings

Much like Group Policy you can trace Compliance Settings back a few generations of SCCM/SMS, to SMS 2003 to be precise. I have to on good authority it was originally created to confirm that exchanges servers in a large company had the same settings as each other. In 2003 the feature was called Desired Configuration Monitoring it was very much a passive process of collecting information, from which you could pull a report from. In SCCM 2007 this feature was renamed to Desired Configuration Management, and improved slightly it was included as a component that ran under ccmexec, it was converted to XML files stored on the client computer rather than WMI Classes which were returned with Hardware Inventory. Again it was very much a passive reporting feature which required manual steps to remediate the problems, and in large environments it gave you some where to start. Then Microsoft moved to SCCM 2012 and like a good deal of the product this component was given a comprehensive overhaul, along with the Compliance Settings moniker. As part of the overhaul a few new options were added, such as Remediation, a larger range of detection types (AD, Registry Keys, Scripts, SQL/WQL queries to name a few), and the ability to create a Collection from each deployment dependent on the status message.

Until SCCM 2012 I didn’t see a huge use for DCM as I was managing sites of around the 5000 seat mark, which is just on the cusp of needing to have everything repeatable. But with SCCM 2012 I can see great potential for Compliance Settings to replace large parts of Group Policy Objects which will not only allow for the reporting of settings, but ideally reduce the logon/startup time for our computers. In addition to this it has the ability for staff to run the evaluation independent of the schedule & create a local report without using the commandline. One of the downsides is this is equivalent to a local group policy setting, which is trumped by the Domain Group Policy, so it is one or the other for each of the defined settings.

Demo

Group Policy

So let’s for example say you work for a company which wants to annoy your staff by defining a standard wallpaper for all staff.

So in Group Policy we would create a new Group Policy Object, and define the following setting:

To point to in this example c:\windows\demo.jpg and defined to be centered.

We then assign it to the desired OU and it’s deployed.

Then you get the staff that have managed to convince the people of power, that to complete their work they must have local admin access to the work computer, you know the type that install “freeware” software for Business purposes and deny it when you approach them for a licence key. These guys are super smart and work out that they can change the wallpaper by making a regkey change, or replacing a file. As stated above there is no way out of the box to report on this, so you get questions from your managers as to why these guys have different wallpapers and the inevitable how can I change theirs for them.

dcm1

SCCM Compliance Settings

So with SCCM to define this we first need to get the RegKey that is being defined as part of the Group Policy Setting, for something like Desktop Wallpaper you can google Bing it and some bright spark will have published it, like this: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System Wallpaper – REG_SZ WallpaperStyle – REG_SZ

For the more complicated settings if they are default Windows polices you can download excel files which detail each policy and the regkey that is set from here and for Office products you can find the link here.

We now have the registry key for our new Configuration Item in SCCM 2012 to create this we need to open the SCCM 2012 Console and navigate to Assets and Compliance, Compliance Settings, Configuration Items.

From here we can select the Create Configuration Item task from the Ribbon

dcm2

On the Create Configuration Item Wizard form enter a descriptive name something like

U – Desktop Wallpaper which represents that we are defining a user setting for the desktop wallpaper, in addition to this I would recommend put a brief blurb in the Description box as you will be wondering why you created the item 6 months later.

The other part you need to make sure is that if you are defining a registry key that the settings applies to the operating systems which you are targeting on the Supported Platform page.

When we get to the point of creating a new Setting this is where we can define multiple settings that must be met, for example a scripted item to confirm the wallpaper file hasn’t been changed, and a registry value to ensure that the registry key hasn’t been changed.

Something like this for the registry key item:

dcm3

We can then create compliance rules around the setting, which is where we can set it to report on if a certain value exists, and that it meets a defined task. In this example we want Wallpaper to equal “C:\windows\demo.jpg” in addition to reporting on if the systems are compliant, we can also remediate the setting where desired, in this case we do want to remediate the setting as shown below:

dcm4

We have now created the Compliance Item which we can deploy to our users/computers with a configuration baseline. Again use a descriptive name, so for this demo we will use U – Desktop Wallpaper and add the Configuration Item that we created earlier.

dcm5

We then deploy this to our desired collections, and this is where we can create multiple deployments one which will remediate the setting, and the other to only report on it, along with how often we want the evaluation to run on the computers.

dcm6

On the client side your users will see the following tab in the Configuration Manager Client in the control panel.

dcm7

As you can see you have ability to evaluate each of the Assigned baselines, along with providing a local report of the compliance of the baseline.

Good Luck

Steve