jets187

vor 2 Minuten schrieb Nobbyaushb:

Das kannst nur du machen, indem du eine Antwort als Lösung markierst

Danke Nobbyaushb 

vor 1 Minute schrieb MurdocX:

Mir ist so eine Gruppenrichtlinie nicht bekannt. Auch finde ich bei Microsoft nichts darüber. Dann wird er sie selber angelegt haben. Da Ihr sicher keine NT-Computer mehr im Einsatz habt, kannst du diese getrost entknüpfen. 

Hi Murdoc,

das habe ich auch nun gemacht. Ich warte jetzt mal ab, ob sich in den nächsten Tagen einer meiner Kollegen sich meldet, das er / sie probleme am PC haben.

Ich denke aber das sollte nicht der Fall sein. 

Ich danke euch allen für eure hilfe.

Kann ich diesen Thread selber als "gelöst" markieren, oder macht das der Admin?

Hallo zusammen,

so nun das Ergebnis,

ich habe den Übeltäter ausfindig gemacht. Es ist eine GPO die sich NT-kompatible Security nennt und diverse Computer Eigenschaften konfiguriert. Diese GPO ist auf die übergeordnete OU in unser Domain angehängt und wird natürlich mittels Vererbung auf alle OUs verteilt.

Kennt eine von euch diese GPO. Ist das eine Default GPO von Microsoft oder wurde diese GPO von meinem Vorgänger angelegt. Die Domain wurde meines Wissens nach bisher von 2000 bis 2008 R2 hochgezogen.

Kann das ein Überbleibsel sein?

Danke

Gerade eben schrieb NorbertFe:

Kommt ja wohl drauf an, was du darin konfiguriert hast, oder?

In der Default Policy habe ich nichts verändert. ich weis aber nicht, ob mein Vorgänger dort irgendetwas angefasst hat. 

Es gibt leider keine Doku.

Ich taste mich nun voran und schaue, ob es eine User oder Computer Konfiguration auslöst.

vor 33 Minuten schrieb NorbertFe:

Gilt das auch für den sich anmeldenden Nutzer?

Hi NorbertFe,

ja auch der User ist in der selben OU

vor 25 Minuten schrieb g2sm:

Hi, gleiche Problem habe ich hier auch immer mal wieder, jedoch auf Server 2016.

Probier mal folgendes in der Powershell (mit admin rechte):

 

$packages = Get-ChildItem -Path "$env:USERPROFILE\AppData\Local\Packages"

if($packages.count -lt 20){

$apps =  Get-ChildItem -Recurse -Path "C:\Windows\SystemApps","C:\Windows\ImmersiveControlPanel","C:\Windows\PrintDialog","C:\Windows\MiracastView" -Include "AppXManifest.xml"

Foreach($app in $apps){
Add-AppxPackage -DisableDevelopmentMode -Register "$app" -Verbose}
}
Else{
$null}

und\oder

 

Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System"
New-Item "HKLM:\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System"

 

Hi g2sm,

werde ich mal auf einem defekten Win10 Rechner probieren.

Danke

Hi zusammen,

so nochmal zusammenfassung.

Win 10 Rechner in leerer OU ohne Vererbung löst diesen Fehler nicht aus. Ich werde mich jetzt einmal durchhangeln und schauen welches der vererbten GPOs dieses Verhalten auslöst.

Werde das Ergebnis dann hier posten.

Kann es sein, dass die Default Domain Policy so ein Problem auslöst?

Danke

Hi NorbertFe und Jan,

habe jetzt eine neue leere OU angelegt und die Vererbung deaktiviert. Aktuell werden laut gpresult /R keine Richtlinien angewendet. Das Problem besteht aber immer noch. 

Ich werde jetzt eine neue VM aufsetzen und schauen, ob das Verhalten nochmal in einer leeren OU mit deaktivierter Vererbung auftritt. Ich melde mich wieder.

Wenn Ihr weitere Tipps habt, immer her damit ;)

Danke

vor 6 Minuten schrieb NorbertFe:

Welche gpos wirken denn sonst noch, wenn man am Windows 10 Client angemeldet ist?

Hi NorbertFe,

es wirken unter anderem die Default Domain Policy, NT-kompatible Security und einige andere GPOs, die keine nennswertern Einstellungen für dieses Verhalten haben dürften, unter anderem GPOs wie z.B. Skripte gleichzeitig ausführen etc.

vor 4 Minuten schrieb testperson:

Hi,

 

wenn du den Win10 Client nach dem Domain-Join in eine neue, leere OU schiebst auf der keine GPO angewendet wird und dich mit einem Testuser anmeldest, der ebenfalls keine GPO anwendet. Ist dann alles i.O? Falls ja, dann würde ich mich langsam vorhangeln. :)

 

Gruß

Jan

Hi Jan, 

das werde ich mal sofort probieren. Aber die OU in der der Client drinne ist, war eh neu. Nur das ich dort GPOs im Nachhinein verknüpft habe.

Melde mich wieder 

Hi zusammen,

wir sind gerade dabei erste Tests für die Migration unserer Windows 7 Clients auf Windows 10 durchzuführen. 

Wenn ich einen Testclient in unsere Server 2008 R2 Domäne aufnehme, dann werden auf dem Client das Startmenü und die Infoleiste unbrauchbar, sprich in kann das Startmenü nicht öffnen und die Icons der Infoleiste haben auch keine Funktion mehr.

Ich habe versucht anhand dieser Anleitung https://www.deskmodder.de/wiki/index.php/Startmenü_reparieren_Windows_10 das Startmenü zu reparieren. Leider ohne Erfolg. 

Die ADMX Templates sind im Ordner PolicyDefinitons auf dem DC abgelegt. Ich habe auch eine Policy in einer eigenen OU angelegt mit der einige Startmenü Einträge angepasst werden sollten. Die Policy wird auf den Win10 Client bzw. auf den entsprechenden Test User angewendet. Aber das Ergebnis ist gleich. Das Startmenü lässt sich nicht öffnen.

Rechtsklick auf das Startmenü funktioniert.

Die Windows Firewall Einstellungen lassen sich ebenfalls auf dem Client nicht öffnen (nur als Hinweis)

Die Win 10 Test Maschine ist eine VM und hat die Versionsnummer 1809 Build 17763.107.

Hat vielleicht jemand einen Tipp wie ich das Problem lösen kann.

Bevor hier über unsere eingesetzte Server Version "gemeckert wird ;)" . Der Upgrade unserer Server auf mindestens Version 2016 ist in der Planung und wird auch umgesetzt. Aber die Clients werden voraussichtlich vorher auf Windows 10 umgestellt.

Besten Dank für eure Tipps.