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

 

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

Strona personalna Zbigniewa