Monthly Archives: June 2013

SCSM 2012 SP1: AD Connector is not synchronizing cross domain manager information

Everyone who uses System Center Service Manager 2012 SP1 in an enterprise environment (with more than one active directory domain) and uses multiple AD connectors to synchronize objects with SCSM could recognize this current bug.

Problem description

Imagine you have a user from domain A (User A) and a user from domain B (UserB).

UserA has the manager UserB. This is shown in the “Managed By” field in AD in UserA.

So the AD objects UserA and UserB are synchronized with SCSM through two different connectors (AD connector A and AD connector B).

The problem is, that the field “Manager” in SCSM for ther UserA is empty.

This forum entry also describes it:

http://social.technet.microsoft.com/Forums/systemcenter/en-US/59b72a39-b2f4-4e17-b815-22e7231a7af7/scsm-2012-ad-connector-not-syncing-manager-information

Why do we need that?

Without the organizational links there is no way to offer service requests which query the organizational hierarchy (for example for password resets, group memberships, etc.) within the Service Manager forms.

Microsoft feedback

I asked an MVP from my contacts to get feedback from the Microsoft product group about this problem. The feedback he got was that this “feature” has been disabled in SP1. And that this synchronization could be achieved through a CSV connector.

What can we do?

At this stage I do not understand why a workaround needs to be created and the standard AD connector should not provide this anymore. That is the reason why I have added an improvement request to connect.microsoft.com.

https://connect.microsoft.com/SC/feedback/details/790767/scsm-2012-rtm-sp1-active-directory-connector-does-not-sync-cross-domain-links

If you agree that this functionality is important for a Service Manager 2012 SP1 installation in an enterprise environment, then I would ask you to login to connect.microsoft.com and vote for this feedback to raise the importancy.

Perhaps we can get this “feature” back into the system.

SCOM 2012: Some details about the new state and alert widgets

In System Center Operations Manager 2012 (RTM /SP1) Microsoft introduced widgets which can be used in dashboard views. If you are using the new alert and state widgets in a dashboard view then you will see some differences to the old style (2007 R2) alert and state views.

State widget

First of all there is a nice new feature in the state widget that you now can scope it to multiple groups.

stateview

After you have created your view you will start to work with it.

Right click on a server in the state widget or check the tasks pane on the right side, then you can see a difference to the old views. The maintenance mode options are missing!

stateview-rightclick

So if you want to set a computer into maintenance mode, then you have to use the “old style” state view for it!

Something else what you cannot see in the state widget are the details (properties) of the computer.

Alert widget

The alert widget still has no option to add multiple classes to it. So nothing changed here. But in standard you have no alert details anymore. You have to enable that explicit. When you configure the properties of the widget select “Enable alert details inline” in the “Specify Display Preferences” section.

enablealertdetails

It will show some details directly below the alert when you click on it but it has no links anymore to the monitor/rule properties.

alertdetails

You can also recognize changes in the right click drop down menu and the task pane.

alertrightclick

What is missing? Multiple things:

  • Maintenance mode options
  • Notification subscription options
  • Overrides
  • View or edit settings of this monitor/rule

So for all of this you need to use the “old style” alert view again!

The problem with all this differences is that you have to think about what you need to provide to your SCOM users and which view/widget will have the required functionality.

The new widgets look nice but with this missing parts you still need to give the users the old style views for some things and which focuses the use of the new widgets into question.

Additional general handling information: If you have grouped columns then you need to double click the grouping to collaps or expand it! In the “old style” alert view only one single click is needed.

Orchestrator 2012: Patch a server with SCCM 2012

You will perhaps have the question in your mind “Why initialize patching with Orchestrator?”.

We had the request to restart and patch servers on a reoccuring schedule in groups and with pre and post tasks to check. You can do that all in SCCM 2012 through tasks sequences, but Can you also control that SCCM should stop when one of the servers in the group fails and that you get a status at the end? Orchestrator can do that. It can run some general tasks for all servers or special tasks for single servers, so you can control more in there.

I will also create another blog post to describe the reboot runbooks. Here I want to focus on the patching part. This can also separately be initialized outside of the reboot process.

For our reboot szenario we only wanted to check which patches are available. Install them, reboot and after the reboot check which patches are installed successfully and if there are additional missing patches. We did not install those then. You could extend that as you need it.

We use System Center Orchestrator 2012 SP1. For my runbook I do not use the System Center Configuration Manager 2012 SP1 integration pack. I only use WMI queries to check which patches are available. But you still need SCCM 2012 to deploy the patches!

I use the following WMI classes:

CCM_SoftwareUpdate (http://msdn.microsoft.com/en-us/library/jj155451.aspx)
CCM_SoftwareUpdatesManager (http://msdn.microsoft.com/en-us/library/jj155384.aspx)
Win32_QuickFixEngineering (http://msdn.microsoft.com/en-us/library/windows/desktop/aa394391(v=vs.85).aspx)

We have one additional database in the same database instance as our Orchestrator database for logging. It is called OrchestratorTemp.

For this runbook we use a table called SoftwareUpdate to log the patch status.

softwareupdate

In the reboot runbooks we have another table which logs the general server status which also has columns Servername and RBInstance. With these both columns we later can link both tables and clean up the columns at the end of the process.

I use three runbooks to patch the server.

  1. SCCM Dev – Check updates
  2. SCCM Dev – Install updates
  3. SCCM Dev – Check previous updates

SCCM Dev – Check updates

sccm dev - check updates

It has the following initialize data parameters:

  • Servername
  • Patch (in the reboot runbook you can decide if you want to patch or not, Values: “True/False”)
  • Previous Found (needed for the second run after the reboot, should be “False” at the beginning)
  • RBInstance (reference to the main reboot runbook, can be any number if called outside)

I will focus on the interesting details of the main activies.

  • Get Updates/Check for additional updates (Run .Net Activity):
    Runs the following PowerShell script:
    getupdates
    and publishes the following data:
    getupdates-published
  • Write Updates/Write additional Update Status (Write To Database Activity):
    Writes into the OrchestratorTemp database:
    WriteUpdates
  • Install Update (Invoke Runbook): Initializes the “SCCM Dev – Install Update” runbook and waits for its completion. Loops until Finished=True. Given Parameters: Servername, RBinstance.
  • Check previous updates (Invoke Runbook): Initializes the “SCCM Dev – Check previous updates” runbook and waits for its completion. Given Parameters: Servername, RBinstance.

SCCM Dev – Install updates

sccm dev - install updates

The install updates will be initialized for each update which needs to be installed.

  • Get first missing update (Query Database Activity): Runs the following query:
    get first update
  • Install update (Run .Net Activity):
    Runs the following PowerShell script:
    install update
  • Check update (Run .Net Activity):
    Runs the following PowerShell script:
    check update
    and publishes the following data:
    check update - published
    Loops with a delay of 10 seconds and exits loop when these conditions occur:
    check update - loop
    (pattern: 8|9|10|11|12|13|14|15|16|17|18|19|20|21|22|23)
    => waits 2 minutes for the patch to install. Can be extended by increasing the number of attempts!
  • Cancel Update (Run .Net Activity):
    Runs the following PowerShell script:
    cancel update
  • The Write Update activities sets “ComplianceState” to 1 and the “EvaluationState” to the output status when the update was installed successfully. Otherwise it sets different “ComplianceStates” depending on the update status.

SCCM Dev – Check previous updates

sccm dev - check previous updates

This runbook should check if the update is listed in the installed updates after the reboot.

  • Get Compliance State (Query Database Activity): Runs the following query:
    get compliance state
  • Get ArticleID (Query Database Activity): Runs the following query:
    get articleID
  • Check install status (Run .Net Activity):
    Runs the following PowerShell script:
    Check install status
    and publishes the following data:
    Check install status - published
  • Write Update Compliance (Query Database Activity): Runs the following query:
    Write update compliance

Here is the link to the exported runbooks.

That’s it. Have fun!