Jump to content

vonAbisZ

Members
  • Gesamte Inhalte

    57
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von vonAbisZ

  1. ********************** PS>CommandInvocation(Out-String): "Out-String" >> ParameterBinding(Out-String): Name="InputObject"; Wert="Postfach nicht verfügbar. Die Serverantwort war: 5.7.60 SMTP; Client does not have permissions to send as this sender" Send-Mailmessage : Postfach nicht verfügbar. Die Serverantwort war: 5.7.60 SMTP; Client does not have permissions to send as this sender In C:\Ordner\Skripts\Passwort-Ablauf-Mail.ps1:96 Zeichen:1 + Send-Mailmessage -smtpServer $smtpServer -from $from -to $emailaddres ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (System.Net.Mail.SmtpClient:SmtpClient) [Send-MailMessage], SmtpException + FullyQualifiedErrorId : SmtpException,Microsoft.PowerShell.Commands.SendMailMessage Send-Mailmessage : Postfach nicht verfügbar. Die Serverantwort war: 5.7.60 SMTP; Client does not have permissions to send as this sender In C:\Ordner\Skripts\Passwort-Ablauf-Mail.ps1:96 Zeichen:1 + Send-Mailmessage -smtpServer $smtpServer -from $from -to $emailaddres ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (System.Net.Mail.SmtpClient:SmtpClient) [Send-MailMessage], SmtpException + FullyQualifiedErrorId : SmtpException,Microsoft.PowerShell.Commands.SendMailMessage Send-Mailmessage : Postfach nicht verfügbar. Die Serverantwort war: 5.7.60 SMTP; Client does not have permissions to send as this sender In C:\Ordner\Skripts\Passwort-Ablauf-Mail.ps1:96 Zeichen:1 + Send-Mailmessage -smtpServer $smtpServer -from $from -to $emailaddres ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (System.Net.Mail.SmtpClient:SmtpClient) [Send-Mai lMessage], SmtpException + FullyQualifiedErrorId : SmtpException,Microsoft.PowerShell.Commands.SendMailMessage ********************** Weise ich dem oben genannten AD User SMTP@unsereFirma.ch die Berechtigung "Senden als" zu, so müsste man doch nun annehmen, dass der Mailversand der Aufgabenplanung auf dem Exchange Server, welche eben mit dem User Domain\smtp ausgeführt wird (und mit höchsten Privilegien ist auch angekreuzt), funktioniert? Die PowerShell Überwachung, welche ich zu Analyse Zwecken aktiviert habe, teilt mir nach wie vor die gleiche Fehlermeldung mit wie oben im LOG zu sehen: "Die Serverantwort war: 5.7.60 SMTP; Client does not have permissions to send as this sender" Send-Mailmessage : Postfach nicht verfügbar. Die Serverantwort war: 5.7.60 SMTP; Client does not have permissions to send as this sender" Weitere Infos zur Aufgabenplanung bzw. zum Mailversand - Das Info Mail, welches an die User*innen versendet werden soll mit der Erinnerung, dass Ihr AD Passwort in xy Tagen abläuft, verwende als Absender Mailadresse Support@unsereFirma.ch Und: Dieses Postfach existiert und funktioniert. Auf diesem erhalten wir unsere Support Fälle von unseren User*innen geschildert. - In der Aufgabenplanung auf dem Exchange habe ich als User den AD User SMTP verwendet, weil dieser bereits existiert hat in unserem AD und für ähnliche Szenarios (Drucker Meldungen Versand etc.) schon verwendet wird.
  2. Vielen Dank tesso. Werde mir die beiden Links anschauen. NEWS folgen ;)
  3. Hi all Beim Starten von MS Edge erscheint eine Willkommensmeldung mit blauem Knopf: "Einrichtung abschliessen". Frage: Lassen sich diese Fragen per GPO automatisieren? Die User nerven sich, da Sie immer diese Willkommensschritte von Microsoft Edge durchklicken müssen Und: am Schluss glaube ich sogar noch eine Microsoft Webseite geöffnet wird, mit der Frage, was man mit den Favoriten machen will usw. Übrigens: Beim Punkt (Fenster): Favoriten und mehr aus allen Geräten anzeigen. Wenn man NICHT auf den Knopf "zum Synchronisieren von Daten anmelden" klickt, sondern auf "Ohne Anmeldung fortfahren, dann erscheint eine Fehlermeldung (ein kleines Fenster popp auf) und dessen Titel lautet: cookie_exporter.exe - erfolgreich. In der Mitte des kleinen Pop-Up erscheint die Fehlermeldung: Unknown Hard Error Wichtige Bemerkung Dies betrifft z.B. die Homeoffice Umgebung. Da werden die virtuellen VMs mit Windows 10 immer wieder neu erstellt, sprich die servergespeicherten Profile bzw. das lokal erstellte, zwischengespeicherte Serverprofil auf den virtuellen Maschinen ist dann jeweils wieder weg (wenn sich ein Benutzer nach getaner Arbeit von dieser abmeldet und z.B. am nächsten Tag wieder an der VMware View Umgebung einloggt, da er dann wieder eine neue, aufgesetzte, Windows 10 Maschine aus dem Desktop Pool erhält).
  4. NorbertFe Also ich mache nichts kompliziert. Ich hinterfrage lediglich das Dokument von Microsoft mit der Support Matrix. Nun, jetzt nach einigem hin und her mit euch so netten und hilfsbereiten Usern weiss ich in der Zwischenzeit etwas mehr über die Problematik, somit finde ich das sehr positiv. Wie bei der Eröffnung des Posts erwähnt: Gemäss Exchange Server supportability matrix gäbe es Abhängigkeiten zwischen den CUs und eines Exchange Servers. Weil ich dann im Server Manager die aktivierte Version 4.6 mir angezeigt wurde und ich in der Systemsteuerung wie am Anfang des Posts erwähnt, auch "nur alte" .NET Framework Versionen fand, war mir halt nicht klar, warum und wesshalb bei der Installation von .NET Framework 4.8 schon die Meldung kam, es sei schon installiert (sinngemässe Übersetzung). Genau dies war der Grund, warum ich diesen Post hier eröffnet habe. Hätte ich die Antwort schon gekannt hätte ich auch nicht Zeit investiert, um diesen Post hier zu eröffnen. NorbertFe: Zur Erinnerung, deine vorgängige Antwort war Und meine Antwort kannst du sonst selber oben nochmals nachlesen. Auf jeden Fall kam dann die sehr nette Frage von Dir, was mein Problem ist? Nun, Du antwortest mir, ich soll im Update Verlauf nachschauen. Zur Erinnerung, ich fand weder in der Systemsteuerung noch im ServerManager die bereits, anscheinend aktuelle, installierte .NET Framework Version 4.8, welche anscheinend durch die Installation von CU18 installiert wurde, einfach NICHT. Lieber NorbertFe, auch dank deinem gut gemeintem Tipp NICHT (ich soll doch im Update Verlauf nachschauen). Wenn ich deinem Tipp folge und nichts finde, das hier auch so als Rückmeldung entsprechend platziere und wohlgemerkt, in einem netten Ton, dann erwarte ich auch eine entsprechende Stellungnahme und sicher nicht ein Satz wie: Was ist denn dein Problem? Eine solche Art von Kommunikation finde ich nicht passend und gefällt mir nicht. So, gut, haben wir darüber gesprochen super, gehe ich gleich nachlesen, kam noch nicht dazu. Bin so sehr damit beschäftigt, mich hier zu rechtfertigen, dass das eigentliche Thema "fas" auf der Strecke bleibt.¨¨ Super, vielen Dank auch Dir für diesen hilfreichen Post. Das wegen dem ServerManager, diesen Hinweis kannte ich bis dato nicht und finde ich noch spannend. Wunderbar: vielen Dank NorbertFe, das wusste ich so nicht. Denke, nach dieser Stellungnahme hier ist etwas klarer, woher oder warum meine Reaktion plötzlich so ausgefallen ist. Ich habe das Wort schwachsinnig in einen Zusammenhang gebracht, welcher von der Wortwahl wohl nicht passend war. Dies ist mir nun klarer, da ich die Hintergründe dieser Support Matrix für Exchange kenne. Ihr seht, ich versuche auch, an mir selber zu arbeiten und positive Kritik entsprechend zu werten. Das sollte aber nicht nur ich, sondern generell jede und jeder von uns, den nur positive Kritik bringt einem weiter - so finde ich Hey Jungs, Ich wünsche euch allen einen guten Wochenstart und nicht zu viel Stress Daumen hoch
  5. Danke für die Inputs. Habe das Thema aufgegriffen, weil es doch einige Artikel gibt, welche den Finger hochheben und uns Lesern mitteilen wollen: Hey, wenn Du Exchange installiert, dass pass gut auf, dass Du auch die passende .NET Framework installiert hast. Gemäss dem am Anfang von mir eröffneten Artikel steht: Gemäss Exchange Server supportability matrix, welche .NET Framework Version mit welcher CU Version installiert sei. Wenn es Instabilitäten mit Exchange geben könnte, dann wäre wohl am ehesten diese Abhängigkeit zu prüfen?! Nun frage ich mich natürlich schon, warum und wesshalb Microsoft eine solche Support Matrix erstellt, wenn bei der Installation von Exchange sowieso die richtige .NET Framework installiert wird, welche man obendrauf nicht mal nachkontrollieren kann? Also ich pers. muss dies nicht nachkontrollieren müssen, denn wenn .NET Framework sowieso mit installiert wird, denn das ist in etwa das gleiche, wie wenn Microsoft eine Support Matrix veröffentlichen würde, in welcher irgendwo steht: keine Ahnung, dass die installierte Postfachserverrolle zwingend Version X sein muss, wenn man z.B. für Exchange 2016 CU18 installiert hat? Versteht Ihr, was ich meine? eine solche Support Matrix wäre genau so schwachsinnig, um es gleich mal au den Punkt zu bringen - die Komponente Postfachserverrolle wird sowieso mit installiert, also warum noch die Version dabei prüfen? So, von mir aus können wir demnach das Thema hier beenden, es nervt anscheinend wohl div. Exchange Spezialisten. Nur so zur Erinnerung: Ich habe die Exchange Support Matrix sicher NICHT erstellt, kannst dich also über denen Sinn oder Unsinn direkt an Microsoft wenden
  6. Habe unter dem Updateverlauf nachgeschaut (Programme und Features, installierte Updates) und fand NICHTS in Bezug .NET Framework. Dann habe ich oben rechts im Suchfenster nach .NET gesucht, nichts gefunden, dann habe ich die letzte Spalte (Programme und Features, installierte Updates) "installiert am" so sortiert, dass die neusten, zuletzt installierten Updates erscheinen Und: Da heute das CU18 installiert habe, hätte ja da, wenn überhaupt, unter dem heutigen Datum was auftauchen sollen, kam aber nichts?
  7. Hi Exchange Spezis Gemäss Exchange Server supportability matrix wird für Exchange 2016 CU18 (das aktuelle, letzte neue CU) .NET Framework 4.6 NICHT mehr supportet. Bei Exchange 2016 CU18 ist nur noch .NET Framework 4.8 supportet. Öffne ich den ServerManager und prüfe die installierten Features, so ist 4.6 angekreuzt inkl. ALLER Unterpunkte. Wie update ich nun .NET Framework korrekt auf .NET Framework, dass auch mein ServerManager das mitbekommt? Habe einen Versuch gestartet und die Offline Version .NET Framework 4.8 heruntergeladen und gestartet: Es erschien die Meldung, es sei schon eine neuere Version installiert? what? Systemsteuerung, installierte Programme zeigte mir keine neure Version als .NET Framework 4.6, im Gegenteil: Alte 4.5.1 bzw. 4.5.2 Multi Targeting Packs werden mir angezeigt. Greez vonAbisZ
  8. Danke für den Tipp. Was ich mich aber frage ist, warum auf dem Fileserver Ordner vom AppData\Local vorhanden sind, denn AppData\Local, AppData\LocalLow sowie Unterordner z.B. Verlauf, Temp oder temp. i-Net Dateien sind default mässig aus dem servergespeicherten Profil ausgeschlossen. Da frage ich mich, wie das möglich ist, dass ich bei mehreren Stichproben an folgendem Pfad Benutzername\AppData\Local\Microsoft\Edge\User Data\Default\Cache bzw. \Code Cache wie oben im Post erwähnt, so viele GB Edge Chromium Cache Dateien finde? Kurz: Die dürften doch gar nicht auf dem Server liegen? Ausser, soweit ich informiert bin, es wäre die Ordnerumleitung irgendwo aktiv Und: der Ordner AppData wäre darin enthalten. Nur, wir haben zig GPOs, muss ich nun jede einzelne GPO von Hand überprüfen, ob diese Einstellung dort aktiv ist, bei gefühlten hunderten GPOs?
  9. Moin zusammen Info: wir haben Roaming Profiles im Einsatz. Auf unserem Fileserver stelle ich fest, dass für sehr viele servergespeicherte Profile in folgendem Pfad sich GB weise Daten ansammeln Benutzername\AppData\Local\Microsoft\Edge\User Data\Default\Cache bzw. \Code Cache Und: Habe "auf die Schnelle" noch keinen schlauen MS Artikel gefunden, wie man diese Cache Dateien des MS Browsers Edge Chromium effizient löschen darf/ kann? (Skript, GPO usw.) Kennt Jemand diese Problematik? Wünsche ein gutes Mittagessen (ist ja schon wieder Mittag, meega) vonAbisZ
  10. Guten Morgen zusammen Problem Manche Mitarbeiterinnen und Mitarbeiter haben sich an unsere ICT-Abteilung gewendet und folgendes geschildert: Das Laden von freigegebenen Kalendern dauert sehr lange, unabhängig von der Tageszeit. Definition sehr lange aus Sicht des Users: mehrere Sekunden,. Es sei auch schon länger als eine halbe Minute gegangen, bis sich ein freigegebener Kalender geöffnet habe (Sanduhr dreht und dreht). Zuerst zu meinem pers. Test. Arbeite zurzeit im Homeoffice und bin auf meiner physikalischen Workstation per remote eingeloggt. Egal, welches freigegeben Postfach bzw. Kalender ich öffne, im Durchschnitt dauert es vielleicht eine halbe Sekunde, bis mir der Inhalt angezeigt wird, aus meiner Sicht somit schnell genug Kurz: Ich fand bei meinem Test, wo ich versucht habe, das Problem einer Benutzerin nachzustellen, von meinem Outlook kein solches Verhalten vor. Kurz: ich hatte sicher ca. 10 verschiedene, freigegebene Kalender spontan geöffnet, welche ich noch nie in der Vergangenheit geöffnet hatte und muss sagen, der Zugriff war sehr schnell (für mein Befinden). Grobe Details zu unserer Firma und der Konfiguration - Firma = ca. 130 Mitarbeitende - Windows 10 PCs mit Office 2016 Outlook Clients - 1x Exchange Server 2016 (läuft als VM aus einer ESX Cluster Umgebung) - Arbeiten ist im Geschäft, vor Ort möglich oder via Homeoffice - servergespeicherte Profile sind im Einsatz - Ordnerumleitung ist ebenfalls via GPO konfiguriert Wie Problem eingrenzen? Aus meiner Sicht muss man das Problem entweder von C nach E oder von E nach C lösen (C = Computer, E = Exchange). Habe die Problem Analyse beim C, also beim Computer gestartet und warte da zum Teil noch auf Antworte der Benutzer. Versuche gerade folgende Punkte in Erfahrung zu bringen: Lokal: Liegt es am PC und oder am lokalen Outlook? - Problem auch auf anderen, physikalischen PCs vorhanden? - Problem auch in der Homeoffice Umgebung vorhanden - Wird das Problem gelöst, wenn lokale .OST Datei gelöscht wird? - Ist evtl. der lokal installierte Kaspersky Antiviren Scanner "schuld" oder dessen Add-In im jeweils integrierten Outlook Profil jedes Benutzers? Exchange seitige Analyse - wie viele Ordner und Unterordner haben die betroffenen Personen unterhalb vom Posteingang (Outlook Ordnerstruktur vielleicht sehr gross?) - Grösse des Mail Postfachs des Benutzers? - Auslastung des Exchange Servers (Prozessor, RAM, I/O Auslastung HDs bzw. der virtuellen HDs usw. ?) Für mich ist das Problem etwas "speziell", da ich noch keine "Gründe" für das Verhalten verantwortlich machen konnte, welche bei manchen Benutzern leider auftreten. Habe ich vom Vorgehen her, wie diesem komischen "Phänomen" auf den Grund zu kommen, wichtige Aspekte vergessen und oder hat Jemand noch gute Tipps, wie oder was ich noch prüfen könnte? Nette Grüsse Andrew
  11. Wer sagt, dass wir eine Software Verteilung haben? Es wäre sinnvoll, wenn Du einen Lösungsvorschlag anbietest, der für Jedermann (Frau) umsetzbar ist
  12. Hi all Wir haben bei uns in der Firma bestimmte Einschränkungen (Security) in Bezug PowerShell. Möchte ich z.B. das PS Modul NTFSSecurity installieren, so wäre ja der Befehl Install-Module ntfssecurity. Danach und soweit ist noch alles in Ordnung, erscheint der Hinweis: "Der NuGet-Anbieter ist erforderlich, um den Vorgang fortzusetzen". Danach erscheint die Fehlermeldung: WARNUNG: Es kann kein Download von URI "https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409" nach "" durchgeführt werden. WARNUNG: Die Liste der verfügbaren Anbieter kann nicht heruntergeladen werden. Überprüfen Sie Ihre Internetverbindung. Das heisst, man hat also anscheinend bei uns Security technisch unterdrückt, dass PowerShell von Online Daten ziehen kann. Nun, was gibt es für Alternativen? Soweit ich im Bilde bin, kann man PS Module z.B. auch manuell downloaden und dann z.B. in einem manuell angelegten Repository (Share Freigabe z.B. auf Fileserver) ablegen. In einem nächsten Schritt würde man dann bei der Installation des Modules auf dieses Repository verweisen, welches wohl zuerst auch noch angelegt und PowerShell bekannt gemacht werden müsste?! Nun, möchte ein PS Repository mit dem Befehl Register-PSRepository anlegen. kommt natürlich, wie könnte es anders sein, zuerst wieder die gleiche Fehlermeldung (Internet Download geht nicht), dann erscheint noch, der Paketanbieter "NuGet" wurde nicht gefunden. .... Get-PackageProvider -ListAvailable Führe ich Get-PackageProvider -ListAvailable aus, erscheint: Name Version DynamicOptions ---- ------- -------------- msi 3.0.0.0 AdditionalArguments msu 3.0.0.0 PowerShellGet 1.0.0.1 PackageManagementProvider, Type, Scope, AllowClobber, SkipPublisherCheck, InstallUpdate, NoPathUpdate, Filter, T... Programs 3.0.0.0 IncludeWindowsInstaller, IncludeSystemComponent Offensichtlich ist dieser NuGet Package-Provider tatsächlich nicht installiert. Nun, wir haben ha nun eine "Schwanz beisser Situation" *lach* (PS kann noch immer nicht Online Daten abrufen, an dem hat sich ja in der Zwischenzeit noch nichts geändert). Frage betreffend Nuget PackageProvider Finde irgendwie via google keinen schlauen Download und eine Anleitung, wie das Vorgehen ist, um NuGet manuell installieren zu können im Sinne von: Internet Download, entpacken, welche Files entpacken und ausführen, wohin installieren usw.
  13. Vielen Dank lieber ITKobold. Vielleicht brauche ich diesen Befehl noch, wer weiss. Aber schon mal Gut zu wissen, wie man den richtig "programmiert". Ich suchte wohl viel zu weit, als ich mir überlegt habe, wie ich so einen Befehl gestalten könnte ;)
  14. Ok, das wäre sicher noch ein Test wert. Werde das der Benutzerin mitteilen und mal schauen, was dabei herauskommt. NEWS folgen .. Aber wohl erst nächste Woche Habe von der Mitarbeiterin schon NEWS erhalten. Sie meinte, Sie komme in das Büro, starte die Büchse und gehe dann in der Zwischenzeit alle rundum begrüssen, wenn Sie dann wieder in Ihrem Büro sei, seien sicher rund 5 min vorbei Und: Trotzdem sei es ab und zu so, dass Sie eben nach dem Einloggen rote Laufwerke im Dateimanager antreffe...
  15. Danke für die Hinweise. Evtl. liegt das Problem an folgender Sache: Gemäss der soeben geführten Rücksprache mit der betroffenen Benutzerin meinte Sie: - Die Laufwerke wären ab und zu nach dem Anmelden an der Domäne rot, jedoch meinte Sie auf meine Frage hin, ob Sie denn Zugriff auf deren Inhalt hätte, ja, meistens. - Nur ein Laufwerk werde aber öfters GAR NICHT verbunden. Der Unterschied, wie dieses LW gemappt ist, unterscheidet sich vom Mapping Mechanismus der anderen. Denn dieses LW wird via AD Benutzerobjekt (rechte Maustaste auf das Benutzerkonto im AD, dann Eigenschaften) im Reiter (Register) Profil gemappt (Punkt: Basisordner). Nun habe ich diese Einstellung deaktiviert und habe nun im GPO Objekt, welches die anderen LW mappt, dieses Laufwerk auch dort konfiguriert (Benutzerkonfiguration\Einstellungen\Windows Einstellungen\Laufwerkzuordnungen (Aktion = Aktualisieren) und ab Morgen weiss ich mehr, ob in Zukunft das eine LW nun immer gemappt wird oder doch ab und zu nicht? Meiner Ansicht nach dürfte nun höchstes noch der Fall eintreten wenn überhaupt, dass ALLE Laufwerke nach der erfolgreichen Benutzeranmeldung im Dateiexplorer rote Laufwerke antrifft, jedoch sollten dann hoffentlich, meiner Ansicht nach - diese bei einen Klick darauf den Inhalt anzeigen.
  16. Für diese eine Datei wäre das von der Grösse her nicht unbedingt so problematisch, da wir den die Datei .mp4 von über 100 MB auf ca. 25 MB verkleinern konnten. Jedoch müssen wir uns überlegen, wie wir das in Zukunft lösen wollen, denn wir sind zurzeit an der Ablösung von Sharepoint 2010 auf Sharepoint 2019. Dort wird es einfachere Wege geben, um Dateien in das Sharepoint Portal zu uploaden, jedoch muss man sich dann natürlich auch automatisch die Frage stellen, wie wir die Dateispeicherablage für Sharepoint gestalten. Denn wenn dann vermehrt Audio/ Film Dateien auf die Sharepoint Ablage hochgeladen werden, ist natürlich die Speicherfrage/ der Speicherplatz wichtiger den je
  17. Die Laufwerke werden via GPO verbunden: Benutzerkonfiguration\Einstellungen\Windows Einstellungen\Laufwerkzuordnungen (Aktion = Aktualisieren) Und: Dieses Problem hat nur eine Maschine von über 130 insgesamt. Windows PC wurde auch schon ersetzt, BN Profil auch schon neu gemacht, ja, dies noch ergänzend und darum wieder zurück zu meiner ursprünglichen Frage
  18. HI all Gibt es in den GPOs eine Einstellung, mit welcher ich folgendes Problem lösen kann: Nach der Anmeldung von Computer X (Windows 10, Ver. 1803 => Update der Version folgt bald) an der Domäne sind ab und zu ALLE gemappten Laufwerke rot! Die Einstellung "Auf das Netzwerk warten" ist bereits schon eingestellt. Ich suche z.B. nach einer Einstellung in der GPO, welche z.B. nach dem Anmelden eines Windows Clients an der Domäne sofort damit beginnt, periodisch, vielleicht jede Sekunde oder so zu prüfen, ob die Laufwerke auch effektiv verbunden sind und wenn nicht (sprich, Sie werden rot angezeigt, beim Klick auf LW kein Zugriff), dann konstant versucht wird, die rot markierten Laufwerke wieder zu verbinden?
  19. Hi all Wie gestalte ich am einfachsten einen Skript (z.B. DOS), welcher ein Laufwerk X: verbindet, wenn der DOS Befehl DIR X: keine Verzeichnisse anzeigt? freue mich auf zahlreiche Vorschläge *smile* Ergänzung: Die Laufwerke werden bereits via GPOs verbunden, jedoch kommt es ab und zu vor, dass an einem PC mit Win10, Version 1803, warum auch immer, ab und zu nach der Anmeldung die Laufwerke einfach rot erscheinen und darum könnte vielleicht dieser Lösungsweg das Problem lösen bzw. dafür sorgen, dass die Benutzerin nicht immer Ihre Windows 10 Büchse kurz nach dem Starten am Morgen früh, ein zweites Mal herunterfahren bzw. neu starten muss, nur damit Sie dann endlich Zugriff auf ALLE gemappten Laufwerke hat.
  20. Spannend und danke für diese ersten Erkenntnisse. Das Problem war ja bei uns, dass wenn Jemand in der Firma via Intranet Webseite (zurzeit noch Sharepoint 2010) eine NEWS Seite öffnet und in dieser ist ein Link hinterlegt, dass dann durch klick auf den Link KEIN Edge Chromium sich geöffnet und die Datei abgespielt hat. Die Ursache liegt wohl daran, wie StefanWe schon erklärt hat https://support.google.com/gsa/answer/2664790?hl=en Nun haben wir aber in der Zwischenzeit noch die Möglichkeit gefunden, dass wir im Intranet nicht einen Link verwenden, weil da Sharepoint immer die Adresse in file: /// abändert, sondern dass wir im NEWS Beitrag, welchen wir dann im Intranet veröffentlichen, halt wie einem Mail, die Datei als Anhang uploaden und die betreffende Person, welche den NEWS Beitrag liest, dann halt die Datei im NEWS Beitrag herunterladen und öffnen kann, so ist das
  21. Hi all Problem: Edge Chromium öffnet eine Intranet URL (file:///x:\share\datei.mp4) nicht Erwarten würde ich, dass der Microsoft Edge sich öffnet und das Video abspielen würde (es ist eine PPT Präsentation, umgewandelt in .mp4 File) Jemand eine Idee, warum dies nicht funktioniert? P.S. Gebe ich den Pfad zum Share (auf Fileserver) direkt im Microsoft Edge Chromium ein, im Sinne von: X:\Sharename\Dateiname.mp4 - so spielt der Edge Chromium anstandslos das .mp4 File ab, interessant - so finde ich... Bin gespannt, was für Antworten kommen ;)
  22. @NorbertFe: Du wolltest die Ausgabe vom get-calendarprocessing dein-raum | fl in Erfahrung bringen. Die ist weiter oben (scrolle doch mal noch oben). Was sagt Dir die Ausgabe?
  23. Du hast vorhin erklärt, Du wüsstest keinen sinnvollen Grund, warum man für Ressourcenpostfächer das Feld Beschreibung nutzen soll. Nun, habe Dir soeben erklärt, warum und wieso wir die Beschreibungsfelder der Ressourcenpostfächer nutzen. Aus irgend einem Grund hat Microsoft für jedes Postfach ein Feld programmiert, welches erlaubt, dieses mit Informationen abzufüllen. Ob wir ein organisatorisches Problem haben oder nicht, ist eine Ansichtssache und nicht Teil dieser Diskussion. Erwarte hier konstruktive Vorschläge, sonst wäre ich nicht auf diesem Board mit meinem Anliegen *buuurner*. Und, hast Du mir auch einen konstruktiven Vorschlag technischer Natur, für unser Problem, was bis vor noch nicht langer Zeit keines wahr - so am Rande erwähnt Und: Auf die Frage, was haben wir den in der Zwischenzeit geändert kann ich bereits vorgreifen: Windows Updates wie jeden 2ten Dienstag auf dem Servern installiert, auf dem Exchange seit dem letzten aktuellen CU keine technische Änderungen vorgenommen!
×
×
  • Neu erstellen...