VirtualBox – nie można usunąć migawki

Taka sytuacja: masz na dysku maszynę wirtualną w VirtualBox wraz z wykonaną migawką. Migawka ta już nie jest potrzebna więc chcesz ją usunąć żeby odzyskać miejsce na swoim dysku i tutaj pojawia się błąd:

Nie udało się usunąć migawki „” maszyny wirtualnej „”

Not enough free storage space. E_OUTOFMEMORY (0x0807000E)

Jednym słowem: chcesz odzyskać miejsce na dysku, a nie możesz bo nie da się skasować migawki, bo nie masz wystarczająco dużo miejsca na dysku, bo nie możesz skasować migawki 🙂 Jeśli spróbujemy na chama usunąć migawką to oczywiście nie skończy się to dobrze, VirtualBox wyświetli nam niemiły komunikat, że możemy się cmoknąć:

Próba uruchomienia maszyny wirtualnej bez pliku migawki

Jest jednakże jeden sposób by sobie z tym problemem poradzić – trzeba oszukać VirtualBox za pomocą linku symbolicznego i przekonać go, że plik z migawką jest na dysku lokalnym mimo, że fizycznie przenieśliśmy go na inny. W przypadku poniżej przeniosłem migawkę na inny dysk. Dokładna ścieżka to D:\Snapshots\ I według tego zrobimy link symboliczny uruchamiając to polecenie z cmd/PS:

C:\users\korbuttz\VirtualBox VMs\VM\mklink /J Snapshots "D:\Snapshots"

dostaniemy komunikat:

Junction created for Snapshots <<===>> D:\Snapshots  

W eksploratorze pojawi się folder, którego ikona będzie wyglądała jakby był to zwykły link, we właściwościach będzie jednakże widać, że jest to folder. Dla porównania założyłem skrót o tej samej nawie i otworzyłem właściwości zarówno skrótu, jak i podlinkowanego folderu:

Różnica między linkiem, a skrótem

Po tej małej zmianie uruchomiłem normalnie maszynę wirtualną i mogłem z niej korzystać, a migawka cały czas siedziała sobie na innym dysku.

Tak samo usunięcie migawki również poszło bez problemu i wcale nie musiałem nawet czekać tyle lat:

Monitorowanie hostów ESXi w CheckMK

Co należy zrobić aby monitorować hosty w CheckMK? Dowiecie się z tego poradnika.

Przede wszystkim należy wiedzieć, iż można monitorować nasze serwery ESXi na kilka sposobów:

  1. Przez zwykłe SNMP
  2. Przez specjalnego agenta wbudowanego w każdą wersję CheckMK
  3. Przez Vcenter

W tym wpisie opiszę opcję 2 i 3 ponieważ oferują one o wiele więcej informacji niż opcja 1 i taką również zalecam Wam przybrać metodę monitorowania.

Aby skonfigurować monitorowanie hostów ESXi przez CheckMK należy:

  1. Utworzyć użytkownika z prawami Read-only na każdym z hostów ESXi. Uwaga – jedyny sposób jaki znalazłem, by dodać usera do hosta ESXi to skorzystanie z nierozwijanego już Vsphere Client w c++. Z netu można wyczytać, że można się również posłużyć PowerCLI ale tego akurat nie próbowałem. W każdym razie, po zalogowaniu się do hosta w kliencie Vsphere Client, wchodzimy w zakładkę Users i wybieramy „Add…”:

2. Przejść do zakładki „Permissions” i nadać nowo utworzonego kontu uprawnienia tylko do czytania przez kliknięcie PPM i wybranie „Add Permission…” -> następnie „Add” -> znajdujemy naszego nowo założonego użytkownika -> znowu „Add” żeby wskoczył na listę niżej i na koniec dajemy „OK”:

Z prawej strony okna w „Assigned role” wybieramy „Read-only” (powinno być zaznaczone domyślnie) i upewniamy się, że na dole zaznaczone jest „Propagate to Child Objects”:

3. UWAGA! Używam wersji 1.5.0p7 CheckMK, w innych wersjach może się to nieco różnić. W CheckMK wchodzimy z menu WATO do „Host & Service Parameters” -> „Datasource programs”:

5. W polu „Search” wyszukujemy regułę dotyczącą serwerów ESX wpisując po prostu frazę „esx” – powinno nam znaleźć „Check state of VMWare ESX via vSphere” – jak widać ja już jedną mam utworzoną, u Was będzie to zapewne „0”:

6. Wchodzimy w edycję reguły klikając w nią i ustawiamy jakiego konta chcemy użyć do monitorowania (oczywiście to jest właśnie to, które tworzyliśmy w poprzednich punktach) oraz co dokładnie chcemy monitorować. Ja używam takich ustawień:

7. Co dokładnie widać w monitorowanym hoście ESX? Ano na przykład zużycie CPU, RAM, datastore’ów, zajętość filesystemów, czujniki hardware – czy są jakieś alerty na nich, podniesione interfejsy sieciowe, czy host jest w Maintenance Mode czy uptime.

Nie można skonsolidować dysku – DISKLOCKED albo msg.fileio.lock

Jedna z maszyn wirtualnych zgłasza konieczność skonsolidowania dysku:

Niestety proste kliknięcie „Consolidate” nie pomaga z powodu błędu „msg.snapshot.error-DISKLOCKED”:

Postanowiłem najpierw przenieść maszynę wirtualną na inny host i tam spróbować ponownie konsolidacji – nie udało się. Następnie spróbowałem wykonać snapshota i go usunąć (udało się), a następnie zrobić konsolidację – również nie zadziałało. Tym razem jednakże error już był inny:

W szczegółach błędu dowiadujemy się, że nie można uzyskać dostępu do pliku (maszyny wirtualnej) ponieważ jest ona w trybie „Locked” – zablokowanym. Jak wynika z tego linka – maszyn wirtualna może być zablokowana w ten sposób z powodu tego, że jeden z ESX nadal „trzyma” nad plikiem tej maszyny pieczę. Zazwyczaj jest to efekt przyblokowania go przez narzędzie do tworzenia backupów – podczas wykonywania kopii soft blokuje sobie dostęp do pliku maszyny wirtualnej i „wypuszcza” go gdy skończy backupować plik. Niestety czasami nie zrobi tego do końca poprawnie i wtedy powstaje rzeczony błąd.

Rozwiązań tego problemu jest kilka, ja akurat skłoniłem się ku najbardziej drastycznemu czyli wyłączeniu wszystkich maszyn wirtualnych i zrestartowanie wszystkich wirtualizatorów (ESXi). Akurat wypadał i tak termin cyklicznego restartu hostów więc czemu nie. W ten sposób upewniłem się, że wszelkie blokady zostały ucięte przez system operacyjny oraz, że wszelkie dostępy zostały wycięte. Po tej operacji mogłem już spokojnie skonsolidować plik i alert zniknął. Jeśli ktoś nie ma luksusu restartu wszystkich hostów ESXi może zlokalizować, który konkretnie z nich trzyma „lock” na pliku maszyny wirtualnej i zrestartować na tym jednym usługę hostd – to powinno pomóc. Trzeba jednakże pamiętać, by wcześniej zmigrować z niego wszelkie maszyny wirtualne na inne hosty. Myślę jednak, że skoro już trzeba zwolnić host z maszyn wirtualnych to lepiej od razu zrestartować go całego żeby system się nieco odświeżył bo kto wie co tam się jeszcze zablokowało wewnątrz?

Brak przypisywanych licencji RDS

Sytuacja: po migracji serwera licencji z Windows Server 2008R2 na Windows Server 2012R2 w RD Licensing Manager nie widać przypisywanych licencji dla użytkowników logujących się na serwery przy użyciu RDP. W logach pojawia się błąd:

Event 4105, TerminalServices-Licensing:

The Remote Desktop license server cannot update the license attributes for user "xxxxxx" in the Active Directory Domain "xxxxxx.com". Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain "polski-cukier.pl".
If the license server is installed on a domain controller, the Network Service account also needs to be a member of the Terminal Server License Servers group.
If the license server is installed on a domain controller, after you have added the appropriate accounts to the Terminal Server License Servers group, you must restart the Remote Desktop Licensing service to track or report the usage of RDS Per User CALs.
Win32 error code: 0x80070005

W samym logu polecają sprawdzić 3 rzeczy:

  • upewnić się, że serwer, na którym postawiliśmy RD Licensing Managera należy do grupy „Terminal Server License Servers” w AD
  • jeśli jest to zarazem kontroler domeny, to należy upewnić się, że do tej samej grupy należy konto „Network Service”
  • po dodaniu tych dwóch kont do grupy zrestartować usługę „Remote Desktop Licensing service”

W moim wypadku serwer nie był kontrolerem domeny oraz obiekt komputera był dodany do odpowiedniej grupy, a błąd pojawiał się nadal. Okazało się, że może to być zaszłość po migracji z domeny Windows Server 2003 do 2008 i wyżej. A dowiedziałem się tego z biuletynu MS pod tym linkiem. Stoi tam, iż:

If the user accounts existed before the domain was upgraded to Windows Server 2003, the Terminal Server License Servers group might be missing in the discretionary access control list (DACL) of the user objects in Active Directory directory service. Or, the group is in the DACL, but the group does not have permissions to update the Terminal Services Licensing information for the user account.

Proponowane jest kilka sposobów rozwiązania teog problemu, ja skorzystałem z metody drugiej czyli delegowania uprawnień:

1. W przystawce AD Users and Computers kliknij PPM na domenę i wybierz „Delegate control”

2. W okienku Users and Groups kliknij „Add” i wpisze „Terminal Server License Servers”, a następnie zaakceptuj „OK” i „Next”

3. W oknie „Tastks do Delegate” wybierz „Create a custom task to delegate” i ponownie „Next”

4. W „Active Directory Object Type” kliknij „Only the following objects in the folder” i wybierz „User objects” czyli ostatnią pozycję na liście i znowu „Next”

5. Na koniec w oknie „Permissions” upewnij się, że zaznaczone jest „General”, a następnie w liście uprawnień zaznacz „Read and Write Terminal Server license server” i naciśnij Next

 

Po wykonaniu tych kroków mój serwer licencji zbiera już prawidłowe informacje o wykorzystywanych licencjach dostępowych RDS CAL:

Nie można się zalogować przez RDP Do Windows Server 2012R2

Po aktualizacji Windows może zdarzyć się, że nie serwer przestanie uwierzytelniać użytkowników przez RDP. Czy może raczej RDP przestanie po prostu działać. Przyczyną może być fakt, że Windows Server nagle uzna nasza sieć jako publiczną zamiast domenowej. Aby to sprawdzić należy wejść w Network and Sharing Center (ncpa.cpl) i zobaczyć co jest napisane pod nazwą domeny – np. „Domain network” albo „Private” albo też „Public”. Jak wiadomo windowsowy firewall ma trzy profile działania odpowiadające właśnie tym trzem ustawieniom sieci. I jeśli np. mamy polisę GPO, która odblokowuje porty do jakiegoś programu na profilu domenowym, to w sytuacji gdy Windows Server zmieni profil sieci na inny to reguła ta przestaje działać i porty są zamykane. Najprościej jest zatem zmienić profil sieci z powrotem na domenowy.

Niestety po wejściu w Network and Sharing Center nie możemy wyklikać ikonki i zmienić tę opcję. Można to jednakże zrobić za pomocą jednej linijki Powershella:

Set-NetConnectionProfile -NetworkCategory DomainAuthenticated

Oczywiście żeby nie było za prostu Windows Server wyrzuci nam błąd, że ręcznie tego przestawić się nie da. W takiej sytuacji pozostaje tylko zrestartowanie usługi odpowiedzialnej za całe to rozpoznawanie profili sieciowych. Nazywa się ona „Network Location Awareness” i po jej zrestartowaniu serwer sam powinien już zmienić profil na domenowy.

Oczywiście można również ustawić w zaporze Windows puszczenie ruchu na profilu publicznym ale chyba jednak lepiej przestawić serwer w tryb sieci domenowej, w końcu zakładamy, że serwer jest w domenie.

 

 

Nie można się zalogować przez OWA na Exchange 2010

Była taka sytuacja: administrator usunął konto w AD, które miało również skonfigurowaną skrzynkę w Exchange 2010. Odzyskanie nie sprawiło większych problemów, wystarczyło skorzystać z funkcjonalności kosza w AD dostępnej od Windows Server 2008R2. Po przywróceniu zostało również przywrócona skrzynka na MS Exchange (wersja 2010) ale użytkownik niestety nie mógł się do niej zalogować. Błąd, który się pojawiał podczas próby zalogowania przez OWA to:

Your account has been disabled.
Request
Url: []
User: Kowalski, Jan
EX Address: /o=firma/ou=uzytkownicy/cn=oddzial/cn=kowalskij
SMTP Address: jan.kowalski@firma.com
OWA version: 14.3.146.0

Należy przy tym zaznaczyć, że konto z cała pewnością jest włączone i można się na nim zalogować – użytkownik mógł zalogować się na stacji, nawet takiej bez zachowanych poświadczeń i normalnie pracował. Jedyne co nie działało to właśnie poczta.

Na serwerze Exchange logowany jest Event 14035, który jednakże niewiele nam powie poza „Cannot open mailbox” oraz „Unable to open message store”:

Po krótkim dochodzeniu okazało się, że całe AD było właśnie sprzątane i pousuwano wiele kont, z których to jedno akurat niepotrzebnie. Sprawiło to, że na Exchange pojawiło się bardzo wiele skrzynek w stanie Disconnected. I nie wiem teraz czy ta nadmierna ilość skrzynek w tym stanie spowodowała błąd w Exchange, czy też był jakiś inny powód ale rozwiązaniem jest wyczyszczenie baz danych skrzynek, a następnie podpięcie ponownie danej skrzynki, tak jak to opisałem poniżej.

W konsoli MS Exchange:

  • wyłącz skrzynkę pocztową tego użytkowika (PPM na nazwie konta w Recipient Configuration -> Mailbox) i wybierz „Disable”, a następnie potwierdź
  • wyczyść bazę mailboxów – najlepiej zrobić to od razu na wszystkich bazach – czyszczenie tej jednej, na której była dana skrzynka pocztowa nic nie dawało. Polecenie to w PS to:
Get-Mailboxdatabase –Identity * | Clean-Mailboxdatabase
  • Podłącz skrzynkę z powrotem do bazy danych. Aby zobaczy które skrzynki są obecnie odpięte, a możliwe do odzyskania należy wybrać „Recipient Configuration” -> „Disconnected Mailbox” -> „Connect” i wybrać odpowiedni serwer DAG. Pokaże się lista odłączonych skrzynek, należy wybrać jedną z nich klikając nań PPM i wybierając „Connect”, a następnie podążać za kreatorem ustawień (użytkownik, podłącz do istniejącego konta, etc.).

Na podstawie:

https://exchangeexpertscommunity.blogspot.in/2013/07/your-account-has-been-disabled-error.html

 

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

 

Strona personalna Zbigniewa