All posts in knowledge base @en

cmWatcher User Manual

Kategorien: Allgemein @en, cmWatcher @en, knowledge base @en
Comments Off on cmWatcher User Manual


You want to install and configure cmWatcher. Therefore you want to have the latest User Manual available.


This note contains the latest User Manual. Please use the following link to download ist:


How to install cmWatcher in a cluster

Kategorien: Allgemein @en, cmWatcher @en, knowledge base @en
Comments Off on How to install cmWatcher in a cluster


Your monitoring concept requests a high available monitoring solution for Microsoft System Center Operation Manager (SCOM) and SAP components. Therefore also connmove cmWatcher shoud be high avilable.

connmove cmWatcher supports a configuration in a Microsoft Failover Cluster environment. With this configuration, cmWatcher is protected against single Hardware outages and single Operating systems outages.

This article describes how to install and configure cmWatcher in a Microsoft Failover Cluster. It describes how to configure a generic service within the microsoft failover cluster role.



cmWatcher Failover Cluster configuration is supported in a two node configuration. Alike other cluster configuration, cmWatcher with its specific functionality has special demands on the cluster configuration:

IP Adresss:
The cluster Service does not need a specific IP adress, because cmWatcher connects to the systems and database. No connections goes to the cmWatcher installation directly

Cluster shared Storage
cmWatcher is normaly installed in c:program files. Of couse you can install it directly on a cluster shared disk. But while cmWatcher stores configuration and status items in the database, there is not really a need to do so. It’s suitable to install cmWatcher on both Cluster nodes on local disks.
Disadvantage off this local configuration: Patches of cmWatcher must be done on both nodes.


cmWatcher runs in a Microsoft Failover Cluster. connmove recomment the cluster configuration itself along to current Microsoft Failover Cluster configuration guidelines. connmove support this kind of configuration in Microsoft Failover Cluster with Windows Server version 2008 R2 and above, x64 bit only.


Installation of cmWatcher:

Install cmWatcher (for additional information, see the cmWatcher manual)  on the respective nodes of the cluster. Note: The cmWorker service has to be stopped. After the installation of the cmWatcher instances the database connection of one cmWatcher instance has to be configured. Then change to the directory of the cmWatcher “C:Program FilesConnmove GmbHcmWatcher” and copy the “cmWatcherSettings” file to the other nodes.

Creating cluster service:

Open the Failover Cluster Manager and click on “Create Empty Role”.


The new role will appear in the Roles list. Double clicking the role opens the properties window. Specify the name for the role and select the cluster nodes on which you have installed cmWatcher. Apply changes and close the window.


Right click on the role and select “Add Resource/Generic Service”.



The “New Resource Wizard” window opens. Choose the cmWorker service from the list and click next until the wizard finishes.




Right click on the role entry and choose “Start Role”.


The cmWorker service will now start on one of the specified cluster nodes.


You now succesfully completed the cmWatcher cluster installation.


cmShell for SAP version 1.11 is available

Kategorien: cmShell @en, knowledge base @en
Comments Off on cmShell for SAP version 1.11 is available


With version 1.11 cmShell for SAP features new commandlets which are about profile and job management and enables you to update preconfigured program parameters. See following examples for more informations on how to use these commands.

Profile management:


Returns a table with the existing profiles.




Returns all parameters of the profiles.




Sets or changes the specified parameter.

Set-CmSapProfileParameter -CmSapConnect $con -ProfileName EC1_DVEBMGS00_ERP -ParameterName ZTEST -ParameterValue “new parameter” -CreateBackup -DynamicChange


Removes the specified parameter from profile.

Remove-CmSapProfileParameter -CmSapConnect $con -ProfileName EC1_DVEBMGS00_ERP -ParameterName ZTEST -CreateBackup -DynamicChange


Job management:


Returns informations like the job steps or spool attributes of the specified job.




Variant management:


Changes values of a specified variant.

Set-CmSapVariant -CmSapConnect $con -Report SMIGR_CREATE_DDL -Variant SMIGRTEST -SelName P_MDB -LowValue X



Download and execute the cmShell for SAP Setup from the connmove download portal1. The setup wizard will guide you through the installation process.

If you have already installed an older version than 1.10 of cmShell for SAP, you have to do some actions before you can install the new version:

  • Unregister the cmdlets by using installutil: [Path to installutil.exe] –u [Path to CmCmdlets.dll]
  • Uninstall cmShell for SAP
  • Download and install the new version of cmShell for SAP


SQL Server AlwaysOn – no automatic failover when database files are lost

Kategorien: Allgemein @en, knowledge base @en, News @en
Comments Off on SQL Server AlwaysOn – no automatic failover when database files are lost

With SQL Server Release 2012, Microsoft has introduced a new high-availability technology named “AlwaysOn”. It comes integrated with the database software and extends Microsoft’s high-availability portfolio. AlwaysOn is intended to eventually replace Database Mirroring entirely (refer to High Availability Solutions – MS TechNet).

In this post, we would like to familiarize you with the AlwaysOn technology, but also investigate a constellation of problems that can arise from its use.

What is AlwaysOn?

The SQL Server AlwaysOn (AO) technology has been extensively researched and documented online. We would like to point you to the FAQ on Microsoft’s TechNet website (Microsoft TechNet – AlwaysOn FAQ) and this insightful blog post by Juergen Thomas: SQL Server 2012 AlwaysOn – What is it?.

To put it simply:

AlwaysOn is an alternative high-availability solution for SQL Server databases that is available alongside Database Mirroring (DBM) and SQL Server Clustering. Its objective is to combine the advantages of these two HA solutions, while eliminating all of their disadvantages.

AO mitigates the complexity of a clustered SQL Server instance by means of locally installed SQL Server instances with locally attached storage. As with DBM, the database exists locally on each server.

Other than with DBM, however, a database secured with AO can be addressed using a unique DNS name / IP address. The application that uses the database is not aware of a potential failover and does not have to address another database server at runtime.

Today, a wide variety of business processes is mapped in IT systems and their execution depends on the availability and proper functioning of the systems they are based on. Particularly when it comes to systems that drive business-critical processes, downtime can result in significant financial losses. Users and administrators need to know that the databases that are protected by high-availability technologies will be available at any time even in case of error (hardware failures and the like). But does AlwaysOn function reliably and as expected for every conceivable error?

How does SQL Server / the database protected by AlwaysOn respond if the primary connection is lost (failure of the hard disks or SSDs)?

To answer this question, we set up the following test environment:

  • Operating system platform Windows Server 2012 R2
  • SQL Server 2012 SP1 CU2 (the exact patch level is irrelevant, the following applies to all SQL Server 2012 versions starting with RTM)
  • iSCSI-connected (internet Small Computer System Interface) LUNs for the test database protected by AO
  • Setup of Windows Server Failover Clustering
  • Provision of a test database on the iSCSI LUNs
  • Setup of an SQL Server AO Availability Group


Figure 1: AlwaysOn test setup


As illustrated in figure 2, the databases on both AlwaysOn test servers are currently synchronized.

Figure 2: Synchronous databases in AO


Now we will try to simulate the failure of the primary disk connection by setting the hard disk on which the data files of the primary database reside to offline in the Disk Manager.

One would expect SQL Server 2012 to detect the failure and respond accordingly by triggering a failover.

Figure 3: Simulated hard disk failure

Upon switching to the AO dashboard and refreshing the AlwaysOn status, one will quickly see that despite the “failure” of the hard disk it still considers the databases to be synchronous. Even the SQL Server error log of the primary database instance does not indicate any problems seconds after the “failure” of the hard disk on which the data files of the database reside.

Critical status:

But as soon as one tries to access any database object in this database (in this case using SQL Server Management Studio), the following error message appears:

Figure 4: Message: DB cannot be accessed anymore, DB check is recommended


Based on this error message, an administrator would assume that the hard disk on which the data files of the primary database reside is defective and counteract by triggering a failover with AlwaysOn in order to open the database on the secondary side, which is assumed to be synchronous. It is fairly likely, however, that in this state SQL Server will no longer be able to fail over to the up-to-then synchronous second database! The SQL Server error log of the secondary database instance displays the following error message:


AlwaysOn: The local replica of availability group ‘AOGroupSLM’ is preparing to transition to the primary role in response to a request from the Windows Server Failover Clustering (WSFC) cluster. This is an informational message only. No user action is required.

The availability replica for availability group ‘AOGroupSLM’ on this instance of SQL Server cannot become the primary replica. One or more databases are not synchronized or have not joined the availability group, or the WSFC cluster was started in Force Quorum mode. If the cluster was started in Force Quorum mode or the availability replica uses the asynchronous-commit mode, consider performing a forced manual failover (with possible data loss). Otherwise, once all local secondary databases are joined and synchronized, you can perform a planned manual failover to this secondary replica (without data loss). For more information, see SQL Server Books Online.




The behavior shown by AlwaysOn in such cases is, at first, unexpected:

  • No failover is triggered if the status of a database protected by AO changes. Why is this the case?
    Because AlwaysOn does not perform an availability check on the database level. Other than Database Mirroring, AO just like SQL clustering allows for the logical grouping of multiple databases that can be failed over together if necessary. This must be considered when looking at its behavior. With AlwaysOn, availability is not checked and assessed on the level of individual database, but rather on the level of the SQL Server instance and the AO Availability Group. This is what sets it apart from the Database Mirroring behavior, which checks the availability of the individually protected databases and triggers a failover as soon as the availability of the database on the primary server is affected.

    The following information can be found in SAP Note 1772688 (login required):
    “The latter point also forced a change in the granularity of health checks or indications which would trigger a failover. In DBM the close of a database as result of e.g. a disk failure will trigger a failover (if automatic failover is configured). Whereas in AlwaysOn the health checks are mainly around the Availability Group and the SQL Server instance running the Availability Group as primary. But health detection is not checking the health of the individual databases which are contained in an Availability Group. As a result a database within an Availability
    Group can be closed, triggered e.g. by a disk failure without the AG moving into an unhealthy state or triggering a failover (if automatic failover got configured). This is a drastic change in behavior and coverage area compared to DBM. Especially in the case of disk failures which as a secondary effect cause affected SQL Server databases to close, DBM triggered a failover, whereas AlwaysOn in its default settings won’t trigger a failover.”

  • Following a storage defect on the primary side, the databases are assumed to be out of sync, making it necessary to open the secondary database, which is actually synchronous, as if it were an asynchronously replicated database (‚with allow_data_loss’).
    The actual status of the secondary AO database, however, is identical to that of the secondary DBM database for a similar database error. The databases are equally synchronous or asynchronous with both technologies, but AlwaysOn is more conservative in its assessment than DBM and changes the status of the secondary database to out-of-sync (which is always is case an asynchronously mirrored databases or asynchronous AO).


The behavior when log or data files are lost is the same for both AlwaysOn and Database Mirroring until the protected database is closed. Here, the difference between the two HA solutions lies in their level of automation. AlwaysOn will only provide high availability for as long as the integrity of the database files of the current primary database is maintained. In cases, however, where the primary database is lost due to problems such as storage/SSD failure or iSCSI connection loss, the database, depending on its runtime status, is marked as “out of sync” and requires manual intervention. Database Mirroring on the other hand will, depending on its configuration, automatically fail over to the mirror when data or log files are lost.

From a data consistency perspective, there is no reason not to use the SQL Server AlwaysOn high availability solution, if SLAs are continued to be met after manual intervention and starting the mirror.

ITSM Integration powered by easyCloud

Kategorien: knowledge base @en
Comments Off on ITSM Integration powered by easyCloud


What has been standard within the classical manufacturing and other producing industries for several decades becomes more important to IT organizations nowadays: tailoring standard processes from best practices and implementing these processes with the help of integrated software.

Many IT organization – independently if internal or external – currently concentrate their strategical activities on adopting and implementing IT processes like those found in the ITIL framework. However, not only the processes itself are introduced, further more tools and software suites are being implemented to support these processes.

These described circumstances lead to several challenges, which can be divided into organizational and technical challenges. On the one hand, changing the processes – and therefore the way people used to act for a certain time – is not always easy. On the other hand, as soon as these processes are agreed upon, the chosen tools or tool suites need to communicate and integrate into the existing landscape. Commonly, this results in integrating a multitude of different platforms, applications and technology components into one leading ITSM tool (suite).

SAP applications – like SAP ERP, SAP BW, SAP CRM etc. – often act as important part of the offered service portfolio, supporting the established business processes and business services. The integration of ITSM processes and SAP ALM processes is therefore an important topic to be discussed. In addition, the concrete integration of ITSM software with SAP software needs to be discussed.

This blog post is not about how to choose ITSM software or what software should be used. Further on, this blog will not give an overview of what ITIL or ITSM and how to implement ITSM processes within organizations. This blog is rather about the integration of SAP solutions into an existing or newly implemented Non-SAP-ITSM software (e.g. like Microsoft System Center Service Manager, ServiceNow, BMC, etc.). It tries to answer questions about what might be suitable for integration and how to integrate it.

Possible Scenarios

First of all, let us have a closer look on possible scenarios, where an integration makes sense. During some customer projects, four main areas emerge as the key points of interest and integration: Change Management, Incident Management, Event/Capacity Management and CMDB design. Within the next few chapters, these scenarios will be detailed and evaluated. Possible solutions will be recommended in the trailing chapters of this blog post.

Change Management

SAP has its own processes established for a – more or less – technical change management: SAP Transport Management System. The STMS defines transportation routes between SAP systems and “packages” every modified or newly created object into a transport request, which can be transported within the landscape. Further on, SAP delivers Change and Request Management (ChaRM) as part of the SAP Solution Manager. ChaRM implements change request management processes with a tight integration into the underlying SAP technology (e.g. STMS).

So, if SAP offers its own its own implementation of Change and Request Management, why should one think about integration? Wouldn’t it be easier to use SAP’s ChaRM for SAP changes? Indeed – but then there would be at least two entry points: one request entry for SAP changes, one entry point for Non-SAP changes. Moreover, what needs to be done, if the change is for SAP and Non-SAP?

Therefore, the first reason to integrate SAP and Non-SAP ITSM is a central entry point for Change Management. This way, key users and change managers can create and track Change Requests during their way towards becoming a change and being implemented. In addition, this should be possible on a higher level, independent from the application and infrastructure underneath.

The second reason, from the perspective of the application owner, is traceability and auditability of changes made to the offered IT services, especially changes made to critical SAP applications. Even if the application owners use their own software for technical or non-technical change management, redundant maintenance of information should be avoided – as far as possible. An integration between a central ITSM tool and the SAP Change Management would solve this issue by either integrating the process layer from the ITSM tool with SAP ChaRM or directly with the SAP TMS.

Event Management

The next possible integration scenario is based on the requirements for a central event management. Common organizations have an SAP Basis team, which monitors their SAP systems on a daily basis. By introducing a central management and monitoring system of IT Services and IT Service Management, monitoring of available IT Services and the underlying applications and infrastructure should be done within these central applications. Critical events should be forwarded to the central software for monitoring and event management. For further analysis, it is – as with any other application – required to work with the SAP system itself. Nevertheless, alerting can be done centrally, which also makes it easier to aggregate and report these information. Furthermore, these information can be used as foundation for SLA reporting.


Another example for integrating SAP and a third party ITSM tool is the enrichment of the central CMDB with SAP Applications, SAP Application Components and versions. This way one has a CMDB with all these SAP related information automatically maintained within the central CMDB, which makes the process integration, e.g. within Incident Management, much easier and much more comfortable.

Incident Management

The integration between the Incident Management process and SAP is also a common requirement. Adding additional information for incident tickets is always helpful for solving the incident. Either through adding information directly while creating the incident, or by enriching the incident ticket while working on it, the incident resolution can be accelerated.

As example, an incident ticket could be enriched by general information like the SAP System, the installed application components and versions and further on, additional information about the user could be added. This may include the locked-status of the user or recent authorization issues, which are helpful for processing and solving the incident, but also for using the incident database as Knowledgebase.

Overview on EasyCloud cmShell for SAP

Kategorien: cmShell @en, EasyCloud @en
Comments Off on Overview on EasyCloud cmShell for SAP


This note shows the current available EasyCloud cmShell Function, available in current Release by February 2014.


Function-Name Description Module
Get-CmClusterNodes Get information about one or more nodes (servers)   in a failover cluster. SAP
Add-CmSapUser Create a new Sap user. SAP
Get-CmSapSM51 Returns a table with the status of the SAP   instances. SAP
Get-CmSapReportSRC Returns the source code of   the specified report. SAP
Set-CmSapTMSRequest Creates a new change request. SAP
Get-CmSapUserAuthorizationData Checks if a user has   authorization issues. SAP
Get-CmSapTMSRequestDoc Returns the current documentation of a transport   request SAP
Get-CmSapTMSObjects Returns all Object of a   specific  transport request SAP
Get-CmSapTMSList The function reads all request data for the   request. SAP
Add-CmSapTMSRequest  Appends the repository objects specified in   IT_OBJECTS into the request IV_REQ_ID. SAP
Get-CmSapTMSRequests Selects all changeable change requests from a   system. SAP
Add-CmSapTMSRequestDoc Edit the documentation of   a request SAP
Import-CmSapTMSRequest Import transport requests into a system. SAP
Release-CmSapTMSOrder Release transport Request OSWIN
Release-CmSapTMSRequest Release transport task or request SAP
Get-CmSapUserDetails Returns detail   informations of a user SAP
Get-CmSapSLDComponents Access a SLD and find a SAP system. Get information   about the installed software components and associated support packages. SAP
Get-CmSAPJobSpoolList Read spool list of a job   that has been run. SAP
Set-CmLicense Enter licensekey to activate the product. For   further information contact Other
Save-CmCluster Saves the whole failover   cluster to a configuration file. OSWIN
Move-CmClusterGroup Moves a clustered service or application from one   node to another in a failover cluster. Moving a resource group is a way of   simulating failover. It is also an appropriate step to take in preparation   for routine maintenance on a node. You can move a single group or all group   of a node. OSWIN
Restore-CmCluster Restores a single node or   the whole failover cluster from a configuration file. By default no   group/application will be restarted/shutdown. OSWIN
Start-CmSAPEvent Raising an event SAP
Set-CmSAPJobStep Creates a jobstep-list   that you can use for Set-CmSAPJob. SAP
Set-CmSAPJobPrintParameters Creates an object with print parameters that you   can use for Set-CmSAPJobStep. SAP
Set-CmSAPJobAuditLevel Use this cmdlet to   determine the global audit level for the XMISESSION log. The audit level   controls which messages are logged with sessions with the CCMS system   administration interfaces. SAP
List-CmSAPJobsWithStatus Determines the status of a list of jobs by reading   AS ABAP information on all jobs. SAP
List-CmOsInstalledUpdates Returns a list of the   installed updates. OSWIN
Get-CmSAPVariants Returns a table with the variants of specified   reports SAP
Get-CmSapTable Reading SAP database   tables SAP
Invoke-CmSE38 Runs an ABAP program. SAP
Get-CmSAPJobVariantInfo For a given ABAP the   variants are read. SAP
Get-CmSAPJobStatus Determines the status of a job by reading AS ABAP   information on the job. SAP
Get-CmSAPJobResources You can use this function   module to determine whether background work processes are available at a   particular time on any server in the AS ABAP system. SAP
Get-CmSAPJobLog Get job log (also called job protocol) for a   particular job. SAP
Get-CmSAPJobIntercepted Retrieves jobs which have   status INTERCEPTED SAP
Get-CmSAPJobChildren Get all children created by a job and return them   in an internal table. SAP
Get-CmOsPendingReboot Checks if the specified   system need to reboot. OSWIN
Cancel-CmSAPJob Abort a running job. SAP
Get-CmSapIDOC Returns data from table   ‘EDIPORT’. SAP
Get-CmSAPHostConnect SAP
Get-CmSapFILE Returns data from table   ‘PATH’. SAP
Get-CmSapALE Returns data from table ‘EDIPOA’. SAP
Get-CmRZ12 Gets a list of RZ12 RFC   Server Groups. SAP
Get-CmCredfileEntries  Returns the   data of stored credentials. Other
Add-CmCredfileCredentials You can use this command   to store your credential into the credfile. The credentials will be   encrypted. Other
Remove-CmCredfileCredentials Removes the credential for the specified id Other
Set-CmSM51 Change the status of the   specified SAP instance. SAP
Set-CmRZ12 Adds a new RFC Server Group assignment. SAP
Remove-CmRZ12 Removes all assignments   from the RFC Server Group that you want to delete or from which you want to   remove an instance. SAP
List-CmSapJobServerGroup Lists the names of the SAP JobServerGroups assigned   to the specified SAP instance. SAP
Get-CmSM59 Gets a list of RFC   Connections. SAP
Get-CmSapSystemType Returns data from table ‘T000’. SAP
Get-CmSapMAIL Returns data from table   ‘SXNODES’. SAP
Get-CmSapInstanceInformations Loads more informations of the specified instance. SAP
Invoke-CmSapGuiScripting Load and run a recorded   SAP GUI script. SAP
Close-CmSapGuiConnect Closes the SAP GUI connection and all sessions. SAP
Get-CmSapGuiConnect Opens a connection to the   given SAP system for scripting. The Connection is opened using the assigned   credentials. As soon as a connection has been established a session is   created. SAP
Set-CmSapJobServerGroup Creates a new job background server group to manage   background job processing on a SAP system. SAP
Remove-CmSapRole The cmdlet deletes the   specified activity group assignment for user SapUserName. SAP
Remove-CmSapProfile This cmdlet deletes all of the profile assignments   of the user SapUserName. SAP
Remove-CmSapJobServerInstance Remove a SAP server   instance assignment to a jobserver group in background processing. SAP
Remove-CmSapJobServerGroup Remove a job background server group with all   assignments. SAP
Get-CmSqlConnect Initializes a new instance   of the CmSqlConnection class and returns    a (closed) connection object to the given SQL Server database. DBSQL
Invoke-CmSqlCommand You can use this Cmdlet to perform catalog   operations (for example, querying the structure of a database or creating   database objects such as tables), or to change the data in a database by   executing UPDATE, INSERT, or DELETE statements. DBSQL
Get-CmSapRole This cmdlet connects to   the SAP System and gets a list of all by the identity management provided   user. SAP
Confirm-CmSapUser The method checks that the user SapUserName exists SAP
Add-CmSapRole This method adds a user   role assignment (ActivityGroup). SAP
Add-CmSapProfile This Cmdlet adds a profile assignments for user   SapUserName in a table called PROFILES. All existing assignments will be   kept. SAP
Add-CmSapJobServerInstance Assign a SAP server   instance to an existing job server group. SAP
Start-CmSAPJob Start a job immediately. SAP
Select-CmSAPJob Select a set of jobs in   the SAP R/3 system that match the selection criteria given. By default the   username  is set to the SAP log on name   and the job name is partly specified using wildcards (*). Further more the date   to start from is set to the current date by default and all job selection   criteria (scheduled, released, ready, active, finished, canceled) except   released are chosen. SAP
Remove-CmSAPJob Delets a not running job. SAP
Set-CmSAPJob Create a new SAP   background job with on Step. SAP
Copy-CmSAPJob With this CmdLet you can copy a job definition   including all definition data, except for the start conditions. The copy has   the status ‘scheduled’. A name can be specified for the target with the   parameter target_jobname. If no name is specified, the target job has the   same name as the source job. SAP
Set-CmSMLGLogonGroup Adds a Logon Group /   Instance name assignment. SAP
Get-CmSMLGLogonGroups Gets a list of SMLG Logon Groups. SAP
Remove-CmSMLGLogonGroup Removes all assignments   from the logon group that you want to delete or from which you want to remove   an instance. Use -LogonGroup “Logon Group Name” or set the first   parameter to “LogonGroupName” to delete the desired log on group . Groups   will be removed by default. To remove an instance you have to use named   parameter: -InstanceName “InstanceName” to remove the assignments   of the instance from all logon groups. SAP
Set-CmSM02 Creates a System Message SAP
TypeOf-CmSAPInstance Checks the type of the SAP   Instance, returning the SAPInstance feature list. SAP
Test-CmSAPInstance Checks the running status of the SAP Instance,   returning the SAPControl color code. SAP
Stop-CmSAPInstance Stops immediately an SAP   Instance by reference, system number or list without any further inquiries. SAP
Start-CmSAPInstance Starts an SAP Instance by reference, system number   or list. SAP
List-CmSAPInstance Returns a list of all   instances of the SAP system. features identifies the instance type (ABAP,   J2EE, GATEWAY, MESSAGESERVER, ENQUE, ICMAN, TREX, IGS, ENQREP), e.g.:   Dual-stack dialog instance: “ABAP|J2EE|GATEWAY|ICMAN”
Test-CmOsUpdates Searches for all the applicable software updates   and list them. Checks whether updates are available, returns True / False.   The optional parameter “mandatory” limits the review to absolutely   necessary updates. If the parameter is not specified checks for updates   without restriction. OSWIN
Search-CmOsUpdates Searches for all the   applicable software updates and list them. OSWIN
Restart-CmOsUpdates Immediately performs system shutdown and restart   without any further confirmation. OSWIN
Measure-CmOsUpdates Gets the number of   applicable software updates. OSWIN
Install-CmOsUpdates Installs all previously downloaded updates   (presupposes the execution of the Get-Command). Returns a list of updates and   their installation status. By the optional parameter “reboot” an   automatic restart after installation can be initiated if necessary. If the   parameter is not specified an automatic restart will be initiated. OSWIN
Set-CmLocalSecurityPolicy Sets user or group rights.   Manipulates rights on local or a remote computer. This function use NTRights   utility (Ntrights.exe). OSWIN
Get-CmCluster Establishes a connection between the Cluster   manager and the PowerShell. DBSQL
Close-CmCluster Closes CmCluster   connection. DBSQL
Close-CmSapConnect Close a SAP Connection explicitly. SAP
Start-CmLocalProcess Starts an application in a   new process on the local host. OSWIN
Measure-CmFreeSpace Calculates the available free spacce on a host   drive. OSWIN
Get-CmXmlValues Returns the values which   could be determined using the specified XPath-expression. OSWIN
Get-CmSapConnect The SAP Connect module establishes a connection   between the SAP instance the PowerShell. SAP
Get-CmPageFilePath Gets the location of the   Windows PageFile. The paging file is a reserved space on disk that backs up   committed physical memory on the computer. OSWIN
Get-CmOsVersion If a computer has multiple operating systems   installed, this class only returns an instance for the currently active   operating system. Version number of the operating system. OSWIN
Get-CmOSLCID Gets the locale ID of the   host.. As defined by Microsoft, a locale is either a language or a language   in combination with a country. OSWIN
Get-CmOsConnect Gets an connection object to the user account on   the remote host, returning an CmOSConnection object.  The connection objects gives you access to   the WMI of the remote computer. OSWIN
Get-CmLicenseInformation Shows details of the   entered license. OSWIN
Get-CmGroups Returns a list of group accounts. OSWIN
Disconnect-CmSAPHost Closes the connection   holded by the web service. SAP
Connect-CmSAPHost The start service offers its Web service interface   on port sapctrl<NR> (HTTP) where “<NR>” corresponds to   the SAP instance number (00.98). If the ports are not defined in   etc/services, the default values 5<NR>13 (HTTP)  are used. The port 50013 will be used by   default if no port number was given. SAP
Compare-CmObject These overloaded operator   method perform the appropriate comparison operation, between obj1 and   obj2.Both obj1 and obj2 can be either a string (obj1s, obj2s) object or a double   (obj1d, obj2d).

Acceptable operators are:

“eq”: equal
“ne”: not equal
“lt” : less than
“le”: less or equal
“ge”: greater or equal
“gt”: greater than

Add-CmGroupUser Adds an existing user account to an existing group   on the local host. The process must have administrative privileges. OSWIN
Measure-CmPageFileSize Gets the size of the   PageFile. The paging file is a reserved space on disk that backs up committed   physical memory on the computer. OSWIN
Measure-CmRAMSize Calculates the available RAM on the host. OSWIN
Remove-CmLocalSecurityPolicy Removes user or group   rights. Manipulates rights on local or a remote computer. This function use   NTRights utility (Ntrights.exe). OSWIN
Set-CmXmlValues Sets the specified value at all nodes which could   be determined using the specified XPath-expression. OSWIN
Start-CmProcess Starts an application in a   new process on a remote host. OSWIN
Test-CmAdminPrivilege Checks if you have Administrator rights on your   computer. OSWIN
Test-CmGroupUser Checks if the user account   is assigned to a group on a local, remote or domain user administration. OSWIN
Test-cmPowerOption Checks whether the power plan is the active plan on   the system. A power plan or scheme consists of a group of power settings and   preference information. Each power plan is identified through a unique GUID   as well as by a friendly name. OSWIN
Test-CmProcess Checks whether the   Microsoft Management Console is running on that host using an CmOsConnect   object. OSWIN

cmShell for SAP version 1.10 is available

Kategorien: cmShell @en, knowledge base @en
Comments Off on cmShell for SAP version 1.10 is available


Now it is possible to load the CmCmdlets with Import-Module when you use PowerShell 3 or above. Add-PSSnapin is still supported.

If you load the CmCmdlets with Import-Module, you will get a warning message (cmdlet names include unapproved verbs). You can ignore this message.

We have changed the names of some comandlets. Please use the new names of the comandlets in your scripts.

Obsolete name New name
List-CmSapJobServerGroup Get-CmSapJobServerGroup
Cancel-CmSapJob Stop-CmSapJob
List-CmSapJobsWithStatus Get-CmSapJobsWithStatus
Release-CmSapTMSRequest Set-CmSapTMSRequestRelease
Release-CmSAPTMSOrder Set-CmSapTMSOrderRelease
List-CmOsInstalledUpdates Get-CmOsInstalledUpdates
List-CmSapInstance Get-CmSapInstances
TypeOf-CmSapInstance Get-CmSapInstanceType


Download and install the cmShell for SAP Setup from Downloads.

If you have already installed an older version of cmShell for SAP, you have to do some actions before you can install the new version:

  • Unregister the cmdlets by using installutil: [Path to installutil.exe] –u [Path to CmCmdlets.dll]
  • Uninstall cmShell for SAP
  • Download and install the new version of cmShell for SAP

Note: SAP GUI pop-up message appears when invoking a cmdlet

Kategorien: cmShell @en, knowledge base @en
Comments Off on Note: SAP GUI pop-up message appears when invoking a cmdlet


Some Cmdlets like Get-CmSapUserAuthorizationData need the SAP GUI for the execution. It could happen that the following pop-up message is displayed:


The cmdlet waits until the popup is confirmed. For the automatic execution of cmdlets eg with the Orchestrator, the following configuration must be performed.



Start the SAP GUI. Click with the right mouse button on the icon in the upper left corner and select Options.



In the new window, select Security / Security Settings and click on Open Security Configuration.



Now set the drop down box of Default Action to Allow. Confirm the change.


Configuration MAI on non Windows servers

Kategorien: cmWatcher @en, knowledge base @en
Comments Off on Configuration MAI on non Windows servers


If your SAP Solution Manager does not runs on a Windows server, the configuration for cmWatcher is a little bit other as described in the cmWatcher manual.

Because it is not possible to pass the alerts directly from the SAP system to the cmWatcherMAI2SCOM tool, the alerts must be stored in a shared folder which is accessible from the SAP Solution Manager server and the server where the cmWatcher is installed. Then, the SAP system can save the alerts in the folder and the cmWatcher can take them from there.


Create a new shared folder and mount it to your SAP Solution Manager server.
In our example, we call the folder cmWatcherShare. The folder contains a subfolder called alerts and a file with the following content:

 echo $@ >> /cmWatcherShare/alerts/$filename

The script has the following function: It takes two parameters. The first is the file name and the second is the content of the file. The script creates in the folder alerts a file with the given file name and the content.

If you have not yet configured the connection to the database for the cmWatcher open its programs folder and execute cmWatcherMAI2SCOM.exe.
The form for providing the database settings will appear. Fill out the form and click Connect.

Log on to Solution Manager using SAPGui, open transaction SM49 (External Operating System Commands) and create a new entry. Set the command name and the path to the Option Additional Parameters Allowed must be checked.


Configure your SAP system as described in guide HOW-TO GUIDE OS Command Adapter.pdf. In section 3.1.1 of this guide set the external command which we have just created.

Section 3.1.2 (OS Command Parameters) describes how to configure the parameters for:

Configuration ID Extra key combination

Download the file CmWatcherMAIConfig_NonWin.xml from this post, open it and scroll down to the bottom. You will find an entry similar to:


Replace SID with the system ID of your SAP system and save the changes.

Now return to the browser as described in section 3.1.2 and select configuration option:

Configuration ID Extra key combination

Under Configuration details click View as XML to open the upload dialog. Click Browse, select the CmWatcherMAIConfig_1.xml file and click Perform upload. Repeat these steps for configuration option:

Configuration ID Extra key combination



Configuration of cmWatcher

Open the cmWatcher GUI, go to tab SAP, select the respective entry and choose Modify Entry to open the SAP System Settings dialog. Go to tab SAP MAI and select option Enable MAI.


Save the changes.


Create a scheduled Task for CmWatcherMAI2SCOM.exe:

Once we the Solution Manager creates the alert-files in the shared folder, we have to configure the CmWatcherMAI2SCOM tool to collect and store them into the database. For that we create a scheduled Task which executes our tool each x minutes.


Steps to create the scheduled task:

  • Open the Windows Task Scheduler and create a new task.
  • Enter a name for the task. If you selected Windows Authentication for the cmWatcher database connection, the user account with which the task will be executed must have privileges for the database.
  • Change to tab Triggers and create a new one. Set the options similarly tot he picture:
  • Change tot ab Actions and click on New. Set the Action field to Start a program. For Program/script browse the cmWatcher program directory and choose cmWatcherMAI2SCOM.exe. In the field Add arguments set PATH <Path to alerts folder>. For Example: PATH \cmWatcherSharealerts


The configuration is now complete.

Note: Update cmWatcher to Version 3.14

Kategorien: cmWatcher @en, knowledge base @en
Comments Off on Note: Update cmWatcher to Version 3.14


connmove released a new Version of cmWatcher which supports the SAP Solution Manager Monitor and Alering Infrastructure (MAI) for SCOM.


You already use cmWatcher and want do update to this new version. If your current version is higher than 3.11. this note explain the upgrade path.

If you use cmWatcher Version < 3.11, please follow section “Steps if you have an older version” in this note.


Steps for updating cmWatcher:

  • Uninstall cmWatcher.
  • Download the latest version of cmWatcher from
  • Unzip the downloaded file and install cmWatcher.
  • Update cmWatcher database:
    • Open the file CmWatcherDBUpdate.sql which is contained in the program directory of cmWatcher.
    • You will find the line USE [cmWatcher]. If you have named your database other than cmWatcher, edit the line.
    • Execute the script.
  • Open the cmWatcher GUI, go to the tab SCOM, select the respective entry and choose Install Management Pack.

For further informations on how to configure cmWatcher see the manual (you can find it in the file).

Steps if you have an older version:

  • Uninstall cmWatcher.
  • Remove cmWatcher Management Pack from SCOM.
  • Delete database of cmWatcher.
  • Download the latest version of cmWatcher from
  • Unzip the downloaded file and install cmWatcher.
  • Install/Configure cmWatcher as described in the manual (you can find it in the file).