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
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.