All posts in Knowledge Base

cmWatcher User Manual

Kategorien: Allgemein, cmWatcher, Knowledge Base
Kommentare deaktiviert für cmWatcher User Manual

Intro

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

Solution

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

„connmove_cmWatcher_UserManual_EN“.


How to install cmWatcher in a cluster

Kategorien: Allgemein, cmWatcher, Knowledge Base
Kommentare deaktiviert für How to install cmWatcher in a cluster

Intro

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.

Solution

Architecture:

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.

Prequesites:

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 Files\Connmove GmbH\cmWatcher“ and copy the „cmWatcherSettings“ file to the other nodes.

Creating cluster service:

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

FailoverClusterManager

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.

FailoverClusterManager_RoleProperties

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

FailoverClusterManager_RoleAddRessource

 

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

FailoverClusterManager_RoleSelectService

FailoverClusterManager_RolePropertiesConfirmation

FailoverClusterManager_RolePropertiesSummary

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

FailoverClusterManager_StartRole

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

FailoverClusterManager_RunningRole

You now succesfully completed the cmWatcher cluster installation.

 


cmShell for SAP version 1.11 is available

Kategorien: cmShell, Knowledge Base
Kommentare deaktiviert für cmShell for SAP version 1.11 is available

Intro

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:

Get-CmSapProfiles

Returns a table with the existing profiles.

Example:

GetCmSapProfiles_Example

Get-CmSapProfileParameters

Returns all parameters of the profiles.

Example:

GetCmSapProfileParameters_Example

Set-CmSapProfileParameter

Sets or changes the specified parameter.

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

Remove-CmSapProfileParameter

Removes the specified parameter from profile.

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

 

Job management:

Get-CmSapJobDetails

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

Example:

GetCmSapJobDetails_Example

 

Variant management:

Set-CmSapVariant

Changes values of a specified variant.

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

 

Solution

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

1http://connmove.eu/software/downloads/


ITSM Integration powered by easyCloud

Kategorien: Knowledge Base
Kommentare deaktiviert für ITSM Integration powered by easyCloud

Introduction

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.


CMDB

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.


SQL Server AlwaysOn – kein automatischer Failover bei Verlust von Datenbank-Files

Kategorien: Allgemein, Knowledge Base
Kommentare deaktiviert für SQL Server AlwaysOn – kein automatischer Failover bei Verlust von Datenbank-Files

SQL Server AlwaysOn – kein automatischer Failover bei Verlust von Datenbank-Files

Seit SQL Server Release 2012 stellt Microsoft eine neue Hochverfügbarkeitstechnologie namens „AlwaysOn“ zur Verfügung, die in die Datenbanksoftware integriert ist und das bestehende Angebot an Hochverfügbarkeitslösungen ergänzt. In Zukunft soll AlwaysOn den Datenbankspiegel sogar komplett ablösen (siehe Hochverfügbarkeitslösungen – MS Technet)

In diesem Beitrag möchten wir die AlwaysOn-Technologie näher erläutern, uns aber auch einer Problemkonstellation widmen, die mit deren Einsatz auftreten kann.

Was ist AlwaysOn?

Die SQL Server AlwaysOn (AO) Technologie ist bereits umfassend online beschrieben und dokumentiert. Besonders hervorzuheben sind die FaQ auf den Technet-Seiten von Microsoft Microsoft Technet – AlwaysOn FAQ sowie dieser sehr anschauliche Blogbeitrag von Jürgen Thomas: SQL Server 2012 AlwaysOn – What is it?

Kurz gesagt:

AlwaysOn ist neben Database Mirroring (DBM) und Clustering des SQL Servers eine alternative Hochverfügbarkeitslösung für SQL Server Datenbanken, deren Ziel es ist, alle Vorteile aus der Kombination der beiden genannten HA-Lösungen zu vereinbaren und gleichzeitig deren Nachteile auszumerzen.

Die Komplexität einer geclusterten SQL Server Instanz wird bei AO durch lokal installierte SQL Server Instanzen mit lokal angebundenem Storage vermieden. Die Datenbank ist wie bei DBM auf jedem Server lokal vorhanden.

Im Gegensatz zu DBM lässt sich eine über AO abgesicherte Datenbank über einen einheitlichen DNS-Namen / IP-Adresse ansprechen. Die Applikation, die die Datenbank nutzt, hat somit Transparenz über einen eventuell erfolgenden Failover und muss nicht zur Laufzeit einen anderen Datenbankserver ansprechen.

Zahlreiche Geschäftsprozesse werden in der heutigen Zeit in IT-Systemen abgebildet und deren Ausführung erfordert die Verfügbarkeit und korrekte Funktionsweise der zugrundeliegenden Systeme. Besonders bei Systemen, die von geschäftskritischen Prozessen genutzt werden, kann Nichtverfügbarkeit zu hohen finanziellen Verlusten führen. Nutzer bzw. Administratoren müssen sich daher darauf verlassen können, dass die durch die Hochverfügbarkeitstechnologie abgesicherten Datenbanken auch im Fehlerfall (Hardwareausfälle und dergleichen) jederzeit erreichbar sind. Doch funktioniert AlwaysOn in jeder denkbaren Fehlersituation zuverlässig und wie zu erwarten?

Wie reagiert SQL-Server bzw. die durch AlwaysOn gesicherte Datenbank auf den Verlust der primären Anbindung (Ausfall der Festplatten oder SSDs)?

Um diese Frage zu klären haben wir folgende Testumgebung aufgebaut:

  • Betriebssystem-Plattform Windows Server 2012 R2
  • SQL Server 2012 SP1 CU2 (dabei ist der genaue Patchlevel unerheblich, das Folgende gilt für alle SQL Server 2012 ab RTM)
  • Anbindung der LUNs für die durch AO abgesicherte Test-DB mit iSCSI (internet Small Computer System Interface)
  • Einrichtung von Windows Server Failover Clustering
  • Bereitstellung einer Test-DB auf den iSCSI-LUNs
  • Einrichtung einer SQL Server AO Verfügbarkeitsgruppe

     

Abbildung 1: AlwaysOn Testaufbau

Wie in Abbildung 2 ersichtlich ist, befinden sich die Datenbanken momentan auf den beiden AlwaysOn Testservern in einem synchronisierten Zustand.

Abbildung 2: Synchrone Datenbanken im AO

 

Nun versuchen wir, den Ausfall der primären Disk-Anbindung zu simulieren, indem wir die Festplatte, auf der die Datenfiles der primären Datenbank liegen, im Disk Manager offline setzen.

Zu erwarten wäre, dass SQL Server 2012 den Ausfall bemerkt und entsprechend mit einem Failover darauf reagiert.

Abbildung 3: Simulierter Festplattenausfall

Wechselt man nun zum AO-Dashboard und refresht den AlwaysOn-Status, sieht man jedoch, dass dieses trotz „Ausfall“ der Festplatte weiterhin davon ausgeht, dass die Datenbanken synchron sind. Auch das SQL-Server Errorlog der primären Datenbankinstanz verzeichnet selbst Sekunden nach dem „Ausfall“ der Festplatte, auf der eigentlich die Datenfiles der Datenbank liegen, keine Probleme.

Kritischer Status:

Beim Zugriff auf ein beliebiges Datenbankobjekt in dieser Datenbank (hier mittels SQL Server Management Studio) erscheint dann allerdings folgende Fehlermeldung:

Abbildung 4: Hinweis: Zugriff auf DB nicht mehr möglich, DB-Check wird empfohlen

 

Als Administrator würde man basierend auf dieser Fehlermeldung vermuten, dass die Festplatte, auf der die Datenfiles der primären Datenbank liegen, defekt ist und als Korrekturmaßnahme einen Failover über AlwaysOn auslösen, um die Datenbank auf der vermeintlich synchronen sekundären Seite zu öffnen. Doch SQL Server kann in diesem Zustand mit gewisser Wahrscheinlichkeit nicht mehr auf die bis dahin synchrone zweite Datenbank failovern! Im SQL Server Errorlog der sekundären Datenbankinstanz taucht folgende Fehlermeldung auf:

 

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.

 

 

Fazit:

AlwaysOn verhält sich in einem solchen Fall auf den ersten Blick hin unerwartet:

  • Es wird kein Failover ausgelöst, wenn sich der Status einer der durch AO abgesicherten Datenbank ändert. Warum ist das so?
    Weil AlwaysOn keine Verfügbarkeitsprüfung auf Datenbankebene ausführt. Im Gegensatz zum Datenbankspiegel bietet AO wie SQL-Clustering die Möglichkeit, mehrere Datenbanken logisch zu gruppieren und bei Bedarf gemeinsam zu failovern. Dies ist für die Betrachtung des Verhaltens von entscheidender Bedeutung. Die Prüfung und Bewertung der Verfügbarkeit findet bei AlwaysOn nicht auf Ebene der einzelnen Datenbank statt, sondern auf der Ebene der SQL Server Instanz und der AO Availability Group. Dies ist ein entscheidender Unterschied zum Verhalten von Database Mirroring, denn Mirroring prüft die Verfügbarkeit der einzelnen abgesicherten Datenbanken und löst auch dann einen Failover aus, wenn die Verfügbarkeit der Datenbank auf dem primären Server beeinträchtigt ist.

    Dies ist im SAP Hinweis 1772688 (Login nötig) nachzulesen:
    „Letzteres hat auch eine Änderung in der Granularität von Health-Checks oder Indikationen erzwungen, die einen Failover auslösen könnten. Das Schließen einer Datenbank infolge von z.B. einem Datenträgerausfall löst in DBM einen Failover aus (wenn ein automatischer Failover konfiguriert ist). Wohingegen die Health-Checks in AlwaysOn hauptsächlich in der Verfügbarkeitsgruppe stattfinden und die SQL-Server-Instanz die Verfügbarkeitsgruppe als primär ausführt. Bei der Integritätsermittlung wird aber nicht der Zustand der einzelnen Datenbanken geprüft, die sich in der Verfügbarkeitsgruppe befinden. Folglich kann eine Datenbank innerhalb einer Verfügbarkeitsgruppe geschlossen werden, z.B. ausgelöst durch einen Datenträgerausfall, ohne dass die Verfügbarkeitsgruppe in einen problematischen Zustand gerät oder einen Failover auslöst (sofern der automatische Failover konfiguriert ist). Dies stellt im Vergleich zu DBM eine drastische Änderung im Verhalten und im Abdeckungsbereich dar. Insbesondere im Fall von Datenträgerausfällen, die durch sekundäre Auswirkung das Schließen von betroffenen SQL-Datenbanken verursachen, löst DBM einen Failover aus, wohingegen AlwaysOn in der Standardeinstellung keinen Failover auslöst.“

  • Die Datenbanken befinden sich nach einem Storage-Defekt auf Primärseite in einem vermeintlich asynchronem Zustand, sodass die in Wirklichkeit synchrone sekundäre Datenbank so geöffnet werden muss als wäre sie eine asynchron gehaltene Datenbank (‚with allow_data_loss‘)
    Dabei ist der Zustand der sekundären AO-Datenbank identisch zum Status der sekundären DBM-Datenbank bei einem vergleichbaren Datenbankfehler. Die Datenbanken sind mit beiden Technologien gleichartig synchron bzw. asynchron, AlwaysOn beurteilt hier jedoch konservativer, als DBM und ändert den Status der Sekundär-Datenbanken auf Out-of-Sync (wie es bei einem asynchron betriebenen Datenbankspiegel bzw. asynchronem AO generell und dauerhaft der Fall ist)

 

Das Verhalten beim Verlust von Log- oder Datenfiles ist bei AlwaysOn und Database Mirroring so lange identisch, bis die geschützte Datenbank geschlossen wird. Hier liegt der Unterschied zwischen den beiden HA-Lösungen in der Automatisierung. AlwaysOn bietet nur so lange Hochverfügbarkeit, wie die Integrität der Datenbankdateien der aktuellen Primärdatenbank gegeben ist. Geht die Primäre Datenbank z.B. durch Storage/SSD-Ausfall oder iSCSI-Verbindungsverlust verloren, wird die Datenbank je nach Laufzeitzustand als „out of sync“ markiert und erfordert ein manuelles Eingreifen. Database Mirroring dagegen schwenkt je nach Konfiguration automatisch bei Verlust von Daten- oder Logfiles auf den Spiegel.

Wenn mit einem manuellen Eingreifen und Starten des Spiegels die SLAs weiterhin erfüllt werden, spricht aus Sicht der Datenkonsistenz nichts gegen die Verwendung der Hochverfügbarkeitslösung SQL Server AlwaysOn.


Overview on EasyCloud cmShell for SAP

Kategorien: cmShell, EasyCloud
Kommentare deaktiviert für Overview on EasyCloud cmShell for SAP

Intro

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

Solution

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 http://www.connmove.com 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“
SCS instance: „MESSAGESERVER|ENQUE“
SAP
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

OSWIN
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


EasyCloud Report and Variant Scanner- Example

Kategorien: cmShell, EasyCloud, Knowledge Base
Kommentare deaktiviert für EasyCloud Report and Variant Scanner- Example

Intro

connmove EasyCloud offers a powerful Interface to scan SAP Reports and Variants for specific pattern.

This is very useful in case of OS/DB Migrations. Our solution scans the SAP ABAP System for Paths or Database commands and provide with a To Do List for you development Teams.

Major Features:

  • Scans one or multiple SAP Systems
  • Scans Reports and Variants for any text pattern
  • Reports the result as CSV

Attention: While scanning for Variants, please note they have a SAP Client dependency.

Solution

Download and install the cmShell for SAP Setup from Downloads.

Download the attached Script of this Note. Save the script on a Windows (Windows Server 2008 R2  or above) in a read/writeable Directory.

Edit the Script in These Sections:

Search configuration

 

###################################################
 Search configuration
##################################################
#Specify the reports which will be searched
# % - A substitute for zero or more characters
$reports= @("Z%","Y%","A%")
#Specify the terms which will be searched in the variants
# _ - A substitute for a single character
$VariantSearchList= @("USR")
#Specify the terms which will be searched in the source code
$ReportSrcSearchList= @("0") 

SAP Systems to scan

##################################################

# SAP Connections

##################################################

# Create new SAP connection:

# – Copy the next three comments and remove the ‚#‘

# $SAPSystems[„<InstanceName>“] = New-object -TypeName PSObject

# $con = Get-CmSapConnect -UserName <Username> -Password <Password> -Language en -Client <Client> –Host <Host> -SystemNumber <SystemNumber>

# Add-Member -InputObject $SAPSystems[„<InstanceName>“] -Name Connection -Value $con -MemberType NoteProperty

# – Specify the instance name of the SAP system in the <InstanceName>placeholders.

# – Set up the SAP Connection in the Get-CmSApConnect cmdlet.

#

#Create SAP connections here:

#SAP Connection Example:

$SAPSystems[„ERP_EC1_00“] = New-object -TypeName PSObject

$con = Get-CmSapConnect -UserName admin -Password ******** -Language en -Client 100 –Host ERP.REDFRUIT.CORP -SystemNumber 00

Add-Member -InputObject $SAPSystems[„ERP_EC1_00“] -Name Connection -Value $con -MemberType NoteProperty

CSV-Output

##################################################

# Create CSV file

##################################################

$csvEnabled = $true

$csvDelimiter = „;“

$csvVariantsPath = „.\Variants.csv“

$csvReportsPath = „.\Reports.csv“

 

 


cmShell for SAP version 1.10 is available

Kategorien: cmShell, Knowledge Base
Kommentare deaktiviert für cmShell for SAP version 1.10 is available

Intro

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

Notice:
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

Solution

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

SAP – Acceleration: Erfolgsstory mit SQL Server 2012 AlwaysOn

Kategorien: Allgemein, Knowledge Base, Nachrichten
Kommentare deaktiviert für SAP – Acceleration: Erfolgsstory mit SQL Server 2012 AlwaysOn

SAP Implementierungen sind in Unternehmen auf der ganzen Welt stabil, schnell und sicher auf der Microsoft SQL Server Plattform zu betreiben. In diesem Artikel wird ein Beispiel herausgegriffen, dass durch das connmove Services-Team umgesetzt wurde:

Eine historisch gewachsene SAP-Landschaft sollte neu designed und auf eine zukunftsfähige Technologie-Architektur gehoben werden. Im Fokus stand dabei die strategische Vision für die SQL Server Installation: Aus administrativen Gründen aber auch unter Performance- und Lizenzaspekten wurde eine Konsolidierung der SAP-Datenbanken auf einer zentralen SQL Server Farm angestrebt.

Als erstes Pilotsystem, das auf die neue Architektur umgestellt wurde, war das größte und performancekritischste System des Kunden vorgesehen. Durch die fokussiert kundenspezifische Analyse konnte connmove ein Konzept erstellen und umsetzen, dass aus einem teilweise von Geschwindigkeitsproblemen geplagten System eine High-Performance-Implementierung werden ließ. Doch nicht nur dies – im Zuge der Neukonzeption der Technologieebene konnte die Hochverfügbarkeitsarchitektur optimiert werden. Die Erfahrungen der letzten Monate beweisen eine hohe Gesamtverfügbarkeit der wartungsfreundlichen Umgebung.

Das inzwischen auf der neuen Architektur betriebene System ist zweifellos eine eher große SAP Implementierung. Mit über 10 SAP-Applikationsservern arbeiten bis zu 4000 Dialoguser gleichzeitig. Dieses ERP-System basierte ursprünglich auf einer geclusterten SQL Server 2008 bzw. nach einem Upgrade auf einer SQL Server 2012 SP1 Datenbankinstanz. Die Datenbank selbst hatte eine unkomprimierte Größe von 2,2 Terabyte. Die Datenbankfiles waren auf Standard-iSCSI-Storage abgelegt. Dieses Storage war nach stetigem Systemwachstum nicht mehr jederzeit in der Lage, die von der Datenbanksoftware bzw. der SAP-Applikation angeforderte Anzahl an IOPS bzw. die nötige geringe I/O-Latenz (lt. SAP Hinweis #521750 und #987961 – Login notwendig) zu liefern.

Abbildung 1: Ausgangssituation und alte Architektur

Um die verbesserungswürdige Datenbankgeschwindigkeit zu erhöhen, entwickelte connmove zusammen mit dem Unternehmen eine auf zwei Säulen stehende Strategie:

  • Austausch der Datenbank-Serverhardware
  • Komprimierung der SAP-Datenbankinhalte

Der erste und entscheidendste Punkt betraf den Austausch der physikalischen Server. Für die neue Architektur wurden zwei identische Datenbankserver mit Intel Xeon 4-Wege CPUs, Codename Westmere. Entscheidendes Detail: Jeder Datenbankserver wurde mit vier hochperformanten FusionIO-Karten á 1,2 Terabye als SSD-Speicher bestellt. Die Konfiguration dieser Maschinen wurde den SAP on SQL Server Best Practices nach vorgenommen und teilweise nach direkter Rücksprache mit den Softwareherstellern auf die kundenspezifische Umgebung angepasst.

Auf dieser Hardwareplattform aufsetzend wurde SQL Server 2012 im AlwaysOn-Verbund (SQL Server 2012 AlwaysOn – What is it?) installiert. Diese neu mit SQL Server 2012 eingeführte HA-Lösung sichert die Datenbanken vor einem Ausfall des lokalen Storages, da die FusionIO-SSDs im Gegensatz zu herkömmlichem Storage nur vergleichsweise wenig eingebauten Schutz gegen Ausfall bieten. Um die SAP-Downtime beim Wechsel der Datenbank-Infrastruktur zu minimieren, wurde im ersten Schritt das iSCSI-Storage von dem Bestandscluster an einen der neuen Datenbank-Clusterserver umgehängt. Die SAPSID-Datenbank konnte danach sofort an einem der neuen Server online gebracht werden, sodass die SAP-Nichtverfügbarkeit auf einige Minuten reduziert werden konnte. Der Aufbau der DB-Hochverfügbarkeit geschah anschließend asynchron:

  • Spiegelung der Datenbank von Server N1 (NAS) auf Server N2 (FusionIO SSD)
  • Einrichtung SQL Server AlwaysOn synchron
  • Failover von N1 auf N2. Auswirkungen auf Produktivbetrieb minimal: Dauer i.d.R. >10 Sekunden, in einem Beispiel von 3.500 aktiven SAP-Usern nur bei ~20 Benutzern (5‰) unmittelbare Auswirkung in Form von Shortdumps mit Hinweis auf unterbrochene Datenbankverbindung.
  • Resync der Datenbank von N2 auf N1 – jetzt Betrieb auf FusionIO-SSDs
  • Aufnahme einer dritten Cluster-Node in Form einer virtuellen Maschine in den SQL Server AlwaysOn-Cluster: Asynchrone AlwaysOn-Spiegelung der Datenbank auf bestehendes iSCSI-NAS zur Ausnutzung aller Storagefeatures

Abbildung 2: Neue SQL Server Farm auf Windows Server 2008R2 / SQL Server 2012 aus 2 physikalischen und 1 virtuellen Server

Im Ergebnis steht eine ausfallsichere SAP Datenbank, die nahezu InMemory-Performance liefert, auf einer zukunftsfähigen, ausbaubaren Datenbankserver-Farm. Die mittlere Datenbankantwortzeit bewegt sich nun bei um 100 Millisekunden. Die im SAP DBACockpit gemessene Disk-I/O-Latenz ist oft unter 1 Millisekunde.

Für den connmove-Kunden ebenfalls von großer Wichtigkeit: Die SQL Server Lizensierung orientiert sich an der Anzahl der für die Datenbankinstanz verwendeten CPUs. Mit dieser Konzeption werden durch die extrem effiziente Konsolidierung mehrere SAP-Datenbankinstanzen auf physikalischen Servern die Lizenzkosten minimiert.

Da die Ausgangshardware aus physikalischen Servern, auf denen nach dem Umzug des Datenbankclusters nur noch die SAP ABAP Central Services aktiv waren, für diesen Anwendungszweck überdimensioniert waren, führte connmove eine Systemkopie dieser geclusterten ASCS auf virtuelle Server durch. Der virtuelle Clustername und die IP-Adresse, unter der das System angesprochen wird, sollte 1:1 beibehalten werden. Dies war nötig, um die große Anzahl an SAP Logon-Clients und viele externe Schnittstellen nicht modifizieren zu müssen. In Verbindung mit der zur Verfügung stehenden Systemdowntime stellte diese Anforderung eine Herausforderung dar, die dank guter Vorbereitung und einer zuvor erfolgten identischen Umsetzung im Qualitätssicherungssystem erfolgreich gemeistert werden konnte.

Abbildung 3: Neue SAP HA-Architektur in VMs basierend auf Windows Server 2008 R2

Die neue Architektur des SAP Produktivsystems hat sich seit der Umstellung extrem bewährt. Zum einen konnte die Betriebssicherheit und damit die Gesamtverfügbarkeit des Systems gesteigert werden. Die durchschnittliche Dialogantwortzeit ist über den Arbeitstag hinweg unterhalb einer Sekunde. Darüber hinaus haben sich die für Maintainance-Aktionen benötigten Downtimefenster eindeutig verkürzt. So konnte auf der neuen Plattform ein SAP Systemupgrade, für das der Softwarehersteller eine technische Downtime von bis zu 32 Stunden geschätzt hatte, in nur noch 7 Stunden abgeschlossen werden!


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

Kategorien: cmShell, Knowledge Base
Kommentare deaktiviert für Note: SAP GUI pop-up message appears when invoking a cmdlet

 Intro

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

CmShell_SAPGUI_1

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

 

Solution

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

CmShell_SAPGUI_2

 

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

CmShell_SAPGUI_3

 

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

CmShell_SAPGUI_4