in

myITforum.com

Windows Management Experts at myITforum.com

October 2011 - Posts

  • Example of Hardware Inventory Customization in SCCM

    System Center Configuration Manager (SCCM) gathers lots of data from workstations and places it in the SCCM database. You can use this data to more intelligently manage your systems. For example, you can deploy a specific software product only to systems that don’t have it installed. Or you can obtain a report regarding software installed on systems and whether it is being used or not. This information is useful to assist you with licensing compliance.

    Sometimes, administrators need to get some information from systems that is not gathered by SCCM. For example, an in-house developed application creates an entry in the registry, and the administrator needs to know what systems have it enabled or set to a specific value. SCCM has a process called “hardware inventory extension” that allows you to send your custom data to the SCCM database. Getting custom data from the registry or WMI is fairly straight-forward as there is a registry provider and a WMI provider that allow you query for data.

    In this article, we provide information on how to get the systems to send information of a specific event. This solution was put together from an actual need by administrators to determine what Active Directory (AD) group policies the machines were applying. When the systems refresh their machine policies, they log a trace event in the Group Policy trace event. Trace events are different than the standard Windows event logs. Below you can see that trace events are in a different node in event viewer: Applications and Services.

    clip_image001

    Events from standard Windows logs can be easily obtained by querying WMI but not Trace events. Part of this solution involves getting the trace events and putting them into WMI. Then the WMI provider is used to get the data into SCCM.

    A powershell script was created to get the events into WMI. The script first creates a custom WMI class to define the type of data that will be stored in WMI. Then it gets the specific events (Group Policy event 5312) that have been logged in the last three days. The data from these events is recorded into WMI.

    This is a sample of the information that event 5312 provides:

    clip_image002

    Sometimes the event indicates that no group policy was applied. The reason is out of the scope of this article but our solution will concentrate on obtaining the group policy objects that get applied.

    clip_image003

    This is the powershell script that gets the last events 5312 that were logged and puts them into a custom WMI class. Every event that gets recorded into WMI is called an instance of our class. When the script runs, it first deletes any existing instances before adding the new instances of the events logged in the last three days. This is so we don’t have new instances appended to old ones when the script runs.

    clip_image005

    clip_image007

    The script, called in this example event5312toWmi.ps1, has three functions, which are hi-lited. The first line of the EventsToWMI function has the following at the end: “days 3”. This is what determines how many days back from the time the script runs, to gather the events. You can change this number to any number of days that fits your needs.

    The AddInstance function starts by defining that the data collected consists of a field of type Date, and another field of type Text.

    The createClass function creates a custom class in the root\cimv2 WMI namespace called Russell_Event_5312. The fourth line indicates that the SMS_Group_Name is Event_5312. This is the group name that will be used in SCCM.

    Now we need to let SCCM know that it needs to get our custom data from WMI on each machine into the SCCM database. We do this by modifying two configuration files that tell SCCM what data to collect: configuration.mof and sms_def.mof. These files are in the following directory:

    <SCCM_install_dir>\inboxes\clifiles.src\hinv

    Add the following at the end of the configuration.mof file:

    #pragma namespace ("\\\\.\\root\\cimv2")

    [Union,ViewSources{"select TimeCreated, GPOList from Russell_Event_5312"},ViewSpaces{"\\\\.\\root\\cimv2"}, dynamic,Provider("MS_VIEW_INSTANCE_PROVIDER")]

    Class Russell_Event_5312

    {

    [PropertySources{"TimeCreated"},key]

    datetime TimeCreated;

    [PropertySources{"GPOList"}]

    string GPOList;

    };

    Add the following to the end of the SMS_DEF.mof file:

    [ SMS_Report (TRUE),

    SMS_Group_Name("Event_5312"),

    SMS_Class_ID ("WME|TraceEvent_5312|1.0") ]

    class Russell_Event_5312 : SMS_Class_Template

    {

    [SMS_Report(TRUE),key]

    datetime TimeCreated;

    [SMS_Report(TRUE)]

    string GPOList;

    };

    When you add the above information to the MOF files, SCCM will compile the new instructions, the dataldr.log SCCM log (in <SCCM_Install_Dir>\Logs) will immediately log “SMS_DEF.Mof change detected” or “Configuration.Mof change detected”. It will then log any errors if the compilation failed, or it will log “end of cimv2\sms-to-policy conversion; returning 0x0” if the compilation was successful and no error was detected.

    After a successful compilation of the MOF changes, the next time client systems obtain policies from the Management Point, they will be instructed to report the custom data, and SCCM will be ready to receive it.

    Now we need to find a way for the systems to run the powershell script at a regular basis. Since we have SCCM, we’ll have SCCM do it for us. We create an SCCM package that contains two files: the powershell script, and a batch or cmd file to call the script. In this example, we create a file called runEvent5312toWMI.cmd containing one line:

    powershell.exe -NoLogo -ExecutionPolicy RemoteSigned %~dp0event5312toWmi.ps1 > c:\Event5312toWmi.log

     

    The command line in the .cmd file runs the powershell script and sends the output to c:\Event5312toWmi.log in case you need to troubleshoot the execution of the script.

    The program in the SCCM package will just call the .cmd file.

    clip_image008

    You can advertise the program to a collection or collections of systems that you want to obtain this custom data from, and you can set the advertisement in a recurrent schedule to keep the data in SCCM current. For example, you can run the script once a day. Clients will get the data from WMI and send it to SCCM as frequently as the hardware inventory agent is configured to do so.

    Once the data makes it to SCCM, you can look at Resource Explorer in SCCM for one machine to see the data.

    clip_image009

    clip_image010

    Finally, you can create some custom reports in SCCM to analyze the custom data in the SCCM database. You can use the following queries to create SCCM reports.

    All events 5312 for specified machine excluding events with “None” as applied GPO

    select sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, Event.TimeCreated00 AS "Time Created", Event.GPOList00 AS "GPO List" from v_R_System sys join dbo.Event_5312_DATA Event on sys.ResourceID=Event.MachineID WHERE sys.Netbios_Name0 = @ComputerName AND Event.GPOList00 <> 'None' order by Event.TimeCreated00 DESC

    prompt: ComputerName

    begin

    if (@__filterwildcard = '')

    SELECT DISTINCT SYS.Netbios_Name0 from v_R_System SYS WHERE SYS.Client0=1 ORDER By SYS.Netbios_Name0

    else

      SELECT DISTINCT SYS.Netbios_Name0 from v_R_System SYS WHERE SYS.Client0=1

      and SYS.Netbios_Name0 like @__filterwildcard

      ORDER By SYS.Netbios_Name0

    end

    Information for the last event 5312 on machines in collection excluding "none" for applied GPO

    select sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, MAX(Event.TimeCreated00) AS "Time Created", Event.GPOList00 AS "GPO List" from v_R_System sys join dbo.Event_5312_DATA Event on sys.ResourceID=Event.MachineID JOIN v_FullCollectionMembership FCM ON SYS.ResourceID = FCM.ResourceID WHERE FCM.CollectionID = @CollectionID AND Event.GPOList00 <> 'None' group by sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, Event.GPOList00 order by sys.Netbios_Name0 DESC

    Prompt CollectionID

    begin

    if (@__filterwildcard = '')

      select v_Collection.CollectionID, v_Collection.Name from v_Collection order by v_Collection.Name

    else

      select v_Collection.CollectionID, v_Collection.Name from v_Collection

      WHERE v_Collection.CollectionID like @__filterwildcard

      order by v_Collection.Name

    end

    Machines in collection that have "Baseline-Computer-Workstations" listed in last Event 5312 excluding "None" applied

    select sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, MAX(Event.TimeCreated00) AS "Time Created", Event.GPOList00 AS "GPO List" from v_R_System sys join dbo.Event_5312_DATA Event on sys.ResourceID=Event.MachineID JOIN v_FullCollectionMembership FCM ON SYS.ResourceID = FCM.ResourceID WHERE FCM.CollectionID = @CollectionID AND Event.GPOList00 <> 'None' AND Event.GPOList00 LIKE '%Baseline-Computer-Workstations%' group by sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, Event.GPOList00 order by sys.Netbios_Name0 DESC

    Prompt CollectionID

    begin

    if (@__filterwildcard = '')

      select v_Collection.CollectionID, v_Collection.Name from v_Collection order by v_Collection.Name

    else

      select v_Collection.CollectionID, v_Collection.Name from v_Collection

      WHERE v_Collection.CollectionID like @__filterwildcard

      order by v_Collection.Name

    end

    Machines that don't have "Baseline-Computer-Workstations" listed in the last Event 5312 excluding "None" applied

    select sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, MAX(Event.TimeCreated00) AS "Time Created", Event.GPOList00 AS "GPO List" from v_R_System sys join dbo.Event_5312_DATA Event on sys.ResourceID=Event.MachineID join v_FullCollectionMembership FCM ON SYS.ResourceID = FCM.ResourceID WHERE FCM.CollectionID = @CollectionID AND Event.GPOList00 <> 'None'AND SYS.ResourceID NOT IN (SELECT sys.ResourceID FROM v_R_System SYS join dbo.Event_5312_DATA Event on sys.ResourceID=Event.MachineID JOIN v_FullCollectionMembership FCM ON SYS.ResourceID = FCM.ResourceID WHERE FCM.CollectionID = @CollectionID AND Event.GPOList00 <> 'None' AND Event.GPOList00 LIKE '%Baseline-Computer-Workstations%') group by sys.Netbios_Name0, sys.Resource_Domain_OR_Workgr0, Event.GPOList00 order by sys.Netbios_Name0 DESC

    Prompt CollectionID

    begin

    if (@__filterwildcard = '')

      select v_Collection.CollectionID, v_Collection.Name from v_Collection order by v_Collection.Name

    else

      select v_Collection.CollectionID, v_Collection.Name from v_Collection

      WHERE v_Collection.CollectionID like @__filterwildcard

      order by v_Collection.Name

    end

  • Best Practices for Managing VDI Clients with SCCM

     

    If your company relies on a Virtualized Desktop Infrastructure to manage client systems, you may have many –perhaps hundreds—of desktop virtual machines running on one or a few servers. Users connect to these virtual machines remotely using a remote desktop protocol to access and work on their virtual desktops. The user’s virtual desktops have to be managed, just like any other physical desktops. One way to efficiently manage the virtual desktops is to use System Center Configuration Manager (SCCM) 2007.

    The SCCM client can manage the Windows operating system (OS) running on the virtual desktop just the same way as it manages the operating system running on a physical desktop. You can deploy the SCCM client to the virtual desktops using any of the deployment methods, such as the SCCM client push. The SCCM client can also be included in the master image used to provision new virtual desktops. If the SCCM client is to be included in the master image, ensure that it is prepared to be part of a master image before you capture the reference machine to become the master image. If this process is followed, when new virtual machines (VMs) are provisioned from a master image (or VM template), the SCCM client on the newly provisioned VM will create a unique SCCM client GUID. If the process is not followed, then all systems provisioned from the same template will have the same SCCM client GUID, leading to a duplicate GUIDs problem in SCCM.

     

    Avoiding VDI Performance Issues

    In a VDI, all desktop operating systems and applications are stored on a server or group of servers. The operating systems and applications also run on them. This means that the workload is on the servers. A well designed VDI infrastructure has sufficient resources to host the needed virtual desktops. It is possible, however, for the virtual desktops to overload the VDI resources if they all perform an activity at exactly the same time. The activity itself may not be resource intensive, but if the amount of the consumed resources is multiplied by hundreds of virtual desktops, then it may negatively affect the performance of your VDI. This situation may occur if all the virtual desktops perform an SCCM hardware or software inventory cycle at the same time.

    The hardware and software inventory client agents collect inventory according to a schedule that is configured on their assigned SCCM site server. Once the inventory data is gathered, it is sent to the site server. Software inventory is more resource intensive than hardware inventory. As a best practice, consider scheduling software inventory to recur less frequently than hardware inventory. The schedule can be configured to be a Simple Schedule, where you indicate how often it is performed (i.e. every 24 hours, every 7 days), or a Custom Schedule, where you configure a start time and interval. If a custom schedule is used on a site, then all of your SCCM clients assigned to that site will perform inventory activities at the same time. As a best VDI practice, do not configure a custom schedule.

    It seems then that it is best practice for a VDI environment to use a simple schedule for hardware inventory activities. Unfortunately, this may not be the case if your virtual desktops are provisioned from one or a few master images that include the SCCM client. This is because the simple schedule would be based on the installation time in which the SCCM client was installed on the reference image that was captured to obtain the master image. The SCCM client installation time would be the same on all virtual desktops provisioned from the same master image. In a physical environment, as machines are turned off for a time period longer than the one specified in the simple schedule, their simple schedule reporting time will change if they are powered back on after the simple schedule period, as they would need to perform the inventory activity right away. However, this may not occur much in a VDI environment.

    If you are using a simple schedule for your hardware and software inventory cycles and are having performance issues with your VDI resources at specific times, check the InventoryAgent.log file on virtual desktop systems to see if they are performing inventory activities at the same time in which your VDI environment experiences performance problems. If you verify that this is happening, you can attempt to change the simple schedule reporting time by at different times forcing different groups of clients to report inventory. For example, if most systems are performing inventory activities at 4 pm every day (their custom schedule is every 24 hours), you can force a group of systems to perform an inventory scan at 5 pm, other systems at 6 pm, and so on. Then, these different group of systems will perform the scans again 24 hours later (5 pm, 6 pm, etc.). One way to force systems to perform an inventory scan is by using a script that you could execute using SCCM software distribution, logon scripts, etc. This is one script that can be used:

    Switchable SCCM forced inventory

    As a best practice, do not include the SCCM client in the master image for VDI environments. You can install the SCCM client afterwards using any of the supported client installation methods.

    SCCM Client GUIDs

    A new and unique SCCM client GUID should be generated when the SCCM client starts on a new system or if hardware has changed on the system where it is running. As part of managing a VDI environment, administrators sometimes need to make changes to a VM or replace it with another one while keeping the same computer name. Any operation that causes the machine’s Hardware ID to change will result on duplicate non-obsolete computer objects in the SCCM database as a new SCCM Client ID is generated (an example of an operation that changes the Hardware ID is VMware’s recomposing or powering a VM off from the console). As a best practice, avoid performing any activity that will change the VM’s Hardware ID (or Machine ID). If you must perform these activities, then modify your business process for the activity so part of the procedure is to delete the computer object from the SCCM database prior to the new computer object coming online.

    If you already have duplicate non-obsolete computer objects in the SCCM database, you can manually delete the original records (these are the ones that have not reported to SCCM since the new record was created). You can create a report based on the last hardware scan of the systems. If enabled, you can also let the “Delete Inactive Client Discovery Data” task delete the duplicate computer objects automatically over time.

    Note: If the Hardware ID has not changed when the new SCCM Client GUID is generated, then by default the original record will be marked as obsolete, and it will be deleted according to the maintenance task that deletes obsolete records if enabled).

    SCCM Client Inventory Data

    The SCCM client periodically sends changes (deltas) of hardware and software inventory (if enabled) to its site server. In the event that a VM is powered off without saving its state, it is possible that the SCCM client had sent new inventory changes to the site server during the time in which its state was lost. When the VM is powered back on and sends delta changes, the site server will determine that the inventory data is not synchronized and will force the SCCM client to send a full inventory (not just the Deltas). As a best practice, do not turn VMs off without saving their state so potential performance issues caused by full inventory synchronization are avoided.

  • SCCM USMT Migration Fails in a Refresh Scenario Involving Windows 7 SP1

    System Center Configuration Manager (SCCM) 2007 generates certificates for the SCCM clients to communicate securely with SCCM site servers. One of the properties of a certificate is the Friendly Name. The SCCM certificates have contained a NULL character in the Friendly Name, and this hasn’t been a problem in the past. This changed, however, with the release of security update 974571 from Microsoft:

    MS09-056: Vulnerabilities in CryptoAPI could allow spoofing

    For security reasons, this security update prevents importing certificates that contain a NULL character in the Friendly Name property.

    As part of SCCM Operating System Deployments that use USMT (User State Migration Tool) to migrate state data in refresh or replace scenarios, the SCCM client certificates have to be migrated from the source operating system (OS) to the target OS. If the source or target OS has security update 974571 installed, then the USMT migration will fail.

    Service Pack 1 (SP1) for Windows 7 includes security update 974571. Due to this, when the source or target OS is Windows 7 with SP1, the USMT migration will fail during USMT operations. USMT will also fail during capture of state data on the source OS if the source OS is Windows XP or Windows Vista with security update 974571.

    To avoid this problem, Microsoft has provided hotfix 977203:

    User state migration is unsuccessful on an ConfigMgr 2007 SP1 or SP 2 client after you install security update 974571 or Windows 7 SP1

    Hotfix 977203 needs to be installed on all SCCM site servers and on all SCCM clients so they stop generating certificates with a NULL character in the Friendly Name property. The hotfix also includes a tool, ccmcertfix.exe, that will remove the NULL character in the Friendly Name from the SCCM certificates on systems that already have them.

    When you install the hotfix on a site server, the ccmcertfix.exe tool is extracted to the following directory:

    ConfigMgr_2007_Installation_Directory\Logs\KB977203

    However, if the hotfix can’t be installed on a site server or SCCM client because it is not applicable, then you would have to manually extract the hotfix files to obtain the ccmcertfix.exe tool. One reason for hotfix 977203 not to be applicable is that hotfix 977384 is installed on the site server. Hotfix 977384 supersedes hotrfix 977203. Hotfix 977384 includes hotfix 977203. This is the error that you may get if the hotfix isn’t applicable.

    49

    Even if hotfix 977203 isn’t applicable (because hotfix 977203 or 977384 is already installed), the current certificates on SCCM clients still need to be fixed using the ccmcertfix.exe tool.

    Extracting the hotfix files

    The hotfix .exe file that you download from Microsoft is really a compressed file. When you execute it, it extracts the actual .exe hotfix file. You extract the files from this hotfix file by executing it with the /x parameter as in the following example.

    SCCM2007-SP1-KB977203-X64-ENU.exe /x

    You then specify where you want to extract the files.

    50

    This is a partial list of the extracted files.

    51

    The article for hotfix 977203 provides details on how to install the hotfix via SCCM software distribution or via a Task Sequence. It also explains how to run the ccmcertfix.exe tool during refresh and replace OSD scenarios by using your deployment task sequences.

Copyright - www.myITforum.com, Inc. - 2010 All Rights reserved.
Powered by Community Server (Commercial Edition), by Telligent Systems