Samoth

Moin, Danke dir! Verschiedene Tenants... also... öhm... ja, vermutlich %-) Soweit ich sagen kann, bin ich ja im eigenen Firmen-Tenant unseres Unternehmens und er hat sich bei Teams mit der gleichen Mail-Adresse eingeloggt, die er auch für sein Office 365 Family nutzt. Ich denke damit liegt eine grundsätzliche Trennung vor. Wir schauen gerade, wie/ob wir die Telefonie-Option mal kostenlos testen können, dann hätten wir damit ja Gewissheit. MS bietet das an verschiedenen Stellen (bspw. bei MS Teams Essentials) an. Grüße Samoth

Danke dir! Ich blicke bei den leider Telefonie-Begrifflichkeiten nicht durch. Das was du geschickt hast, wäre dann doch aber das was ich gar nicht brauche, also Telefonie nach außen auf eine Telefonnummer, oder? Hier im Screenshot sieht man, dass ich einen Teams-"Audioanruf" durchführen könnte oder aber auch den Anruf auf eine Festnetznummer/Handynummer. Mir gehts um den markierten Punkt aus dem Screenshot, also den Audioanruf innerhalb von Teams. So soll es sein. Aber dieser Punkt ist bei dem Office 365 User ausgegraut (zweiter Screenshot).

Hallo mal wieder, ich wurde per Google-Recherche KI nicht fündig. Evtl. könnt ihr mir helfen. Ein Bekannter nutzt das Microsoft 365 Family Abo und dort ist Teams enthalten. Wir haben seinen MS-Account, unter dem auch das Abo läuft, genutzt um ihn bei Teams anzumelden. Das funktionierte und wir können per Teams chatten. Wenn ich eine Telko-Einladung verschicke, kann er vollständig teilnehmen. Was jedoch nicht funktioniert (egal ob vom Handy/PC aus): Anrufe über Teams. Damit meine ich nicht die Festnetztelefonie auf eine Festnetznummer. Wenn ich versuche, ihn aus dem Teams-Chat heraus mit dem Telefonhörer anzurufen ist das nicht möglich, das Hörersymbol ist grau. Auf seiner Seite verhält es sich ganz genauso aus. Ich nutze einen Teams-Account über die Firma und kann sonst überallhin telefonieren. Habt ihr eine Idee, was er freischalten/kaufen muss, um die normale Teams-Telefonie (wie gesagt, nicht zwingend auf das Festnetz) nutzen zu können? Viele Grüße + Danke Samoth

Hallo zusammen, jetzt hat sich das Thema etwas beruhigt. Daher wollte ich mich noch mit dem Ausgang melden. Danke euch für euren Support! HP hat ja alle Platten getauscht. Darauf haben wir ein neues RAID aufgebaut und dann einen Veeam Bare Metal Restore gefahren. Die Daten sind soweit OK - es wurde umfangreich (naja, so gut es geht) getestet und seit gut einer Woche sieht immer noch walles OK aus. Es laufen gerade die Plantungen den Server zu ersetzen. Viele Grüße Samoth

Hallo zusammen, heute mit etwas mehr Ruhe und Details: Ursache für die Probleme, ist laut HP, das alle 6 Platten (RAID5) im Server eine ordentliche Menge an Lesefehlern haben. Wie ich das zukünftig im Vorfeld mitbekomme, muss ich noch herausfinden. In der System Management Homepage des Servers steht es wohl nicht. Von HP werden nun alle Platten getauscht. Ich soll das RAID löschen, neu anlegen und einen Restore durchführen. Soweit zur Theorie. @testperson In der einen läuft der Terminal Server und in der anderen der Domain-Controller/Exchange. Ich habe nun über Nacht per SyncToy "einfache" Daten (Dokumente, Projekte,...) auf die NAS kopiert und das ging zumindest ohne Fehlermeldung durch. Über die direkte Anmeldung am Server habe ich von verschiedenen VMs noch in der Applikation Backups auf die NAS gemacht, bspw. Kaspersky Security Center, etc. Da ich ja aktuell mit Veeam/Altaro keine VM-Backups erstellen kann, da diese fehlschlagen, habe ich versucht per disk2vhd aus der jeweiligen VM eine vhdx zu erzeugen. Das bricht auch mit unterschiedlichen disk2vhd-Optionen mit einer Fehlermeldung ab. Aktuell läuft ein Restore der aktuellsten Veeam-Sicherung, die wir haben die jedoch mit der Warnung "One or more bad blocks were detected and skipped." beendet wurde. Ich will mal sehen, ob ich daraus die VHDX bekomme und diese im Hyper-V Manager als Server einhängen kann. Das wäre Bombe. Per Google bin ich dann noch über ein paar Seiten gestolpert, die sich mit VHDX-Reparatur beschäftigen. Das werde ich dann mal am Kaspersky-Server testen, der ist unkritisch. Weiterhin bin ich überfragt/erstaunt, weil die VMs anscheinend noch laufen, ein Kopieren der VHDX jedoch nicht möglich ist. Viele Grüße Samoth

Hallo zusammen, ich bin gerade etwas nervös - habt Nachsicht mit mir. An einem HP-Server wurde Anfang der Woche eine defekte HDD in einem RAID5 getauscht. Der Rebuild lief sauber durch und ich dachte das Thema wäre gegessen. Auf die fehlerhafte HDD kam ich im Übrigen, weil die beiden Datensicherungen mit Altaro/Veeam Fehler bei der Sicherung zeigten. Leider sehe ich im Eventlog immer noch: Logical drive 1 of array controller P440ar [Embedded] returned a fatal error during a read/write request from/to the volume. Logical block address 6751321, block count 8 and command 32 were taken from the failed logical I/O request. Array controller P440ar [Embedded] is also reporting that the last physical drive to report a fatal error condition (associated with this logical request), is located in bay 6 of box 6 connected to port 2I. Soweit ich das erkennen kann, handelt es sich beim genannten drive in bay 6 um die getauschte HDD. Diese Fehler haben auch zur Folge, dass die beiden Datensicherungen mit Altaro und Veeam entsprechende Fehler liefern in Form von "...vhdx kann nicht gelesen werden". Nun wollte die VMs im Hyper-V Manager exportieren - bricht ab. Auch das manuelle kopieren der VHDX-Dateien der beiden Server bricht wg. einem Lesefehler ab. Was aber möglich ist - zumindest bis vorhin: Die beiden VMs starten noch und man könnte sich anscheinend anmelden. Ich bin gerade etwas planlos, was ich nun machen soll. Aktuell lasse ich einen Test-Restore mit Veeam (letzte "grüne" Sicherung vom 19.01.) laufen und restore die VHDX-Datei des wichtigeren Servers auf eine NAS, um zu prüfen, um zumindest das noch möglich ist. Habt ihr gerade Ideen einen Rat? Was mich bspw. interessieren würde: Wieso kann ich die VMs noch starten, aber nicht die VHDX kopieren? Könnte ich die VHDX evtl. reparieren, um Sie dann noch zu kopieren? Viele Grüße und Danke erst mal Samoth

Gleich mal ein Sorry, weil ich nach so langer Zeit hier noch mal poste. Aber ich hatte diesen Tab angeheftet und so fiel er mir ins Auge. Und weil ich viel von diesem Forum halte und auch immer wieder konkrete Lösungen erhielt, möchte ich hier an dieser Stelle noch die Lösung für mein damaliges Problem posten. Ich vereinfache stark, denn der Weg dahin war nicht so einfach, aber: Das Windows war zu alt. Wir haben dann mit einer (damals ) aktuellen 2016er ISO eine Reparaturinstallation durchgeführt, um auf den aktuellen 2016er Stand zu kommen. Damit konnten im Nachgang auch alle Windows Updates eingespielt werden und die ursprüngliche Fehlermeldung war verschwunden.

Hi zusammen, schon wieder ich und ein Share-Thema Ich spreche gerade mit einem Kunden, der mir beschreibt: Immer wenn ich aus dem System heraus auf den Share zugreife klappt es beim ersten Versuch nicht. Wenn ich den Prozess dann direkt und ohne Änderungen erneut triggere, funktioniert es problemlos. Seine Annahme ist nun in etwa, dass das halt so ist und Shares inaktiv werden, wenn sie nicht genutzt werden. Und dagegen helfen dann Disconnect/Reconnect-Skripte. Wenn ich das nur mal mit meiner Logik bewerte, klingt das nicht schlüssig, oder? Es wäre doch fatal, wenn das der Standard wäre und die Lösung ist ein Skript. Ich kenne es zumindest aus unserer Infra und aus der vieler Kunden nicht so. Da läuft das einfach... bis in alle Ewigkeiten Wie seht ihr das? Und wenn wir schon dabei sind: In welche Richtung könnte ich den Kunden stupsen, um auf seiner Seite weitere Analysen zu veranlassen? Viele Grüße und Danke mal wieder Samoth

Hallo zusammen, es wird abenteuerlich und ja, das Topic hat "Drucker druckt nicht" Charakter, ich weiß. Aber ich schreibe mal runter, was mich aktuell plagt, evtl. habt ihr noch Ideen. Ich kann auch nicht gewährleisten, dass ich alles was wir bisher versucht haben, hier aufliste und nichts vergesse Grundsätzlich geht es darum, dass von einem Windows Server auf einen anderen Windows Server per UNC-Pfad zugegriffen werden soll. Soweit ich sagen kann ist das eigentlich wenig spektakulär. In dieser Konstellation wird nicht mit Domänen-Usern gearbeitet, sondern ausschließlich mit lokalen. Soweit ich weiß, muss der User, der auf den Share zugreifen will, auf beiden Systemen mit dem selben Passwort angelegt werden, um direkt zugreifen zu können, oder? Diese Voraussetzung ist zumindest erfüllt. Grundsätzlich funktioniert der Zugriff auf den Share nämlich schon - mit dem passenden User "t11adm". Ich greife von Server A mit dem User t11adm auf Server B per "\\server\trans" im Explorer zu und sehe dort die Daten. Nutze ich jedoch von Server A aus einen anderen lokalen User "servicet11" um auf \\server\trans zuzugreifen erhalte ich die Fehlermeldung "...cannot access... 0x80004005 Unspecified error". Sehr interessant finde ich jedoch auch, dass ich im Explorer bei der Eingabe von "\\server" [Enter] die Meldung erhalte: "Windows cannot access \\server ... Error Code 0x80070035 The network path was not found". Ich sehe also nicht mal die Übersicht der bereitgestellten Freigaben auf dem "server". Das finde ich irgendwie sehr merkwürdig. Mit dem t11adm funktioniert da aber alles. Ist das was ich beschreibe nachvollziehbar? %-) Was haben wir geprüft: - Firewalls aus - Ping geht - Kein AV installiert - Neue Freigabe erstellt - Soweit als möglich User-Berechtigungen geprüft - Restart der beiden Server durchgeführt - ... Hier gleich noch eine Ergänzung: Ich finde auf "server", also dort wo auch die Freigabe erstellt wurde, im Ereignisprotokoll folgende Meldung, die sich explizit auf den User "servicet11" bezieht: EventID: 4625 Failure Reason: The NetLogon component is not active Status: 0xC0000192 Sub Status: 0x0 Habt ihr noch Ideen? Update: Es ist ja nicht das erste Mal, dass ich hier poste, mir im Anschluss das Problem selbst, alleine und in Ruhe noch mal ansehe und dann eine Lösung finde, grml... Analyse/Lösung in Kürze: Ich habe über den Failure Reason von oben gesehen, dass der Dienst "NetLogon" nicht gestartet war. Den habe ich dann entsprechend gestartet und im Anschluss war direkt und ohne weiteres Zutun der Zugriff auf den Share mit dem "servicet11" möglich. Warum der Zugriff allerdings vorher schon mit dem "t11adm" möglich war, ist mir noch ein Rätsel. Dazu muss ich mir noch Gedanken machen. Aber viele Grüße erst mal!

Ja, ist fix installiert.

Hi dartzen, du liegst richtig mit einer Annahme Und ja, ich möchte mich auf das installierte TV-Hostmodul auf dem Server verbinden. Das hat einfach irgendwann nicht mehr funktioniert. Ich hab nichts drauf gegeben und lange Zeit nichts unternommen. Irgendwann war mal mehr Luft für die Analyse und das Ticket bei TV. Und da bin ich nun seit Monaten... Ich glaube auch nicht, das TV mich da korrekt informiert. Aber was will ich machen, wenn der Entwickler das doch so gesagt hat!!?!!??"!111 Leider ist das Deaktivieren des Mehrbenutzermodus wohl nicht mehr möglich - und das wohl schon sehr lange. Hier auch eine Erklärung aus 2021 von einem TV-Mitarbeiter: https://community.teamviewer.com/German/discussion/116334/teamviewer-host-15-mehrbenutzer-deaktivieren?tab=all Ich habe auch sicher gestellt, dass ich mich wirklich an die Server ID verbinde und nicht auf eine ID eines angemeldeten Users. Wenn ich den TV im Server öffne steht dort auch in einer Meldung "Sie können darum immer die Server-ID xxxxxx verwenden, um sich zu diesem Server zu verbinden." Grüße Samoth

Hi zusammen, Kurzversion: Was sehe ich im TM im Reiter "Sitzung" und was bedeutet "Console"? Ist die Aussage "Das Fehlen einer Konsolensitzung im Task-Manager bedeutet nicht, dass keine existiert." korrekt? Detailliert: ich brauche mal eure Hilfe. Ich habe seit einiger Zeit beim Hersteller eines Fernwartungstools einen Fall offen, weil ich mich nicht mehr ohne Weiteres direkt auf einen virtuellen Terminal Server (Hyper-V Umgebung) verbinden kann, auf dem das Tool fix installiert ist. Wir haben da schon div. Sachen durchgetestet, also unterschiedliche Tool-Versionen, Neuinstallation, Logs ausgewertet, etc. Letztlich stecken wir gerade fest. Der Hersteller hat hinsichtlich der Ursache die folgende Aussage getätigt: "Im Task-Manager sehen wir, dass keine Konsolensitzung eingeloggt ist. Und nur RDP-Sitzungen. Unsere Vermutung, dass es gar keine Konsolensitzung gibt, ist also nach wie vor gültig. Die einzige Lösung ist aus unserer Sicht daher, dass Sie ihr Setup so anpassen, dass eine Konsolensitzung verfügbar ist. Eine Lösung für das Problem können wir bedauerlicherweise nicht anbieten." Ich konnte gestern einen Workaround schaffen, der es mir möglich macht wieder problemlos und wie gewohnt direkte Sitzungen zu öffnen: Ich bin in den Hyper-V Manager, habe dort eine Verbindung zum Server aufgebaut und mich angemeldet. Dann war im Task Manager auch eine "admin" Sitzung deklariert als "Console" zu sehen. Ab dann war die Verbindung zum Server wieder dauerhaft möglich. Ich habe die Sitzung abgemeldet(!) und bin mit einem normalen Terminal User auf den Server: Im Task Manager war keine "admin" Session und auch keine einzige Sitzung "Console" zu sehen - wie erwartet. Die Verbindung auf den Server per Fernwartungstool ist aber weiterhin möglich! Das habe ich dem Hersteller geschickt und damit argumentiert, dass eine frisch gestartete VM auch direkt und ohne jegliches Zutun über das Remote-Tool erreichbar ist. Als Antwort erhielt ich: "Das Fehlen einer Konsolensitzung im Task-Manager bedeutet nicht, dass keine existiert. Es zeigt lediglich an, dass keine Sitzung "eingeloggt" ist. Für TeamViewer ist es nur relevant, ob eine Sitzung aktiv ist. Auch eine Sitzung mit einem Login-Fenster reicht aus und wird nicht im Task-Manager angezeigt." Macht das für euch alles Sinn? Ich dachte eigentlich, dass eine Konsolensitzung erst entsteht, wenn sich jemand per, naja, Konsole (Hyper-V Manager) oder direkt per Maus/Tastatur/Monitor am Server anmeldet. Für mich scheint es so, als ob wir uns hier im Kreis drehen. Mein Bauchgefühl sagt mir, dass die da keinen weiteren Aufwand reinstecken wollen. Grüße Samoth

Hab einfach mal den Titel von Amazon kopiert: HP (15,6 Zoll FHD Notebook (Intel Core i3 1215U, 6 Kerne, 4.40 GHz, 16 GB DDR4, 512 GB SSD, Intel UHD, HDMI, Webcam, Bluetooth, USB-C + USB 3.0, WLAN, Windows 11 Prof. 64 Bit) Laptop - 7681

Guten Morgen und ein Sammel-Danke hier in die Runde! Das neue Notebook ist bestellt... ich freue mich auf den After-Care

Guten Morgen OK... also dann sollte-könnte-müsste für ich für mein Mini-Setup (vermutlich ein FHD/WQHD-Monitor, Maus, Tastatur) auf keine Probleme stoßen. Soweit ich es verstanden habe, ist das nur eine Erweiterung, um nicht immer am kleinen Notebook hocken zu müssen. Danke euch!