Jump to content

thor

Members
  • Gesamte Inhalte

    232
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von thor

  1. Hallo Jan.
    Danke für die Rückmeldung.

    vor einer Stunde schrieb testperson:

    Hi,

     

    das kommt mir bekannt vor. Kannst du mal prüfen, ob es folgende Keys gibt und diese (exportieren und dann) löschen:

     

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\msedge.exe
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\msedgewebview2.exe

     

    Gruß

    Jan

     

    Ich hab mich durch die Registry gewühlt, aber die beiden genannten Keys sind nicht vorhanden.

    Gruß 

    thor

     

     

     

  2. Hallo ins Forum.

    Meine Frage bezieht sich auf die Problematik, das der Microsoft EDGE sich bei jedem Benutzer soviel CPU zieht, das unsere Terminal-Server stetig ausgelastet sind.

    Wir nutzen auf einer virtuellen Farm  Windows Terminal Server mit Windows Server 2019 - 32 GB RAM - 6 CPU (vorher 4 CPUs)

    Nach der Anmeldung eines Users mit RDP startet gewollt der Microsoft EDGE (Version 124.0.2478.51 (Offizielles Build) (64-Bit)) und stellt einfach unsere Intranetseite von einem Sharepoint Server her.

    Nach einiger Zeit (wenn der User andere Programme nutzt) zieht sich ein Prozess vom Edge auf -12 %  bis 20 % pro User - bis halt der ganze Terminal Server auf 100% CPU ausgelastet ist.

    Es ist im Edge auch keine weitere Seite (Tab) angeklickt.

     

    Wir haben via GPO den EDGE in den Effizienzmodus gestellt, aber dies half nicht, wie auch das Upgrade von 4 auf 6 CPUs.

    Wenn ich mich bei dem User aufschalte und Edge einfach nur anklicke geht die CPU Nutzung wieder fast auf Null zurück.

     

    Hat jemand ähnliche Erfahrungen damit gemacht oder vlt. auch einen weiteren Lösungsvorschlag parat. Wäre sehr dankbar dafür.

     

    Beste Grüße ins Forum

    thor  

       

     

  3. Hallo ins Forum.

    Ich möchte folgende Anfrage einbringen und hoffe, jemand kann mir eine Lösungsmöglichkeit anbieten.

    Wenn dieses Thema nicht in diesen Forumsbereich gehört, so bitte ich (vor allem die Forum-Admins) um Verständnis und das Verschieben in das richtige Forum.

     

    Hier die Problematik:

    Seit einiger Zeit haben wir aus unsere Domäne und den Tochtergesellschaften die Problematik, das keinerlei Mails mehr an die verschiedenen Microsoft Domänen geendet werden können. Darunter outlook.com (wie in meinem Beispiel unten beigefügt) aber auch hotmail.de und weitere Domänen unter dem Schirm von Microsoft.

    In der Fehlermeldung wird unser Exchange Server, der mit einer eigenen externen IP versehen ist geblockt.
    Zunächst war die Meldung, das sogar eher das Netzwerk unseres Providers (Vodafone) geblockt wird, aber im Gespräch mit denen gab es keinerlei Info, das auch andere Kunden dieses Problem haben.
     

    Zitat

     

    Ihre Nachricht wurde aufgrund eines Berechtigungs- oder Sicherheitsproblems nicht zugestellt. Sie wurde möglicherweise von einem Moderator zurückgewiesen, über die Adresse können nur E-Mails von bestimmten Absendern empfangen werden, oder eine weitere Einschränkung verhindert die Zustellung der Nachricht.

    BN1NAM02FT028.mail.protection.outlook.com hat diesen Fehler ausgegeben:
    Unfortunately, messages from [externe IP des Exchange] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to
    http://mail.live.com/mail/troubleshooting.aspx#errors
    . [BN1NAM02FT028.eop-nam02.prod.protection.outlook.com

     

     

    Bei anfragen über das reguläre Supportformular Neue Supportanfrage (microsoft.com) bekomme ich nur die üblichen Standardantwort:

    Zitat

     

    We have investigated your deliverability issue regarding IP (externe IP des Exchange). At the current time, these IPs are not eligible for mitigation.

     

    We are concerned with a pattern of irregular mail traffic originating from your IPs. While this could be benign, sudden changes in email sending volume can be the result of a server or network compromise or the result of compromised user accounts.

     

    It takes time to improve IP reputation and careful vigilance of your email systems which includes monitoring the information you can receive from server logs and programs such as JMRP and/or SNDS to help identify potential issues, such as compromised servers or accounts, spikes in sending overall volume etc. There is no silver bullet, unfortunately, to improve or maintain IP reputation.

     

     

    Dann hab ich versucht unsere IP über das Formular https://sender.office.com/ Delist IP - Delist IP (office.com) wieder zu entsperren. 

    Nach den ersten Angaben konnte ich die IP auswählen und auf delisten klicken. Das wurde aber dann verweigert mit der Möglichkeit das nun zur Eskalation weiterzureichen.

    Somit hab ich dies angeklickt. Seitdem ist Seitens Microsoft nix weiter passiert. DAs war am 22.11.

     

    Gibts Eurerseits ein Anlaufpunkt oder Lösungsansatz, den wir hier noch anwenden könnten.

    Ich sag schon mal vielen Dank für jedwede Information.

     

    Grüße ins Forum 

    thor 

     

     

      

      

      

  4. Sodele. Nach langem suchen hätt ich ja fast aufgegeben, aber durch Zufall funktionierts wieder.

     

    Zum System: Ich hab ein Windows 10 Pro (noch in der Version 1607)

    Die Workstation steht in einer Domäne.

     

    Ich hab nur durch zufall mal folgendes geändert.

    Bei der Einstellung für den Sperrbildschirm hab ich die Umstellung von Bild in Windows Blickpunkt.

    Dann hab ich mich abgemeldet. Siehe DA im Loin Bildschirm war nun  das Windows Blickpunkt Bild.

    Wieder angemeldet und in den Einstellunge für den Sperrbildschirm wieder Bild ausgewählt.

    Siehe Da! :D

    Nun war das gewünschte Sperrbildschirm Bild ebenso bei der Sperre wie auch bei der Abmeldung zu sehen.

     

  5. Hallo in die Runde. :grins2:

    Wenn ich ein bereits ausführlich diskutiertes Thema wieder aufgreife dann sag ich schon mal "Pardon" :grin3: aber ich hab nach einigem googlen immer noch nicht die Lösung für mein Problem gefunden.

    Folgendes. Wenn ich an meinem Win10 angemeldet bin und sperre den PC, dann erscheint mein einer Sperrbildschirm mit meinem favorisierten Hintergrundbild. :thumb1: Das ist auch so gewollt.

    Wenn ich mich aber an dem PC abmelde (und somit niemand angemeldet ist) , erscheint auf dem Sperrbildschirm ein schönes Blumenbild, was wiegesagt schön ist, aber ich hätte doch gern mal ein anderes.

    Hab auch schon mich mit dem lokalen Admin angemeldet, aber dort ist auch ein anderes Foto im Sperrbildschirm.

    Meine Frage, wie bekomme ich entweder ein anderes Bild nach dem Abmeldevorgang bzw. wo ist den der Speicherplatz für diese Bilder.

    Ich meine mich zu erinnern, das es nicht eine .jpg Datei oder so ist, sondern die Datei wird  vom System umbenannt (Kann das sein? :sauer:)

    Könnt Ihr mir vlt. dazu eine Lösungsmöglichkeit nennen? Danke sehr schon mal.

    Grüße in die Runde.

    thor

  6. Hallo.
    Zunächst mal die Information, das der Lösungsansatz von  Gulp bei unserem Problem half.

    vor 39 Minuten schrieb Gulp:

    Ändere mal den Namen des betroffenen Clients und versuche den Beitritt dann nach dem fälligen Neustart, könnte ein Problem mit dem NetBIOS Namen des Clients sein.

     

    Grüsse

     

    Gulp

    Hab folgendes ausgeführt.

    Name geändert von AB111222-0118 in AB111222-0218

    Neustart

    Anmeldung

    Name wieder abgeändert von AB111222-0218 in AB111222-0118

    Neustart

    DomainJoin nun wieder möglich.

     

    Danke sehr.
    thor

     

  7. Guten Morgen in die Runde.

    Seit heute Morgen haben wir Probleme neue Win 10 Clients in eine Windows2008R2 Domäne aufzunehmen. Bislang lief dieses auch ohne weiteres. Seit heute Morgen erhalten wir die Meldung.

    Bei dem versuch der Domäne "****.****" beizutreten, trag folgender Fehler auf.

    Der Domänencontroller erfüllt nicht die Versionsanforderungen für diesen Vorgang.

    Informationen dazu finden sie unter "http://go.microsoft.com/fwlink/?LinkId=294288 for more Informations".

     

    Die DNS Adressen hab ich überprüft und diese stimmen. Auch Zeitlich sind sowohl DCs und die Clients synchron.
    Die Variante aus dem Microsoft Forum, den Client zunächst in der AD Manuell anzulegen und dann beizutreten schlug fehl.
    Gibt es von Eurer Seite womöglich einen weiteren Lösungsansatz.

    Vielen Dank und beste Grüße in die Runde

    thor

     

  8. Hallo in die Runde.

    Wir haben nun unseren Exch 2010 mit dem SP3 und dem Rollup 10 versehen. Ich kann nun sagen, die Aussage von Nobbyaushb trifft weiterhin zu.

     

    Moin,

     

    nein, das kann man meines Wissens nicht ändern, ist hardcoded.

     

    Für mich: welches RU hast du drauf?

     

    ;)

     

    Es bleibt bei der max. Anzahl von 10 Verteilerlisten

    Somit könnte man hier jetzt den grünen Haken setzen und dieses Thema als gelöst betrachten.
    Danke an alle, die sich hier beteiligt und sich Gedanken gemacht haben.  

    thor
     

  9. Hallo ins Forum.
    Wir haben auf unserer Terminal-Server-Farm Outlook 2010/Exchange 2010 am Laufen.
    Jetzt haben wir in einem Verzeichnis in den öffentlichen Ordner eine Adressverzeichnis angelegt. In diesem Adressverzeichnis sind 13 Verteilerlisten angelegt.
    Wenn ich nun eine Mail an alle 13 Verteilerlisten senden möchte, markiere ich diese und klicke dann auch Email-Nachricht. Das Problem ist nun, daß ich diese Mail nicht versenden kann.
    "Ein unerwarteter Fehler ist aufgetreten"
    Entferne ich mind. 3 Verteiler listen (dabei ist es egal wie viele Mitglieder eine solche Liste hat) kann ich die Mail senden.
    Auch wenn mindestens 3 Verteilerlisten in das 2. Adressfeld Cc: eingefügt werden, kann ich erst die Mail abschicken.

    Die Länge des Verteilernamens als auch die Menge der eingefügten Mitglieder scheint fürs System irrelevant zu sein.

    Test bei der Mitgliedermenge:
    Hab bei einem Versuch 3 Verteiler mit insgesamt 14 Mitglieder entfernt. Mail ging raus.
    Beim nächsten Versuch hab ich gleich eine Verteilerliste mit 20 Mitglieder herausgenommen - Fehlermeldung.
    Erst als ich noch 2 weitere Listen herausgenommen habe, konnte ich die Mail senden.
    Test bei Namenslänge:
    Die Länge des Namens der Verteiler ists auch nicht, denn ich hab 12 Verteiler erstellt mit Namen a1; a2; etc
    Auch hier max. 10 Verteilerlisten im Adressfeld erlaubt.

    Nun meine Frage, kann man die max. Anzahl der Verteilerlisten im Adressfeld ändern? Wenn ja, wie?
    Hab schon etliche Suchmaschinen und -begriffe durch, komme aber meist auf die max. Anzahl von Mitgliedern in eine Verteilerlisten

    Danke schon mal in die Runde.
    thor

  10. Hallo ins Netz.

    Nach langem Suchen und mit Einschalten unseres Microsoft Gold Partner sowie mehreren Telefonaten mit Microsoft, konnte die Fehlerquelle eingekreist werden.

    Nach der Installation des Hotfixes KB2831347, laufen die Terminal-Server-Profile nun endlich wieder regulär. Wir haben das 2 Wochen auf einer Farm getestet, dann auf alle übertragen.

    Dies für alle, welche momentan ähnliche Probleme haben.

    Ein Dankeschön an alle, die sich über diese Problematik die Köpfe zerbrochen haben und mich in der Lösungsfindung unterstützen.

    Gruß Thor

     

  11. So, da bin ich wieder.

    Terminal-Server als auch File Server sind nun auf dem neuesten GData Stand V13.

     

    Die angezeigte Einstellung im Gdata verglichen.

    Die Verhaltensüberwachung ist nicht eingeschaltet.

     

    Trotz dem Update, bliebt der Fehler weiterhin beharrlich hartnäckig unser Begleiter.

    Wir können bei diesem Fehler wirklich keinerlei Reproduktion rekonstruieren. Weder Abmeldezeit; noch angemeldeter Server; noch Organsisationseinheit; noch Art des Arbeitsgerätes (ThinClient oder Workstation);  läßt Rückschlüsse auf das fehlerhafte Verhalten der NTUSER.dat zu. So langsam beginnen wir zu verzweifeln :confused: , aber die Hoffnung ist noch da! :wink2:

    Grüße thor.

  12. Hallo.

    Das Scannen der Netzlaufwerke ist ausgeschaltet.

    Die Problematik besteht seit ca. 4-6 Wochen. An einem best. Datum kann ich dies nicht festmachen.

    Zur GData Version. Erst seit Montag Abend 10.11. haben wir die neue 13er Version von GData auf unserem ManagementServer drauf. Die TS-Server und Clients arbeiten noch mit der 12er

    Wir wollten die Client zunächst noch im 12er Modus lassen, da wir Mitte Dezember wieder ein Rollout der kompletten Serverfarm durchführen.

    mit besten grüßen

    thor

  13. Hallo karlh.

    Wir haben von unserem Programmierer ein Automatisches Login zusammengeschustert bekommen, welches wir nur per Doppelklick ausführen. 

    Aber auch manuell haben wir schon die AutoLogons eingerichtet.
    Erstelle Benutzer (Gehe mal davon aus, daß Du diesen nur mit Benutzerrechten ausstatten möchtest).

    Gib dem Kind ein Kennwort und dann in der Registry (ich sollte vorsichtig sein mit meinem Registry Aktionen! :wink2: )

    Unter HKLM>Software>Microsoft>Windows NT>CurrentVersion>WinLogon

    AutoAdminLogon: 1

    DefaultUserName: Benutzername eintragen

    DefaultDomainName: Lokaler Computername
    DefaultPassword: Passwort eintragen. 

    Fertig. Reboot

     

    So hab ichs auf meinem Laptop mit 8.1 eingerichtet.

     

    Hoffe dies funktioniert bei Dir.

    Grüße thor

  14. Hallo.

    Nach einigem recherchieren im Netz bei Onkel Google etc.bin ich bei diesen 3 Seiten vielleicht fündig geworden.

    http://support.microsoft.com/kb/124594/en-us

    http://support.microsoft.com/kb/2567018

    http://support.microsoft.com/kb/935649/de

     

    Stichpunkte - registrySizeLimit. Ich bin auf diesen Zug aufgesprungen, weil die Benutzer, deren NTUSER.dat geschrottet wird. immer eine NTUSER.dat von 6MB aufwiesen (Im Nachhinein vlt. purer Zufall)

    Also hab ich bei unserem testserver des Registry Key gesetzt.

    Vielleicht noch erwähnenswert, das es sich bei unseren Terminal Server um eine virtuelle Server gemanaged von VMware handelt.

    HKLM>System>CurrentControlSet>Control RegistrySizeLimit REG_DWORD  0x02faf080  (50000000) 50MB sollte genügen.

    Den Testserver gebootet. nach dem Reboot erscheint ein richtig schöner BlueScreen

    0x0000074 BAD_SYSTEM_CONFIG_INFO

     

    Das war also ein richtiger Sprint ins Abseits. Falls jemand ähnliche Problematik hat in virtuellem Umfeld. Setze diesen Key nicht! Tue es nicht.  
     

    Server wieder da, aber das Problem bedauerlicherweise auch. Ich suche weiter, lasse es Euch wissen und falls Ihr eine neue Spur habt, immer her damit.

     

    Deinstalliere zum Test GData doch mal, anschließend auch das Removal Tool von GData verwenden. Wäre nicht das erste Mal wenn hier ein AV-Scanner Amok läuft.

     

    An Sunny61. Danke für den Lösungsansatz. Daran hab ich auch schon gedacht, jedoch müssten wir dies dann bei allen 35 Servern tun!
    da wir die Problematik nicht nur einem Server zuordnen können.

     

    Grüße ins Forum.

    thor

     

     

  15. Hallo Testperson.
    Danke für Deine Rückmeldung.

    Aufm Terminalserver im Ereignisprotokoll /Anwendung sehe ich nur dieses.

    Der Winlogon-Benachrichtigungsabonnent <Sens> ist bei einem Benachrichtigungsereignis fehlgeschlagen.

     

    Die Klassenregistrierungsdatei kann nicht geladen werden.

    DETAIL - Das System kann die angegebene Datei nicht finden.

     

    Der Winlogon-Benachrichtigungsabonnent <GPClient> ist bei einem kritischen Benachrichtigungsereignis fehlgeschlagen.

     

    Auf dem File Server sind keinerlei nützliche Ereignisse protokolliert

     

    Die GData Ausnahmen sind für die NTUSER.dat auf den Terminal-als auch Fileserver gesetzt.

     

    Mit freundlichen grüßen

    thor

  16. Hallo.
    Schade das niemand bislang ein Lösungsansatz anbieten konnte.  

    Hab ich das ins falsche Forum gestellt? Wenn ja, dann kann man dies gerne ins richte Forum verschieben....
    Ähnliches Problem hatte auch ein User in diesem Thread http://www.mcseboard.de/topic/191468-gruppenrichtlinienclient-zugriff-verweigert-dom%C3%A4nen-anmeldung/

    Die Prozedur, das sich der User wieder anmelden kann  ist bei uns einfacher, da wir diese Problematik bei den wandernden Profilen der Benutzer haben. 

    Aber wir würden gerne herausfinden warum die NTUSER.dat nur noch 256KB anstatt die 2-3 MB hat....

     

    Grüße thor

  17. Hallo in die Runde.

    Seit einiger Zeit haben wir folgende Problematik. Unsere Benutzer können sich nicht mehr an der Serverfarm anmelden. „ Fehler beim Anmelden an Dienst Gruppenrichtlinie“ wird als Fehler angezeigt.

     

    Unser Netzwerkaufbau.

    Terminal-Server-Farm mit Windows Server 2008 R2 und WSUS Updates.

    File Server (Dort liegen unsere Profilverzeichnisse)  ebenfalls mit Windows 2008 R + WSUS

    Benutzer melden sich via Remotedesktopprotokoll an den TS an und haben ein wanderndes TS-Profil.

     

     Zunächst haben wir immer das Profil des Benutzers gelöscht und neu schrieben lassen. Wir haben herausgefunden, dass die Datei NTUSER.dat im Terminal-Server-Profil des Benutzers der Auslöser ist. Diese hat im defekten Userprofil eine Größe von 256 KB. Standard meist über 2 MB. Auch die Datei ist nicht mehr versteckt, sondern offen sichtbar. Wenn wir nur diese löschen und den Benutzer neu anmelden lassen, geht es auch wieder. Wir vermuteten des G Data Antivirenwächter für den Auslöser, das diese vlt. beim Abmelden die nicht korrekt zurückschreibt und haben die NTUSER.dat in der Überwachung explizit herausgenommen. Bislang kein Erfolg.

    Die defekte NTUSER.dat hat in dem Sicherheitsregister aber alle notwendigen Berechtigungen wie es sein sollte.

     

    Hat jemand ähnliche Problematik und dann auch eine Lösungsmöglichkeit, die wir angehend könnten?

    Vielen Dank schon mal für Euer Interesse an unserem Problem.

    thor. 

  18. Hallo.

    Auf unserem Printserver ist sowohl der 32 als auch der 64 bit Treiber installiert. Das müssten wir testweise auch mal auf dem Terminalserver probieren.

     

    Hallo,

     

    mein Gedanke war, auch den 32.Treiber zu installieren unter zusätzliche Treiber.

     

    Nachdem unsere System Riesenprobleme mit den KX Treibern der Fa. Kyocera hatte, sind wir wieder umgestiegen auf die "regulären" PCL Treiber. Da gingen plötzlich keinerlei Druckaufträge mehr raus. Das Problem bestand auch darin, daß ein lokaler KX Treiberer auf einer WS das Drucksystem stoppte. Zunächts sind wir von der KX Version 5.3 (sig. und zert. von MS) auf die 6.1 (sig. und zert. von MS) Version umgestiegen. Pah! Die haben uns was gehustet.

    Bei unserem Großgeräten haben wir sogar "nur" den Standard Universaltreiber installiert. BIslang läufts zufriedenstellend.

    Da hab ich (auch meine Kollegen bedenken), nochmal andere Treiber aufzuspielen.

    Hab gerade auf der Kyo Homepage nachgeschau. DIe haben keine PS Treiber! Oder bin ich nur blind auf der Brille?

    Wir testens aus.

    Vielen Dank für Eure Antworten.

    Gruß

    thor

×
×
  • Neu erstellen...