KB5034441 0x80070643 fix
Microsoft zapowiedział, że nie wyda poprawki do poprawki KB5034441, która w większości wypadków wysypuje się błędem 0x80070643. w takim razie pół-automatyczne rozwiązanie do zassania tutaj, a poniżej informacje o co chodzi i jak to działa.
czemu to się sypie
niby opis naprawy można znaleźć na stronie Microsoft. ale po pierwsze, nie każdy jest na tyle odważny, żeby grzebać na żywych partycjach. po drugie w całym tym opisie brakuje bardzo ważnej informacji: potrzebny jest plik w winRE. teoretycznie wykonanie komendy 'reagentc /disable’ powinno skopiować plik winRE, ale tego nie robi. a więc po zmianie wielkości partycji, próbujemy włączyć… i nie działa.
w związku z tym ogólne kroki do wykonania to:
- przygotowanie pliku winRM.wim i umieszczenie go w katalogu 'recovery’.
- wyłaczenie winRM
- znalezienie partycji recovery
- zmniejszenie partycji systemowej, żeby zrobić miejsce na winRM
- zwiększenie partycji recovery
- właczenie winRM
Skrypt
skrypt wymaga uruchomienia jako administrator. co robi:
- pobiera plik winRM.wim do katalogu 'recovery’
- próbuje znaleźć partycję recovery i jak mu się uda:
- przygotowuje plik wsadowy dla diskpart
- wypluwa instrukcje do robić dalej
jeśli skrypt się nie wysypał – to prawie na pewno wszystko jest ok. jeśli się wysypał przed końcem – cóż, może masz pecha i Twoja konfiguracja jest niestandardowa.
nie działa w 1oo% oczywiście – dla tego nie jest w pełni automatyczny. są różne dziwne scenariusze, ale w większości, na komputerach firmowych sytuacja jest dość prosta. skrypt odpaliłem na wielu serwerach i stacjach roboczych i skuteczność jest na poziomie 95%, oszczędzając mojemu zespołowi godzin pracy i dziargania w diskpart.
Przypadki, które sprawiały problemy to:
- kilka przypadków z bitlocker, dziwnym układem partycji
- trudne do wyjaśnienia przypadki w których winRE nie było włączone a patch i tak chciał się instalować. partycja recovery była w 'dziwnym’ stanie [chyba ktoś przy niej wcześniej grzebał (; ]
- w kilku przypadkach, kiedy zabrało miejsca na dysku systemowym, chociaż było go dużo – pomogła defragmentacja.
w sumie nie dziwię się, że Microsoft nie wydaje automatu, bo nie chce potem odpowiadać za utracone dane. i ja również dodam: USE ON YOUR OWN RISK.
powodzenia
eN.
Classic Administrator – porządki i źle wyświetlane przypisanie
kolejny brzegowy przypadek. tym razem mógł mnie kosztować usunięcie istniejących subskrypcji – a więc 'niuans, który może zabić’.
scenariusz to clean up subskrypcji. jest ich kilkaset, więc trzeba podejść do tematu systemowo. najpierw zajmę się omówieniem scenariusza i moim podejściem do sprzątania, a jak kogoś interesuje sam bug w Azure – to będzie na końcu.
clean up process
w pierwszej kolejności trzeba wyizolować osierocone i puste subskrypcje. o tym jak znaleźć te puste szybko, czyli KQLem – za niedługo, wraz z małym qrsem KQL. dziś o tych 'osieroconych’.
duża część subskrypcji zakładana jest na chwilę, głównie przez developerów, którzy przychodzą i odchodzą…. a subskrypcje zostają. warto więc znaleźć te, których właściciele już nie istnieją w AAD.
zadanie wygląda więc tak – zrobić listing wszystkich subskrypcji wraz z osobami które są Ownerami w ARM IAM oraz Classic Administrators – czyli role Service Administrator oraz Co-Administrator. posłużą zarówno jako lista kontaktowa, oraz pozwolą na kolejne odpytania, żeby wyłuskać te konta, które już nie istnieją. subskrypcje bez właścicieli to najlepsze kandydatki do podróży do śmietnika. posłuży do tego taki prosty skrypcik, napisany na kolanie:
load-CSV to kolejna funkcja z eNlib – jedna z najczęściej przeze mnie używanych. ładuje CSV z automatyczną detekcją znaq oddzielającego, co jest mega istotne jak się pracuje w różnych regionalsach. ma też kilka innych bajerów… ale nie o tym tu. dalej już z górki – wyłusqję SignInNames unikalne i odpytuję AAD o użytkownika. ponieważ brak użytkownika nie jest błędem, a nullem, więc nie można użyć try/catch a trzeba wykorzystać IFa.
i wydawałoby się że mam już to, co potrzeba – wrzucam wynik do excela, robię XLOOKUP i pięknie widać które subskrypcje należą do kont, których już wśród nas nie ma… zabrzmiało złowieszczo khekhe…
Błąd w Azure
…chyba, żeby nie. całe szczęście natchnęło mnie, żeby jednak kilka posprawdzać ręcznie. i nagle okazało się, że konta których nie ma… czasem jednak są. a wszystko rozbija się o 'Classic Administrators’, który musi wewnętrznie źle komunikować się z ARMem. wiele staje się jaśniejsze, jeśli przyjrzeć się jak takie obiekty są listowane przy 'get-AzRoleAssigment -includeClassic’:
na pierwszy rzut okiem może wydawać się, że jest ok… ale gdzie jest 'ObjectId’? to jednak tylko pierwsza część problemu. porządki mają to do siebie, że robi się je rzadko. a to oznacza bagaż historii. a w tym bagażu np. projekt standaryzacji nazw użytkowników i zmiana UPNów z gsurname@domain.name na givenname.surname@domain.name. okazuje się, że ten staruszek nie ma mechanizmu odświeżania i pomimo zmiany UPN, czyli de facto SignInName, tutaj pokazuje starą nazwę. a więc przy odpytaniu AAD – nie znajduje usera, pomimo, że ten istnieje.
co ciekawe, jeśli wejdzie się do uprawnień IAM w portalu Azure, każdy user jest aktywnym linkiem, pozwalającym na kliknięcie i przeniesienie do AAD, na szczegóły konta. tak z ciekawości spróbujcie to zrobić dla Classic Administrators…
całe szczęście projekt był zrobiony z głową i stare UPNy zostały jako aliasy mailowe, a więc doprecyzowałem zapytanie:
ale co mnie to czasu i nerwów kosztowało…
eN.