Beispiele für Kundentickets.
Support-Tickets werden schneller von US-amerikanischen Teams bearbeitet, die sich um die gesamte Microsoft-Software kümmern.
Themen auf dieser Seite
Azurblau
Azurblau
Problem: Ein Benutzer meldet, dass seine Azure-Virtual Machine (VM) nach einer Größenänderung der VM-Ressourcen, z. B. CPU oder Arbeitsspeicher, nicht mehr startet. Der Benutzer hatte die VM vor der Größenänderung heruntergefahren und die dokumentierte Vorgehensweise zur Größenänderung befolgt. Nach der Größenänderung und dem Start der VM zeigt das Azure-Portal an, dass die VM ausgeführt wird, aber der Benutzer kann keine Verbindung über das Remote Desktop Protocol (RDP) herstellen.
Lösung: Nach Untersuchung des Problems wurde festgestellt, dass der Virtual Machine Agent auf der Azure-VM nicht richtig reagierte. Dies lag daran, dass die Größenänderung der Ressource die Kommunikation zwischen dem VM Agent und dem Azure Fabric Controller unterbrach. Um das Problem zu beheben, wurde der Virtual Machine Agent manuell mit dem Azure PowerShell-Modul neu gestartet. Nach dem Neustart des Agenten konnte die VM erfolgreich gestartet werden, und der Benutzer konnte über RDP eine Verbindung zu ihr herstellen.
Azurblau
Problem: Ein Kunde meldet, dass seine Azure Virtual Machine Scale Sets (VMSS) nicht skaliert werden, um den erhöhten Anforderungen an seine Website während der Spitzenzeiten gerecht zu werden. Er hat seine Skalierungsrichtlinien überprüft und festgestellt, dass eine Skalierung erfolgen sollte, aber die VMSS-Instanzen werden nicht erstellt.
Lösung: Das Azure-Supportteam untersucht das Problem und stellt fest, dass die Regeln für die automatische Skalierung so konfiguriert sind, dass sie die Metrik „durchschnittliche CPU-Auslastung” verwenden, die aufgrund anderer Faktoren während der Spitzenzeiten nicht ansteigt. Um das Problem zu beheben, empfiehlt das Team, die Regeln für die automatische Skalierung so zu ändern, dass eine andere Metrik verwendet wird, z. B. „Anfragen pro Sekunde”, die den gestiegenen Bedarf der Website besser widerspiegelt. Der Kunde nimmt diese Änderung vor, und die VMSS-Instanzen beginnen während der Spitzenzeiten erfolgreich zu skalieren. Das Problem ist behoben.
Azure Intune
Problem: Der Kunde versuchte, Richtlinien für Geräte festzulegen, die von Intune in zwei Phasen verwaltet werden, um die Verarbeitung von Windows-Updates zu erzwingen. Die Richtlinien wurden angewendet, aber die entsprechenden Geräte führten keine Maßnahmen durch. Der Kunde eröffnete ein Ticket bei US Cloud, um die Richtlinien zu überprüfen und herauszufinden, was möglicherweise fehlt, damit die Geräte ausstehende Updates verarbeiten können.
Lösung: US Cloud untersuchte das Problem und teilte dem Kunden mit, dass das Problem wahrscheinlich mit der Microsoft Teams Rooms App (MTR) zusammenhängt. MTR verfügt über eine integrierte Logik für eine Windows 10-Funktion, die Updates (für Geräte, auf denen Microsoft Teams Rooms ausgeführt wird) erst sechs Monate nach der Veröffentlichung eines Windows-Updates zulässt. Dies wird erreicht, indem eine spezielle Sperre für Microsoft Teams Rooms-Geräte im Windows Update for Business-Kanal (d. h. im Semi-Annual Channel) und über die App-Einstellungen eingerichtet wird. Während dieses Sperrzeitraums führt Microsoft verschiedene Tests sowohl intern als auch über Geräte-OEM-Partner durch, um sicherzustellen, dass die neue Windows 10-Funktion mit der Microsoft Teams Rooms-App und den daran angeschlossenen Peripheriegeräten harmoniert.
Dies ist wichtig, um sowohl die Gerätesicherheit und eine konsistente Benutzererfahrung zu gewährleisten als auch die Qualität der über die Microsoft Teams Rooms-App angebotenen Erfahrungen sicherzustellen. Das Problem und die Ursache wurden dem Kunden ausführlich erläutert, und die IT-Abteilung konnte die Erwartungen hinsichtlich dieser verzögerten Updates zurücksetzen.
Azure AD
Problem: Auf einem Windows Server, auf dem Azure AD Connect ausgeführt wird, funktioniert der Synchronisierungsprozess nicht ordnungsgemäß. Der Synchronisierungsstatus zeigt an, dass die letzte Synchronisierung nicht erfolgreich war und Änderungen, die im lokalen Active Directory vorgenommen wurden, nicht in Azure AD repliziert werden.
Lösung: Nach Überprüfung der Azure AD Connect-Installation und Bestätigung, dass der Dienst ausgeführt wurde, stellte sich heraus, dass das Problem mit den Firewall-Einstellungen zusammenhing. Die für die Kommunikation mit Azure AD erforderlichen Ports waren in der Windows-Firewall nicht geöffnet. Um das Problem zu beheben, wurden die erforderlichen Ports in der Firewall durch Erstellen von Eingangs- und Ausgangsregeln geöffnet. Nach diesen Änderungen wurde der Synchronisierungsprozess erfolgreich ausgeführt und die Änderungen im lokalen Active Directory wurden in Azure AD repliziert.
Azure DevOps
Problem: Während des Bereitstellungsprozesses konnte eine Azure DevOps-Pipeline nicht ausgeführt werden, was zu einer Verzögerung bei der Veröffentlichung der Anwendung führte. Die Fehlermeldung wies darauf hin, dass ein erforderliches Paket fehlte, aber es war unklar, warum das Paket nicht gefunden wurde.
Lösung: Das Problem wurde behoben, indem das fehlende Paket zu den Abhängigkeiten des Projekts hinzugefügt und die Anwendung neu erstellt wurde. Zusätzlich wurde die Pipeline aktualisiert, sodass vor der Ausführung nun alle erforderlichen Abhängigkeiten überprüft werden, was dazu beiträgt, ähnliche Probleme in Zukunft zu vermeiden. Das Team führte außerdem automatisierte Tests ein, um Probleme zu erkennen, bevor sie zu Verzögerungen im Release-Prozess führen können.
Azure-Ressourcen-Manager
Problem: Bei der Bereitstellung einer neuen Azure Resource Manager (ARM)-Vorlage schlägt die Bereitstellung mit einer Fehlermeldung fehl, die besagt, dass eine Ressource nicht erstellt oder aktualisiert werden konnte.
Lösung: Um das Problem zu beheben, wurde die Ressourcengruppe überprüft, um sicherzustellen, dass sie vorhanden war und die richtigen Berechtigungen zugewiesen waren. Es wurde festgestellt, dass die erforderlichen Berechtigungen fehlten, sodass dem erforderlichen Benutzer und Dienstprinzipal die entsprechenden Berechtigungen erteilt wurden. Die Bereitstellung wurde dann erneut versucht und erfolgreich abgeschlossen. Die Ressource wurde wie erwartet aktualisiert.
Microsoft 365
M365 Verteidiger
Problem: M365 Defender erkennt keine Bedrohungen auf Windows-Geräten, obwohl die entsprechenden Richtlinien vorhanden sind und die Geräte auf dem neuesten Stand sind.
Lösung: Das Problem wurde behoben, indem die M365 Defender-Einstellungen überprüft und sichergestellt wurde, dass alle Richtlinien ordnungsgemäß konfiguriert waren. Im nächsten Schritt wurde überprüft, ob die neuesten Updates für Windows Defender auf den betroffenen Geräten installiert waren. Nachdem bestätigt wurde, dass die Updates installiert waren, wurden die Geräte erneut auf Bedrohungen gescannt, und das Problem wurde behoben. Schließlich wurden zusätzliche Maßnahmen ergriffen, um sicherzustellen, dass M365 Defender alle Windows-Geräte kontinuierlich überwacht und Bedrohungen erkennt.
M365 Power BI
Problem: Ein Benutzer meldete, dass sein Power BI-Dashboard nicht automatisch aktualisiert wurde, obwohl er eine automatische Aktualisierung nach einem Zeitplan eingerichtet hatte.
Lösung: Nach Untersuchung des Problems wurde festgestellt, dass die Anmeldedaten der Datenquelle des Benutzers nicht ordnungsgemäß gespeichert worden waren, wodurch die Aktualisierung fehlschlug. Die Anmeldedaten der Datenquelle wurden mit den korrekten Login-Informationen aktualisiert und der automatische Aktualisierungszeitplan wurde neu gestartet. Das Dashboard konnte dann erfolgreich zum festgelegten Zeitpunkt aktualisiert werden. Dem Benutzer wurde empfohlen, bei ähnlichen Problemen in Zukunft seine Anmeldedaten für die Datenquelle zu überprüfen.
M365 PowerApps
Problem: PowerApps -Formular übermittelt keine Daten an SharePoint-Liste
Lösung: Zunächst haben wir überprüft, ob die SharePoint-Liste ordnungsgemäß konfiguriert war, um Daten aus dem PowerApps-Formular zu akzeptieren. Anschließend haben wir sichergestellt, dass die Verbindung des Formulars zur SharePoint-Liste korrekt funktionierte. Als Nächstes haben wir die OnSelect-Funktion der Schaltfläche „Senden” überprüft, um sicherzustellen, dass sie ordnungsgemäß mit der SharePoint-Liste verknüpft war. Schließlich haben wir das Formular auf fehlende oder falsche Formeln oder Ausdrücke überprüft, die das Problem verursachen könnten. Nach diesen Schritten konnten wir Daten aus dem PowerApps-Formular erfolgreich an die SharePoint-Liste senden.
M365 SharePoint
Problem: Ein Benutzer meldete, dass er den Inhalt einer SharePoint-Liste in M365 nicht anzeigen konnte. Immer wenn er auf die Liste klickte, wurde die Seite geladen, aber die Listenelemente wurden nicht angezeigt.
Lösung: Unser Team hat das Problem untersucht und festgestellt, dass der Benutzer versehentlich die Ansichtseinstellungen der Liste geändert hatte. Wir haben dem Benutzer empfohlen, eine andere Ansicht auszuwählen oder die aktuelle Ansicht auf die Standardeinstellungen zurückzusetzen. Nachdem der Benutzer unsere Anweisungen befolgt hatte, konnte er den Inhalt der Liste ohne weitere Probleme anzeigen. Wir haben den Benutzer außerdem daran erinnert, bei der Änderung von Listeneinstellungen vorsichtig zu sein, um unbeabsichtigte Folgen zu vermeiden.
M365 Teams
Problem: Der Kunde hatte kürzlich auf Teams umgestellt, und es kam noch häufig zu Benutzerfehlern. Es stellte sich heraus, dass einige wichtige Teams-Nachrichten versehentlich gelöscht worden waren und alle Bemühungen des internen IT-Teams, diese wiederherzustellen, erfolglos geblieben waren.
Lösung: US Cloud beschaffte sich zunächst Hintergrundinformationen und Details zu den Nachrichten und bestätigte, dass diese tatsächlich gelöscht und nicht archiviert worden waren. Anschließend überprüften die Techniker von US Cloud, ob die Microsoft Teams-Instanz des Kunden möglicherweise mit „Legal Hold” konfiguriert worden war. Obwohl diese Funktion von IT-Teams nicht häufig verwendet wird, wird „Legal Hold“ oft bei der Einrichtung aktiviert, um sicherzustellen, dass alle Informationen und Interaktionen innerhalb von Teams auf unbestimmte Zeit gespeichert werden, damit jemand die Beweise für ein Gericht suchen und exportieren kann. „Litigation Hold“ bewahrt eine Kopie der Daten auch nach deren Löschung auf. Ein Benutzer kann den Inhalt weiterhin wie gewohnt löschen, aber Microsoft speichert die Daten weiterhin an einem versteckten Ort, auf den nur Administratoren Zugriff haben.
Das US-Cloud-Team stellte fest, dass der gelöschte Teams-Raum tatsächlich in Litigation gesichert war und die Nachrichten wiederhergestellt wurden. Die Audit-Protokolle wurden während einer Bildschirmfreigabe überprüft, und es wurde festgestellt, dass es für diese Art von Ereignis keine Audit-Ebenen gab. US Cloud riet dem Kunden, die Exchange-Seite zu überprüfen, und fand den Benutzer, der die Nachrichten gelöscht hatte. Anschließend wurde er bei der Anpassung der entsprechenden Berechtigungen unterstützt, um das Problem zu beheben und eine Wiederholung des Vorfalls zu verhindern.
M365 Exchange
Problem: Ein Exchange Server sendet oder empfängt keine E-Mails mehr. Bei der Untersuchung wird festgestellt, dass die Transportdienste des Exchange Servers nicht mehr funktionieren. Die Ursache des Problems liegt in einem abgelaufenen SSL-Zertifikat, das für die sichere Kommunikation zwischen dem Exchange Server und den E-Mail-Clients erforderlich ist.
Lösung: Das abgelaufene SSL-Zertifikat wird durch ein gültiges ersetzt und die Transportdienste des Exchange-Servers werden neu gestartet. Anschließend wird der Exchange-Server auf seine E-Mail-Sende- und Empfangsfunktionalität getestet und es wird bestätigt, dass das Problem behoben wurde. Um ähnliche Probleme in Zukunft zu vermeiden, wird ein Überwachungssystem eingerichtet, das das IT-Team benachrichtigt, wenn SSL-Zertifikate kurz vor dem Ablauf stehen.
M365 OneDrive
Problem: Benutzer haben Probleme bei der Synchronisierung ihrer Office-Dokumente mit OneDrive, was zu Synchronisierungsfehlern führt. Bei einigen Benutzern werden außerdem doppelte Dateien in ihrem OneDrive-Ordner erstellt.
Lösung: Nach Untersuchung des Problems wurde festgestellt, dass die Synchronisierungsfehler durch einen Konflikt mit dem Office-Uploadcenter verursacht wurden. Die Lösung bestand darin, das Office-Uploadcenter zu deaktivieren und anschließend Microsoft Office zu reparieren. Die doppelten Dateien wurden durch Deaktivieren der Option „Dateien bei Bedarf“ in den OneDrive-Einstellungen behoben. Nach diesen Änderungen waren die Synchronisierungsfehler und doppelten Dateien behoben, und die Benutzer konnten ihre Office-Dokumente ohne Probleme mit OneDrive synchronisieren.
M365-Ablauf
Problem: Ein Benutzer hatte gemeldet, dass sein Microsoft Flow-Workflow trotz Erfüllung der Auslösebedingungen nicht ausgelöst wurde. Er hatte bereits überprüft, dass die Auslösebedingung erfüllt war und dass sein Konto über die erforderlichen Berechtigungen zum Ausführen des Workflows verfügte.
Lösung: Das Support-Team untersuchte das Problem und stellte fest, dass es mit einem bekannten Fehler im Microsoft Flow-Dienst zusammenhing. Es wandte einen Patch auf den betroffenen Server an, woraufhin der Workflow des Benutzers erfolgreich ausgelöst werden konnte. Das Team riet dem Benutzer, das Dashboard zum Status des Microsoft Flow-Dienstes zu überprüfen, um sich über zukünftige Ausfälle oder Probleme mit dem Dienst zu informieren.
M365-Planer
Problem: Ein Team meldet, dass die Aufgabenverteilungen in Microsoft Planner für gemeinsam genutzte Pläne nicht aktualisiert werden. Wenn einem Teammitglied eine Aufgabe zugewiesen wird, werden die Änderungen für andere Teammitglieder nicht in Echtzeit angezeigt. Das Team hat bestätigt, dass alle Benutzer ordnungsgemäß mit dem gemeinsam genutzten Plan verbunden sind und über die erforderlichen Berechtigungen verfügen.
Lösung: Nach eingehender Untersuchung wird festgestellt, dass das Problem auf eine Synchronisationsverzögerung zwischen dem Planner-Server und dem lokalen Cache des Benutzers zurückzuführen ist. Das Support-Team wendet einen Patch an, um den Synchronisationsprozess zu verbessern und die Verzögerung zu verringern. Darüber hinaus empfiehlt das Team den betroffenen Benutzern, ihren lokalen Cache manuell zu aktualisieren, indem sie temporäre Dateien löschen und die Planner-Anwendung neu starten. Dadurch wird sichergestellt, dass die Aufgabenverteilungen für alle Teammitglieder im gemeinsamen Plan korrekt und zeitnah aktualisiert werden.
Dynamik
Dynamics 365
Problem: Benutzer hatten Probleme mit einer langsamen Leistung bei der Verwendung von Dynamics 365 im Webclient. Dies führte zu Frustration und einer Verlangsamung der Produktivität.
Lösung: Nach Untersuchung des Problems wurde festgestellt, dass im Hintergrund einige benutzerdefinierte Skripte ausgeführt wurden, die nicht für die Leistung optimiert waren. Diese Skripte führten zu einer Verlangsamung des Webclients. Die Lösung bestand darin, die benutzerdefinierten Skripte zu optimieren, indem unnötige Schleifen entfernt, die Anzahl der DOM-Manipulationen reduziert und die Abfragen optimiert wurden. Nach der Implementierung der optimierten Skripte verbesserte sich die Leistung des Webclients erheblich, und die Benutzer hatten keine Probleme mehr mit einer langsamen Leistung.
Dynamics AX
Problem: Während der Installation eines Updates für Dynamics AX wird eine Fehlermeldung angezeigt, die darauf hinweist, dass die Installation aufgrund fehlender Abhängigkeiten fehlgeschlagen ist. Nach Überprüfung der Abhängigkeiten wird festgestellt, dass eine der erforderlichen Komponenten von Drittanbietern nicht auf dem Server installiert ist.
Lösung: Die fehlende Komponente wird identifiziert und auf dem Server installiert. Die Installation des Updates wird dann erneut versucht und erfolgreich abgeschlossen. Das System wird getestet, um sicherzustellen, dass das Update keine Probleme mit der Funktionalität von Dynamics AX verursacht hat. Schließlich wird die Dokumentation aktualisiert, um die neu installierte Komponente als erforderliche Abhängigkeit für zukünftige Installationen oder Upgrades zu berücksichtigen.
Dynamics GP
Problem: Ein Benutzer meldet eine Fehlermeldung, wenn er versucht, eine Transaktion in Dynamics GP zu buchen. Die Fehlermeldung besagt, dass der Stapel von einem anderen Benutzer bearbeitet wird und nicht gebucht werden kann. Der Benutzer bestätigt jedoch, dass er der einzige Benutzer ist, der auf den Stapel zugreift.
Lösung: Das Problem wird auf eine Sperre in der Datenbank zurückgeführt. Das Support-Team identifiziert und entfernt die Sperre, sodass der Benutzer die Transaktion erfolgreich durchführen kann. Das Team empfiehlt dem Benutzer, regelmäßige Datenbankwartungsaufgaben durchzuführen, z. B. Datenbankintegritätsprüfungen und das Löschen alter Transaktionsdaten, um ähnliche Probleme in Zukunft zu vermeiden.
Dynamik F&O
Problem: Ein Dynamics F&O-Benutzer meldete eine Fehlermeldung, die beim Öffnen eines bestimmten Formulars angezeigt wurde. Die Fehlermeldung wies auf ein Problem mit einem Objekt im Formular hin und verhinderte, dass der Benutzer es öffnen konnte. Der Benutzer versuchte, das Formular zu aktualisieren, den Cache zu leeren und sogar das System neu zu starten, aber der Fehler blieb bestehen.
Lösung: Das Problem wurde auf eine Dateninkonsistenz in der Dynamics F&O-Datenbank zurückgeführt. Der Datenbankadministrator führte eine Abfrage durch, um die spezifische Dateninkonsistenz zu identifizieren, und korrigierte sie. Nachdem die Dateninkonsistenz behoben war, konnte der Benutzer das Formular ohne Fehlermeldung öffnen. Der Administrator wies den Benutzer an, ähnliche Probleme unverzüglich zu melden, um weitere Datenbankinkonsistenzen zu vermeiden.
Windows Server
Windows Server
Problem: Der Kunde hatte Windows Server 2012 mit einer wiederkehrenden Aufgabe, die einen wöchentlichen Neustart des Servers vorsah. Ohne ersichtlichen Grund begann der Server, diese Aufgabe früher in der Woche und dann erneut zur geplanten Zeit auszuführen.
Lösung: US Cloud untersuchte zunächst, ob sich das System im Ruhezustand befand. Darüber hinaus gab es in den Ereignisprotokollen keine Ereignisse im Zusammenhang mit einem Kernel-Stromausfall und auch keine Ereignis-ID 42. Die Techniker von US Cloud wiesen den Kunden an, die AC-Bedingung aus der Aufgabe zu entfernen und sicherzustellen, dass keine GPO-Einstellungen oder ein SCCM-Neustartplan vorhanden waren. Der Kunde setzte den Taskplaner zurück, um ihn für Windows Server 2012 r2 zu konfigurieren, da er für 2008 eingestellt war. Nach den Änderungen ließ der Kunde die Aufgabe über das Wochenende mit der Änderung laufen und bestätigte, dass das Problem behoben war.
Windows Server
Problem: Ein Windows Server-Administrator meldete, dass sein Server ständig abstürzte und nicht mehr reagierte. Bei der Untersuchung stellte er fest, dass der Server aufgrund eines bestimmten Dienstes abstürzte, der nicht mehr reagierte, aber er konnte die Ursache des Problems nicht ermitteln. Er versuchte, den Dienst und den Server neu zu starten, aber das Problem blieb bestehen.
Lösung: Das Team empfahl die Verwendung des Debug Diagnostic Tools, um die Ursache für den nicht reagierenden Dienst zu ermitteln. Es analysierte den vom Tool erstellten Speicherauszug und stellte fest, dass das Problem durch eine bestimmte Funktion innerhalb des Dienstes verursacht wurde. Das Team untersuchte die Funktion und stellte fest, dass sie versuchte, auf eine Ressource zuzugreifen, die nicht mehr verfügbar war. Es aktualisierte die Funktion, um dieses Szenario korrekt zu behandeln, und der Server stürzte nicht mehr ab.
Windows Server
Problem: Eine virtuelle Maschine (VM) unter Windows Server 2019 konnte auch nach Eingabe der korrekten Anmeldedaten nicht mit der Domäne verbunden werden. Die Fehlermeldung wies auf ein Problem mit dem sicheren Kanal hin, wodurch die VM keine Verbindung zum Domänencontroller herstellen konnte. Der Administrator versuchte, das Computerkonto zurückzusetzen und den sicheren Kanal mit dem Befehl „Netdom“ wiederherzustellen, aber das Problem blieb bestehen.
Lösung: Das Team stellte fest, dass die Uhr der VM um mehr als 5 Minuten von der Uhr des Domänencontrollers abwich, wodurch der sichere Kanal ausfiel. Der Administrator aktualisierte die Uhr der VM, sodass sie mit der Uhr des Domänencontrollers übereinstimmte, und die VM konnte erfolgreich der Domäne beitreten. Das Team empfahl außerdem, die Zeitsynchronisation auf der VM zu konfigurieren, um sicherzustellen, dass die Uhr mit der Uhr des Domänencontrollers synchron bleibt.
Windows Server – Active Directory
Problem: Ein Windows Server-Administrator meldete ein Problem mit der Active Directory-Replikation zwischen zwei Domänencontrollern. Der Administrator überprüfte die Netzwerkverbindung und die DNS-Konfiguration, konnte den Replikationsfehler jedoch nicht beheben. Der sichere Kanal zwischen den Domänencontrollern wurde zurückgesetzt, aber das Problem blieb bestehen.
Lösung: Das Support-Team untersuchte den Fall und stellte eine Nichtübereinstimmung der Sicherheitskennungen (SID) der Domänencontroller fest. Um das Problem zu beheben, empfahl das Team eine Bereinigung der Metadaten der Domänencontroller, um ungültige oder verwaiste Einträge zu entfernen. Die Bereinigung wurde durchgeführt, woraufhin die SIDs der Domänencontroller übereinstimmten. Die Replikation wurde neu gestartet, und die Domänencontroller konnten miteinander kommunizieren und die Active Directory-Daten erfolgreich replizieren, wodurch das Problem behoben wurde.
Windows Server – AD-Verbund
Problem: Ein Windows Server-Administrator meldete Probleme mit der ADFS-Authentifizierung, da sich Benutzer nicht bei der Verbundanwendung anmelden konnten. Nachdem er überprüft hatte, dass die Zertifikate gültig waren und die Vertrauensstellung zwischen den Verbundservern ordnungsgemäß funktionierte, überprüfte der Administrator die Ereignisprotokolle und fand Fehlermeldungen, die darauf hinwiesen, dass der ADFS-Dienst keine Verbindung zur SQL-Datenbank herstellen konnte.
Lösung: Das Support-Team untersuchte das Problem und stellte fest, dass es durch eine Fehlkonfiguration des ADFS-Dienstkontos in der SQL-Datenbank verursacht wurde. Das Team empfahl dem Administrator, die SQL Server-Datenbankberechtigungen für das ADFS-Dienstkonto zu überprüfen und sicherzustellen, dass es über die entsprechenden Berechtigungen für den Zugriff auf die erforderlichen Tabellen verfügt. Der Administrator folgte der Empfehlung des Teams und aktualisierte die Berechtigungen des Dienstkontos in der SQL-Datenbank. Danach konnte der ADFS-Dienst ohne Probleme eine Verbindung zur Datenbank herstellen und Benutzer authentifizieren. Das Problem wurde behoben.
Windows Server – Gruppenrichtlinie
Problem: Ein Windows Server-Administrator hat gemeldet, dass die Gruppenrichtlinieneinstellungen nicht auf Clientcomputer in der Domäne angewendet werden. Der Administrator hat überprüft, dass die Gruppenrichtlinienobjekte mit den entsprechenden Organisationseinheiten (OUs) verknüpft sind und dass die Berechtigungen korrekt festgelegt sind, aber die Einstellungen werden immer noch nicht angewendet. Der Administrator hat auch die Ereignisprotokolle auf den Clientcomputern überprüft und Fehlermeldungen gefunden, die darauf hinweisen, dass die Verarbeitung der Gruppenrichtlinien fehlschlägt.
Lösung: Nach Untersuchung des Problems stellte das Supportteam fest, dass das Problem durch eine Beschädigung des Gruppenrichtlinien-Caches auf den Clientcomputern verursacht wurde. Zur Behebung des Problems empfahl das Team, den Gruppenrichtlinien-Cache auf den Clientcomputern zu löschen, indem der Inhalt des Ordners „C:\Windows\System32\GroupPolicy“ gelöscht wurde. Der Administrator führte diese Aktion auf den Clientcomputern durch, woraufhin die Gruppenrichtlinieneinstellungen erfolgreich angewendet wurden. Das Problem wurde behoben, und die Client-Computer empfingen und übernahmen die Gruppenrichtlinieneinstellungen korrekt.
Windows Server – PowerShell
Problem: Ein Windows Server-Administrator meldet, dass PowerShell-Befehle auf seinem Server nicht ausgeführt werden können. Der Administrator hat versucht, grundlegende Befehle wie „Get-ChildItem“ und „Get-Service“ auszuführen, aber alle Befehle schlagen mit Fehlermeldungen fehl, die darauf hinweisen, dass die Befehle nicht erkannt werden. Der Administrator hat außerdem überprüft, dass die auf dem Server installierte PowerShell-Version auf dem neuesten Stand ist und dass die Ausführungsrichtlinie so eingestellt ist, dass Skripte ausgeführt werden können.
Lösung: Das Supportteam stellt fest, dass das Problem durch eine fehlende Umgebungsvariable verursacht wird, die für die korrekte Ausführung von PowerShell erforderlich ist. Um das Problem zu beheben, empfiehlt das Team, die Umgebungsvariable PATH so einzustellen, dass sie den Ordnerpfad enthält, in dem sich die ausführbare Datei von PowerShell befindet. Der Administrator fügt den Ordnerpfad zur Umgebungsvariable PATH hinzu, woraufhin die PowerShell-Befehle erfolgreich ausgeführt werden können. Das Problem ist behoben, und der Administrator kann nun PowerShell-Befehle auf dem Server verwenden.
Windows Server – Hyper-V
Problem: Wir sind auf ein häufig auftretendes Problem gestoßen, bei dem eine virtuelle Maschine keine Verbindung zum Netzwerk auf einem Hyper-V-Server herstellen konnte. Dies führte zu Kommunikationsproblemen zwischen der virtuellen Maschine und anderen Netzwerkgeräten.
Lösung: Das Problem mit der Netzwerkverbindung der virtuellen Maschine auf dem Hyper-V-Server wurde durch Überprüfen der Konfiguration des virtuellen Switches und Aktualisieren der Netzwerkkarteneinstellungen der virtuellen Maschine behoben. Wir stellten fest, dass die Konfiguration des virtuellen Switches falsch war und aktualisiert werden musste, damit die virtuelle Maschine eine Verbindung zum Netzwerk herstellen konnte. Zusätzlich haben wir die Netzwerkkarteneinstellungen der virtuellen Maschine aktualisiert, um die richtige Netzwerkkonfiguration zu verwenden.
Windows Server – Remotedesktop
Problem: Wir sind auf ein häufig auftretendes Problem gestoßen, bei dem eine Remotedesktopverbindung auf einem Windows Server fehlschlug. Dies verhinderte den Fernzugriff auf den Server und verursachte Kommunikationsprobleme zwischen dem Server und Remote-Geräten.
Lösung: Um das Problem zu beheben, haben wir die Ereignisprotokolle der Remotedesktopdienste überprüft und einen Fehler gefunden, der besagte, dass der RDP-Listener nicht verfügbar war. Anschließend haben wir ein PowerShell-Skript ausgeführt, um den RDP-Listener-Dienst neu zu starten. Dadurch wurde das Problem behoben und der Remotezugriff auf den Server ermöglicht.
Windows Server – IIS
Problem: Wir sind auf ein häufiges Problem gestoßen, bei dem der Webserver auf einem Windows Server mit IIS nicht reagierte. Dies verhinderte den Zugriff auf die Website und verursachte Kommunikationsprobleme zwischen dem Server und Remote-Geräten.
Lösung: Um dieses Problem zu beheben, haben wir die IIS-Protokolle überprüft und einen Fehler gefunden, der besagte, dass die Website keine Verbindung zu einer bestimmten IP-Adresse herstellen konnte. Anschließend haben wir die Netzwerkkonfiguration überprüft und festgestellt, dass die IP-Adresse nicht korrekt konfiguriert war. Wir haben die Netzwerkkonfiguration aktualisiert, um die richtige IP-Adresse zu verwenden, und die Website neu gestartet, wodurch das Problem behoben wurde und der Zugriff auf die Website wieder möglich war.
Windows Server – DFS
Problem: Die DFS- Replikation zwischen zwei Windows Server-Computern funktioniert nicht mehr, was dazu führt, dass Dateien nicht ordnungsgemäß synchronisiert werden und Dateninkonsistenzen auftreten.
Lösung: Wir haben festgestellt, dass das Problem auf einen veralteten Netzwerktreiber auf einem der Rechner zurückzuführen war. Nach der Aktualisierung des Treibers haben wir den DFS-Replikationsdienst neu gestartet und eine Synchronisierung zwischen den beiden Servern erzwungen. Dadurch wurde das Problem behoben und sichergestellt, dass die Dateien zwischen den Servern ordnungsgemäß synchronisiert wurden.
Windows Server – Identitätsmanager
Problem: Benutzer können sich aufgrund von Synchronisierungsproblemen zwischen Windows Server Active Directory und dem Identity Manager-System nicht bei Anwendungen anmelden.
Lösung: Wir haben festgestellt, dass das Synchronisierungsdienstkonto nicht über ausreichende Berechtigungen für den Zugriff auf die erforderlichen Active Directory-Ressourcen verfügte. Wir haben das Dienstkonto mit den entsprechenden Berechtigungen aktualisiert und den Synchronisierungsdienst neu gestartet. Nachdem wir überprüft hatten, dass der Synchronisierungsprozess reibungslos ablief, konnten sich die Benutzer ohne weitere Probleme bei den betroffenen Anwendungen anmelden.
Vor Ort
Vor Ort – System Center
Problem: Die System Center Operations Manager (SCOM)-Konsole lädt langsam und reagiert träge auf Benutzereingaben.
Lösung: Wir haben festgestellt, dass die SCOM-Datenbank aufgrund eines übermäßigen Datenwachstums Leistungsprobleme hatte. Wir haben eine Datenbankbereinigung und -optimierung durchgeführt, bei der alte Daten gelöscht, Tabellen neu indiziert und Statistiken aktualisiert wurden. Nach Abschluss des Optimierungsprozesses hat sich die Leistung der SCOM-Konsole deutlich verbessert, und die Benutzer berichteten von schnelleren Ladezeiten und einer verbesserten Reaktionsfähigkeit.
Vor Ort – SharePoint
Problem: Ein Sharepoint-Administrator meldet, dass Benutzer nicht auf eine bestimmte Dokumentbibliothek auf der Sharepoint-Website zugreifen können. Der Administrator hat die Berechtigungen für die Bibliothek überprüft und sichergestellt, dass die Benutzer über die entsprechenden Berechtigungen verfügen, aber das Problem besteht weiterhin. Der Administrator hat auch die Website- und Serverprotokolle überprüft und keine Fehler im Zusammenhang mit dem Problem gefunden.
Lösung: Nach weiteren Untersuchungen stellt das Supportteam fest, dass das Problem durch beschädigte Berechtigungen für die Bibliothek verursacht wird. Um das Problem zu beheben, empfiehlt das Team, die Bibliotheksberechtigungen mit PowerShell auf ihre Standardeinstellungen zurückzusetzen. Der Administrator führt das PowerShell-Skript aus und überprüft, ob die Bibliotheksberechtigungen zurückgesetzt wurden. Die Benutzer können nun auf die Bibliothek zugreifen, und das Problem ist behoben.
Vor Ort – Austausch
Problem: Die MS Exchange-Datenbank wird nicht gemountet, und Benutzer können nicht auf ihre E-Mails zugreifen. Der Exchange-Administrator hat überprüft, dass sich die Datenbank in einem ordnungsgemäßen Herunterfahrzustand befindet und genügend Speicherplatz verfügbar ist. Beim Versuch, die Datenbank zu mounten, schlägt dies jedoch mit einer Fehlermeldung fehl, die darauf hinweist, dass die Datenbank beschädigt ist.
Lösung: Nach Untersuchung des Problems stellt das Support-Team fest, dass die Exchange-Datenbank beschädigt ist und die Protokolle nicht wiedergegeben werden. Um das Problem zu beheben, empfiehlt das Team, die Datenbank aus der letzten Sicherung wiederherzustellen und die Protokolle wiederzugeben. Der Administrator stellt die Datenbank aus der Sicherung wieder her und gibt die Protokolle wieder, woraufhin die Datenbank erfolgreich gemountet wird. Das Problem ist behoben, und die Benutzer können nun auf ihre E-Mails zugreifen.
Vor Ort – BizTalk
Problem: Ein BizTalk-Administrator meldet, dass beim Senden und Empfangen von Nachrichten zwischen zwei Systemen ein Problem auftritt. Der Administrator hat überprüft, dass der Sendeport und die Empfangsorte korrekt konfiguriert sind, aber die Nachrichten werden weiterhin nicht verarbeitet. Der Administrator hat auch die Ereignisprotokolle überprüft und Fehlermeldungen gefunden, die darauf hinweisen, dass die Nachrichten aufgrund eines Schema-Validierungsfehlers ausgesetzt werden.
Lösung: Nach Untersuchung des Problems stellt das Supportteam fest, dass das Problem durch eine Nichtübereinstimmung zwischen dem Nachrichtenschema und dem vom Empfangssystem erwarteten Schema verursacht wird. Zur Behebung des Problems empfiehlt das Team, das Nachrichtenschema so zu aktualisieren, dass es mit dem erwarteten Schema des Empfangssystems übereinstimmt. Der Administrator aktualisiert das Nachrichtenschema und startet den Sendeport und den Empfangsort neu, woraufhin die Nachrichten erfolgreich verarbeitet werden. Das Problem ist behoben.
Vor Ort – SQL Server
Problem: Ein Windows Server-Administrator meldet, dass eine lokale SQL Server-Datenbank nicht reagiert und Benutzer nicht darauf zugreifen können. Der Administrator hat überprüft, dass die Serverhardware ordnungsgemäß funktioniert und keine Probleme mit der Netzwerkverbindung vorliegen. Der Administrator hat außerdem die SQL Server-Fehlerprotokolle überprüft und Fehlermeldungen gefunden, die darauf hinweisen, dass die Datenbank Transaktionssperren aufweist.
Lösung: Nach der Analyse der Deadlock-Informationen stellt das Support-Team fest, dass das Problem durch widersprüchliche Abfragen aus verschiedenen Transaktionen verursacht wird. Um das Problem zu beheben, empfiehlt das Team, die SQL-Abfragen so zu ändern, dass sie sich nicht gegenseitig widersprechen. Der Administrator arbeitet mit den Anwendungsentwicklern zusammen, um die SQL-Abfragen zu ändern, und die Datenbank reagiert wieder. Das Problem ist behoben, und die Benutzer können ohne Probleme auf die Datenbank zugreifen.
Vor Ort – Skype Business
Problem: Ein Benutzer meldet, dass er keine Nachrichten in einem permanenten Chatraum in Skype for Business anzeigen kann. Andere Benutzer können die Nachrichten sehen, dieser Benutzer jedoch nicht. Der Administrator hat überprüft, dass der Benutzer über die entsprechenden Berechtigungen für den Chatraum verfügt und dass der Chatraum ordnungsgemäß funktioniert, aber der Benutzer kann die Nachrichten weiterhin nicht sehen.
Lösung: Nach Untersuchung des Problems stellt das Supportteam fest, dass der Skype for Business-Client des Benutzers nicht ordnungsgemäß mit dem Server synchronisiert wird. Um das Problem zu beheben, empfiehlt das Team, den Skype for Business-Cache des Benutzers zu leeren, indem der Inhalt der folgenden Ordner gelöscht wird: \Lync und \Lync\sip_USERNAME. Der Benutzer führt diese Aktion auf seinem Client durch, woraufhin die Nachrichten im persistenten Chatraum korrekt angezeigt werden. Das Problem ist behoben.
Entwickler
Entwickler – Edge-Browser
Problem: Beim Zugriff auf eine Webseite von einer anderen Domain zeigt der Edge-Browser eine Fehlermeldung an, dass die Webseite aufgrund eines Problems mit der „Cross-Origin Resource Sharing“-Richtlinie (CORS) nicht aufgerufen werden kann. Dieser Fehler verhindert das ordnungsgemäße Laden der Webseite und kann das Surferlebnis des Benutzers beeinträchtigen.
Lösung: Um das CORS-Problem zu beheben, haben wir in den Einstellungen von Edge unter „Internetoptionen“ die Option „Auf Datenquellen über Domänen hinweg zugreifen“ aktiviert. Außerdem haben wir den serverseitigen Code aktualisiert und die entsprechenden CORS-Header hinzugefügt, um Cross-Origin-Anfragen zu ermöglichen. Nach diesen Änderungen haben wir die Anwendung erneut getestet und festgestellt, dass das CORS-Problem behoben war.
Entwickler – Visual Studio
Problem: Ein Entwickler meldete, dass sein Visual Studio-Build mit einem MSB3073-Fehler fehlschlug, der darauf hinwies, dass ein Befehl mit einem Exit-Code ungleich Null beendet wurde. Dieser Fehler trat auf, als der Entwickler versuchte, einen Post-Build-Befehl auszuführen, der gebaute Dateien an einen bestimmten Speicherort im Dateisystem kopierte. Der Entwickler hatte bestätigt, dass der Befehl korrekt funktionierte, wenn er manuell über die Befehlszeile ausgeführt wurde.
Lösung: Nach einer Untersuchung stellte das Support-Team fest, dass der Fehler MSB3073 dadurch verursacht wurde, dass Visual Studio versuchte, den Post-Build-Befehl auszuführen, bevor alle Abhängigkeiten des Projekts vollständig erstellt worden waren. Um das Problem zu beheben, empfahl das Support-Team, eine Abhängigkeit zum Attribut „BeforeTargets” des Ziels „Copy” in der Projektdatei hinzuzufügen. Dadurch wurde sichergestellt, dass der Post-Build-Befehl erst ausgeführt wurde, nachdem alle Abhängigkeiten erfolgreich erstellt worden waren. Der Entwickler nahm diese Änderung an der Projektdatei vor und konnte das Projekt erfolgreich erstellen, ohne dass der Fehler MSB3073 auftrat.
Entwickler – .Net-Entwicklung
Problem: Ein .NET-Entwickler meldete, dass seine ASP.NET Core-Anwendung beim Start einen System.InvalidOperationException-Fehler mit der Meldung „Unable to resolve service for type” (Dienst für Typ kann nicht aufgelöst werden) auslöste. Trotz verschiedener Lösungsversuche wie dem Neuaufbau des Projekts, dem Bereinigen der Lösung und dem Leeren des NuGet-Paket-Caches verhinderte der Fehler weiterhin den korrekten Start der Anwendung.
Lösung: Nach Untersuchung des Problems stellte das Support-Team fest, dass der Fehler durch eine Diskrepanz zwischen den registrierten Diensten und den Abhängigkeiten in der Anwendung verursacht wurde. Zur Behebung des Problems empfahlen sie, die ConfigureServices-Methode in der Datei Startup.cs zu überprüfen, um sicherzustellen, dass alle Abhängigkeiten korrekt registriert waren. Der Entwickler aktualisierte den Registrierungscode, woraufhin die Anwendung ohne den Fehler „System.InvalidOperationException“ gestartet werden konnte.
Entwickler – Outlook
Problem: Dieser sehr große und renommierte 100 Jahre alte US-Einzelhändler, der sich zum Online-Händler gewandelt hatte, stellte plötzlich fest, dass sich keiner seiner Mitarbeiter mehr bei seiner SharePoint-Website anmelden und darauf zugreifen konnte. Das Unternehmen nutzte diese Plattform als primären internen Hub für die gemeinsame Nutzung und den Zugriff auf Dokumente, und der fehlende Zugriff führte zu erheblichen Störungen im Geschäftsbetrieb.
Lösung: Es wurde ein US Cloud-Ticket eröffnet. Nach einer ersten schnellen Antwort und einer ersten Einstufung wurde noch am selben Tag ein Premier-Techniker hinzugezogen. Bei der Untersuchung der jüngsten Aktivitäten des Kunden stellte sich heraus, dass das Zertifikat für SharePoint-Server erst kürzlich aktualisiert worden war. US Cloud stellte fest, dass dies höchstwahrscheinlich die Ursache des Problems war, und riet dem Kunden, das Zertifikat „SharePoint Root Authority” in den vertrauenswürdigen Stammzertifikatspeicher aller SharePoint-Server zu importieren. Der Kunde führte diesen Schritt durch, woraufhin die Anmeldefunktion für alle Benutzer wiederhergestellt wurde.
Entwickler – Office-Suite
Problem: Ein Entwickler meldete, dass sein VBA-Makro in Excel langsam lief und viel Speicherplatz beanspruchte, wodurch Excel abstürzte. Das Makro lief zuvor ohne Probleme, aber nachdem neue Funktionen hinzugefügt und die Größe der zu verarbeitenden Daten erhöht worden war, war es nicht mehr stabil. Der Entwickler versuchte, den Code zu optimieren und die Datengröße zu reduzieren, aber das Problem blieb bestehen.
Lösung: Es wurde festgestellt, dass die langsame Leistung und der hohe Speicherverbrauch durch die ineffiziente Verwendung von Bereichsobjekten und die wiederholte Berechnung von Formeln verursacht wurden. Das Team empfahl, den Makrocode so umzugestalten, dass anstelle von Bereichsobjekten Arrays verwendet werden und die Formelberechnung nur einmal mit der Methode .Calculate ausgelöst wird. Der Entwickler nahm diese Änderungen am Makrocode vor, wodurch die Probleme mit der Leistung und Stabilität behoben wurden. Das Makro läuft nun effizient und verursacht keinen Absturz von Excel mehr.
