Beim Zusammenschluss von Unternehmen wird in vielen Fällen mit einer Active Directory Vertrauensstellung zwischen Domänen aus unterschiedlichen AD-Gesamtstrukturen gearbeitet.
Um das Arbeiten mit Ressourcen in beiden Strukturen zu ermöglichen, verfügen Active Directory Objekte über das Attribute sIDHistory. In diesem Attribut in Zieldomäne A wird die SID aus der Quell-Domäne B eingetragen. Hierdurch ist es möglich, dass ein in Domäne A migrierter Benutzer weiterhin auf Ressourcen in der "alten" Domäne B zugreifen kann.
Dies funktioniert allerdings nur, wenn die Active Directory Vertrauensstellung zwischen beiden Domänen die Nutzung der sIDHistory aktiviert ist. Aus Sicherheitsgründen ist diese Funktionen im Normal ausgeschaltet. Dies nennt man auch SID-Filterung.
Die Aktivierung der SID-History bzw. die Deaktivierung der SID-Filterung erreicht man durch folgenden Kommandozeilenbefehl:
netdom trust LOKALEDOMAIN.tld /domain:REMOTEDOMAIN.tld /enablesidhistory:yes
Wenn Sie den o.g. auf einem deutschsprachigen Windows Server Betriebssystem ausführen, erhalten Sie u.U. folgende Fehlermeldung:
"Der SID-Verlauf ist für diese Vertrauensstellung deaktiviert."
Die Lösung ist sehr trivial. Verwenden Sie anstatt yes ein ja, um die SID-History zu aktivieren. Der folgende Kommandozeilenaufruf bringt Sie ans Ziel:
netdom trust LOKALEDOMAIN.tld /domain:REMOTEDOMAIN.tld /enablesidhistory:ja
Viel Spaß mit Active Directory.
Die Aktivierung der Kerberos Authentifizierung für Exchange Server 2013/2016 wird in diversen Artikeln im Internet beschrieben. In diesem Blogartikel geht es heute um ein Phänomen, das mir in einer Exchange Server 2013 Umgebung (8 Server DAG) begegnet ist.
Alle Outlook 2010 Clients verwenden OutlookAnywhere für den Exchange Server Zugriff aus dem internen Netz. MAPI over Http ist sowohl auf der Organisationsebene als auch auf Postfachebene deaktiviert, da noch ein Problem mit der Kompatibilität einer Drittanbietersoftware existiert.
Nach der Aktivierung der Kerberos Authentifizierung verwenden alle Outlook Clients weiterhin nur die NTLM Authentifizierung, um sich am OutlookAnywhere Endpunkt anzumelden. Und dies, obwohl die Schritt-für-Schritt Anleitung aus dem TechNet befolgt wurde. Kerberos war für die Outlook Clients kein Thema.
Ein Blick in die Übersicht des Outlook Verbindungsstatus (Strg + Rechter Mausklick auf des Outllok Symbol im System Tray) zeigt die Verwendung von NTLM.
Die Umstellung der Authentifizerung auf Kerberos für OutlookAnywhere erfolgt auf jedem CAS Server über das folgende PowerShell Cmdlet:
Get-OutlookAnywhere -Server CASSERVER | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate
Alle acht Exchange 2013 Server boten auch nach gebotener Zeit keine Nego Authentifizierung an. Die Überprüfung der OutlookAnywhere Konfiguration mit Hilfe der PowerShell zeigte die korrekten Konfigurationswerte. Aber was nun?
Ein Kontrolle der Authentifizerungseinstellungen für das \Rpc virtuelle Verzeichnis der Front End Website in der IIS Management Console zeigte, dass das virtuelle Verzeichnis nur für NTLM konfiguriert war.
Mit Hilfe der IIS Management Console wurde der Negotiate Authentifizierungsanbieter hinzugefügt in der Reihenfolge der Anbieter an die erste Stelle gesetzt..
Nach Anpassung der Authentifizierungsanbieter in der Front End Wesbite können sich Outlook Clients mit Kerberos Authentifizerung an den OutlookAnywhere Endpunkt verbinden.
Im Normalfall sollte die IIS Management Console nicht für die Konfiguration der virtuellen Verzeichnisse einer Exchange Server INstallation verwendet werden. Die Anpassung der Konfigurationen mit Hilfe IIS MMC sollte nur im Troubleshooting-Fall verwendet werden, wenn einem unerklärliche Phänomene begegnen.
Die bevorzugte Methode zur Konfiguration von Exchange Server Einstellungen für virtuelle Verzeichnisse ist die Exchange Management Shell.
Weiterhin viel Spaß mit Exchange Server
Die Installation des Windows Features Active Directory Domains Services (AD DS) kann fehlschlagen.
Bei der Installation per PowerShell kommt es zu folgendem Fehler:
Install-WindowsFeature -Name AD-Domain-Services Install-WindowsFeature : The request to add or remove features on the specified server failed. The operation cannot be completed, because the server that you specified requires a restart. At line:1 char:1 + Install-WindowsFeature -Name AD-Domain-Services + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : DeviceError: (@{Vhd=; Credent...Name=localhost}:PSObject) [Install-WindowsFeature], Exce ption + FullyQualifiedErrorId : DISMAPI_Error__Failed_Reboot_Required,Microsoft.Windows.ServerManager.Commands.AddWindow sFeatureCommand Success Restart Needed Exit Code Feature Result ------- -------------- --------- -------------- False No Failed {}
Das ganze sieht erstmal danach aus, dass es sich um ein VMWare Problem handelt. "+ CategoryInfo: DeviceError: (@{Vhd=; Credent...Name=localhost}:PSObject) [Install-WindowsFeature], Exception" und das noch ein Reboot aussteht "because the server that you specified requires a restart."
Dem ist leider nicht so. Auch nach mehrfachem Neustart des Servers, bleibt es bei der gleichen Fehlermeldung.
Ein Blick ins EventLog zeigt, es gibt eine Abhängigkeit zwischen dem Dienst "DFS Namespace" und "Remote Registry".
Der "Remote Registry" Dienst konnte nicht gestartet werden, da dieser deaktiviert war.
Dieser Dienst war in der VM Vorlage deaktiviert.
Nach Umstellung auf Automatisch und einem Reboot ließ sich das Windows-Feature AD DS fehlerfrei installieren und der Server zum Domain Controller hochstufen.
Wenn Sie CRM Online verwenden, möchten Sie ebenfalls den CRM 2013 Client für Outlook verwenden. Bei der Konfiguration der Client Integration kann es zu einem Fehler kommen, der ursächlich mit dem Office 365 Single-Sign-On Client und den Internet Explorer Einstellungen zusammenhängt.
Nach dem Download des Microsoft Dynamics CRM 2013 for Microsoft Office Outlook, müssen Sie die Outlook Verbindung zu Ihrem CRM Online Tenant mit Hilfe des CRM Konfigurationsassitenten konfigurieren.
Zu diesem Zeitpunkt der Konfiguration konnte sich der Client mit CRM Online verbinden, da das Outlook Add-In den Organisationsnamen und Anzeigenamen der Organisation erfolgreich abfragen konnte. Wenn Sie nun mit der Konfiguration fortfahren möchten, kommt es zu einem Fehler in der Kommunikation mit dem CRM Online Server.
Beispiel der Fehlermeldung: Exception : Object reference not set to an instance of an object. at Microsoft.Crm.Passport.IdCrl.OnlineServicesFederationLogOnManager.GetBrowserClientAuthInfo(String redirectEndpoint, String partner, String policy, String& postData) at Microsoft.Crm.Outlook.ClientAuth.PassportAuthProvider`1.SignIn() at Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.SignIn(Uri endPoint, Credential credentials, AuthUIMode uiMode, IClientOrganizationContext context, Form parentWindow, Boolean retryOnError) at Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.GetAuthProvider(Uri endPoint, Credential credentials, AuthUIMode uiMode, Uri webEndPoint, IClientOrganizationContext context, Form parentWindow) at Microsoft.Crm.Application.Outlook.Config.ServerInfo.LoadUserId() at Microsoft.Crm.Application.Outlook.Config.ServerInfo.Initialize(Uri discoveryUri, OrganizationDetail selectedOrg, String displayName, Boolean isPrimary) at Microsoft.Crm.Application.Outlook.Config.ServerForm.LoadDataToServerInfo() at Microsoft.Crm.Application.Outlook.Config.ServerForm.<InitializeBackgroundWorkers>b__2(Object sender, DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e) at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
Quelle: SF-Tools, CRM 2013 for Outlook configuration fails
Der browserbasierte Zugriff auf ein Exchange Postfach mit Hilfe von Outlook on the Web (OWA) ermöglicht Ihren Anwendern die Anzeige und Bearbeitung von Office-Dateianhängen ganz ohne Medienbruch in eine andere Applikation.
Für Kunden von Microsoft 365 und Exchange Online sind hierzu keine weiteren Konfigurationen notwendig. Die Integration von Office Online mit Outlook on the Web ist standardmäßig aktiviert. Jedem Anwender wird automatisch eine Standard-Richtlinie zu gewiesen. Zu den Betriebsrisiken später mehr.
Wenn Sie diese Funktion auch für Ihre lokale Exchange Organisation bereitstellen möchten, müssen Sie zuerst eine Office Online Server Umgebung aufbauen und, falls erforderlich, aus dem Internet erreichbar machen. Die Anforderungen und Implementierungsoptionen einer Office Online Umgebung schauen wir uns in einem der nächsten Artikel an.
In Outlook on the Web wird die Möglichkeit einer Anzeige im Browser im Auswahlmenü eines Dateianhanges anzeigt:
Ebenso ist das Öffnen des Anhanges das Standardverhalten bei einem Klick auf den Dateinamen.
Im Rahmen einer betrieblichen Anforderung kann es notwendig sein, dass bestimmten Anwendergruppen der Zugriff auf Office Online aus OWA heraus zu unterbinden und stattdessen das Herunterladen von Office-Dateianhängen zu erzwingen.
Die Gründe hierfür können sehr unterschiedlich sein.
Je nachdem, ob Sie Office Online als SaaS-Lösung in Microsoft 365 nutzen, oder aber Ihre eigene Office Online Server Umgebung betreiben, stehen Ihnen unterschiedliche Lösungen zur Verfügung. DIe von Office Online (Server) bereitgestellten Funktionen werden nciht nur von OWA verwendet.
Die Option einer neuen OWA-Postfachrichlinie (OwaMailboxPolicy) steht Ihnen für Microsoft 365 und die lokale Exchange Organisation zur Verfügung. Die Erstellung einer neuen OWA-Postfachrichtlinie ist zwar auch über das Exchange Admin Center, jedoch ermöglicht dieser Weg anschließend nur eine sehr rudimentäre Konfiguration. Daher empfehle ich Ihnen, OWA-Postfachrichtlinien immer mit Hilfe der Exchange Management Shell (EMS) zu erstellen und zu verwalten. Wenn Sie mit Exchange Online arbeiten, stellen Sie bitte sicher, dass Ihr administratives Konto mit einer Multi-Faktor-Authentifizierung (MFA) geschützt ist und Sie das speziell hierfür zur Verfügung gestellte PowerShell Modul verwenden.
Die Erstellung einer neuen OWA-Postfachrichlinie gliedert sich immer in zwei Schritte:
Im folgenden Beispiel erstelle ich in Exchange Online eine neue OWA-Postfachrichlinie für das fiktive Unternehmen Contoso. Der Name der neuen Richtlinie ist Contoso-Restricted-OWA-Policy.
# Aktivierung der PowerShell-Protokollierung (Transkript) Start-Transcript # Uneingeschränkte Anzeige von Array-Inhalten $FormatEnumerationLimit=-1 # Erstellung der neuen OWA-Postfachrichtlinie New-OwaMailboxPolicy -Name 'Contoso-Restricted-OWA-Policy' # Auflistung der Namen der vorhandenen OWA-Richtlinien Get-OwaMailboxPolicy | ft Name
Nach der Erstellung der neuen Richtlinie wurden alle Standard-Einstellungen der Richtlinie im PowerShell-Fenster ausgegeben. Dank der aktivierten Protokollierung haben Sie diese Einstellungen in der Transkript-Textdatei festgehalten.
In diesem Artikel interessieren wir uns für die relevanten Einstellungen zu Office Online (Server). Diese Einstellungen verbergen sich in den Parametern mit dem Kürzel Wac.
# Auflistung der Wac-relevanten Parameter der OWA-Richtlinie Get-OwaMailboxPolicy 'Contoso-Restricted-OWA-Policy' | FL *wac* WacEditingEnabled : True WacViewingOnPublicComputersEnabled : True WacViewingOnPrivateComputersEnabled : True ForceWacViewingFirstOnPublicComputers : False ForceWacViewingFirstOnPrivateComputers : False WacExternalServicesEnabled : True WacOMEXEnabled : False
Die gewünschte Deaktivierung von Office Online erfolgt über die Parameter WacViewingOnPublicComputersEnabled und WacViewingOnPrivateComputersEnabled. Mit diesen beiden Parametern wird festgelegt, ob für den Anwender, dem diese Richtlinie zugewiesen ist, eine Anzeige des Anhanges in Office Online möglich ist oder nicht. Die Möglichkeit zur Anzeige wird für öffentliche und private Computer getrennt konfiguriert. Seit Exchange Server 2013 werden Zugriffe per OWA immer als Zugriffe von einem privaten Computer gewertet.
Die Bedeutung der Wac-relevanten und aller anderen Parameter ist auf der Hilfe-Seite des Cmdlets Set-OwaMailboxPolicy bestens beschrieben.
Nach der Erstellung muss die neue Richtlinie noch einzelnen oder allen Anwenderkonten zugewiesen werden.
# Zuweisung der neuen OWA-Richtlinie an ein einzelnes Anwenderkonto Get-CASMailbox AllanD | Set-CASMailbox -OwaMailboxPolicy 'OwaMailboxPolicy-Default' # Zuweisung der neuen OWA-Richtlinie an alle vorhanden Anwenderkonten Get-CASMailbox | Set-CASMailbox -OwaMailboxPolicy 'OwaMailboxPolicy-Default' # Optionale Konfiguration der neuen OWA-Richtlinie als Standardrichtlinie Set-OwaMailboxPolicy 'Contoso-Restricted-OWA-Policy' -IsDefault:$true
Nach der Zuweisung der neuen OWA-Postfachrichtlinie wird die Möglichkeit zur Vorschau eines Dateianhanges nicht mehr angezeigt.
Wenn Sie die neu erstellte OWA-Postfachrichlinie Anwendern zuweisen, die zu diesem Zeitpunkt in OWA angemeldet sind, so haben die neuen Einstellungen noch keine Wirksamkeit. Die Einstellungen der neu zugewiesenen Richtlinie werden erst nach einer Ab- und Anmeldung an OWA wirksam.
Auf den ersten Blick erscheint die Deaktivierung der Office Online Lizenz im Rahmen eines Office 365-Lizenzplanes auch eine Möglichkeit zu sein, um die Nutzung von Office Online zu verhindern.
Sie deaktivieren die Office Online Lizenz direkt in der Lizenzzuweisung eines Anwenders im Microsoft 365 Admin Center oder über die gruppengesteuerte Lizenzzuweisung in Azure AD.
Aber führt diese Anpassung der Lizenzzuweisung zum gewünschten Ergebnis? Nein, leider nicht.
Die Deaktivierung der Lizenzzuweisung von Office Online hat keine Auswirkungen auf
Damit scheidet die Option zur Zugriffssteuerung von Office Online über die Lizenzzuweisung für einen Anwender aus.
Wie bei vielen anderen Richtlinien von Exchange Online und Exchange Server existiert nach der ersten Einrichtung des Office 365 Tenants bzw. der Exchange Organisation eine Standardrichtlinie zur Konfiguration der Outlook on the Web (OWA) Einstellungen für alle Anwender. Da der Zugriff auf OWA ebenfalls standardmäßig für alle Anwender aktiviert ist, müssen Sie sich mit der Konfiguration der Standardrichtlinie auseinandersetzen.
Verschaffen Sie sich einen schnellen Überblick über all die Zusatzfunktionen, die im Rahmen einer OWA-Richtlinie gesteuert (*enabled) werden.
# Beispielhafte Abfrage der Parameter einer OWA-Richtlinie, die eine Zusatzfunktion steuern Get-OwaMailboxPolicy 'OwaMailboxPolicy-Default' | FL *enabled*
Diese Abfrage liefert Ihnen eine Grobüberischt der vorhandenen Einstellungen und deren Standardkonfigurationen. Überprüfen Sie alle Einstellungen für OWA-Postfachrichtlinien, ob sie den Compliance-Anforderungen Ihres Unternehmens entsprechen. Sie finden dieser EInstellunge in der Dokumentation für das Cmdlet Set-OwaMailboxPolicy.
Denken Sie beim Thema Office Online auch daran, dass Office Online auch Dokumente öffnen kann, die bei externen Speicheranbietern liegen. Die Nutzung von externen Speicheranbietern, aus Sicht von Office 365, kann im Microsoft 365 Admin Center ausgeschaltet werden.
Wählen Sie im Menüpunkt Einstellungen > Dienste und Add-Ins den Punkt Office Online aus.
Setzen Sie den Schieberegler für die Konfiguration Personen die Verwendung von gehosteten Speicherdiensten von Drittanbietern gestatten aus Aus und speichern Sie die Einstellung.
Viel Spaß mit Microsoft 365 und Exchange Server!
Manchmal ist es notwendig, das Offline Adressbuch (OAB) für den Outlook E-Mail Client manuell herunterzuladen.
Kommt es beim Herunterladen des OAB zu einem Fehler, in diesem Fall 0x80200051, wird durch den First-Line Support gerne zwischen dem Online- und dem Cached-Modus von Outlook hin und her gewechselt. Leider behebt dieses Vorgehen den Fehler nicht.
Nach dem erneuten Aktivieren des Cached-Modus, muss das OAB vollständig neu heruntergeladen werden. Leider ist im Outlook-Diaglog zum manuellen Download des OAB die Checkbox "Änderungen seit der letzten Übermittlung herunterladen" standardmäßig aktiv. Diese Option muss abgewählt werden, um einen vollständigen Download es OAB durchführen zu lassen.
Mit dieser Download-Einstellung kommt es nicht mehr zu einem Fehler.
Viel Spaß mit Outlook.
Die Einführung von Office 365 ist im Allgemeinen keine große technische Herausforderung. Die technischen Anforderungen sind klar definiert und können in den meisten Fällen direkt 1:1 umgesetzt werden. Bei manchen Unternehmen ist die Konfiguration der technischen Anbindung der lokalen IT-Infrastruktur an Office 365 durchaus komplex, aber kein wirkliches Hindernis.
Neben den rein technischen Themen bei der Implementierung von Office 365 können unternehmensinterne Abstimmungen und Entscheidungsfindungen ein großer Hemmschuh für Office 365-Projekte sein. Diese sind immer dann eine Herausforderung, wenn keine ausreichende Unterstützung aus der Führungsebene vorhanden ist oder, noch wesentlich schlimmer, keine klare Cloud-Strategie existiert. Ohne eine klar definierte Unterstützung der Geschäftsführung sollten Sie von einer produktiven Office 365-Einführung Abstand nehmen.
Welche Hindernisse gibt es jenseits der technischen Implementierung von Office 365 und unternehmensinternen Entscheidungsprozessen?
Aber selbst mit allen notwendigen technischen Voraussetzungen und einer klaren Entscheidung, Office 365 als integralen Bestandteil der IT-Plattform im Unternehmen zu nutzen, kann es zu Problemen bei der Einführung von Office 365 kommen. Wenn ein Unternehmen keine eigenen IT-Mitarbeiter hat, die über das notwendige Knowhow zur Einführung von Office 365 verfügen, werden gerne Projektpartner oder Personaldienstleister in Anspruch genommen. Dies führt zu besonderen Kunde-Dienstleister-Konstellationen.
Und hier beginnen die Herausforderungen, die zu einer schlechten Office 365-Implementierung führen können.
An den folgenden beiden Beispielen möchte ich Ihnen die Problemsituationen verdeutlichen, die auch für die Office 365-Einführung in Ihrem Unternehmen ein Risiko darstellen können.
Fachkräfte, die sich mit allgemeinen Cloud-Technologien und mit Office 365 im Besonderen auskennen, sind rar. Dies ist hauptsächlich darauf zurückzuführen, dass viele Unternehmen ihre IT-Mitarbeiter im Bereich Cloud-Technologien nicht weiterbilden.
Möchte ein Unternehmen Office 365 einführen und eine Migration zu Office 365 durchführen, wendet man sich entweder an ein IT-Systemhaus oder einen Projektdienstleister, mit dem man bereits andere Projekte durchgeführt hat. Alternativ beauftragt man einen Personaldienstleister, einen Office 365-Experten für einen definierten Projektzeitraum zu finden. Dies resultiert in einer direkten Beauftragung zwischen dem Kunden (Ihr Unternehmen, im Folgenden AG genannt) und Personal-/Projektdienstleister bzw. Systemhaus als Auftragnehmer (AN).
Auf dieser ersten Ebene (A) endet bereits Ihre direkte Einflussnahme als Kunde, da nur zwischen Ihrem Unternehmen und dem direkten Auftragnehmer ein Vertragsverhältnis besteht. Bei der Zusammenarbeit mit einem Personaldienstleister sollte es Ihnen als Kunden bewusst sein, dass ein weiteres Glied der Beauftragungskette hinzugefügt wird, bevor Ihnen ein Office 365-Experte zur Seite gestellt wird. Wenn Sie einen Projektdienstleister oder ein Systemhaus beauftragen, haben Sie die Erwartung, dass diese Ihnen mit eigenen Experten helfen können. Diese Erwartung kann oft nicht erfüllt werden, da die Auftragnehmer mehr Projekte annehmen als sie effektiv bedienen können. Die vorhandenen Experten werden schlichtweg überbucht.
Um das angenommene Kundenprojekt nicht zu gefährden, bedienen sich die Aufragnehmer der Ebene A der gleichen Methodik wie der Endkunde. Sie kontaktieren ihrerseits Personaldienstleister, um fehlendes Expertenwissen einzukaufen. Damit sind wir in der zweiten Beauftragungsebene (B) angekommen. Oftmals kontaktieren Projektdienstleister und Systemhäuser mehrere Personaldienstleister, um das fehlende Expertenwissen möglichst günstig einzukaufen. Hierbei kommt es zu einer weiteren Beauftragung und einer zusätzlichen Auftraggeber-/Auftragnehmer Konstellation.
Verfügt ein Personaldienstleister aus Ebene B nicht direkt einen Experten zur Projektunterstützung, erfolgt eine erneute Suche nach einem Experten aus dem Pool registrierter Beraterunternehmen und Freelancer.
Dies ist nun die dritte Beauftragungsebene (C). Die Suche nach einem Office 365-Experten der beiden ersten Beauftragungseben A + B führt manchmal zu der amüsanten Situation, dass das gleiche Kundenprojekt bei Dienstleistern der Ebene C durch unterschiedliche Personal- und Projektdienstleister angefragt wird. Die Beauftragung des ausführenden Dienstleisters oder Freelancers in dieser dritten Ebene führt natürlich zu einer weitere Auftraggeber-/Auftragnehmer-Situation.
Das folgende Diagramm verdeutlicht die Situation der Beauftragungskette zwischen einem Kunden und dem endgültig ausführenden Office 365-Experten.
Wie wirkt sich solch eine Beauftragungskette für ein einzelnes Office 365-Projekt auf den Erfolg des Kundenprojektes aus?
Das große Problem einer solchen Beauftragungskette ist, dass mehrere AG/AN-Beziehungen zwischen Parteien bestehen, die ganz unterschiedliche Geschäftsinteressen verfolgen, die von Ebene zu Ebene undeutlicher werden. Der Dienstleister der dritten Ebene hat keine direkte Beziehung zum Kunden und zum ausgehenden Kundenprojekt. Die Erbringung der Dienstleistung und die damit verbundene Verantwortung erfolgen immer nur von Ebene zu Ebene. Diese Beauftragungskette beeinträchtigt auch die Kommunikationswege für das Kundenprojekt, wodurch dem Kunden nicht das vollständige Expertenwissen zur Verfügung steht.
Ein weiteres Problem dieser Beauftragungskette ist, dass die Dienstleister und Freelancer der dritten Ebene preislich gegeneinander ausgespielt werden. Auf dem Weg nach oben wiederum schlägt jeder beteiligte Personal- oder Projektdienstleister 10-20% auf den Einkaufspreis der Dienstleistung auf. Der Preis, den der Kunde wahrnimmt, suggeriert ihm, dass er Expertenwissen erhält, was eine entsprechende Erwartungshaltung generiert. Die natürlichen Kommunikationsverluste der Beauftragungskette führen nahezu zwingend dazu, dass die Kundenerwartung nicht erfüllt werden kann.
Erschwert wird diese Situation dadurch, dass Dienstleister und Freelancer oftmals gezwungen sind, unter der direkten Flagge eines Projektdienstleisters aufzutreten. Hierbei erhalten sie ein eigenes Benutzerkonto mit E-Mail-Adresse und Telefonnummer des Projektdienstleisters und erscheinen dem Kunden gegenüber wie hausinterner fester Mitarbeiter. Um einer Scheinselbstständigkeit zu entgehen, arbeiten Freelancer zur gleichen Zeit in mehreren Projekten. Dies wiederum führt zu Zeitverzögerungen bei der Erbringung von Dienstleistungen und der Projektkommunikation und hinterlässt so bei Ihnen, als Kunden, automatisch einen schlechten Eindruck,
Die mehrstufige Kommunikation fördert Missverständnisse, gerade im Hinblick auf notwendige Kundenberatung für die erfolgreiche Einführung von Office 365. Durch die Eingrenzung auf festdefinierte Projektthemen ist keine ganzheitliche Beratung und Einführung von Office 365 Produkten und Diensten möglich. Selbst wenn der Dienstleister oder Freelancer, als beauftragter Experte, seine Expertise in das Kundenprojekt einbringen möchte, wird er in den meisten Fällen durch einen Auftraggeber in Ebene A oder B ausgebremst, da diese vermeintlich zusätzliche Expertise nicht Bestandteil der Beauftragung ist. Der Kunde erfährt nie, dass er keine umfängliche Dienstleistung erhalten hat.
Für den Kunden birgt solch eine Beauftragungskette ein hohes Risiko, nicht die optimale Beratung zur Implementierung von Office 365 zu erhalten.
Ähnlich sieht es im zweiten Beispiel aus, wenn Sie im Rahmen der Einführung einer neuen Software-Lösung zwangsweise auch Office 365 einführen müssen.
Dieses Beispiel ist eine Variation von Beispiel A und in der Wahrscheinlichkeit zum Scheitern einer zukunftsfähigen Office 365-Einführung noch riskanter.
Als Kunde möchten Sie gerne eine neue Software-Lösung, wie z.B. eine cloudbasierte ERP-Lösung, einführen, um eine ältere, lokal betriebene, Software-Lösung zu ersetzen. Die Nutzung dieser ERP-Lösung erfordert, dass die Postfächer Ihrer Mitarbeiter in Exchange Online bereitgestellt werden. Die ERP-Lösung ist nicht kompatibel mit Postfächern, die in einer lokalen Exchange Organisation gespeichert sind oder bei einem anderen Provider gehostet sind.
Der primäre Fokus des ERP-Vertriebsteams liegt auf dem Verkauf von Nutzungslizenzen. Die Voraussetzungen zur Nutzung der ERP-Software und die technische Realität in der Kundenumgebung werden bewusst ausgeklammert. Sie als Kunde werden in der Sicherheit gewogen, dass eine cloudbasierte Software leicht und einfach zu implementieren ist. Die noch fehlende Office 365-Implementierung in Ihrem Unternehmen wird als Integrationsbaustein zur Softwarenutzung mitverkauft.
Mit dem Erwerb der ERP-Lizenzen beauftragen Sie In diesem Beispiel auch die Migration von Office 365.
Nun ist es so, dass der Software-Dienstleister (Beauftragungsebene A) nicht über das erforderliche Knowhow verfügt, um einen neuen Office 365-Mandaten vollständig und sicher zu konfigurieren. Um dieses Defizit auszugleichen, vergibt er die Office 365-Anbindung an einen anderen Dienstleister (Ebene B). Dieser Dienstleister wiederum verfügt ebenfalls nicht über das notwenige Knowhow bzw. hat kein Personal verfügbar, um die Office 365-Anbindung selbst auszuführen.
Auch in diesem Fall tritt dieser Dienstleister an einen weiteren Dienstleister oder Freelancer (Ebene C) heran, um die eigentlich Office 365-Anbindung durchzuführen.
Das folgende Diagramm verdeutlicht die Situation der Beauftragungskette zwischen einem Kunden, dem Software-Dienstleister und dem endgültig ausführenden Office 365-Experten.
Der wichtigste Unterschied zu Beispiel A ist der Umstand, dass dem Kunden eine Software-Produkt verkauft wurde und die Office 365-Anbindung preislich bereits inkludiert ist. Somit besteht keinerlei Spielraum, um eine umfassende Office 365-Beratung und Umsetzung durchzuführen. Der ausführende Dienstleister in Ebene C ist gezwungen, nur das notwendige Mindestmaß an Arbeiten durchzuführen.
Als Resultat verfügt der Office 365-Mandant des Kunden zwar über die Funktionen zur Nutzung der verkauften ERP-Software, eine Konfiguration zur Absicherung des Office 365-Mandaten findet jedoch nicht statt. Als weitere negative Auswirkungen auf diese Art einer Office 365-Implementierung sind u.a. zu nennen:
In diesem Fall nutzt der Kunde anschließend zwar Office 365, jedoch in mit einer als unsicher einzustufenden Konfiguration.
Wenn Sie für Ihr Unternehmen die Einführung von Office 365 planen oder die Nutzung von Office 365 eine Voraussetzung für die Einführung einer SaaS-Lösung ist, achten Sie besonders darauf, wer welche Dienstleistung erbringen kann. Je mehr Beauftragungsstufen in solch einem Projekt vorhanden sind, desto komplizierter werden die Auftraggeber- und Auftragnehmer-Abhängigkeiten. Es entstehen automatisch Interessenskonflikte, die nicht mehr das Wohl des Kunden und den Erfolg des Projektes im Fokus haben.
Das Scheitern der Office 365-Einführung ist dann besonders groß, wenn Sie als Kunde keinerlei Wissen über Cloud-Technologien im Allgemeinen und Office 365 im Besonderen in Ihrer IT-Abteilung verankert haben. Ohne dieses Wissen sind Sie nicht in der Lage, die Empfehlungen und Arbeiten der beauftragen Dienstleister zu bewerten. Diese Situation wiegt noch einmal schwerer, wenn Sie die Betreuung Ihres Office 365-Mandanten als Managed Service an einen Dienstleister ausgelagert haben. Sorgen Sie für eine regelmäßige Weiterbildung und Zertifizierung Ihrer IT-Mitarbeiter in den Technologiefeldern, die Sie in Ihrem Unternehmen nutzen.
Achten Sie bei der Beauftragung eines IT-Dienstleisters unbedingt darauf, dass keine Beauftragungsketten entstehen. Nehmen Sie hierzu Ihre Dienstleistungspartner in die Pflicht und fordern Sie eine Mitteilung über solche Beauftragungsketten ein. So haben Sie die notwendige Klarheit über vertragliche Abhängigkeiten, die außerhalb Ihres Kontrollbereiches sind und eventuell ein Risiko für Ihr Office 365-Projekt darstellen.
Viel Spaß mit Office 365.