Piszki Lab

Analiza przypadku w języku przodków…

Horizon Workspace: drobne problemy (od których można osiwieć).

| 0 comments

Konfigurując środowisko Horizon Workspace można się natknąć czasem na różne komunikaty, najczęściej wynikają one z tego, że zapomnieliśmy wykonać jakiś krok z dokumentacji. Niestety, gdy już to zrobimy, bardzo ciężko jest powiązać dany komunikat z pominiętą czynnością (np. nie włączoną opcją). W tym wpisie opiszę najczęściej występujące problemy i w miarę jak będę miał do czynienia z kolejnymi, będę je dopisywał do tej listy.

ERROR_NETNAME_DELETED

W trakcie rekonfiguracji jednej z maszyn connector-va, przy zmianie nazwy udziału sieciowego w którym rezydują aplikacje ThinApp, zaskoczył mnie błąd jak na rysunku poniżej.

herr1

Ewidentnie komunikat ten wskazuje na problemy z domeną AD, szybki risercz po Internecie i właściwa informacja zostaje znaleziona. U mnie zadziałała procedura bardziej rozbudowana:

1. Odłączenie maszyny od domeny

2. Restart maszyny connector-va

3. Usunięcie konta komputera w AD

4. Podłączenie maszyny do domeny AD

Przy ponownej rekonfiguracji udziału sieciowego błąd nie wystąpił.

herr2

CDS_HTTP_NOT_FOUND_ERROR

W trakcie uruchamiania Horizon Workspace Agent w logu odłożyły się następujące komunikaty:

CDS: Initializing a CDS updater client 1.0 for product agave, version 1.8.1
CDS: Fetching repository index from https://workspace.pulab.pl/cds/index.xml
VThreadBase detected multiple threads.
HOSTINFO 8639910073393 @ 14318180Hz -> 0 @ 1000000000Hz
HOSTINFO ((x * 2343484437) >> 25) + -603422367396236
CDS: Using NONE proxy (null):0 for https://workspace.pulab.pl/cds/index.xml.
CDS: Retrieved 10 X.509 certificates from system store
CDS: HTTP error 404 received!
CDS: Change client state to CDS_HTTP_NOT_FOUND_ERROR, 0 bulletins available
UPDATE CALLBACK:
isPerform = false
Result:
prodId:    agave
available: false
detail:    Failed to connect to update server: CDS_HTTP_NOT_FOUND_ERROR
success:   false
CDS: Failed to finish active transfer for https://workspace.pulab.pl/cds/index.xml: CDS_HTTP_NOT_FOUND_ERROR

Zero informacji w Internecie, ale łącząc fakty, można dojść do następującego wniosku – domyślna instalacja data-va nie zawiera plików instalacyjnych klientów Horizon Workspace!

Należy ściągnąć ze strony VMware.com z sekcji “Downloads/Horizon Workspace” plik zbiorczy klientów (np: clients-1.8.1-1751013.zip), wgrać na każdą data-va i zainstalować następującym poleceniem:

horr2

Opcja ta ma normalnie zastosowanie w momencie gdy musimy podnieść zbiorczo wersję zainstalowanych Agentów. Przy pierwszej instalacji Horizon Workspace powoduje komunikat jak wyżej (czyli nie jest krytyczny).

SC_FILE_COPY_ERROR

Current install mode = COPY_TO_LOCAL
Package #0 “pgAdmin III” {8A278A6F-F448-431D-A577-381BA73AC26F} not installed – installing
Copy failed for “pgAdmin III” (\\UGWSUS1\Workspace\pgAdmin_full\pgAdmin III.dat), SC_FILE_COPY_ERROR (Failed to copy file: Odmowa dostępu.)
Failed to install package file “pgAdmin III” (\\UGWSUS1\Workspace\pgAdmin_full\pgAdmin III.dat): SC_FILE_COPY_ERROR (Failed to copy file: Odmowa dostępu.)

Błąd wynika z braku uprawnień użytkownika do odczytania zawartości udostępnionego katalogu z aplikacjami ThinApp.

upr1

Wszystkim lub wybranej grupie użytkowników dajemy dostęp do katalogu zawierającego aplikacje ThinApp.

NTLM tokens cannot be used for authentication. Redirecting to login page.

Could not authenticate a user. Clearing session attributes. Not a valid kerberos token.

Nieprawidłowo skonstruowana sekwencja autentykacji. Zakładamy, że główną metodą jest Kerberos dla lokalnej sieci, a metoda autentykacji login/hasło dla dostępu z Internetu (lub awaryjna). W takim przypadku rozróżnienie następuje po adresie IP, dla wewnętrznych inna metoda, dla zewnętrznych inna. Na początku musimy stworzyć właściwy “Network Range”:

lan1

W kolejnym kroku ustalamy właściwą kolejność dla “Identity Providers”, tak aby pierwszą metodą był Kerberos:

lan2

lan3

lan4

Możemy też zmienić kolejność “Authentication Methods”, tak aby Kerberos był pierwszym i domyślnym trybem a login/hasło drugim.

lan5

Nie zapominamy też o prawidłowym skonfigurowaniu Internet Explorera, tak jak to jest opisane w punkcie 6.

Unable to get audit report.

horr5

Nieprawidłowy X-Forwarded-For (configurator-va). W rozbudowanych środowiskach czasem ciężko namierzyć ten właściwy adres IP z jakiego idzie komunikacja z Load Balancera do Horizon Workspace. Ale można to dość szybko sprawdzić zaglądając do logu, tym właściwym jest /opt/vmware/nginx/log/error.log w gateway-va:

horr6

Zaznaczony na czerwono adres należy do naszego serwera… proxy! Można też całkowicie wyłączyć sprawdzanie adresów IP, logujemy się do gateway-va i w pliku /opt/vmware/nginx/conf/location-443.conf znajdujemy sekcję AUDIT i maskujemy pierwsze trzy linie:

horr11

English

Oceń ten artykuł:
[Total: 0 Average: 0]

Dodaj komentarz

Required fields are marked *.