You are browsing the archive for Opalis 6.3.

Opalis 6.3 : Building a VMware/SCCM Opalis provisioning workflow

7:54 pm in ConfigMgr, ConfigMgr 2007, ConfigMgr 2007 R2, ConfigMgr SP2, configmgr2007, ConfigMgr2007 R3, Deployment, Installation, Opalis, Opalis 6.3, Operating System Deployment, powershell, sccm, SCCM 2007, SCCM 2007 R2, SCCM 2007 R3, SCCM 2007 SP2, sccm2007, Virtual machine, Vmware by Kenny Buntinx [MVP]

Recently we did a customer private cloud project where we used all the system center tooling ( , except for the hypervisor layer , which was VMware .

One of the scenarios that the customer had in mind , was to provision all there virtual servers with SCCM and we had to use Opalis to become the glue between VMware – BMC Remedy and System Center. In the first step of the project we didn’t use the Change request mechanism from BMC Remedy yet. Special thanks to my colleague Gunther Dewit for helping me out on this one .

**** Disclaimer **** – This is a very basic workflow – we will post improvements as we go along – it is for helping people moving forward **** Disclaimer ****

The workflow itself


Delivering input


The first step in creating a workflow is doing a custom start where we could input some necessary variables . The Custom Start Activity is used to create a generic starting point for Workflows. By adding parameters to the Custom Start Activity it can consume external data which can be passed to downstream Workflow Activities.


These are the parameters the workflow needs in further steps.  All the rest of the information that is residing in the data bus of Opalis  .

This input is required, without it, the workflow won’t start. A popup will be presented when starting the workflow.

Now that we have all the necessary input required, we can continue with the creation of the virtual machine. In order to create a virtual machine, we need to provide some parameters, some of them will come from the Custom start step, others will have to be adapted per workflow.


Creating the virtual machine



These are the required parameters.

  • Name: This is the name that will be given to the virtual machine, we will get it from the Custom Start  where we filled in a name.
  • Datastore: This is the datastore that will host the virtual machine disk, we will get it from the Custom Start  where we filled in the datastore.
  • DiskMB: Since it was decided to have a fixed disk with a size of 100GB, we filled it in directly instead of asking it in the first step.
  • DiskStorageFormat: This is the thick or thin format, thin was decided as the default format.
  • MemoryMB: This is the amount of memory that will be given to the virtual machine, we will get it from the Custom Start where we filled in an amount of memory.
  • NumCPU: This is the number of CPU’s that will be given to the virtual machine, we will get it from the Custom Start where we filled in the number of CPU’s we need.
  • CD: It was decided that all VM’s will have a cd drive so we set this to true.
  • VMSwapFilePolicy: This will set the swapfile policy the states where the swapfile will be saved, it was decided to do this in the VM itself.
  • VMHost: This is the physical host where the VM will be hosted, this integration pack cannot provision on cluster yet so you need to choose a physical host.
  • GuestID: This is the OS version that will be installed on the VM.
  • Folder: This is the foldername where the VM will be installed as shown in the ESX console.

You can add more details trough the “optional properties” button. If all goes well, the workflow has created the virtual machine now.

Now we need to change some things on the virtual machine.


Getting the network adapter settings from the created virtual machine


First we need to change the network settings. The VM name, we get from the Custom Start , since this is a read action, no further settings are needed.

Alternatively, you can specify some filters to narrow the data that you receive back.

Alternatively, you can specify some filters to narrow the data that you receive back.


Now we will delete all the network connection that VMware made by default because they are useless to us.


Removing the network adapters from the virtual machine



The Network Adapter name is data that we got back from the read action above and the VM name is still the name entered at the Custom Start .

This will remove all network adapters from the VM, alternatively, you can specify filters if you only want to delete a specific adapter.


Adding the production network adapter to the virtual machine


Now we need to add a network adapter to the VM. The VM name is still the name we entered at the Custom Start .


The NetworkName is the name of the network that you want your network adapter connecting to.

The StartConnected specifies if it will be connected to the network or only added without being connected.

The Type is e1000 as this is the only VMware adapter SCCM can work with.

Now we do another step to get the properties from the newly created adapter so we can use the information to input the computer into SCCM.


Getting the production network adapter settings from the virtual machine



Now that we collected the necessary information for SCCM, we can import the computer into SCCM.

This is done by a powershell script that needs to input parameters, the name and the MAC address.


Adding the computer to SCCM


Now that the computer is known is SCCM, we need to add it to the collection that has the OSD advertised to it.


The is done by the following step.


Adding the computer to an SCCM collection


In the collection field, you can enter 2 things, either the name of the collection or the ID of the collection. What you enter must match the collection value type. If you enter an ID as shown here, the value type must be ID as well. The same is true for the computer where we use the name from the Custom Start step so the value type is name in this case.


Now that the VM is created and provisioned in SCCM, we are ready to deploy the operating system on it.

So let’s power on the VM.


Powering on the virtual machine


The only thing you need to power on a VM is the name and we still get the from the first step.


Now that the VM is booting up, SCCM can start the task sequence to deploy an operating system on the VM.

Meanwhile, we will check the progress in Opalis.


Getting the virtual machine deployment status


The advertisement ID is the ID as it is known in SCCM and the computer name is still the name as we specified in the first step.


Looping the task

Now since the OSD deployment takes some time to complete, we will let the step loop until it gets a result back from SCCM.



It will recheck every 300 second and will do this 8 times or when it gets back from SCCM that the deployment was successful in order not keep the loop while the deployment was finished faster then in 8 loops.


Getting the deployment result


Now we need to output the result to any medium you want (logfile, mail, …), I do an output to a text file as an example.

Conditional progress

Now how does Opalis know when to write to which log file?

This can be regulated by double clicking on the arrows. This is the arrow toward the success file.


As you can see, it will only follow this arrow when SCCM outputs a succeeded message for the advertisement. If not, it will take the other path towards the failed log file.


So , It is not so easy to get it all together , but if I may give a great tip: ” Write down all steps of your manual flow  and then try to translate them into an opalis workflow “


Hope it Helps ,

Kenny Buntinx

Opalis 6.3 : Integration pack error solution – “Failed to CoCreate IOpalisServerExtension"

6:49 am in Opalis, Opalis 6.3 by Kenny Buntinx [MVP]

At my customer , we had a weird issue when running our workflow. We had a workflow with a custom start that fired off , but failed at the moment we hit to “add resource to SCCM”.


It failed with a error message “Failed to CoCreate IOpalisServerExtension" as shown in the screenshot below.


It seems that sometimes the deploy action server wizard does not function fully. The action server will work for most things but you could get error message that the server could not create extension and so on. Probably the wizard fails in registering some components and you get error messages like this. In our case, it was only when using items from the SCCM integration pack.

Below you will find the log file on the “RunbookServers” :


But you can overcome this by doing a manual install First of the “runbook” server en then overwrite doing an install trough the deployment console.

Start the installer.



This is the welcome screen, follow the instructions of the next screenshots.


Now we still need to install the same management server through the Deployment console as you normally would. Start up the deployment manager with the “run as administrator” option.




After this procedure, all IP’s will work correctly.

Hope it Helps ,

Kenny Buntinx

Opalis 6.3 : Operator console and “Ghost” workflows/policies that seems to keep running for ever !

10:18 am in Opalis, Opalis 6.3 by Kenny Buntinx [MVP]

Today at my customer , we had a weird issue thru our operator console in Opalis 6.3. We had a workflow with a custom start that fired off , but failed with a error message “Failed to CoCreate IOpalisServerExtension". This issue had nothing to do with the fact that those workflows kept running in the Opalis Operator Console for eternity as shown in the screenshot below. We had no possibility even when we had the right to delete or stop those running policies. When you tried to stop those running policies , they said there where “No policies found that could be stopped”.



First thought was that it had something to do with Java cache as I am so in love with Java Smile . Answer after clearing cache was the same …

The answer to this is that there is a “known” issue ( I don’t know if its is a “known” issue as I found it after a long search on the internet ) where the log will retain "ghost" entries for running workflows.

So basically it will look like a workflow is running (in the designer and Operator Console) but no workflow is running. This is an operational issue that doesn’t effect runtime, meaning that although it LOOKS like these are running workflows… even though they aren’t… they don’t take up a request queue or impact runtime in any way.

If you call PSS they can give you a procedure to clean up these "ghost" entries or you can simply go into the OPALIS designer, right-click on the bogus instances, and delete them manually as shown in the screenshot below :




After you have cleaned out your "ghost" entries , you will see that there are no ghost entries left any more :




Hope it Helps ,


Kenny Buntinx