limity dla sesji Remote Assistance
pojawiło się takie pytanie: czy da się ograniczyć liczbę kolorów i rozdzielczość przy sesji Remote Assistance?
nie udało mi się znaleźć bezpośredniej odpowiedzi tak/nie ale biorąc pod uwagę ten artykuł:
http://support.microsoft.com/kb/305898
oraz na podstawie tego, jak obsługiwane jest RDP – odpowiedź brzmi: nie, nie da się.
trochę dorabiając teorię do faktów, wynika to z tego, że jeśli sesja RA miałaby łączyć się z limitami – musiałyby one również zostać wprowadzona na stacji klienckiej. w innym przypadq wymagana byłaby ‘przebudowa’ całego mechanizmu, który na chwilę obecną działa [w dużym uproszczeniu] na zasadzie przekierowania strumienia obrazu. żeby możliwe było dwóch połączeń do tej samej sesji na dwóch różnych ustawieniach, wymagany byłby jakiś komponent pośredni, odpowiednio konwertujący w locie. w efekcie RA jest bardzo fajnym mechanizmem – jak się ma w miarę porządne łącza ):
*UPDATED*
jednak da się zmienić ilość kolorów – w każdym razie teoretycznie:
Q. Why does the color depth not match on both users’ computers?
A. Remote Assistance will detect if you have a dialup modem connection and reduce color depth to 8bit (256 colors). The color depth on the requestor’s screen is then sent to the helper to optimize performance.
ze strony wsparcia. pozostaje tylko znaleźć sposób jak zmusić RA żeby sądziło, że połączenie jest modemowe…
eN.
gdzie jest moja przestrzeń?
ciekawostka przyrodnicza: na serwerze kończy się miejsce na dysq. sprawdzam wielkość dysq – 33GB, sprawdzam zajętość katalogów przy pomocy explorera – wychodzi koło 16GB. ilość wolnego miejsca na dysq – bliska 0. o co c’mon?
jeszcze ciekawiej: dokładnie taka sama sytuacja jest na drugim dysq w tym serwerze. wychodzi na to, że zniknęło ok 4o%-5o% wszystkich dysqw – nie wiadomo gdzie i jak.
w pierwszej kolejności zadzwoniłem i zamówiłem nowe dyski do serwera. w między czasie trzeba sprawdzić o-co-cho.
dochodzenie
zacząłem od dość brzydkiej operacji – nadawania uprawnień do ‘zakazanych’ katalogów – system volume information, recycle bin i wszelkie inne systemówki, do których nie ma uprawnień a więc na pewno zostały wkalqlowane w sumaryczną wielkość. wszystkie miały pomijalną wielkość. to, czego się przy okazji dowiedziałem to to, że system sobie potem ładnie te katalogi ‘reperuje’ przywracając im po jakimś czasie [restart?] uprawnienia. ufff… przynajmniej sie nie rozjechał (;
kolejny strzał – shadow copy lub restore points. w w2k8 (R2) nie ma dostępnej opcji/zakładki Restore Points. próbowałem na siłę sprawdzić korzystając z rozwiązania z http://www.win2008workstation.com/forum/viewtopic.php?p=4301#p4301. zakładka pojawia się co prawda – ale wywala się z błędem. niemniej można to sprawdzić nieco bardziej ‘legalnie’:
ponieważ restore point jest ‘migawką’ shadow copy – powinien być zapis o niej w systemie. w związku z tym powinno dać się to sprawdzić przy pomocy vssadmin
PS C:> vssadmin.exe list shadows
vssadmin 1.1 – Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001-2005 Microsoft Corp.
No items found that satisfy the query.
pupa. nie muszę w związq z tym dodawać, że sama funkcjonalność previous versions jest wyłączona. zaczynam zabawę z alternatywnym badaniem wielkości katalogów – czyli powershell. znalazłem fajny art krok-po-kroq wyjaśniający jak do tego podjeść. nie jest miłe i tak proste, jak bym się tego spodziewał – ale działa (: no i kilka fajnych tipsów PS przyda się na przyszłość:
"{0:N2}" -f ((Get-ChildItem ’.program files (x86)’ -recurse | Measure-Object -Property length -sum).sum / 1GB ) +" GB"
nie bez powodu pokazuję od razu ten katalog – ponieważ to właśnie on okazał się być złodziejem przestrzeni. jeszcze troszkę bardziej rozbudowana składnia do reqrencyjnego odpytania i jest winny!
PS C:Program Files (x86)> get-childitem | %{"$_ size: "+ "{0:N2}" -f ((Get-ChildItem $_ -recurse | Measure-Object -Property length -sum).sum / 1GB )+" GB"}
[…]
Microsoft Configuration Manager size: 18,32 GB
[…]
explorer pokazuje dla tego katalogu znaczną różnicę w wielkości: 0B (słownie – zero bajtów). na drugim dysq sprawca jest ten sam – repozytorium SCCM i katalog SMSPKG.
dyski właśnie przyszły – a więc czas na kolejne hardtesty – jak przerzucić cały system na nowe dyski. spróbuję windows backup…
**UPDATED**
pozostaje pytanie – czemu explorer nie pokazuje wielkości niektórych katalogów. i tutaj odpowiedzią jest moja najulubieńsza, taka jej mać, funkcja – UAC. ma to związek ze starszym wpisem. ktoś mógłby stwierdzić, że to nie wina UAC tylko explorera – którego nie da się [normalnie] odpalić z tokenem administratora. powershell potrafił zliczyć wielkości, ponieważ był właśnie z nim uruchomiony. prawie na pewno – gdybym zamiast explodera używał jakiegoś menadżera plików firmy trzeciej – również zliczyłby katalogi prawidło. imho jednak takie rzeczy stanowią integralną część systemu i powinny być przemyślane w całości – jako spójna platforma. no nic – po prostu dodaję nową zasadę: “nie używaj explorera na serwerze z UAC”.
druga kwestia – jeszcze do zbadania – to z jakiej racji SCCM tak pożarł miejsce.
eN.