Skip to Content

IT nieuczesane.
category

Category: tips’n’tricks

jak sprawdzić build Exchange … ten prawdziwy

po instalacji UR i sprawdzeniu wersji [build number], exchange cały czas pokazuje świeżutką wersję bez builda. wersję można sprawdzić w konsoli lub z PS:

okazuje się, że kwestia wersji nie jest taka trywialna, kiedy przyjrzeć się jej bliżej. kilka zebranych informacji:

  • różne komponenty mają różne wersje.to co się zazwyczaj sprawdza, to wersja ‚core’ czyli głównego silnika.
  • wersje zapisywane są w różnych miejscach. ta pokazywana w konsoli oraz powyższy skrypt, zaczytuje je z obiektu w AD z partycji konfiguracji. dla Ex2kd to jest:

ufff… oczywiście można tą ścieżkę wyciągnąć poleceniem:

wersja zapisana jest w atrybucie ‚serialNumber’ więc odczytać ją można:

parametr nie jest uaktualniany przy  instalacji UR – stąd rozjazd.

  • wersję można również sprawdzić w kluczu rejestru „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v<versionNumber>\<roleName>” – są tam klucze o nazwach ‚configuredVersion’ i ‚unpackedVersion’. te również nie są poprawiane.

sprawdzić prawdziwą wersję można na dwa sposoby:

  • z GUI – w EMC [górne menu]-> help -> about

exchangeversion

  • albo sprawdzając wersję pliq ExSetup z katalogu bin:

eN.

 

zdalne odinstalowanie agentów VMM

automationscenariusz: upgrade VMM 2o12 -> 2o12 R2. nie ma inplace upgrade, więc stawiany obok. agentów również nie chce zainstalować z automatu na hostach bo ‚version is not supported’. trzeba więc w pierwszym kroq odinstalować wszystkie agenty na wszystkich hostach. jeśli tylko jest dobra [czyli skrypto-przyjazna] notacja nazewnicza, to można to zrobić szybko, sprawnie i bez bólu. taki przykład – dla dziewięciu hostów o nazwach hvhosto1-o9. wymaganie: skonfigurowane winRM:

eN.

SCVMM – jest sieć… a nie ma

scenariusz: jest sobie SCVMM i podpięte do niego ileś-tam hostów. na wszystkich mam utworzoną sieć „External” z dostępem public, z której korzystają virtualki. tworzę nową maszynę i host, na którym chcę ją utworzyć, dostaje w „rating o”. VMM odmawia utworzenia maszyny na tym hoście a w wyjaśnieniach takiej oceny jest informacja, że nie ma takiej sieci jak „External”. dodam jeszcze, że na tym hoście działa normalnie inna VM podpięta do tej sieci, i wszystko jest prawidłowo.

sprawdzam w VMSwitch w VMMie. porównuję z innymi hostami. nic. sprawdzam bezpośrednio na Hyper-v żeby wyeliminować jakiś błąd czy desynch w informacjach na VMM. ale wszędzie, wszystko wygląda ok. postanawiam zmusić do utworzenia virtualki żeby dostać jakiś sensowny błąd – i tak też się dzieje. tworzę VM bez przypisania do sieci i kiedy po poprawnym utworzeniu zmieniam sieć na „External” pojawia się:

Error (26894)
VM Network (External) is unavailable on Virtual Switch (External)

dziwne. okazuje się, że są wewnętrznie dwa obiekty – VM Network i VM Switch. VM Switch istnieje, tylko sieci nie ma. ale żadnej metody utworzenia takiej sieci również nie ma – ani z PS ani z interfejsu /: przyjrzałem się konfiguracji przypisań sieci do sieciówek. okazało się, że w wyniq jakiegoś błędu, sieć jest przypisana do jednej karty NIC, a VM Switch do drugiej. po zmianie przypisania NIC na poziomie VM Switcha – wszystko zaczęło śmigać. a tak to wygląda w obrazkach:

w widoq VMM/VM proerites/Hardware przy powiązaniu kart sieciowych z sieciami wirtualnymi widać, że sieciówka o numerze #87 nie ma dowiązania z żadną z nich. strzałka pokazuje na ‚External’, które jest dowiązane do drugiego interfejsu.

props1

dla sieciówki #87 ‚External’ nie jest dowiązane

prop2

w interfejsie nie widać pełnych nazw – niestety są poucinane ze względu na długość. dla tego najlepiej upewnić się z PS:

 

jak widać – VM Switch związany jest z #87 a sieć wirtualna z fizyczną #86. i zrobił się split…

eN.

IIS AppPool – 32 czy 64 bit?

scenariusz: upgrade wersji Dell OpenManage. po instalacji wszystkich komponentów, aplikacja IIS wywala się. prawdopodobnie jest niekompatybilność wersji – 32/64bit. jak sprawdzić czy biblioteka jest 32 czy 64bit? w zasadzie odpowiedź można znaleźć w eventlogu:

Could not load all ISAPI filters for site ‚OPENMANAGE ESSENTIALS’.  Therefore site startup aborted.

ISAPI Filter ‚c:\Windows\Microsoft.NET\Framework\v4.0.30319\\aspnet_filter.dll’ could not be loaded due to a configuration problem. The current configuration only supports loading images built for a AMD64 processor architecture. The data field contains the error number. To learn more about this issue, including how to troubleshooting this kind of processor architecture mismatch error, see http://go.microsoft.com/fwlink/?LinkId=29349.

niemniej pytanie pozostaje – jak upewnić się jaka jest wersja biblioteki? pomocnym narzędziem będzie mały tool z VisualStudio – dumpbin

teraz na 1oo% rozwiązaniem będzie: w IIS -> Application Pools -> [RMB] Advanced Settings -> Enable 32-Bit Application

eN.

 

 

 

 

 

pomniejszanie dysq

w zasadzie od w2k jest możliwość pomniejszania/powiększania dysqw bezpośrednio z disk managera. z niewiadomych powodów, z każdą wersją, powolutq, była dodawana nowa funkcja – w NT5.o tylko extend, w NT6.o extend i shrink ale max do 5o% powierzchni izdaje się, że nie można było ruszyć boot partition i system partition, w NT6.1 znów zniesiono obostrzenia aż do NT6.3 gdzie teoretycznie można sobie zmniejszać i zwiększać bez problemu…

to tyle, jeśli chodzi o teorię – czas na trochę praktyki, bo [jak to usłyszałem ostatnio qilqrotnie w ciągu krótkiego czasu] życie weryfiqje. obostrzenia oczywiście są. pierwszym z nich są ‚nieprzenaszalne pliki’ – czyli takie, do których system trzyma konkretny adres i z pewnych względów nie może ich ruszyć. do takich należą np. restore points, pagefile, klucze BitLocer i kilka innych specyficznych obiektów. przy próbie zmniejszenia dysq, system automatycznie wylicza przestrzeń do pierwszego takiego pliq, wskazując maksymalną wielkość, o którą można dysk zmniejszyć.

scenariusz na jaki trafiłem, i skąd bierze się ten wpis jest taki, że po miesiącu pracy dostałem nowego kompa. przeniesienie się jest zawsze mało przyjemne, bo pomimo, że prawie wszystko jest w chmurze, zawsze zostaje sporo poinstalowanych i skonfigurowanych już aplikacji. BUUUEEEH. ponowna instalacja śmierdzi. prosty wniosek – zrobię z tego VHDX, skopiuję na nowego kompa i będę sobie bootwał z niego. proste. tyle, że okazało się, że w jednym kompie jest 5ooGB a w nowym 12oGB dysq. system nie pozwala zmniejszyć dysq o tak dużą wartość. co zrobić?

w pierwszej kolejności trzeba sprawdzić co nas bloqje. w suqrs przyjdzie zajrzenie do eventloga Application i przefiltrowanie po zdarzeniach z ID 259. zdarzenie to jest generowane przez … defrag [sic!], w momencie, kiedy włączamy wizarda w diskmanagerze:

FVE2 to właśnie klucz BL. swoją drogą przy bootowaniu systemu z VHDX trzeba pamiętać, że BL nie jest obsługiwany. nie jest również obsługiwana hibernacja. to tak zanim się podejmie decyzję, czy na pewno ta droga jest prawidłowa. wyłączyłem BL, wyłączyłem Restore Points, i wyłączyłem… czy też chciałem wyłączyć Pagefile. już nie pierwszy raz zdarzyło mi się, że pomimo wyłączenie PF i restartu, ten wracał jak boomerang. dopiero konfiguracja z linii poleceń faktycznie się go pozbyła

jeszcze ręczne wyczyszczenie katalogu System Volume Information i voila! po uruchomieniu wizarda zmniejszania dysq mogę go sqrczyć do maleńkości… szkoda tylko, że kiedy próbuję – dostaję komunikat, że system nie może zmniejszyć partycji ponieważ… wybrałem za dużą wartość /: tutaj rozwiązaniem okazało się krokowe zmniejszanie – najpierw 2ooGB a potem po 5oGB… i jakoś system to przełknął. ciężko powiedzieć zatem po co ten komunikat i o co cho.

teraz disk2vhd i prawie już. prawie, ponieważ disk2vhd nie ma opcji wyboru, jaki typ dysq chcemy uzyskać – jest na sztywno dynamic. no i trzeba mu zmniejszyć wielkość – bo o ile partycja jest sqrczona, to sam dysk pozostaje wielki. i tu kolejne zaskoczenie. kiedyś były toole, które na plikach vhd łatwo i przyjemnie robiły takie operacje. od czasu, kiedy wszystkie narzędzia są dostępne w systemie, i pojawił się format vhdx, narzędzi brak. systemowe narzędzia natomiast mają podstawową wadę – PowerShellowe commandlety Convert-VHD czy Resize-VHD wymagają, aby w systemie działała usługa Hyper-v. niby nic… a jednak cyc. nie udało mi się znaleźć żadnego darmowego toola, który by wykonywał operacje na dyskach vhdx.

ponieważ ta instancja systemu i tak była do wyrzucenia, a poszukiwania były raczej z takiej ciekawości i niedowiary, zainstalowałem Hv, skonwertowałem dysk, potem kopia na nowy, bcdboot i w końcu sukces. ale i tak, pomimo, że finalnie zabrało mi to tyle samo czasu co instalacja system+aplikacje, było to zajęcie dużo przyjemniejsze q:

eN.

Lepsze wrogiem dobrego

Na dobre nastał Ms Office 2013. Funkcjonalność nowych wersji zgubiłem gdzieś w okolicach 2007, ale z tym da się żyć. Rozumiem też, że nowe wersje są konieczne z wielu powodów, głównie finansowych. Nie zmienia się jedynie procent wykorzystania możliwości kolejnych Officów przez „standardowego użytkownika”, który od wersji 95 oscyluje w granicach 1.
Nie o tym jednak jest ten wpis.
Cały czas staram się wskazywać klientom, że rozwiązania IT takie jak Ms Office to nie tylko edytor do napisania listu motywacyjnego, ale cały ekosystem, który odpowiednio użyty potrafi drastycznie zwiększyć wydajność każdej instytucji. Cały czas też spotykam się z tzw. „barierą Crtl-C/Crtl-V” – która jasno pokazuje, że te dwa skróty klawiszowe są maksymalnym pułapem wykorzystania funkcjonalności najlepszego programu biurowego poprzez „zwykłego użytkownika”. Fakt, że w roku 2014 wykorzystanie śledzenia zmian przy pracy nad dokumentem wciąż jest ewenementem wywołuje myśli samobójcze w działach IT i nie tylko ale też nie jest tematem tego wpisu.
Do rzeczy zatem. Na nic moje starania, gdy odbijam się od wściekłego użytkownika, który nie może pracować, bo „pan informatyk zainstalował nowe i zepsuł”  Potwierdzone, co prawda jedynie moim przeczuciem statystyki awaryjności Offic’a 2013 a ZWŁASZCZA Outlooka z ostatniego pół roku, które dotknęły wszystkich – od domowych użytkowników wersji „zgodny z oryginalną” po korporacje z domeną i tych z Officem 365 mówią jedno – coś poszło nie tak.
Zwiechy przy ładowaniu, przycinanie się, aż po całkowitą niemożność załadowania profilu wszystko po zainstalowaniu Office’a 2013. Dotyczy nie tylko Outlooka, ale także pozostałych programów.
Zanim dotrą łatki, rozwiązanie które działało w ok 95% przypadków.

Disable hardware acceleration

1. Run regedit (Win + R ; „regedit”)
2. Browse to HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common
3. Create a New Key and name it „Graphics”
4. Select Graphics, right-click on the right panel and create a New DWORD (32-bit) Value and name it DisableHardwareAcceleration.
5. Enter Value data as 1

Nie mam bladego pojęcia, co robi ten wpis w rejestrze, ale działa.

jak przeczytać ACL po SIDach a nie nazwach?

przy próbie wyszukania okazuje się, że wszyscy szukają zupełnie odwrotnej akcji… a ponieważ znalazłem bardzo fajny wpis szczegółowo opisujący tematykę:

http://blogs.technet.com/b/ashleymcglone/archive/2011/08/29/powershell-sid-walker-texas-ranger-part-1.aspx

eN.

migracja, FSP i ogólnie bałagan

przejąłem projekt migracji – konsolidacja struktury domen do nowej, pojedynczej domeny. „wszystko już praktycznie zrobione, będziesz się nudził” – z taką optymistyczną informacją zaczynałem pracę nad zadaniem. z bardzo wielu krzaków, które wyszły, sqpię się nad jedną ciekawostką.

po przejrzeniu zmigrowanych grup okazało się, że część kont jest pokazywana jako konta external. listing członkostwa w grupie ujawniał wpisy typu:

CN=S-1-5-21-2096504233-xxxxxxxxx-944726268-2633,CN=ForeignSecurityPrincipals,DC=target,DC=domain

CN=S-1-5-21-2096504233-xxxxxxxxx-944726268-3498,CN=ForeignSecurityPrincipals,DC=target,DC=domain

Tak są właśnie przechowywane referencje do kont z lasów ztrustowanych. zacząłem więc szukać co to za domena. sprawa prosta, ponieważ zasada jest taka sama jak przy zwykłych SIDach – pierwsza część SID to domainSID. sprawdziłem więc ID wszystkich domen źródłowych [zwykły (Get-ADDomain).domainsid.value] … i okazało się, że takiej domeny nie ma /:

śledztwo. „taaaaakk…hmmm… była kiedyś migracja parę lat temu, tej domeny już nie ma”. tia. ostatnim etapem migracji jest cleanup SIDhistory, którego ktoś nie zrobił. sprawdzam grupy w domenie źródłowej – sweet, tam też członkowie pododawani są przez SIDHistory.

po dalszym przeglądzie okazało się, że w grupach były również konta z domen połączonych trustem nieprzechodnim z domeną źródłową, czyli nierozwiązywalne – kolejna grupa dziwnych FSP. tych niestety nie da się w żaden sposób przenieść chyba, że utworzy się trust z tymi externalami. poznajdywały się również konta CNF [w nowej domenie!] i inne wynalazki. i tak to właśnie się nudziłem…

po pierwsze wniosek/porada: migrację zaczyna się od czyszczenia. nawet jak klient mówi „przenosimy 1:1” – trzeba zweryfikować jak bardzo jest naśmiecone i poczyścić.

po drugie – skrypt, czyszczący FSP

z ciekawostek: do usunięcia usera z grupy korzystając z CN, musiałem użyć ADSI – nie potrafiłem zmusić koszernych cmdletów do obsłużenia CNa.

eN.

Azure PS Remoting

z wersji na wersję, maszyny dostarczane z szablonu w Azure sa coraz bardziej przygotowane do pracy od pierwszego startu. podobnie jest w przypadq PS Remoting – czyli zdalnego łączenia się z maszynami via PowerShell. automatycznie tworzony jest endpoint dla PSR a sama maszyna ma włączoną usługę i zrobione odpowiednie wyjątki. smacznie. pozostaje się po prostu połączyć.

jedyny problem, na jaki natknie się przeważająca większość osób, to certyfikat – na maszynkach jest oczywiście jakiś self-signed, więc standardowo połączenie zostanie odrzucone. aby połączyć się bezproblemowo należy wyłączyć opcje weryfikacji certów:

 

et voilá!

eN.

Postaw ptaszka

Od wersji Windows Server 2008 mamy dostępną w AD opcję „ProtectedFromAccidentalDeletion”. Generalnie nigdy bym nie pomyślał, żeby kiedykolwiek miało by sens używanie tej opcji, ale od niedawna dodaję ją jako wymaganą i  k_r_ y_t_y_c_z_n_ą  praktycznie w każdej mojej dokumentacji, która zawiera opis obiektów AD.

Generalnie nie ma większego problem gdy skasujemy obiekt komputera czy użytkownika. Nawet jeśli jest to konto serwisowe, po kilku minutach możemy sytuacje  naprawić. Ja jednak byłem świadkiem sytuacji w której jakiś durny program, lub admin … a generalnie admin nawet jak był to program …skasował obiekt serwisu klastra (hosta Cluster Service). To spowodowało, że przestała działać cała instancja SQL oparta na tym klastrze i inne usługi (np.. MSDTC). Obiekt nie jest prosty, więc od tak nie można go sobie stworzyć. Cały klaster SQL oparty na MSCS w zasadzie byłby do przeinstalowania a dokładniej każdy node musiał by być wyciągnięty z clustra, następnie trzeba by było usunąć wszystkie ślady po cluster service i poinstalować wszystko od początku. Roboty, przy kilku nodach na około 8 godzin (a produkcja leży!). Na szczęście jest na to myk .. Ale o tym w kolejnych wpisach.

Generalnie myślałem, że problem był wyjątkowy i że już nic gorszego się stać nie może. Środowisko bez  SPoF. Cały sprzęt nadmiarowy, urządzenia sieciowe dobrej klasy, load balancery, macierze itp. … Ale nie doceniłem adminów.

Po kilku dniach kolejna awaria. Ktoś dopatrzył że są 3 podobne do siebie nazwy komputerów… SuperProdDB1, SuperProdDB2 i SuperProdDB. Popingał, popatrzył na listy VMwareów i postanowił zrobić porządek. Skasował wpisy DNS SuperProdDB. Był to host name dla instancji klastra SQL  składającego się z w/w nodów.

Naprawa tego poszła już znacznie sprawniej.

Generalnie … postaw ptaszka!