Marc Umeno's Blog : SCCM

Service Manager Test Drive Available Now

mumeno — Mon, 04 May 2009 21:06:08 GMT

I have exciting news to share!

We have a Service Manager Test Drive preview of Beta 2 available to try out now. It’s on hosted VMs, so all you need to do is log in with your Windows Live ID and start playing with it.

The VMs have all of the same sample data we used in our demonstrations at the Microsoft Management Summit. You will be able to evaluate the core Incident, Change, and Configuration Management features, as well as integration with Active Directory, System Center Configuration Manager and System Center Operations Manager. There is also some sample data for a few reports available in the Test Drive.

Please check it out and let us know what you think – you can post feedback and questions in the Service Manager TechNet forum.

Desired Configuration Management Integration in Service Manager Beta 1

mumeno — Wed, 21 Jan 2009 10:34:09 GMT

System Center Configuration Manager 2007(SCCM) has introduced a valuable feature, Desired Configuration Management (DCM), that enables assessment of client configuration compliance with specified configuration baselines. With Service Manager Beta 1, we have introduced integration with DCM where incidents are created for out-of-compliance clients.

We do this by collecting DCM non-compliance data using the SCCM connector and then continuously running a Service Manager workflow that creates incidents for non-compliant SCCM clients. You decide which specific DCM Baselines and DCM CIs generate incidents.

To initiate DCM incidents, you must create an connector to an SCCM site that is using the DCM feature. Next, select the Incident Settings view and start configuring the Desired Configuration Management settings using the Configure Workflow task.

This launches a dialog where all DCM workflows are managed:

The Add button launches the Add Desired Configuration Management Workflow wizard.

You can select DCM baselines and DCM CIs to include in the workflow – for each client that has a non-compliant report, an incident will be created. You can apply a pre-configured template and notification rules for the workflow as well. Once you have configured your first DCM workflow, incidents will be created for any current non-compliant clients. After the first DCM workflows are run, incidents will only be created for new non-compliant issues.

Note: You should be careful about which DCM Baselines and CIs you choose to create incidents – for example, if you choose DCM CIs that describe software update non-compliance, you could potentially generate an incident for each unpatched computer in your SCCM site, which could result in thousands of excess incidents.

Newly-created DCM incidents can be viewed in the Work Items –> Incident Management –> All Open DCM Incidents view.

DCM incident forms have a special Compliance Errors tab that adds additional details about the affected SCCM computer, including computer owner, computer name, DCM baseline, DCM scan date, and details from the DCM report about why the computer was non-compliant.

Once DCM incidents are created, they can managed like any other incidents in Service Manager.

Administering and Tracking Service Manager Beta 1 Connectors

mumeno — Tue, 02 Dec 2008 13:52:14 GMT

Early feedback on Service Manager Beta 1 has highlighted that many folks would like more information around administration of connectors, especially on how to track the progress of a connector.

TASKS

First, I would like to point out some of the tasks available for Service Manager Beta 1 for a connector:

The Sync Now task initiates an on-demand data sync for a connector. However, contrary to what you might think, this sync will not be completed immediately as there are often many underlying processes that are involved with a connector sync. I will touch more on the details around connector syncs later on in this post.

The Delete Connector task will do a couple of things, one of which may be surprising. First the connector is deleted and removed from the Service Manager database. What may be a surprise to you is that deletion of a connector will also delete any Configuration Items (CIs) it created, unless those CIs were also updated by another data source. This capability can be very convenient if you need to remove a lot of data from the Service Manager CMDB.

The Disable task will prevent future connector syncs from happening for a particular connector. In-progress syncs will complete even after this task is used.

The Enable task will re-enable a disabled connector and in Beta 1 at least, this will also initiate an immediate connector sync.

The Edit Connector task will pop-up a property dialog for the connector.

TRACKING SYNCS

As I mentioned above, each data sync for a connector is actually comprised of a number of smaller processes that actually run asynchronously.

Each sync for the AD and SCCM connectors comes in 2 asynchronous steps – the first step extracts data from the source and puts it into a staging data cache; the second step takes data from the staging data cache and writes into the Service Manager CMDB.

You can follow the progress of these data syncs in Service Manager Beta 1 by looking at the Event Viewer under Administrative Tools:

If you click on the “Filter Current Log” action and pick the “Lfx Datacenter” “Lfx Service” and “Lfx Source Config” Event services, you will narrow down the events to those related to connectors.

If you are only interested in tracking the progress of a connector, you can filter to just the “Lfx Service” events.

For an SCCM Connector, you will see a sequence that looks something like this – once all of these events are done, the sync is completed.

Date	Event
12/2/2008 2:18	Done:MomStore.DCMNonCompliantConfigItems.DefaultCache.SCCMConnector.
12/2/2008 2:16	Done:MomStore.DCMConfigItemRelations.DefaultCache.SCCMConnector.
12/2/2008 2:15	Done:MomStore.DCMConfigItems.DefaultCache.SCCMConnector.
12/2/2008 2:14	Done:MomStore.TopConsoleUser.DefaultCache.SCCMConnector.
12/2/2008 2:14	Done:MomStore.DeviceHasSoftwareUpdate.DefaultCache.SCCMConnector.
12/2/2008 2:12	Done:MomStore.DeviceHasSoftwareItemInstalled.DefaultCache.SCCMConnector.
12/2/2008 2:11	Done:MomStore.NetworkAdapter.DefaultCache.SCCMConnector.
12/2/2008 2:10	Done:MomStore.Processor.DefaultCache.SCCMConnector.
12/2/2008 2:09	Done:MomStore.LogicalDisk.DefaultCache.SCCMConnector.
12/2/2008 2:08	Done:MomStore.PhysicalDisk.DefaultCache.SCCMConnector.
12/2/2008 2:07	Done:MomStore.OperatingSystem.DefaultCache.SCCMConnector.
12/2/2008 2:06	Done:MomStore.LogicalComputersOnPhysicalComputers.DefaultCache.SCCMConnector.
12/2/2008 2:05	Done:MomStore.LogicalComputers.DefaultCache.SCCMConnector.
12/2/2008 2:04	Done:MomStore.PhysicalComputers.DefaultCache.SCCMConnector.
12/2/2008 2:03	Done:Importer.DCM.SCCMConnector.
12/2/2008 2:02	Done:Importer.Updates.SCCMConnector.
12/2/2008 2:01	Done:Importer.Inventory.SCCMConnector.
12/2/2008 2:00	Done:Importer.Computers.SCCMConnector.

During the running of a sync, even if the connector has not completed all of the processes, Configuration Items might be created or updated & can be visible in the Service Manager console. For example, you might see a number of computer CIs created during an SCCM sync. However, if you were to look at the Software or Software Updates installed on that computer, you might find they are still missing if the sync has not completed.

Creating an SCCM Connector for Service Manager Beta 1

mumeno — Tue, 02 Dec 2008 12:44:53 GMT

In Service Manager Beta 1, you can create a Connector to a System Center Configuration Manager 2007 SP1 database.

The SCCM Connector brings Configuration Item data about computers managed by SCCM, including Hardware & Software Inventory, Software Updates, and Desired Configuration Management (DCM) data.

To create an SCCM Connector, you need to be a Service Manager administrator. Connectors are found in the Administration workspace.

Start by clicking on the “Create Connector” task and choose the Configuration Manager Connector option.

That launches the SCCM Connector wizard:

After supplying a Name and Description, you are given an option to provide an SCCM database server and database instance as well an account to access the database.

(Note: You cannot edit the database server name or database name for an existing SCCM connector – you have to create a new SCCM connector in this case)

TIP: The account must have rights for smsroledb_extract and databasereaders in SQL.

TIP: You should always check the validity of the credentials by pressing the “Test Connection” button.

Next you have provide the schedule for running the SCCM connector, which can run once a day or once a week.

You are then shown a summary screen and a completion screen when the connector is created.

Servicing Offline VMs with SCVMM and SCCM

mumeno — Tue, 25 Mar 2008 11:51:25 GMT

We just released a whitepaper around servicing offline VMs using SCVMM and SCCM.

Download details are here:

https://www.microsoft.com/downloads/details.aspx?FamilyID=c5abb19e-15b1-4692-b465-393584c592a0&displaylang=en

Direct Download file from here:

http://download.microsoft.com/download/d/1/0/d10ecad6-3de9-4bb2-bbc4-4f8d5c487b66/VMMLibraryPatching.zip

There will be more to come on this subject from us in the future, but this is a great start for realizing the combined value of System Center products.

Software Updates Management Whitepaper Published for Transition from SMS 2003 to System Center Configuration Manager 2007

mumeno — Wed, 31 Oct 2007 21:12:56 GMT

I am pleased to announce that we have just published a whitepaper that provides guidance for customers transitioning from SMS 2003 Patch Management to System Center Configuration Manager 2007 Software Updates Management.

You can download the paper from here:

http://download.microsoft.com/download/d/8/6/d861e149-76f7-4348-89aa-7f3d9777f5ae/Configuration Manager Software Updates Management Guidance - Migration from ITMU.doc

Here is a description:

While the release of System Center Configuration Manager 2007 has been accompanied by robust functional and procedural product documentation, the integration of WSUS introduced two additional challenges:

¾ Successful migration of SMS 2003 environments to Configuration Manager while maintaining the existing software update levels of service.

¾ Clarifying a dramatic shift in a fundamental process in the minds of experienced SMS 2003 administrators.

This whitepaper provides guidance on how to migrate software update management from SMS 2003 to Configuration Manager, how to operate in the transition period while maintaining ongoing software update deployments for both SMS 2003 and Configuration Manager clients, and best practices for managing software updates using Configuration Manager.

This document assumes that the reader has experience with both SMS 2003 and the Inventory Tool for Microsoft Updates (ITMU). Additionally, it is beneficial for the reader to be familiar with the operational processes associated with enterprise software update management.

Install Updates Prior to Deadline

mumeno — Thu, 11 Oct 2007 05:57:17 GMT

In SCCM 2007, we added a neat feature similar to one provided by Automatic Updates that gives managed clients the ability to install updates prior to deadline. End users can configure this by clicking the "Schedule Installation" as shown below or by going to directly to the Configuration Manager control panel applet under the "Updates" tab.

What are the Top Reasons for Non-compliance?

mumeno — Thu, 11 Oct 2007 05:40:48 GMT

This is a very fundamental question for Admins trying to raise the level of software update compliance at their company.

Traditionally using SMS 2003, the normal practice was to look at a sample of client logs and use that as a basis for guessing what the top problems were for non-compliance.

In SCCM 2007, we have added a couple of new reports that can help solve this problem for Scan and Deployment, "Troubleshooting 1 - Scan Errors" & "Troubleshooting 2 - Deployment Errors" which displays groupings of the last error received from clients. You can sort by the "count" column to get a stack-ranked list of these errors, which can greatly increase the accuracy in determining the exact top non-compliance issues and dramatically reduce the time & effort required to make the assessment.

No more scrubbing through client logs!

In real-life deployments within MSIT and TAP customers, we used these reports constantly to quickly identify problem areas such as Group Policy conflicts, low WUA version, networking issues, and SUP configuration issues. By addressing the top problems, customers were able to eliminate major sources of failures and achieve much greater compliance numbers.

When Do Downloads Happen on Clients?

mumeno — Thu, 11 Oct 2007 05:23:36 GMT

It's been a while since I added a post. Let's start up again with a quick one.

I was recently asked when do SCCM clients download updates and when would they show the notification balloon in the system tray - here is the answer:

1. SCCM clients download updates according to a deployment-specific setting in the Deploy Software Updates Wizard (DSUW). They begin downloading at the time specified in the "Make Software Updates Available" setting on the Deployment Schedule page. If you select "As soon as possible" then the updates will start being downloaded as soon as the deployment policy hits the client.

2. The notification balloon is displayed immediately for deployments without a deadline and only after updates have completed download for deployments with a deadline.

SCCM 2007 RC1 is Released!

mumeno — Mon, 16 Jul 2007 10:28:45 GMT

Late on Friday, we declared SCCM 2007 RC1 ready for release to the web! It is now available on connect.

For the Software Updates Management feature, RC1 brings a number of improvements, including new reports for overall per-machine compliance, scan errors, deployment errors; reorganized categorization of reports; ability for end users to schedule installations prior to deadline ("install updates every day at 3am"); capability to hide icons and balloon notifications from end users (silent mode); many many performance and scalability improvements; and a lot more. I'll follow-up in future posts to talk more about all of this.

Maintenance Windows

mumeno — Thu, 28 Jun 2007 07:07:10 GMT

Let's talk about maintenance windows in SCCM, a new feature for software distribution and software updates. Maintenance windows usually make sense in a server-based scenario where servers have defined service windows where they can be taken down for changes, including software updates. You can define a maintenance window for a collection by choosing "Modify Collection Settings" and then going to the Maintenance Windows tab.

The window uses an estimated time to execute the entire install. This time is comprised of the following settings:

1. Restart countdown time (Restart countdown time has a default of 5 min and is available to change on each collection in the Admin UI).

2. System restart turnaround time (Site Control File-only setting, which has a default of 10 min).

3. Maximum Run Time, which is the per-update installation time and has a Site Control File-only default setting of 20 min for Updates and 60 min for Service Packs. However, the difference from below is that this setting can be changed in the Admin UI for each update. This setting for each update can be found in a list view when looking at updates in the update repository node, update list node, or in a search folder

If more than 1 update is needed to be installed, say Update 1 with Max Run Time (MRT) of 20 min, Update 2 with MRT of 5 min, and Update 3 with MRT of 30 min, we will start by installing the update with the smallest MRT, in this case Update 2. We watch the installation & if Update 2 finishes, we look for the next shortest MRT and see if that will fit in the window, and so on, until we run out of available time.

In the the situation when the only thing left to do is a pending reboot when waiting for a Maintenance Window, we will only use the restart countdown time and the system restart turnaround time and not use the MRT.

Update Lists

mumeno — Wed, 27 Jun 2007 09:13:08 GMT

One of the most useful new objects in System Center Configuration Manager 2007 is the Update List. An update list is, well, a list of software updates - that is, it is a fixed list of updates that can be created through a wizard (which also allows downloading of updates). Security rights can be assigned to update lists to enable delegation scenarios. We also have a couple of key compliance reports that use update lists as inputs. The first new compliance report is the "Overall Compliance" report, which gives per-machine compliance for a given update list on a collection. This report assesses whether any of the updates in the list are out of compliance and reports the totals for all machines in the collection. The other new report gives per-update compliance for an update list on a collection, giving the results across the collection for a single update.

Also new to SCCM, search folders are the best way to identify exactly which updates should be put in an update list. To create a search folder, simply navigate to the search folders subnode under the Updates Repository node & select the "new search folder" action. It is easy to create a list of updates, for example, that have the following criteria: critical, security, applicable to Windows, released within the last month, not superseded.

Update lists can be used by the Deploy Software Updates Wizard, Deployment Templates, and the Download Wizard, either through right-click/action pane or by drag and drop.

Things to Know About the Software Update Point (explaining WSUS Integration)

mumeno — Wed, 06 Jun 2007 11:41:04 GMT

I thought I could put some thoughts down about the Software Update Point (SUP), which is a new site role within SCCM 2007. The job of the SUP is provide software update metadata to clients that are using the Windows Update Agent (WUA) to scan for missing updates. The underlying component of the SUP is an installed WSUS 3.0 server with an additional SCCM component. The additional component is called the WSUS Control Manager, which allows the SCCM site server to control the behavior of the SUP.

Installing the Software Update Point

In practice, the first thing you need to do to get started with Software Updates Management in SCCM is to install the SUP. The basic steps to do this are:

1. Download the latest WSUS 3.0 bits from their website.

2. Install the WSUS server on the machine that is slated to be the SUP

3. If the SUP is remote from the SCCM site server, then the WSUS admin console needs to installed on the SCCM site server.

4. Once WSUS is installed, go to the SCCM admin console and go to the site systems node, pick the server with WSUS and start the New Site Role wizard to install the SUP.

5. Let synchronization happen between the WSUS server and SCCM site server - you can monitor progress of the sync by looking at the wsyncmgr.log file

6. Once this sync has completed successfully, you are done! You can now see updates in the updates repository subnode under the Software Updates main node.

These are only high-level steps - the detailed instructions can be found here.

How does the Software Update Point work?

The top level SUP gets its metadata catalog from Microsoft Update and stores that catalog in its database. That database is also put into the SCCM database via the sync process. For software updates scanning, SCCM clients utilize the WUA to connect with a SUP and get the specific metadata that are relevant for the client. The client is scanned for missing or installed updates and results from the scanning are stored in a WMI repository. The SCCM agent collects the results and passes them through the State message system and those results are stored in the SCCM database for every client and every update. Reports can then be generated from the scan data to produce accurate and detailed compliance reports.

A Few Practical Things about the Software Update Point

One hurdle that every SCCM installation or upgrade will need to get over is the successful SUP sync - it is an indication that you have covered all the important parts and now can begin deployments. But there are some things that I think you should know about:

1. The most common problems I have seen have been around the proxy settings for the SUP - be sure to put the right settings in there, or the SUP won't be able get to the Microsoft Update site to get the catalog

2. You need a SUP at every primary site - unlike other WSUS-based implementations, SCCM requires one at every site to function.

3. Don't get concerned if the sync does not succeed right away, especially if you installed the WSUS server after the SCCM site server. The SUP first needs to successfully complete its initial sync with Microsoft Update to get the metadata catalog, which can take a while. If this process is not completed, you will see failure to sync errors in the wsyncmgr.log, which is normal.

4. In a similar vein, it can take up to a few hours for the initial sync between SUP and SCCM site server to complete, which can be a CPU-intensive process. I don't recommend trying to complete this while other CPU-intensive SCCM processes are happening.

5. As the metadata catalog is revised with new or expired updates within the SUP database, the SCCM site server needs to re-sync. This sync can be accomplished automatically on a schedule as well as through a manual initiation from the updates repository node.

6. All legacy scan tools other than ITMU should be uninstalled prior to upgrade from SMS 2003 and should not be re-installed after upgrade. They will not work anymore with SCCM and can cause serious problems that can break your site.