Jump to content

Poehli

Members
  • Gesamte Inhalte

    102
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

10 Neutral

Über Poehli

  • Rang
    Newbie
  1. Ja, ok, wäre halt schön wenn es wenigstens eine Projektseite gäbe wo so etwas kommuniziert wird. Der angagierte IT ler sucht erst mal 2 Tage selber den Fehler ehe er andere um Hilfe bittet :-). Auch wenn man nicht genug Zeit zum Coden hat, der Status des WPP Projektes ist seit Monaten unterirdisch. Eine simple Textzeile auf Github das es da derzeit hakt ist sicher für jeden im Rahmen des zeitlich realisierbaren. Davon abgesehen, ich war länger nicht hier, schön das die Antworten in diesem Themenumfeld immer noch von den gleichen SuperMembern kommen Danke!
  2. Ah, Hallo Norbert, Es steigert mein Selbstwertgefühl schon mal ungemein wenn ich lese das es nicht an meiner offensichtlichen Unfähigkeit als ITler liegt Was ich nicht ganz verstehe ist wieso es funktioniert wenn ich als lokaler Admin am Client angemeldet bin.... Ich blick bei Github als Nichtprogrammierer nicht durch, ich finde da überhaupt nix, nicht mal einen ordentlichen Downloadbereich. Wer soll denn so eine Software benutzen wollen, ohne Anleitungsseite, FAQ, Support...Forum. Güße aus dem noch eingeschneiten Thüringen byPö
  3. Hallo, ich hab seit Jahren den WPP im Einsatz, leider ist er seit dem Wechsel von CodePlex zu Gitub kaum mehr exsistent im Netz. Ich habe eine Problem mit dem Zugriff auf den Windows Update Agent der Clients vom WPP aus. Unter WPP/Alle Computer-> Rechtsclick auf einen Client kan man divere Sachen abfragen. Launch Remote MSI Manager - funktioniert Zeige derzeit angemeldete Benutzer - funktioniert Ausstehende Updates anzeigen bzw Ausstehende Updates installieren... - funktioniert nicht. Ich bekomme die Fehlermeldung: Unauthorized Access Exception! Ensure you have admin privileges on remote computer. Ich will es nicht beschwören, aber ich denke das Problem tritt seit Funktionsupdate auf Windows 10 1709 auf. Dieser Zugriff fällt meines Verständnis nach in die Rubrik "Using WUA from a remote computer" Für diese Abfrage sind Firewall-Ports erforderlich, selbige hatte ich bereits vor Jahren per GPO gesetzt, und wenn ich auf den Clients die Firewall prüfe sind sie für die Domäne auch als Eingangsregel eingetragen. Ein Abschalten der Firewall am Client ändert nichts, ich würde die Firwall samt Konfiguration also mal ausschließen. Laut Fehlermeldung soll es eine Berechtigungsproblem sein...nun ja... Ich konnte bisher nur eine Kombination finden wo die Abfrage funktioniert - wenn ich am Client als lokaler Administrator ohne Domäne angemeldet bin. Es funktioniert weder bei lokaler Benutzeranmeldung noch bei Domänenanmeldung, egal ob als User oder Admin. Ich kann mich mit solchen Dingen jetzt nicht wirklich gut aus, meine Vermutung wäre das der von WPP initiierte Zugriff auf die WUA API des Clients nicht (mehr) die erforderlichen Rechte hat. Aber ich weiß nicht ob ich richtig liege und wo ich danach graben soll. wäre da für Ideen dankbar.... byPö
  4. Hallo, ja, nach den Werten habe ich natürlich geschaut. Die sehen für mich allerdings nicht danach aus als ob sie das Problem berühren. Quasi eine andere Baustelle, die ich jetzt nicht öffnen wollte. mein Problem ist ja erst mal das hier:
  5. Ja, alles ein Frage der Kenntnisse und Fähigkeiten, nicht wahr :-) Wenn ich die zuständige Richtlinie nicht identifizieren kann, dann kann ich auch nichts ändern, und genau dahin geht meine Frage. Die Gruppenrichtlinienergebnisse liefern mir unter Zusätzliche Reg- Einstellungen drei Einträge zu denen keine Anzeige gefunden wurde. Das ist schon mal ein Ansatz. "einfach die pol Datei direkt editieren" - hab ich leider noch nie gemacht. Das letzte mal haben wir eine eigene admx erstellt um an den alten Schalter ranzukommen, aber dafür muss man die Richtlinie wissen.
  6. Hallo, ja, den GPMC Bericht bin ich durchgegangen, aber erfolglos. Meine Sorge ist auch das es eine weggefallene Richtlinie ist, schließlich wurde das Windows Defender Security Center komplett neu designt. So einen Fall hatte ich schon mal, das war ein ganz schöner Akt das hinzubiegen.
  7. Hallo, ich fange jetzt an 1709 zu verteilen, habe die neuen Templates importiert, den Fehler mit "CSE_Background" behoben und angefangen die knapp 100 neuen GPOs durchzuackern. Dabei viel auf das wohl auch ein paar ältere Einträge korrigiert werden müßten. Leider hab ich ein paar Schwierigkeiten die passenden Gruppenrichtlinien in meinem DE lokalisierten System zu finden. Windows Defender Security Center/ Firewall & Netzwerkschutz/ Einstellungen für Firewallbenachrichtigungen / "Benachrichtigen, wenn eine neue App von der Windows Defender Firewall blockiert wird" Was/wo ist da die Entsprechung in den Gruppenrichtlinien ? Das ist hier per Gruppenrichtline gesetzt, aber ich finde sie nicht. Ich hab unter WKomponenten/Windows Defender Security Center/ gesucht. und: Windows Defender Security Center/ Viren und Bedrohungsschutz / Einstellungen für Viren und Bedrohungsschutz / Cloudbasierter Schutz - da such ich auch die Gruppenrichtlinie Ansonsten muss ich sagen.... so langsam wirds mit den Konfigurationsmöglichkeiten bei W10. Vor allem bin ich froh das nicht noch mehr Richtlinien den Enterprise vorbebehalten werden. Die Entwicklung war ziemlich bedenklich.
  8. Ich habe jetzt nochmal ein Dutzend Anleitungen durch, aber keinen Hinweis darauf warum es nicht funktioniert. Allerdings war auch keine Anleitung dabei die auf einem aktuellen W10 1607 oder höher basiert und die auch explizit Windows Search und nicht nur die Explorer Suche berücksichtigte. Mich beschleicht der Verdacht das mit dem "Umbau" der Windows Search zu Cortana Search da eventuell einiges nicht mehr funktioniert. Insbesondere wenn Cortana abgeschaltet ist. Ich kann es aber nicht verifizieren. Das Problem betrifft jedenfalls nur Windows Search ( Desktop ), bei Explorer-Suche funktionioniert die Indexierung der Netzlaufwerke meinem Eindruck nach. Damit würde Marco31 doch recht behalten. An dedup kannn es jedenfalls nicht liegen, ist nicht eingerichtet am Server.
  9. Also ich habe es leider noch nicht verstanden, trotz Anleitung, und bisher gab es 3 verschiedene Antworten: es geht automatisch, es geht gar nicht, und man muss es hinzufügen. Abr schön das meine Frage schon mal anderen geholfen hat. :-) Ich bin leider nur wenig schlauer als bisher. Am Server wurde der Index für die ausgewählten zu indizierten Orte erstellt ( C:\Daten\Public ), und der Indizierungsort wo der Index liegt ist standardmäßig : C:\ProgramData\Microsoft . Das ......\Search wird vermutlich automatisch ergänzt, jedenfalls ist dort der eigentliche Index. Wenn ich jetzt am Client eine neue Bibliothek anlege, und den Netzwerkpfad zum Public Ordner angebe, dann wird das akzeptiert, d.h. der Ort wird als indiziert erkannt. Aber wenn ich dann suche wird kein Dokument gefunden was auf dem Server in Public liegt. Nicht mit Dateinamen und natürlich erst recht nicht bei Begriffen in Dateien. Also entweder sucht er bei mir nicht in Bibliotheken oder es ist irgendwas anderes, das er den Index auf dem Server nicht erreichen kann oder sonstwas. Ich kann ja am Client die Bibliothek auch nicht explizit auswählen, das ist nicht vorgesehen.
  10. Hallo, Tja. Schön das es so einfach sein soll :-) Dann habe ich halt das Problem das er genau das nicht macht. Der Server hat indiziert, der Client hat indiziert, aber keine Datei der verbunden Netzlaufwerke wird von der Windowssuche gefunden.
  11. Umgebung: WS 2012R2 W10 1607 Prof Clients Hallo, unsere User haben verbundene Netzlaufwerke am Server, als Benutzer-gekoppelte "private" Laufwerke und als Datenaustauschlaufwerke. Im Prinzip sollen dort alle Daten abgelegt werden. Jetzt gibt es immer wieder die Beschwerde das Windows Desktop Search ( Taskleiste: Windows durchsuchen ) die Dateien dort nicht findet. Beschwerde kann ich nachvollziehen, wenn alles auf den Netzlaufwerken liegen soll wäre es schön wenn Windows dort auch sucht und indiziert. Ist ja erst mal klar das es nicht geht, die Suche und Indizierung läuft standardmäßig lokal. (und Cortana ist abgeschaltet) Also habe ich zunächst die Indizierung am Server aktiviert, für die betreffenden Ordner die als Laufwerke verbunden werden. Die Indizierung ist erfolgt und abgeschlossen. Jetzt der Client. Ein Netzlaufwerk bei den Indizierungsoptionen direkt hinzuzufügen ist nicht auswählbar. Ich sehe hier nur lokale Laufwerke, kein Netzwerk oder AD oder Freigaben. Es ist indirekt doch möglich wenn ich das ganze Netzlaufwerk im Explorer einer Bibliothek hinzufüge, denn Bibliotheken sind immer indiziert. Ist das der offizielle Weg? Greift in diesem Fall die Suche auf den Server-Index zu? Oder versuchen in diesem Fall die Clients das Netzlaufwerk zu indizieren. Das käme natürlich nicht in Frage. Ich habe gelesen: Wird auf einem Windows Server Windows Search installiert und dort ein Index angelegt, nutzt der Client den Suchindex des Servers, was wiederum das Netzwerk entlastet. Um dies zu erreichen muss nur eine Freigabe auf dem Server als Indizierungsort angegeben werden. Der Client befragt in diesem Fall automatisch den Server, Windows Search 4 auf dem Server vorausgesetzt. Verstehe ich nur nicht. Indizierungsort ist laut Indizierungsoptionen/Erweiterte Optionen standardmäßig C:\ProgramData\Microsoft Nur ist es mir nicht möglich da den korrespondierenden Ordner auf dem Server mit dem Indizierungsverzeichnis anzugeben. Da sind nur lokale Adressen möglich, genauso wie bei der Auswahl der zu indizierenden Ordner. Was ist denn hier der Denkfehler? Danke Pö
  12. Ja, das Problem hatte ich auch. Tödlich mit eienr 2000er Leitung :-), vor allem weil keine BITs benutzt wird in dem Fall. Der betreffende Client hat seit irgendeinem KB ein Problem mit dem WSUS, und lädt daher direkt aus dem Netz. Ineressanterweise meldet er aber weiter Status, allerdings falsch. Kurzfristiger Workaround: Umkonfiguration der GPO bezüglich der " Delivery Optimization ". Damit kann man schon erst mal unterbinden das Clients überhaupt wo anders her als vom WSUS holen. Als zweiter Schritt war die manuelle Installation von KB 3197356 nötig. Ist aber schon paar Wochen her, eventuell gibts da mitlerweile was neueres.
  13. W 10 Apps Problem Aktivierung

    Umgebnung: Windows 10 Prof 1607 Hallo, ich habe auf allen getesteten Rechnern Probleme mit der Aktivierung von offline installierten Apps aus dem Business Store. Im Business Store stehen Apps für die Offline Installation bereit. Diese habe ich heruntergeladen und in einen Freigabeordner gelegt. Windows 10 1607 enthält den App Installer, diese soll .appx und .appxBundle Dateien installieren. Ich betone es nochmal: Diese Apps sind explizit für die Offlineinstallation ausgewiesen. Die Installation funktioniert. Versuch 1: Installation einer .appx Wenn ich die App starten will schließt sie sich jedoch sofort wieder. Keine direkte Fehlermeldung. Die Ereignisanzeige liefert für den Zeitpunkt folgenden Fehler: Fehler 5973: Bei der Aktivierung der App „13387RevolutionSoftware.PeriodicTable_ey93dt8f74erj!App“ ist folgender Fehler aufgetreten: Zugriff verweigert. Weitere Informationen finden Sie im Protokoll „Microsoft-Windows-TWinUI/Betriebsbereit“. Allerdings gibt es keine Probleme bei einer ganzen Reihe anderer Clients, gleiche Windows Version. Da startet die App korrekt. Ich konnte bisher keinen Unterschied zwischen den Systemen ausmachen. Was scheinbar nirgends hier funktioniert sind .appx-Bundle Versuch 2: Installation einer .appx-bundle Wenn ich die App starten will schließt sie sich jedoch sofort wieder. Keine direkte Fehlermeldung. Die Ereignisanzeige liefert für den Zeitpunkt ebenfalls folgenden Fehler: Bei der Aktivierung der App „Microsoft.Reader_8wekyb3d8bbwe!Microsoft.Reader“ ist folgender Fehler aufgetreten: Zugriff verweigert. Weitere Informationen finden Sie im Protokoll „Microsoft-Windows-TWinUI/Betriebsbereit“. in dem Log auf das verwiesen wird taucht auf: 5990: Fehler bei der Aktivierung über das Vertragshilfsprogramm: App Microsoft.Reader_8wekyb3d8bbwe!Microsoft.Reader für den Windows.Launch-Vertrag: Zugriff verweigert. 5961: Fehler bei der Aktivierung der App „Microsoft.Reader_8wekyb3d8bbwe!Microsoft.Reader“ für den Vertrag „Windows.Launch“: Zugriff verweigert 5985: ActivateApplicationForContractByAppIdAsUserWithHost-Fehler bei der App Microsoft.Reader_8wekyb3d8bbwe!Microsoft.Reader für den Windows.Launch-Vertrag: Zugriff verweigert. Ich habe bereits Anleitungen gesehen wo bei dieser Fehlermeldung durch manuelle Übernahme von App- Ordnerbesitzrechten am Client eine positive Aktivierung möglich war. Allerdings handelt es sich nicht um ein vereinzeltes Problem sondern betrifft viele Rechner. Mich würde daher interessieren ob es irgendwelche grundsätzlichen Einstellungen gibt, zB über die GPO, die auf dieses Verhalten wirken. Mir ist auch nicht klar was installationsseitig falsch läuft das die Aktivierung in ein Zugriffsproblem rennt. Auch gibt es offensichtlich Unterschiede wie die Apps die AKtibvierung handhaben, sonst würde es nicht bei einer gehen und bei der anderen nicht.
  14. Wie nicht verfügbar? , heute Vormittag offiziell runtergeladen. "Windows 10 and Windows Server 2016 ADMX.msi" vom 5.08.2016. Da sollte doch alles drin sein bei dem Datum. Danke für die Links! SCM hab ich noch nie gehört, macht das Sinn ohne MSCCM?
  15. Hallo, auch wenn das 1607 erst in ein paar Tagen den WSUS erreicht, die neuen .admx Policities für das 1607 und WS 2016 sind ja nun offiziell verfügbar. Was ich beim 1511 schon vermisste - gibt es eine Seite wo man einsehen kann was neu hinzugekommen ist um zu entscheiden was für einen eventuell relevant ist und gesetzt werden könnte ? Danke byPö
×