ciekawy przypadek – użytkownicy nie mogą zalogować się do serwera terminalowego, ponieważ sesja zawiesza się na przetwarzaniu polis grupowych. serwer w2k8R2.

kilka ciekawostek:

  • w eventlogu cisza. żadnych błędów
  • nawet część dot. group policy eventvwrapplications and servicesmicrosoftwindowsgrouppolicy nie zawiera żadnych błędów – biało.
  • spodziewałem się, że będzie widoczna sesja usera, jakieś dowiązanie do plików cokolwiek – nihuhu
  • w process explorer nie widać żadnych procesów użytkownika, który się loguje – to dość zrozumiałe i do przełknięcia
  • w RD Managerze widać tą sesję w dość specyficzny sposób – jako ‘disconnected’ i z nieokreślonym statusem, bez nazwy użytkownika. jedyna dostępna opcja to ‘reset’ i jak się można domyślać – nie działa. czyli jedna próba logowania i żeby user mógł się zalogować – restart serwera
  • RSoP nie działa – zwraca timeout
  • jak widać debugowanie jest dość upierdliwe. szczęśliwie szybko wpadłem na pomysł jak sobie z tym poradzić [w dużym środowisq by to nie wyszło q: ] i zlokalizowałem polisę, która powodowała zawieszanie – chodziło o polisę mapująca drukarki mechanizmem Group Policy Preferences.

    biorąc pod uwagę, że użytkownicy normalnie pracują a problem jest tylko na serwerze RDS, udało mi się dojść o co chodzi:

    • drukarka A została dodana via GPP na stacji lokalnej użytkownika
    • ta sama drukarka zawieszała przetwarzanie polis, ponieważ na serwerze terminalowym była równocześnie przemapowywana mechanizmem RDP oraz dodawana dokładnie tą samą polisą.

    robiło się jakieś sprzężenie zwrotne, serwer reagował w głupi sposób, zawieszając cały proces przetwarzania polis.

    rozwiązanie:

    • w GPP do mapowania drukarek został dodany warunek ‘nie uruchamiaj jeśli nazwa netbios komputer = <nazwa RDS>’

    pacjent uratowany.

    eN.