System Center Configuration Manager (SCCM) 2012 enhances software deployment over SCCM 2007 by allowing SCCM administrators to delegate control to end users on what software gets installed on their systems or devices and when it gets installed. Microsoft has taken into account a trend in which end-users are using devices such as cell phones in addition of desktops and notebooks. Also, users now tend to be more technology-savvy and have expectations to be able to use the software that they need to do their jobs on any device and at any time.
SCCM 2012 introduces the concept of an Application. Think of an application as a high-level definition of software that has intelligence to determine if the user has been authorized to use it on a particular device, how it should be made available to the user on that specific device, and if that device has the capability of running the application for the user.
Applications are made up of the following:
- Deployment Type(s) – installer technology or way in which the software is delivered to the user
- Requirement Rules – Properties per deployment type of users and/or devices that make delivering software appropriate and evaluated by the SCCM client in real time
- Dependencies – other deployment types that must be present before delivery of application
- Detection Method – Enable systems to determine if an application is already present
- Install Command – What command to run
- Content – Files that comprise the application
To deliver the software to the user, the SCCM administrator creates a deployment. A deployment is what an Advertisement is in SCCM 2007. The deployment captures the administrator’s intent by having two deployment purposes: Required and Available. Required compares to a mandatory assignment of an advertisement in SCCM 2007; Available compares to an optional advertisement. The deployment also has two types of actions: Install and Uninstall.
Note: In SCCM 2012 you can still use the Packages and Programs present in SCCM 2007 but you won’t have access to the intelligence built into Applications.
For applications that are not forced on the user devices –those with a deployment purpose of Available, SCCM 2012 offers a user-friendly web portal called Application Catalog, where the user can browse and install applications that are available to her (optionally the application may require approval from an administrator first). If the Available deployment purpose targets a device instead of a user, then the application can be installed from Software Center, which is a local application on the client that replaces “Run Advertised Programs” present in the SCCM 2007 client.
One of the key features that Microsoft provides to make User Centric Software Distribution possible is User Device Affinity (UAC). UAC provides the ability to identify a relationship between a user and a device. This allows complex software deployment scenarios such as where an application should be installed only on a user’s primary device but still make the application available to the user on other devices via other deployment types.
An example of a complex software deployment –but simple to configure for the SCCM administrator, is when the user is using her primary device and wants to use Word 2010. If not installed, the user can go to the Application Catalog and install it locally on the primary device (i.e. a desktop in the corporate network). The following week the user logs-in to someone else’s desktop in the corporate network and needs to use Word 2010 but it isn’t installed. The user then goes to Application Catalog and selects to install the software. However, because of the intelligence built into the Application by the SCCM administrator, Word 2010 is delivered to the user via App-V. The user then uses her Windows Phone and wants to use Word. The user goes to the Application Catalog to install it, and Word Mobile is delivered to her phone using the Windows Mobile Cabinet deployment type.
User Device Affinity supports the following relationships in SCCM 2012
- Single primary user to primary device
- Multiple primary devices per user
- Multiple primary users per device
Note: SCCM 2012 allows these relationships to be defined by the SCCM administrator and by the end user.
In conclusion, SCCM 2012 has made it easy for the SCCM administrator to empower users to use the software they need to perform their job at any time and on any supported device.
Many times when deploying an operating system using SCCM, the task sequence fails on the client. Most of the time, the error presented on the screen does not provide sufficient information to determine what’s failing. This is when you need to look at the logs created by the deployment.
If you have enabled command support on your boot image, you can press F8 if the task sequence failed while in Windows PE to gain access to a command prompt. You enable command support in the Windows PE tab of the boot image properties.
Once at the command prompt, you can look for log files. Their location may be tricky as they move around as the deployment progresses. For example, the smsts.log file is
- At x:\windows\temp\smstslog in Windows PE before the hard disk is formatted (x: is a RAM drive)
- At x:\smstslog after the disk is formatted
- At c:\_SMSTaskSequence\Logs\SMStslog after the disk is formatted
Another important log to analyze is the bdd.log. This log contains a summarized view of all other MDT log files. If it is difficult in your particular scenario to have access to the target machine to press F8 and gain access to a command prompt while in Windows PE, the machine will restart and the logs will be gone. Although it is possible to configure your deployment so the log files are copied to a network share when the task sequence completes, sometimes a failure may prevent the task sequence from reaching the step at the end with instructions to copy the files. The following entry in your CustomSettings.ini file will copy the logs to the specified share.
SLShare=\\<serverName>\<shareName>\%OSDComputerName%
In this case, the logs will be copied to a folder in the share named after the target computer name.
When working a difficult issue with your deployment, it may be necessary to enable real time logging over the network. If you add the instruction below to your CustomSettings.ini file, real time logging is performed on the bdd.log file on the specified share location, in addition of logging on the target computer locally. If you open the file with the Configuration Manager Toolkit utility trace32.exe, you can view the entries being added to the log.
SLShareDynamicLogging=\\<serverName>\<shareName>\%OSDComputerName%
Once you have fixed your challenging issue, disable this dynamic logging over the network. There’s a substantial amount of network traffic generated as every line logged requires the file to be open, the line to be written to it, and the file to be closed.
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.

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 file.
This is a partial list if the extracted files.
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.
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

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:

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.

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.
 
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 type Date, and another field of type Text.
The createClass function creates a custom class in the root\cimv2 WMI namespace 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 SCMM.
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:

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

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 0×0” 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.

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 SCCM, you can look at Resource Explorer in SCCM for one machine to see the data.
 
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 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 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
To deploy software you normally put some computers on a collection and then target the software to it. Sometimes you need to deploy a particular application to any system that doesn’t have it now or in the future (perhaps for compliance reasons). One efficient way to accomplish this in SCCM is to create a dynamic collection that has as members all the systems that are missing this particular application. Then you can advertise the appropriate SCCM program to the collection so the application gets installed on them.
If you configure the collection to update on a schedule (for example every 1 day), the next time the collection membership is evaluated, the systems that received your advertisement, installed the application and afterwards reported hardware inventory to SCCM, will automatically leave the collection. Likewise, new systems detected as not having the application will become members of the collection and be targeted.
As long as the advertisement does not expire, it will continue targeting the collection and installing the application only on the systems that are missing it.
To demonstrate this, we’ll create a collection with systems that are missing Forefront Endpoint Protection 2010 (FEP 2010) based on the data reported by a system in Add/Remove Programs. Here we can see the application displayed in Add/Remove Programs.

When creating the collection, make sure that you enable “Update this collection on a schedule” and select the appropriate frequency. To create a query-based rule click on the database symbol (marked with a red circle below).

Next click on “Edit Query Statement”

Then click on “Show Query Language”

And here’s where we’ll enter our SQL Query.

To start working on our SQL query, let’s first create a query that pulls all systems that report having FEP 2010 installed in Add/Remove Programs.
select
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_ADD_REMOVE
_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.
ResourceId join SMS_G_System_ADD_REMOVE_PROGRAMS_64 on SMS_G_System_
ADD_REMOVE_PROGRAMS_64.ResourceID = SMS_R_System.ResourceId where
(SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName LIKE "%Forefront Endpoint
Protection 2010%" or SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName
LIKE "%Forefront Endpoint Protection 2010%")
An important comment about this query is that it queries both Add/Remove Programs tables. One for x32 and one for x64 as there are separate storage locations for each platform. It also uses the LIKE operator so we don’t have to enter the exact name as it appears in Add/Remove Programs in control panel (as the name displayed in Add/Remove Programs in Control Panel may vary on different systems). This is why we use the percent signs wrapping the name, meaning that the actual name in Add/Remove Programs in Control Panel may have more data before “Forefront” and more data after “2010”. You can replace the application name in red with any application that you are interested in deploying using this method (make sure that you first see how it appears in Add/Remove Programs in Control Panel on a system that has it installed).
Now we’ll use the query above as a sub-query. We’ll create a query that says give me all systems that are NOT IN the result from the query above. This will give us all the systems that are not reporting FEP 2010 installed in Add/Remove Programs to SCCM.
select
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_SYSTEM.ResourceID not
in (select SMS_R_SYSTEM.ResourceID from SMS_R_System inner join SMS_G_
System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID
= SMS_R_System.ResourceId join SMS_G_System_ADD_REMOVE_PROGRAMS_64 on SMS
_G_System_ADD_REMOVE_PROGRAMS_64.ResourceID = SMS_R_System.ResourceId where
(SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName LIKE "%Forefront Endpoint
Protection 2010%" or SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName LIKE
"%Forefront Endpoint Protection 2010%"))
This query will pull all systems that are not reporting to SCCM having FEP 2010 installed in Add/Remove Programs. However, there is a practical problem with it. It will also pull systems that have no inventory data in SCCM. This could be systems that have been discovered in SCCM but don’t have the SCCM client installed. It could also be systems that have the SCCM client installed but for some reason their inventory data is not in SCCM. These systems without inventory data in SCCM may or may not have FEP 2010 installed. To be sure that our dynamic collection includes only systems that are reporting inventory data to SCCM and their reported data indicates that FEP 2010 is not installed in Add/Remove Programs, use the query below.
select
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.
Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomain
ORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System join SMS_G_System
_WORKSTATION_STATUS on SMS_G_System_WORKSTATION_STATUS.ResourceID
= SMS_R_System.ResourceID where SMS_R_System.ClientType =1 and
SMS_G_System_WORKSTATION_STATUS.LastHardwareScan is not null and
SMS_R_SYSTEM.ResourceID in (select ResourceID from SMS_G_System
_SERVICE) and SMS_R_SYSTEM.ResourceID not in (select SMS_R_SYSTEM.
ResourceID from SMS_R_System inner join SMS_G_System_ADD_REMOVE_
PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.
ResourceId join SMS_G_System_ADD_REMOVE_PROGRAMS_64 on SMS_G_System_
ADD_REMOVE_PROGRAMS_64.ResourceID = SMS_R_System.ResourceId where
(SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName LIKE "%Forefront Endpoint
Protection 2010%" or SMS_G_System_ADD_REMOVE_PROGRAMS_64.DisplayName
LIKE "%Forefront Endpoint Protection 2010%"))
Remember, to deploy another application, replace what’s in red above with your application name as it appears in Add/Remove Programs in Control Panel.
Protect your investments in Microsoft® System Center and manage your physical and virtual environment from one console with the Veeam nworks Management Pack™ for VMware. The nworks MP fully integrates with Microsoft System Center, providing a unified view of your physical servers, virtual servers and applications—and enabling you to use System Center Operations Manager as your single management interface.
Situation
In the rush to reap the benefits of virtualization, many organizations have not integrated VMware into their standard IT practices and procedures. Instead, the new technology is being managed as a separate entity. While this might be acceptable in the short term, the limitations of this approach are becoming apparent. For example, organizations no longer have full visibility of applications and services, and the network operations center (NOC) can’t provide 24×7 support for VMware like they do for the rest of the IT infrastructure.
As a result, some organizations have put a moratorium on further virtualization—a situation commonly referred to as “VM stall.” To get things moving again, organizations need a way to bring VMware into System Center. Some consider deploying a separate monitoring framework for VMware and then connecting it to System Center, but this approach undermines efforts to standardize on System Center and introduces unnecessary expense.
Solution
To protect investments and maintain the integrity of processes and policies built around System Center, a native System Center solution for VMware is needed—one that fully leverages System Center while bringing deep VMware domain expertise to the Operations Manager console. The nworks MP does both.
Enterprise strength
The nworks MP provides continuous monitoring of enterprise VMware environments. It features a centrally managed, distributed architecture for horizontal “no limits” scalability and automatic failover and load balancing for high availability. Optimized, user-configurable data collection and publication methods and use of highly advanced features of Operations Manager deliver maximum information with minimal overhead.
Complete integration
The nworks MP integrates fully with both VMware and System Center. It enables all System Center functionality— alerts, topology diagrams, dashboards, reporting, auditing, notifications, responses and automation—for all VMware components. It provides a detailed VMware health model, including metrics such as memory pressure and disk IOPS that are only available from Veeam. The nworks MP also includes a comprehensive knowledge base that serves as your VMware “expert in a box.”
While the nworks MP itself collects VMware data agentlessly, it also fully integrates data from Operations Manager agents running inside virtual machines—providing full end-to-end visibility of virtualized applications and services. The nworks MP is verified by VMware as VMware Ready and is listed in the Microsoft Pinpoint catalog.
Proven architecture
The nworks MP has proven itself in nearly 700 enterprise deployments. It’s a scalable, reliable and mature solution that performs well with both VMware and System Center.

Benefits
Protect your investments in System Center
- Preserve the integrity of your unified Operations Manager console
- Maintain compliance with established IT policies and practices
Manage everything from a single console
- Enable a complete view of the entire IT infrastructure—physical and virtual
- Identify the root cause of any problem and escalate it to the correct team
- Speed problem resolution, minimize user impact and meet SLAs
Eliminate additional monitoring frameworks
- Avoid the expense of deploying, integrating and maintaining another monitoring framework
- Leverage your existing System Center expertise
- Empower operators to monitor VMware with the tool they already know
Last month, we described how you can save time and resources by leveraging SCOM to automate problem resolution. In Part 1 of this series, we described the approach behind implementing a time‐saving process to preemptively automate a known, user impacting issue. In Part 2, we will describe how to use a SCOM rule in conjunction with custom data source and write action module types to execute a PowerShell script.
Since PowerShell may not be configured on your servers, it’s important to ensure your environment is capable of using this approach. As a refresher, last month we discussed how proper planning will lead to a successful and predictable outcome. Before continuing, you may wish to read Part 1 again to understand the prerequisites.
Designing the PowerShell Script
IIS 7 has awesome administrative capabilities when using the WebAdministration PowerShell snap‐in. You can read more about. We are going to leverage this module to achieve our goal of locating the log file directory. Afterwards, we can enumerate through the log files and delete the ones older than xx days. Since we are deleting log files, it would be nice to have a record of which logs were deleted. This is accomplished by writing a Windows Event with the deleted log name for ease of tracking and troubleshooting. From a high level, this is the general flow of the script:
- Determine the number of days to keep the IIS logs (passed as an overridable SCOM parameter)
- Locate the directory of the IIS logs (using the IIS WebAdministration snap‐in)
- Enumerate through the list of IIS logs and determine the file date
- Take the log file date, determine if it is older than xx days and delete
- With a few lines of PowerShell, the aforementioned requirements turn into the following script.


Testing the PowerShell Script
Before implementing the SCOM rule, you can test the PowerShell script at the command prompt to ensure everything is working properly. Copy the included script to an IIS 7 web server that has old log files. Go into the log directory and make a mental note how many logs exist and their dates. Open a PowerShell command and run the script.
During the testing phase, we do not want to inadvertently delete IIS log files because we want SCOM to do this. Additionally, you should validate the number of days to retain the logs is exactly what you want. There is a safe and simple way to test which logs would be deleted without actually deleting them. Open the script in your favorite editor and look towards the bottom of the script. Notice the “‐WhatIf” switch parameter in the Remove‐Item command? This will show you the logs that would have been deleted as shown below. Do the log files listed coincide with those that you observed above?

Alternatively, you could remove the “‐WhatIf” switch parameter and delete the log files manually. For demonstration
purposes, the script output would look as follows:

Working with Scripts in a Management Pack
In order to get the script into a management pack, we have to understand how to pass configuration parameters to the
script. In some cases, you may have servers that need to keep their logs for 7 days and other servers to keep logs for 5
days. By modifying the $NumDays variable, we can pass this value to the script as a configuration parameter. In the
management pack, the first line of the script looks like this:

This allows SCOM to pass the $NumDays value that you define in the rule or override. This works well for IIS servers that have different log retention policies. In the DataSourceModuleType, you can see how this is implemented as “IntervalDays”.

Getting the PowerShell script bolted into a MP requires the use of the Microsoft.Windows.PowerShellWriteAction. The first 8 lines of the script are modified to make it “compatible” with the write action and provide debug output as shown below.

Implementing the Solution
The last thing prior to importing the management pack is to determine which servers to run the cleanup rule against. Since the rule is disabled by default, you must enable through overrides. This table will help you make the best choice for determining how to override the rule:

After importing the sample management pack, click on the Authoring Tab in the Operations Console and select Rules. You will need to adjust your scope to display only IIS 7 Web Server. Next, search for “IIS 7 Log Cleanup Rule”. Based on your particular scenario, override the rule according to your requirements in the table above.
Note: Once the override has enabled the rule, it will run immediately after and delete the IIS logs. If you wish to have the capability to run the rule at a specific time, WME offers a turnkey solution to set the time to delete the logs during after‐hours.
Summary
Referring to the scenario outlined in Part 1 where customers are negatively impacted by LOB application unavailability due to disk spaces issues; the SCOM rule has automated the cleanup process so your users are not interrupted. This is simply one way to use SCOM to automate management of common cleanup tasks.
The files referenced in this article can be found here.
In this article I explain how you can use System Center Configuration Manager (SCCM) 2007 to find systems configured with an incorrect time zone, and then fix it via an advertisement. The SCCM database stores a system’s time in the same format stored in Windows.
One way to obtain the system’s time zone in Windows is to query for the CurrentTimeZone property of the Win32_ComputerSystem WMI class. The value returned will be number of minutes that the computer time is offset from Coordinated Universal Time (UTC).
For example, New York is 5 hours behind UTC when observing daylight saving. So when New York is in Eastern Daylight Time (EDT), a Windows system in New York will keep the system’s CurrentTimeZone setto ‐240, which represents 4 hours (divide 240 by 60 minutes) and the negative sign representing that it is behind UTC. When daylight savings is in effect, the system’s time will be set an hour behind (for a total of 5 hours behind UTC).
The correct time zone value stored in SCCM for a system in New York while observing daylight saving is ‐‐240. There are built‐in reports in SCCM that show you this time zone value. Sometimes the need may arise to fix the time zone on systems that have it set incorrectly. One way to remediate this is to create a collection that will be populated by systems with an incorrect time zone. In this example, I’ll create a collection that will have as members systems in New York with an incorrect value in the CurrentTimeZone property. If you have systems in multiple time zones, you can first create a collection that contains only computers in New York (you can base your collection on systems’ Organizational Unit in Active Directory or their IP subnet(s), and then when you create the collection with systems having an incorrect time zone in New York you just configure it to be limited to the New York collection.

The SQL query for this collection is
select
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client from SMS_R_System JOIN SMS_G_System_COMPUTER_SYSTEM
on SMS_G_System_COMPUTER_SYSTEM.ResourceID=SMS_R_SYSTEM.ResourceID where
SMS_G_System_COMPUTER_SYSTEM.CurrentTimeZone != '‐240'
Once the collection is populated, you can target it with an SCCM package that will run a program with
the following command to fix it:
Tzutil /s “Eastern Standard Time”
You don’t have to indicate that the package contains source files in Windows 7 as tzutil.exe is built‐in into it.
As systems in the collection successfully run the program, they’ll be removed from it when the collection evaluates next time (the image in this example has the evaluation to be performed once a day). As new systems are reported in the SCCM database with the incorrect time zone value, they’ll become members of the collection when it evaluates next time. Once they join the collection, they’ll receive the advertisement to run the Tzutil fix (as long as the advertisement hasn’t expired).
These days, shrinking IT budgets and pressure to maintain the infrastructure with fewer resources seems to be the norm. If you have SCOM in your environment, you can save time and resources by utilizing simple problem resolution tasks or building more advanced methods to automate reoccurring infrastructure maladies. In Part 1 of this series, we describe the approach behind implementing a time‐saving process to preemptively automate a known server issue before users are impacted. The remainder of the solution will be described in more detail in next month’s newsletter.
Regardless of the infrastructure size or complexity, most IT professionals see immediate benefits of automation through scripting. Some companies attempt to self‐heal issues as they arise however this could mask underlying issues within the environment. Understanding the subtleties of issues that can be automated should be thoroughly analyzed prior to implementing a self‐healing task. Putting it all together typically requires up front planning and falls within your companies policies.
Task Process Envisioning
Before automation can be developed, we must have a complete understanding of the problem space and have forethought into what the desired outcome might be. In this scenario, our fictitious company has a LOB application that periodically stops working when the hard drive runs out of space. Based on previous knowledge of this issue, the IIS logs are the root cause of disk space deprivation. The old IIS logs can be safely deleted however they must be retained for a minimum of five days to satisfy corporate policies. This is enough information to begin the preliminary envisioning and readiness checks.
Since automation can be achieved in any number of ways, it’s important to consider which scripting language is best for your organization. We believe the best scripting language is the one your IT pros are most proficient using. Since we are using SCOM to initiate the script, we need to ensure the environment can support our idea. In addition to selecting a scripting language, we also need to organize our information about the application and server components. Here’s what we know:
- We are using SCOM R2 which natively supports vbscript and PowerShell
- The LOB application servers are Windows 2008 R2 with IIS 7
- We have chosen to use a PowerShell script and use the IIS 7 snap‐in
- We don’t know if the servers have PowerShell configured correctly
It looks all good however, we need to first validate the PowerShell configuration on our application servers. With a few minutes of preparation, we can use a process resembling the illustration below to ascertain if the servers are capable of supporting the IIS log cleanup script.

Other Task Design Considerations
Now that we determined the scripting language and verified the servers have all the necessary prerequisites, there are still a few more questions which must be resolved. During the design phase, ask yourself these general questions:
- Do my tasks involve running a script or command?
- What scripting engines do I have available on the servers?
- Are my commands available on all servers (such as “net start”)?
- When should automation to run (on schedule, triggered on failure, etc.)?
- Where automation should be run from (agent or console)?
- Does my script have any dependencies or version requirements?
Make a mental note of the operating system and related application versions as this could impact the way in which you design your process. Authoring a script that must work across operating systems and server components can add complexity.
Running The Task Manually, As a Recovery or Scheduled Rule?
Based on the scenario outlined above, we know the problem happens about once per week and can manifest at any given time. Although we could implement a recovery script when low disk space is detected, it would be easier to run the IIS Log cleanup script once per day as a SCOM rule.
Stay tuned for part two in the series to find out how we automated the IIS Log cleanup using PowerShell and a configurable SCOM rule.
System Center Configuration Manager (SCCM) can be used to perform Zero Touch Installation Operating System (OS) deployments. You can easily target an existing Windows system that has the SCCM client installed to install a new OS on it. But how do you target systems that don’t even have an OS installed on them? This article discusses the available options to deploy an OS to bare metal machines using SCCM.
Investigating the available options to deploy an operating system to an unmanaged system (a computer not known to SCCM) can be confusing when you run into the SCCM terms below.
- Computer Association
- Unknown Computer Support
- Unknown Computers Collection
- Unprovisioned Computers Node
Prior to the release of R2 for SCCM, the only way to target a system unknown to SCCM for OSD was to create a record for the system in the SCCM database. The new computer record is then simply added to a collection, and you just advertise your OSD task sequence to this collection. To create the record, you have to know the system’s MAC address or SMBIOS GUID. The SMBIOS GUID is easy to obtain from a computer running a Windows operating system by querying WMI. For example, in Windows 7, you can type the following command at the command prompt:
Wmic csproduct get uuid
However, for computers without an operating system installed, this isn’t possible. You can get the SMBIOS GUID from the CMOS BIOS. If you are using a PXE Service Point, you can boot the bare metal machine into PXE and check the PXE screen or look at the smspxe.log on the server. The following article provides details on how to add computers to the SCCM database:
http://technet.microsoft.com/en-us/library/bb633291.aspx
The methods detailed in the article above will overwrite a computer that already exists in the SCCM database if the new computer information has the same name. The script in this article will not overwrite an existing record. Run it from the command prompt using the following syntax:
Cscript addComputerRecordToSCCM.vbs
The script will prompt you for the name of the SCCM computer to connect to, the MAC address of the system being added, and the collection ID of the collection where the new computer resource should be added. You can find the collection ID by looking at the properties of a collection.

R2 for SCCM introduced Unknown Computer Support (SCCM needs to be at service pack level SP1 or higher), removing the need to pre-create a record in the SCCM database for OSD. This works with PXE boot and with boot media. R2 creates two unknown system resources: x86 Unknown Computer and x64 Unknown Computer. It adds these two resources to a new collection that it creates called All Unknown Computers.

Once you enable Unknown Computer Support, you can then advertise your OSD task sequence to this collection. Note that you can add these unknown computer resources to any custom collection. You might wonder how this process works. When using a PXE Service Point for OSD, the SCCM PXE Service Point will record the MAC address of the unknown computer when it PXE boots. At this point, SCCM no longer considers this computer as unknown but rather as unprovisioned. SCCM then adds the computer to the Unprovisioned Computers node.

The unprovisioned system now has an SMS unique identifier and is able to receive OSD task sequences. Once the operating system is installed on it, the system is removed from the Unprovisioned Computers node. However, if the task sequence fails, the system will remain in this node. This is good for informational purposes.
To enable unknown computer support for PXE boot, enable the Enable unknown computer support option in the PXE Service Point configuration.

To enable unknown computer support for bootable media, enable the same option in the Create Task Sequence Media wizard after you select Bootable media.

To avoid wiping out systems in error, especially Zero Touch OSD deployments using PXE boot, you may want to require a password so after the system PXE boots someone needs to enter the password before wiping the machine and installing a new OS (if using a mandatory advertisement). Another way to protect systems from being reformatted and getting a new OS by mistake is to create an exclusion list. The following article provides details on how to accomplish this.
http://blogs.technet.com/b/manageabilityguys/archive/2011/03/24/preventing-pxe-boot-on-servers-and-other-critical-client-systems-using-macignorelistfile.aspx .
You can download the source file here:
Add Computer Record to SCCM
|
|