Pfuscher

Weil ich das noch nicht alles komplett umgestellt habe. In diesem Fall ist es eine Samlung von Batches, die Dateien/Verzeichnisse durch die Gegend kopieren, Antivirenscanner auslösen und weiter schubsen zum Zielort. Haben hier Notebooks teilweise im Lockdown wo Mitarbeiter selbstständig Datenträger einschleusen können, damit diese die SD-Cards/Sticks/CDs etc nicht "einschicken" müssen von ihren Standorten. Klingt etwas kompliziert, funktioniert aber recht gut um verseuchte Sticks von Kunden etc aufzuhalten.

Da ichs noch in einer Batch ausführen muss, lautet der Befehl z.B. so: powershell.exe "Get-ChildItem -Path C:\TEMP\*\* -Directory | Remove-Item -Recurse" bzw ohne "-Directory", um auch Dateien zu erwischen powershell.exe "Get-ChildItem -Path C:\TEMP\*\* | Remove-Item -Recurse" Danke!

Alle Unterordner unterhalb eines beliebigen Ordners im gleichen Stamm. Gleich mal guggn. Habs wahrscheinlich wieder zu kompliziert mit CMD und For Schleifen probiert...

Ahoi, ich möchte die Unterordner und Dateien von mehreren Ordnern im gleichen Stammverzeichnis löschen, komm damit aber nicht klar. Eventuell kann mir ja jemand helfen. Stamm -> Ordner 1 -> Unterordner Stamm -> Ordner 2 -> Unterordner Stamm -> Ordner n -> Unterordner Ich möchte die jeweiligen Unterordner löschen, ohne den Namen von "Ordner 1,2,n" im Forfeld zu kennen. Danke schon mal, LG Henry

Ahoi, ich bin grad im Urlaub und hoffe auf schnelle Hilfe. Im Unternehmen taucht seit heute folgender Fehler auf bei der RDS Nutzeranmeldung: Fehler bei der Richtlinienanwendung und beim Umleiten des Ordners "RoamingAppData" nach "\\firma.intern\dfs\users\NUTZERX\Anwendungsdaten". Umleitungsoptionen=0x1001. Der folgende Fehler ist aufgetreten: "Liste der regulären Unterordner unter "\\firma.intern\dfs\users\NUTZER2\Anwendungsdaten" konnte nicht erstellt werden". Fehlerdetails: "Zugriff verweigert ". Die Ordnerumleitung versucht jeden Nutzer (NutzerX) auf Nutzer2 umzuleiten. GPOs wurden nicht geändert, RDS Server haben keine Updates bekommen seit letzter Woche. Fehler seit heute. bin total ratlos.

Ich habe bei uns auch den Defender aktiviert. Allerdings als zusätzliche Instanz (als Zeugen wenn man so will). CCLeaner & Co sehe ich eher skeptisch, lasse ihn aber auch mal gern punktuell laufen. Aber sicherlich nicht als Unternehmenslösung und ganz sicher nicht auf den Hosts für Exchange & Co... Das mit dem Mailplugin halte ich persönlich gerade nicht für unsinnig. Es ist auch hier eine zusätzliche Instanz, um sicher zu gehen, das beim Mailgateway und am Exchange nicht doch was unentdeckt durchflutscht. Rein wie raus. Da macht dann aber auch der Einsatz unterschiedlicher Hersteller Sinn. Ist aber auch Glaubensfrage, ob man davon überzeugt ist, das am Client absolut nix, aber auch garnix passieren kann.

Morsche Leude, heut morgen verschlafen ins Büro gekommen und die Telefonliste ist schon voll. Ich hatte das Problem schon mit 1709, das einige Clients, trotz fehlender Freigabe das 1803 Upgrade installieren. - alle Clients sind in OUs, in denen auch andere Win 10 Geräte stecken, die nicht installieren - im WSUS ist das 1803 nur für eine Test OU mit Zielzuordnung freigegeben - GPO ist eingestellt (von einem der betroffenen Clients mit gpresult gezogen): Internen Pfad für den Microsoft Updatedienst angeben Aktiviert Interner Updatedienst zum Ermitteln von Updates: http://WSUS.netzwerk.intern:8530 Intranetserver für die Statistik: http://WSUS.netzwerk.intern:8530 Alternativen Downloadserver festlegen: http://WSUS.netzwerk.intern:8530 Empfohlene Updates über automatische Updates aktivieren Aktiviert Keine Verbindungen mit Windows Update-Internetadressen herstellen Aktiviert Durch die letzte Option ist zwar der Windows Store abgeklemmt, aber dadurch suchen die Clients ja auch nicht mehr im Internet nach Updates. Das müsste man mir auch noch mal erklären wie man das richtig einstellt, daß der Store geht aber WU im Intranet bleibt... Wo ist mein Denkfehler bei der ganzen Sache? Das bekloppte ist, möchte ich den Windows Store zulassen, Updaten die Clients fröhlich über den Proxy aus dem Internet.

Ja ist Enterprise CA 2008R2. Hab das PKI Cert testweise in ne GPO geklebt. Rechner sind keine Clone, aber auch gemischt von der Installation her. Mal Hersteller Out of the Box und mal frisch vom Stick. Gleiche GPOs/OUs wie die "normalos". Mal reicht Rejoin der Domain, mal muss das CA Cert per Hand reingeklebt werden. Irgendwann ruckelt es sich dann ein. Betrift auch nur 2-4 Rechner auf 100 Clients über den Daumen.

Gleiches hier. Hab das Problem auch schon mit 1709 gehabt. Einige Clients werfen zum Geier die PKI CA raus oder akzeptieren die GPO mit dem Zertifikat nicht. Dadurch wird der PKI nicht vertraut. Dadurch keine Computer/Benutzerzertifikate. Dadurch kein WLAN. Rattenschwanz. Auffällig waren insbesondere Clients die mit Win10 RTM oder Win 7 ursprünglich gestartet sind und aktualisiert wurden.

Hab das Script von https://www.wsus.de/de/Scripts/Decline-WSUS-Updates um Approved Superseded Updates erweitert, die entfernt werden. Mein WSUS war mittlerweile bei 2TB Daten angelangt. Ich hoffe ich hab damit nix kaputt gemacht... Bis jetzt laufen aber alle Clients weiter und neue ungepatchte Clients bekommen alle Updates soweit ich das feststellen kann. Hab ich zusätzlich mit den Online Updates abgegeglichen. im Message Block Zeile hinzugefügt: $IsSuperseded_counted Superseded Updates wurden abgelehnt Im Funktionsblock am Ende wie folgt eingefügt: # Searching if the update is marked as superseded # IsSuperseded $IsSuperseded = $WsusServerAdminProxy.GetUpdates() | ?{-not $_.IsDeclined -and $_.IsSuperseded -eq 'True'} $IsSuperseded_counted = $IsSuperseded.count If ($IsSuperseded.count -lt 1) { $IsSuperseded_counted = 0 } If ($TrialRun -eq 0 -and $IsSuperseded.count -gt 0) { $IsSuperseded | %{$_.Decline()} } Hat bei mir ca 7000 Updates abgelehnt und 1TB Festplatte frei gemacht.

Nach ein paar Tagen Systembeobachtung ist leider weiterhin so, das auch mit KB4088875 immer wieder BSODs auftreten. Allerdings nur noch sporadisch. Alle 2 Tage 1-2 mal.

Es ging hier eher um das ominöse Update, was zu entfernen ist. :) Wir sind jedenfalls noch recht gespannt. EDIT: Ich nehme mal an, es geht um die KB4088875. Werde ich jetzt mal testen.

Schließe mich neugierig an. Dankö!

Problem damit nicht komplett behoben, aber spürbar verringert. Nur noch sporadische BSODs.

Hab BITS reglementiert, das der nicht die Bandbreite auffrist. Hmm, die Scripts sind mir nicht bekannt. Hatte jetzt auch nciht so die Dringlichkeit. Aber grundsätzlich haste natürlich recht, die 1,5TB WSUS Daten gehen mir auch ganz schön auf den Senkel. Selektiere ja bereits über die Klassifizierungen vor, aber ist imemr noch genug Mist dabei den keiner meiner Clients aktuell braucht.

Ja "Solche" hab ich auch hin und wieder. Auf den Hinweis das das nicht gut ist, kommt meist die Antwort, ich hab doch nix zu verbergen und kaputt machen kann man doch auch nix. Also flux Outlook/Webmail/etcpp aufgemacht, neue E-Mail an Geschäftsführer und alle Kunden im Adressbuch, Betreff "Ihr ars***krampen". Spätestens wenn man im Body noch ein paar nette Dinge schreibt, habens auch die Letzten begriffen.

Oha, ja seh grad der WSUS läd seit dem Mittags-Sync 65GB runter...

Danke! Kollege hat mich auf grad drauf gebracht. KB4088875 und/oder KB4088878 sollten/könnten schuld sein. Hier auch dazu grad gefunden: https://www.borncity.com/blog/2018/04/05/windows-kb4090450-kb4088875-kb4088878-kb4088881/ https://community.spiceworks.com/topic/2120588-kb4088875-kb4088878-patch-issues?page=3 KB4099467 kennt mein WSUS nicht, mal manuell reinprügeln.

Ahoi, hänge grad etwas entnervt an einem BSOD Problem in unsere 2008R2 RDS Farm. Bekomme seit ca letzter Woche abwechselnd auf den Farm mit 10 Membern BSODs mit der Meldung "0x000000ab SESSION_HAS_VALID_POOL_ON_EXIT". Laut Inder-Net stehen Druckertreiber in Verdacht. Der Hotfix https://support.microsoft.com/de-de/help/2617115/stop-0x000000ab-session-has-valid-pool-on-exit-error-when-a-client-log ist nicht anwendbar auf meinen Servern. Updates wurden nicht eingespielt in dem Zeitraum, Druckertreiber in der Farm ebenfalls nicht geändert. Ansonsten ist die RDS FARM und die Clients (XP + Windows 10) "tagesaktuell" gepatcht. Drucker sind noch einige USB, ansonsten in Masse LAN. Nutzer Spitze liegt bei 200 Clients. Treiber/Drucker sind relativ homogen, es werden nur 4 Druckertreiber in ca 10 Versionen (HP UPD und UTAX Universaltreiber) eingesetzt. Ich hab mir jetzt schon Logon/off Skripte geschrieben mit denen ich mehr oder weniger die Benutzer An- und Abmeldungen auf den Servern logge um zu sehen wer sich vor dem BSOD zuletzt (ordentlich) abgemeldet hat. Eventuell hat ja jemand eine Idee wie ich dem oder die Übertäter auf die Spur komme. Vieleicht seh ich auch den Wald vor lauter Bäumen nicht. #Ninja-Edit: Wenn man nicht richtig schauen kann. Updates am 05.04. installiert worden. Aber haben den Fehler schon davor gehabt. Dankö!

RU ja, .Net nein Ich hab was gefunden. Wenn ich das SP3 Setup nochmal anstarte, dann bietet er mir die CAS Rolle nochmal zu Installtion an. Ist also nciht sauber durchgelaufen. Als Fehler kommt: Clientzugriffsrolle Fehler Fehler: Der folgende Fehler wurde generiert, als "$error.Clear(); new-ActiveSyncVirtualDirectory -DomainController $RoleDomainController; " ausgeführt wurde: "Das virtuelle Verzeichnis 'Microsoft-Server-ActiveSync' ist bereits unter 'MAIL.DOMAIN.intern/Default Web Site' vorhanden. Parametername: VirtualDirectoryName". Das virtuelle Verzeichnis 'Microsoft-Server-ActiveSync' ist bereits unter 'MAIL.DOMAIN.intern/Default Web Site' vorhanden. Parametername: VirtualDirectoryName Hier klicken, um die Hilfe aufzurufen... http://technet.microsoft.com/de-DE/library/ms.exch.err.default(EXCHG.141).aspx?v=14.3.361.1&e=ms.exch.err.Ex88D115&l=0&cl=cp Verstrichene Zeit: 00:00:01 Das Virtuelle Directory gibts im IIS und funzt komischerweise auch. Hat aber nix mit MAPI zu tun. Ich hab testweise das Outlook mal auf RPC eingestellt für langsame und schnelle verbindungen. funktioniert auch nicht. Soo habs erstmal umschifft bis heute in die Nachtschicht... HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider (REG_SZ) DS Server auf den DC Domain FQDN (NETBIOS.INTERN) gesetzt und es geht fürs erste. Ist mir aufgefallen, als ich das Outlook 2010 auf RPC/http umstellen wollte und es einen anderen Fehler gab.

Sieht gut aus, ServicesNotRunning ist jeweils leer. Es kann doch jetzt nur an der MAPI hängen. Outlook 2016 geht, OWA geht, EAS geht.

Die Nutzer mit EX2003 Profil, verbinden zum EX2003.

immer intern, habe keine externen Clients da drauf. Mir ist grad aufgefallen,das wenn ich von einem Postfach vom Exchange 2003 komme und ein Ordner eines anderen Postfaches auf dem EX2010 öffnen will, kommt eine Benutzername/Kennwort Aufforderung. Ging aber vorher. an den Outlook 2010 clients mit Esxchange 2010 Postfach kommt halt beim öffnen von Outlook "Der Server ist nicht verfügbar".

Mal ne ganz blöde Frage. Ich seh den Wald nicht mehr... Wie verbindet sich per Standard Outlook 2010 zu Exchange 2010. MAPI, RPC, RPC/HTTP?

Öhhm: https://www.microsoft.com/en-us/download/details.aspx?id=55591