Last week I deployed System Center Orchestrator in my testlab to start using runbooks in our private cloud environment. However, when I tried to open the Orchestrator console from my desktop I received the following error:

Further investigation on the Orchestrator management server revealed the following entry in the system logs:

To resolve this issue I fired up the DCOM configuration tool (dcomcnfg.exe) on the Orchestrator server and opened the security properties for the ‘omanagement’ application:

In our System Center lab we use VAMT to keep track of licenses used etc. However, when you try to activate a product with Microsoft VAMT 20 the following error may occur: “VAMT reported that the response from the activation server did not match the request.” This is a result of a misconfiguration of the Region and Language settings of the server VAMT is installed on.

To solve this problem you can take the following steps:

- Open the Control Panel and goto “Clock, Language and Region” and select “Change the date, time or number format”,

- In the “Region and Language” popup select “Additional settings…” button on the “Formats” tab,

- The “Customize Format” popup will appear. Change the “Decimal symbol” on this screen to a . (dot) and click “Apply” and “OK” twice to close the popups.

Microsoft is preparing new courses and certifications aimed at cloud infrastructure technologies, both public and private. The new certifications will be aimed at 4 specific roles:

Recently I noticed that some machines in our environment weren’t configured for high availability. To remedy this I thought it was as simple as shutting down the machine and enabling the High Availability setting in the VM properties. After shutting the machine down however, I noticed that the ‘Make this machine highly available’ checkbox was greyed out.

However, using the ‘Migrate Virtual Machine’ option and starting the migration wizard you can choose to make the VM highly available.

This will start the migration of the VM data to the selected cluster. When the migration is complete the machine will indicate it’s high available.

Yesterday was the kick-off for the new Community Evaluation Program: System Center in the Datacenter and Cloud. This CEP will not only provide introductions and guidance for the new System Center 2012 products to be released in early next year but will also provide insight in how to create a private cloud environment based on the System Center suite.

The following products will be shipped as a part of the System Center 2012 release and will be covered in detail as a part of the Microsoft System Center 2012 Private Cloud Community Evaluation Program:

When deploying the Opalis Operator Console and using Active Directory for authentication you have to provide a domain-based group which will be configured as the administrator group for the webconsole.

Following Microsoft best practices I created a domain global group for users and a domain local group to assign rights. After configuring the webconsole, using the domain local group as the admin group, I then logged on to the webconsole. To my surprise I couldn’t find any policies in the webconsole and got the below screen:

This was strange seeing there are tons of policies configured in our (test) environment.

Eventually I found the following thread on the Technet forums stating “only direct members of the group defined as the administration group have permissions to policies”. To put this to the test I reconfigured the opalis-activedirectory-service.xml file to use the Domain Global group I created with the different Opalis administrators and restarted the Opalis Webconsole service.

This time, after logging on, I got all the policies I have in my environment:

This is more an integration test rather than a production example, it tests the integration of the different System Center applications to show if everything works as intended.

I’ve got some simple service monitors configured in SCOM for testing purposes. These monitors will create an alert when a service is down. The connector in SCOM will synchronize this alert to SCSM which, in turn, will create an incident.

Based on this incident I want to start an Opalis workflow which will do the following things:

1. Get the SCSM incident that will be the starting point for the Opalis workflow

2. Get the related SCOM alert

3. Use the SCOM alert to determine which service is down

4. Start the involved service

When a service goes down an alert will be raised by SCOM. This will be synchronized to SCSM which will produce an incident with the title ‘Windows Service Stopped’. This incident will be the starting point of the Opalis workflow.

This workflow will be started manually whenever this type of incident occurs, therefor you can use the ‘Get-Object’ object which will filter on Title and Status. To start this workflow automatically every time a similar event is created you can use the ‘Monitor-Object’ object.

The ‘Get-Object’ object is configured as follows:

Just to make things easier

As all of you know, before you can proceed with the System Center Operations Manager or System Center Configuration Manager setup, you have to install several Windows 2008 roles and features.

To make our life a little easier we have created two little PowerShell scripts who will do this job for you, the scripts install the necessary Windows 2008 R2 modules and features and check whether PowerShell is running in Elevated mode.

For the SCOM setup we run this script prior to installation.

System Center Service Manager 2010 is a great way to generate incidents based on alerts raised in SCOM 2007. In order to make this work you have to create the connectors necessary for OpsMgr alerting.

Within the Service Manger console go to Administration – Connectors. Here you can create several connectors.

• Active Directory Connector lets you import items from Active Directory, such as users, computers, printers and groups. During the installation you can choose to import everything from AD, or make a selection of users, computers and printers.
• Operations Manager Alert Connector automatically creates incidents which are generated from alerts in SCOM.
• Operations Manager CI Connector imports configuration items that are discovered in SCOM.
• Configuration Manager Connector enables the import of SCSM 2007 configuration items. It can update details about an items already imported by the AD connector or import a configuration baseline used to generate incidents for systems that are non-compliant.

In this blog I want to talk about the Operations Manager Alert Connector. This will be configured in two steps, the first step takes place in SCSM.

Create an Operations Manager Alert Connector

On the General Tab give the connector a name and a description if required.

Today I wanted to talk about a common issue which we often run in to during SCCM 2007 site installations for our customers.

After installing the SCCM 2007 site server and configuring it we get the following error in the SCCM Site Status:

[SMS_MP_CONTROL_MANAGER]
SMS Site Component Manager faild to install component SMS_MP_CONTROL_MANAGER on server <ServerName>.

The WebDAV server extension is either not installed or not configured properly.
Solution: Make sure WebDAV is installed and enabled. Make sure there is an authoring rule that allow "All users" read access to "All content". Make sure the WebDAV settings "Allow anonymous property queries" and "Allow property queries with infinite depth" are set to "true" and "Allow Custom Properties" is set to false.

The thing is that I have set all the appropriate WebDav settings  from within IIS, still the error tells me I didn’t.

For some strange reason the “%Windir%\System32\inetsrv\config\schema\WEBDAV_schema.xml” file is not being updated by the changes you make in IIS.

Here is a quick workaround: