All posts in Allgemein

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.

 


SAP powerd by Microsoft Azure

Kategorien: Allgemein
Kommentare deaktiviert für SAP powerd by Microsoft Azure
Guido Schmitt

Eine flexible und zuverlässige Plattform, kombiniert mit einer Automatisierung steigert die Qualität und minimiert Kosten. Das sind die zentralen Benefits von Azure.

Dr. Guido Schmitt, Geschäftsführer

Die Services for Azure ermöglichen Ihnen,SAP-Anwendungen ohne selbst langfristige Kapitalbindungen effizient zu betreiben.

Der große Vorteil gegenüber allen Mitbewerbern: Microsoft Azure-Cloud basiert auf bewährte Technologien und Standards und ist damit auch für komplexe Anforderung eine sehr gute Lösung. Kombiniert mit einem hohe Automatisierungsgrad ist Microsoft Azure in Kombination mit connmove Services und Software Lösungen die beste Wahl  für einen dynamischen und zeitgleich stabilen Systembetrieb.

Wählen Sie aus unseren Workshop Angeboten:


Toggle title goes here

Im Introduction Workshop SAP on Azure werden folgende Themen vorgestellt und diskutiert. Der Workshop dauert ca. 4h und wir bei Ihnen vor Ort durchgeführt.

Agenda Workshop:

  • Überblick Windows Azure
  • Support Matrix SAP auf Azure
  • Kosten und Lizenzen
  • Klassische Use Cases für SAP on Azure


Workshop: Was bringt SAP on Azure ihrem Unternehmen?

Im SAP on Azure ADS Workshop analysieren wir Ihre Umgebung und finden mit Ihnen zusammen die besten Use-Case , Vorteile und Nachteile von SAP on Azure für ihr SAP Software Lösung.

Im Detail werden hier folgende Komponenten in dem Workshop vor Ort betrachtet:

  • Hardware und Sizing
  • Software Komponenten und Release Stände
  • Lizenz und Kostenbetrachtung
  • Security Aspekte
  • HA/DR Konzepte
  • Betrieb und Administration
  • Mögliche Wege der Implementierung bzw. Migration

Im Anschluss an den eintägigen Workshop wird ein Report mit den entsprechenden Ergebnissen verfasst und präsentiert.


Das passende Angebot dabei? Oder dürfen wir Ihnen weitere Fragen beantworten? Gerne:

Tel: +49 6253 879189-0

http://connmove.eu/kontakt


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.


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!


EasyCloud Cmdlets for managing SAP Users

Kategorien: Allgemein
Kommentare deaktiviert für EasyCloud Cmdlets for managing SAP Users

Intro

There is a functionality needed to manage SAP users.

Solution

There are new cmdlets added to manage SAP user data:

  • Get-CmSapUserDetails
  • Add-CmSapUser
  • Set-CmSapUserDetails
  • Get-CmSapUserAuthorizationData

Get-CmSapUserDetails

Returns detail informations of a user.

Image 1 shows the different return data:

EasyCloud_Sap_User_1

Image 2 shows how to read an information like the E-Mail:

EasyCloud_Sap_User_2

 

Add-CmSapUser

The Cmdlet creates a new SAP User. You can set properties: user name, first / last name, password and a reference user. Use Set-CmSapUserDetails to set more properties.

EasyCloud_SAP_User_5

 

Set-CmSapUserDetails

With this Cmdlet you can change a lot of data of an Sap User:

EasyCloud_Sap_User_3

Here are a few informations which can be changed by using the cmdlet:

  • Data of Person (Name, etc.)
  • Contact Informations (Address, E-Mail, etc.)
  • SNC
  • User Password
  • User Type
  • User Group
  • Validity Period
  • etc.

 

 Get-CmSapUserAuthorizationData

Checks if a user has authorization issues. The function returns the output of the TC SU53.

EasyCloud_Sap_User_4

 


Note: SAP User Authorizations for EasyCloud Cmdlets

Kategorien: Allgemein, EasyCloud, Knowledge Base
Kommentare deaktiviert für Note: SAP User Authorizations for EasyCloud Cmdlets

Intro

To use the SAP functions of the EasyCloud cmdlets, the user must have the appropriate rights. This note explain the minimum priviliges to connect EasyCloud to an SAP ABAP System.

Solution

The minimum rights to create an RFC connection to the SAP system are the following:

EasyCloud_Sap_Role_1

 

Determine the rights of an EasyCloud function

If the user has no rights for a function, you can determine the missing rights as follows:

  • Execute the EasyCloud function.
  • You can check if the user is missing rights by using the transactions ST01, SU53 and SM21. If there is something missing add it to the users role.
  • After you have given the rights to the user, execute the EasyCloud function again. Maybe the function needs more rights.

 

Example: SAP TMS

Attached to this blog post there is a SAP role template for the usage TMS and the AuthorizationData Cmdlets:

Download Template

The following Screenshot there is an example of a typical role for the usage EasyCloud.

EasyCloud_Sap_Role_2

Further Information about SAP TMS and authorization objects: http://help.sap.com/saphelp_nw04/helpdata/de/57/38deb54eb711d182bf0000e829fbfe/content.htm


Neuer Gesellschafter der connmove GmbH: Dr. Guido Schmitt

Kategorien: Allgemein
Kommentare deaktiviert für Neuer Gesellschafter der connmove GmbH: Dr. Guido Schmitt

Dr. Guido Schmitt übernimmt mit Wirkung vom 11.07.2013 25% Anteile an der connmove GmbH. Gemeinsam mit Bernhard Mändle halten nun Beide alle Anteile am Unternehmen.

„Dr. Schmitt brachte connmove in den vergangenen Jahren stetig weiter und ist einer der Garanten für unseren erfolgreichen Wachstumskurs, in der Vergangenheit wie auch für die Zukunft. Ich freue mich außerordentlich dass er nun noch stärker für die connmove GmbH Verantwortung übernimmt und unser Unternehmen der starke, inhabergeführte und unabhängige Partner für unsere Kunden bleibt.“, so Bernhard Mändle, geschäftsführender Gesellschafter.

Guido Schmitt
Dr. Guido Schmitt,
Geschäftsführender Gesellschafter, Connmove GmbH