Gdzie znaleźć kto instalował aplikację na danym serwerze

Czasami, gdy jednym serwerem zarządza kilka osób, może zdarzyć się, że trzeba dokładnie ustalić kto spartolił sprawę zainstalował jakieś oprogramowanie – np. nowszą wersję softu do wspomagania drukowania, na którą nie mamy jeszcze licencji. Pomocne w określeniu tego faktu są logi z Windows Servera. Znajdują się one w:

Event viewer -> Windows Logs -> Application

Aby dowiedzieć się kto zainstalował dany soft i o jakiej godzine szukamy zdarzenia nr 11707:

Zrzut okna z event 11707

Jeśli natomiast chcesz się dowiedzieć kto odinstalował jakąś aplikację to musisz szukać zdarzenia o numerze 11724:

Gdzie znaleźć log z instalacji urządzeń

Jeśli potrzebujesz znaleźć log kiedy i jakie urządzenia zostały zainstalowane w Windowsie to należy szukać takich informacji w pliku:

C:\Windows\inf\setupapi.dev.log

Jest tam opisane praktycznie wszystko co potrzebujesz:

  • kiedu dokładnie było instalowane (Boot session)
[Boot Session: 2017/03/14 01:03:21.428]
  • co było instalowane (Import Driver Package w wypadku instalacji z folderu Windows albo inny folder jeśli uruchamiałeś instalator zewnętrzny – np. dostarczony przez producenta drukarki HP czy innego Ricoha)
sto: Staging all driver updates.
sto: {Import Driver Package: C:\Windows\WinSxS\amd64_wvms_pp.inf_31bf3856ad364e35_6.1.7601.23677_none_c157295e214db25d\wvms_pp.inf} 09:55:46.685
 sto: Importing driver package into Driver Store:
 sto: Driver Store = C:\Windows\System32\DriverStore (Online | 6.1.7601)
 sto: Driver Package = C:\Windows\WinSxS\amd64_wvms_pp.inf_31bf3856ad364e35_6.1.7601.23677_none_c157295e214db25d\wvms_pp.inf
 sto: Architecture = amd64
 sto: Locale Name = neutral
 sto: Flags = 0x00000245
 inf: Opened INF: 'C:\Windows\WinSxS\amd64_wvms_pp.inf_31bf3856ad364e35_6.1.7601.23677_none_c157295e214db25d\wvms_pp.inf' ([strings])
 inf: Opened INF: 'C:\Windows\WinSxS\amd64_wvms_pp.inf_31bf3856ad364e35_6.1.7601.23677_none_c157295e214db25d\wvms_pp.inf' ([strings])
 sto: Importing driver package files:
 sto: Source Path = C:\Windows\WinSxS\amd64_wvms_pp.inf_31bf3856ad364e35_6.1.7601.23677_none_c157295e214db25d
 sto: Destination Path = C:\Windows\System32\DriverStore\FileRepository\wvms_pp.inf_amd64_neutral_602cbe52ca72742e
  • jakie pliki kopiowane. skąd i gdzie (SourceRootPath, SourceFileName, TargetDirectory):
 flq: {FILE_QUEUE_COPY}
 flq: CopyStyle - 0x10000000
 flq: SourceRootPath - 'C:\Windows\WinSxS\amd64_wvms_pp.inf_31bf3856ad364e35_6.1.7601.23677_none_c157295e214db25d'
 flq: SourceFilename - 'vmswitch.sys'
 flq: TargetDirectory- 'C:\Windows\System32\DriverStore\FileRepository\wvms_pp.inf_amd64_neutral_602cbe52ca72742e'
 flq: {FILE_QUEUE_COPY exit(0x00000000)}
  • czy skończyło się sukcesem (Exit status)
 sto: Imported driver package into Driver Store:
 sto: Filename = C:\Windows\System32\DriverStore\FileRepository\wvms_pp.inf_amd64_neutral_602cbe52ca72742e\wvms_pp.inf
 sto: Time = 78 ms
 sto: {Import Driver Package: exit(0x00000000)} 09:55:46.763
<<< Section end 2017/03/27 09:55:46.763
<<< [Exit status: SUCCESS]

Instalacja .NET Framework w Windows 10

Spotkałem się wiele razy z problemem instalacji .NET Framework w wersji 3.5 na stacji, która jest w domenie. Zawsze podczas próby instalacji – czy to z poziomu Dodaj/usuń funkcje Windows czy podczas instalacji innego softu, który potrzebuje właśnie tego .NET do działania, wyskakiwał błąd 0x800F0906 oznaczający, że Windows nie może dokończyć instalacji ponieważ nie może znaleźć plików do instalacji.

Rozwiązaniem tego problemu jest zmiana lokalnych zasad grupy (gpedit.msc) dla danej stacji:

1. Uruchom edytor lokalnych zasad grupy (gpedit.msc)
2. Wybierz gałąź Konfiguracja komputer -> Szablony administracyjne -> System
3. Zmień opcję „Określ ustawienia instalacji składników opcjonalnych i naprawy składników” na „włączone” i zaznacz dolną opcję „Pobierz zawartość naprawczą i funkcje opcjonalne bezpośrednio z usługi Windows Update (a nie z programu Windows Server Update Services)”, następnie zaakceptuj.
4. Wejdź w Programy (appwiz.cpl)
5. Z lewej strony okna wybierz „Włącz lub wyłącz funkcje systemu Windows”.
6. Zaznacz kwadracik z „.NET Framework 3.5”

7. .NET powinien się zainstalować.

Innym rozwiązaniem może być również poniższa komenda, ale zakłada ona, że masz przygotowany już nośnik (zmień na odpowiednią literkę zamiast F:) z instalką Windows 10. Pierwsza metoda wydaje mi się jednak prostsza.

DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:F:\sources\sxs

 

Zmiana przeglądarki zdjęć w Windows 10

Aplikacja Zdjęcia w Windows 10 jest… fatalna. Dla jasności mówię o tym czymś:

Nie dość, że działa masakrycznie wolno, to jeszcze nie ma wszystkich tych funkcji, które posiadał poprzednik znany z Windows 7 – Przeglądarka fotografii systemu Windows – która dla przypomnienia wyglądała tak:

Można na szczęście tę nowość zastąpić sprawdzonym i dobrym rozwiązaniem. Aby tego dokonać, należy:

1. Ściągnąć załączone plik .reg i uruchomić go jako administrator lub alternatywnie, gdy jesteśmy zalogowani na koncie zwykłego użytkownika, uruchomić regedit jako administrator i zaimportować wspomniany plik.
2. W eksploratorze Windows znaleźć jakiś plik z obrazem, który chcemy otwierać w starej przeglądarce, kliknąć na nim PPM i wybrać „Otwórz za pomocą” – „Wybierz inną aplikację” i z listy rozwijalnej wybrać „Przeglądarka fotografii systemu Windows”.

Testowane na najnowszym obecnie na tę chwilę oficjalnym buildze – 1607 (Anniversary Update).

 

Dostęp do bazy danych vPosgreSQL w VCSA 6.0

Załóżmy, że pewnego dnia zjawi się u Ciebie w firmie Pan z firmy, która zlicza licencje Microsoft. Ot, tak – żeby sprawdzić czy na te wszystkie licencje masz odpowiednie papiery. Podczas tych prac będzie chciał się połączyć z pewnością również do serwerów VMware’a, na których hostujesz systemy z rodziny Windows Server. Do tych serwerów, na których jest baza VMware’owa oparta o MSSQL nie powinieneś mieć problemu się dostać. Równie dobrze możesz mieć jednakże Vcenter postawione na Linuksie – nazywa się to-to VCSA i tam jest już baza PostgreSQL dostosowana przez VMware’owych inżynierów na swoje potrzeby i przemianowana na vPostgre. Jak się do niej dostać?

Poniższy przykład pokazuje sposób dostania się do VCSA 6.0, czyli Vcenter 6.0 ale zapewne zadziałają też na 5.5:

Pierwszym krokiem będzie zalogowanie się przez SSH do VCSA (właśnie tam, nie do jednego z ESXi) jako root – konto tutaj jest istotne. Następnie wydanie polecenia

shell.set --enabled true

a następnie:

shell

Dzięki temu dostaniemy sie do normalnej powłoki, gdzie będziemy mogli wykonywać normalne linuksowe polecenia zupełnie jak w starszych wersjach VCSA.

Dostanie sie do shella na VCSA 6.0

2. Musimy teraz poznać usera oraz hasło do bazy VMware’owej. Aby to zrobić należy podejrzeć plik /etc/vmware-vpx/vcdb.properties, w którym wszystko jest zapisane jawnym tekstem… :

cat /etc/vmware-vpx/vcdb.properties

Podgląd usera oraz hasła do bazy vPostgre

3. Kolejnym punktem będzie zmiana konfiguracji pliku /storage/db/vpostgres/pg_hba.conf, gdzie zapisane są miejsca, z których można łączyć się do bazy danych PostgreSQL:

vim storage/db/vpostgres/pg_hba.conf

Znajdź linijkę, gdzie widnieje wpis:

host   all      alll      <<<   0.0.0.0/0 >>>      md5

Ten zakres 0.0.0.0 /0 świadczy o tym skąd możemy się łączyć do bazy przez dany interfejs. Jeśli dla interfejsu ipv4 zmienimy ten wpis na właśnie 0.0.0.0/0, to będziemy mogli połączyć się zewsząd:

Edycja pliku pg_hba.conf

Kolejny krok to wskazanie na jakim adresie będzie trwało nasłuchiwanie przychodzących połączeń. Konfiguruje się to w pliku posgtresql.conf w tym samym folderze:

vim storage/db/vpostgres/postgresql.conf

Najlepiej chyba posłużyć się gwiazdką:

Na koniec jeszcze restart usługi i połączenia przychodzące powinny już działać bez problemu:

/etc/init.d/vmware-vpostgres restart

 

 

Zmiana edycji Windows Server 2008R2

Zakupiliśmy niedawno edycje Windows Server 2008R2 DataCenter, aby pokryć zapotrzebowanie na licencje na wirtualizatorach. Ogólnie chodzi o to, że jeśli posiadasz jakąś farmę np. VMware albo Hyper-V i chcesz przerzucać maszyn wirtualne między nimi, to na każdej z nich musi być dodatkowa licencja Windows Server DataCenter. To jest, jeśli chcesz mieć możliwośc migracji VM z hosta na inny host częściej niż raz na 90 dni – nie ja to wymyslałem. Wszystko jest zgrabnie opisane tutaj.

Wracając do meritum – chciałem sobie zmienić po prostu klucz na Windows Server 2008R2 Standard na ten od DataCenter ale oczywiście okazało sie, że to nie takie proste.

  1. Po pierwsze – wbity klucz od DataCenter nie podobał się aktualnej wersji Windows Servera (Standard), co w sumie jest nawet logiczne – dlaczego klucz od DataCenter miałby pasowac do Standard?

The product key you have entered will not work with this edition of Windows Server 2008 R2. You must run Windows Server 2008 R2 Setup or enter a Windows Server 2008 R2 Standard product key.

      The product key you have entered will not work with this edition of Windows Server 2008 R2.
    You must run Windows Server 2008 R2 Setup or enter a Windows Server 2008 R2 Standard product key.

2. Trzeba zatem zmienić jakoś Standard na DataCenter – zacząłem googlować i znalazłem tę oto stronę, gdzie jest opisane jak tego dokonać. Należy przy tym pamiętać, że działa to tylko w górę (a jakże) – nie można zrobić downgrade’u edycji, np. z DataCenter z powrotem na Standard.

3. Przed zmianą edycji W2K8R2 wg wskazówek ze strony powyżej sprawdziłem jeszcze czy na pewno mam właściwą edycję zainstalowaną i jakie mam możliwości jej zmiany. Zrobiłem to poleceniem

DISM /online /Get-TargetEditions

Wypluło, że i owszem – mogę zmienić Standard – na Enterprise lub DataCenter:

Sprawdzanie możliwości upgrade'u edycji

4. Długo się nie namyślając wklepałem polecenie, który miał aktywować wersję DataCenter podając przy tym mój klucz, który dostaliśmy od Microsoft:

Zmiana edycji z podaniem klucza - błąd 1605

5. Jak widać Windowsowi coś się bardzo nie spodobało i wypluł błąd 1605 (Error: 1605. This specified product key is not valid for the target edition. Run this command again with a product key specific to the target edition.). Czyli każe mi wpisać klucz produktu docelowego, na który chcę podnieść. Czekaj, przecież właśnie to mu  podałem… Potrzebuję więcej  google’a…

6. Rozwiązaniem okazało się podanie klucza tymczasowego, który znalazłem na stronie Microsoftu:

Windows Server 2008R2 DataCenter:
74YFP-3QFB3-KQT8W-PMXWJ-7M648

Podstawiając go do polecenia z punktu 5 udało mi sie pomyślnie zmienić wersję Windows Servera 2008 R2 z Standard na DataCenter. Zatem polecenie do zmiany na klucz tymczasowy brzmi:

DISM /online /Set-Edition:ServerDataCenter /ProductKey:74YFP-3QFB3-KQT8W-PMXWJ-7M648

7. Ostatni krok to restart systemi i zmiana klucza z wersji KMS-owej na nasz zakupiony. Odbyło się już bez problemów i po wstukaniu klucza w panelu sterowania -> System i restarcie miałem aktywowane DataCenter:

Windows activation successfull

Szablony administracyjne Windows 10

Microsoft wydał szablony administracyjne dla Windows 10. Przypominam, że aby móc z nich skorzystać, należy wgrać pliki *.admx do Central Store’u (o ile z takowego korzystacie), czyli  \\nazwa_domeny\SYSVOL\nazwa_domeny\Policies\PolicyDefinitions\, a pliki różnych wersji językowych *.adml do odpowiednich folderów. np. dla serwera w języku angielskim do folderu  \\nazwa_domeny\SYSVOL\nazwa_domeny\Policies\PolicyDefinitions\EN-US.

Po wgraniu nowych polityk może Was uraczyć podczas otwierania jakiejkolwiek polityki GPO komunikat  o treści „Namespace ‚Microsoft.Policies.Sensors.WindowsLocationProvider’ is already defined as the target namespace for another file in the store.”

store-err

Jak podaje producent wyjścia są dwa:

1. Olać błąd i pracować dalej (trochę słabe)
2. Skasować z Central Store’u plik „LocationProviderADM.admx” oraz wszelkie jego wersje językoweo („LocationProviderADM.adml”), a następnie zmienić nazwę „Microsoft-Windows-Geolocation-WLPAdm.admx” na LocationProviderADM.admx. Tak samo postąpić z wersjami językowymi (*.adml).

Aktualizacja systemu do Windows 10 w domenie

Załóżmy, że chcesz uaktualnić system operacyjny do Windows 10 (darmowe przez najbliższy rok, potem trzeba płacić) ale nie dostałeś w zasobniku systemowym ikonki powiadamiającej o możliwości wgrania nowej wersji. Jeśli jest to komputer w domenie to nic dziwnego, że tej ikonki nie widzisz – Microsoft z założenia nie opublikował tej poprawki dla systemów będących w domenie aby firmy mogły się spokojnie przygotować do migracji na nowy system bez marudzących zewsząd o upgrade użytkowników („Dlaczego on ma nowy system a ja jeszcze nie?”).

Na szczęście uaktualnienie systemu do Windwos 10 na komputerze w domenie jest banalnie proste. Wystarczy ściągnąć plik MediaCreationToolx64.exe lub MediaCreationToolx32.exe – w zależności od architektury CPU ze strony Microsoft i go uruchomić. Cały proces przebiega bardzo gładko, przynajmniej z systemu Windows 8.1, bo taki miałem wcześniej. Ale czytając opinie innych ludzi w necie z Win7 również nie powinno być problemu. Na stacji miałem zainstalowaną Javę, Office 2013, kilkanaście innych programów i wszystko to działa bez problemu po aktualizacji systemu. Poniżej porcja zrzutów prezentujących proces uaktualnienia.

updatedo10-1

 

updatedo10-2

updatedo10-3

updatedo10-4

updatedo10-5

 

updatedo10-6

 

updatedo10-7

 

updatedo10-8

 

Na koniec kilka spraw, o których należy pamiętać zanim zrobi się upgrade do Win 10:

1. Nie wypuszczono jeszcze RSAT dla Win 10, dlatego jeśli potrzebujecie tego na swojej stacji, to wstrzymajcie się z uaktualnieniem.

2. Niektórzy producenci sprzętu nie wypuścili jeszcze sterowników dla tego systemu (chociaż taki Dell już to zrobił). Na przykład na moim HP przestała działać klawiatura funkcyjna (z klawiszem FN) i muszę czekać na nową wersję sterowników.

3. OneDrive niestety nie działa tak jak wcześniej w Win 8.1 i Win 7 – w tej chwili wybiera się po prostu foldery, które mają być synchronizowane z chmurą i są one ściągane na dysk czy się tego chce, czy nie. Nie ma już opcji, że plik jest offline (na stacji) albo online (w chmurze). Jest to zdecydowanie krok w tył ale być może poprawią to w przyszłych aktualizacjach.

4. Albo mi się wydaje albo pozmieniały się nieco opcje prywatności, jakie oferuje nam Microsoft przy instalacji systemu. Nie pamiętam dokładnie jak to było w Windows 8 ale wydaje mi się, że tam domyślnie Microsoft nie chciał za dużo wiedzieć o swoich użytkownikach, tj. wszystkie te opcje dotyczące prywatności (a może większość) była wyłączona. Za to w Windows 10 jest – zdaje się – odwrotnie i wszystko jest zaznaczone jako „zgoda”. Czyli domyślnie idzie w cholerę informacji na temat publicznych sieci wifi, informacji o użytkownikach na komputerze, zainstalowanym oprogramowaniu, etc. Widzę zresztą, że serwis ExtremeTech.com podziela moje obawy co do prywatności użytkownika.

5. Po instalacji systemu warto oczyścić stare pliki z systemu żeby pozbyć się zawartości folder Windows.old. Na moim komputerze zwolniło się około 20 GB miejsca, więc warto. Wystarczy wejść we właściwości dysku C:\. a następnie wybrać opcję „Oczyszczanie dysku”, a następnie znowu „Oczyść pliki systemowe”. Wystarczy wybrać „Pliki starego systemu” i poczekać aż Windows skasuje to, czego już nie potrzebuje.

Poniżej zrzuty ekranu:

oldwin1

oldwin

Aktualizacja kontrolera Cisco WLC 2504

Aktualizacja kontrolera Cisco WLC 2504 nie jest zbyt trudna do wykonania, wymaga jednak dość solidnego i czasochłonnego przygotowania.

1. Dodać kontrakt na stronie cisco.com, by można było ściągnąć najnowszy soft dla kontrolera. Jeśli nie masz konta na cisco.com to spytaj o to dostawcę sprzętu, od którego kupiłeś kontroler – powinni pomóc. Następnie ustalić ścieżkę upgrade’u: nie wgrywaj „na pałę” najnowszej dostępnej wersji, bo może się okazać, że jest ona niedostosowana do danego kontrolera, lub należy zrobić najpierw upgrade pośredni.

Pamiętaj również, że jeżeli masz rozwiązanie do zarządzania sieciami typu Cisco NCS (obecnie zastąpione przez Cisco Prime), to aktualizacje kontrolerów również są wspierane do którejś wersji. Najnowsza możliwa może nie zadziałać w NCS, a upgrade do Prime niestety nie jest darmowy.

2. Ustalić z biznesem o jakiej porze i przez jak długi czas nie będzie dostępna sieć bezprzewodowa.

3. Zgrać backup konfiguracji używając serwera FTP. Można użyć postawionego u siebie serwera albo posłużyć się prostym programem typu Open TFTP Server i postawić tymczasowy serwer na swoim laptopie.

Aby zgrać aktualną konfigurację, należy:

– wejść w menu Commands
– z menu z lewej strony wybrać „Upload file”
– wpisać adres serwera FTP/TFTP, do którego chcemy zgrać konfigurację, podać login/hasło i nadać nazwę dla pliku
– wcisnąć przycisk Upload

Po chwili powinniśmy mieć na serwerze FTP plik z konfiguracją. W moim przypadku plik miał wielkość ~18 KB:

blog1_09

4. Opcjonalne: wyłączyć sieci WiFi na kontrolerze (przejść do WLANs, zaznaczyć wszystkie SSID-y, a następnie z menu po prawej stronie wybrać „Disable Selected”.

5. Wrócić do „Commands”, ale tym razem do „Download File”, z listy wybrać „Code” i wybrać sposób, w jaki kontroler ściągnie plik z nowszym firmware. Następnie kliknąć „Download” w prawej górnej części strony. Powinien pojawić się poniższy komunikat:

blog1_01

 

Następnie będzie kilka kolejnych komunikatów o aktualizacji oprogramowania, jak:

Writing new RTOS to flash disk.
Writing new APIB to flash disk.
Executing fini script.

… i jeszcze masa innych, których nie zdążyłem zobaczyć.

Ostatnim etapem wgrywania powinien być komunikat:

FTP File transfer is successful. Reboot the controller for update to complete. Optionally, pre-download the image to APs before rebooting to reduce network downtime.

blog1_06

6. Tak więc restartujemy kontroler, jak nam kazano: wchodzimy w Commands -> Reboot. Z dwóch dostępnych opcji musimy wybrać „Save and Reboot”, po czym oczywiście stracimy łączność z kontrolerem.

7. Opcjonalnie: po nawiązaniu łączności z kontrolerem należy włączyć sieci WiFi (analogicznie do kroku 4).

W moim konkretnym przypadku kontroler wstał po około dwóch minutach. Na wgranie softu na AP-ki trzeba było poczekać kilka kolejnych minut, przy czym pod tym kontrolerem miałem dwie lokalizacje połączone WAN-em (tryb H-Reap). Mimo to, wszystko poszło jak z płatka i po ok. 5 minutach można było się połączyć z sieciami WiFi. Całość operacji zajęła około 30-45 minut ale to tylko dlatego, że robiłem to po raz pierwszy i za każdym razem posiłkowałem się instrukcjami. Zdecydowanie więcej czasu zajmuje zrozumienie ścieżki upgrade’u, dodanie kontraktu do konta na cisco.com i pościąganie firmware’ów.

 

 

Aktualizacja Adobe Flash Player na bieżąco

Jak wiadomo, Adobe Flash Player jest w ścisłej czołówce, jeśli chodzi o znalezione podatności i potencjalne źródła wejścia do stacji zdalnej. Najlepiej świadczą o tym wydawane co chwilę poprawki do rzeczonego oprogramowania oraz lista podatności. Dotychczas radziłem sobie z uaktualnianiem Playera poprzez soft pozwalający mi zdalne instalowanie wcześniej przygotowanych paczek .msi. Fakt – przygotowanie takiej paczki chwilę zajmuje ale da się to jeszcze przeżyć – tak przynajmniej myślałem jeszcze miesiąc temu. Miarka przebrała się, gdy w ciągu ostatniego tygodnia czy dwóch Adobe wydało 3 wersje Playera, każda kolejna łamana w przeciągu kilku dni. Stwierdziłem w końcu, że mam dość zdalnej instalacji i czas wykorzystać funkcję atuo-aktualizacji, którą Adobe Flash Player przecież posiada.

Zacząłem nieco czytać i google’ować i oto do czego doszedłem. Aby update Adobe Flash Player sam aktualizował oprogramowanie na stacji musi być:

  1.  Folder C:\Windows\System32\Macromed\Flash (Windows x32) lub C:\Windows\SysWOW64\Macromed\Flash (Windows x64), w którym znajdują sie co najmniej dwa pliki:
    FlashPlayerUpdateService.exe
    oraz
    mms.cfg
    Zasada działania jest bardzo prosta: system odpala usługę z pliku .exe, która patrzy na plik konfiguracji (.cfg) i postępuje z instalacją lub nie. W pliku mms.cfg wystarczą dwie linijki tekstu:
    AutoUpdateDisable=0
    SilentAutoUpdateEnable=1
  2. Zadanie w harmonogramie zadań, które odpala usługę aktualizacji. Dla ułatwienia można stworzyć sobie przykładowe zadanie na jednej ze stacji, a następnie rozpowszechnić ją na innych stacjach poprzez funkcję Import/Eksport Harmonogramu Zadań.
    Trzeba pamiętać tylko o dwóch rzeczach:
    –  Akcja zadania będzie się różnić na x32 oraz x64 systemach – plik usługi jest gdzie indziej umiejscowiony.
    – Najlepiej, by zadanie było odpalane przez konto stacji, na której jest instalowana poprawka, czyli konto „SYSTEM”.
    Pozostałe ustawienia są w zasadzie bez znaczenia – możemy na przykład ustawić odpalanie usługi co godzinę każdego dnia. Adobe zapewnia, że usługa jest bardzo mało zasobożerna i zamyka się natychmiast po odpaleniu i sprawdzeniu dostępnych aktualizacji. Z moich obserwacji wynika, że tak faktycznie jest.

Zastanawiałem się też czy nie wyłączyć tego cholerstwa w ogóle albo nie zabezpieczyć się przed wykonywaniem niebezpiecznych skryptów przez wykorzystanie technologii „Click to play” ale niestety napotkałem opór ze strony biznesu. Jak zwykle zresztą.