konwersja XLSX do CSV metodą przeciągnij i upuść

drag’n’drop wygląda jakoś bardziej naturalnie… ale co tam. niech będzie po polsq (;

taka sytuacja…

spora część mojej pracy to zbieranie i analiza danych z systemów – AD, AAD, Ex, EXO, SfB i tak dalej. piszę sobie do tego pałerszelki i wrzucam to do CSV. no niestety – ale cały czas nie mogę się przestawić na jakąś sensowną bazę danych, ale to nie na dziś. potem takie CSVki łatwo jest otworzyć, edytować, analizować w Excel – oczywiście już jako xlsx. wszyscy Excel znają (LoL, raczej potrafią go otworzyć i coś wpisać, bo niestety poziom obsługi podstawowych narzędzi jest niestety, na równie podstawowym poziomie), dzięki o365 mamy wspaniałe funkcje koedycji – a więc w prosty sposób cały zespół może pracować na pojedynczym źródle.

żeby odświeżyć dane w excel, znów muszę wyeksportować go do CSV. czyli:

  • otworzyć arkusz
  • zrobić export (kilka kliknięć, wybór formatu, nie pomylić się, bo jest kilka formatów CSV itd…)
  • zamknąć.

nie lubię klikać, a więc fajnie byłoby mieć ikonkę na pulpicie, przeciągam plik XLS i voila! CSVka sobie czeka w ustalonym miejscu.

taki przydługi wstęp, ale taki dzień. jak to zrobić?

automatyczna konwersja XLSX2CSV via drag’n’drop

  1. trzeba sobie machnąć prosty skrypcik PS, który konwersji dokona. np taki:

convert-XLSX2CSV.ps1

param(
  [string]$fileName
)

if(-not (test-path $fileName)) {
  write-host "$fileName not found. exitting"
  exit
}

write-host "converting $fileName ..."

$file=get-childItem $fileName
if($file.Extension -ne '.xlsx') {
  write-host "$fileName doen't look like excel file. exitting"
  exit
}
try{
  $Excel = New-Object -ComObject Excel.Application
} catch {
  $Error
  exit
}
$Excel.Visible = $false
$Excel.DisplayAlerts = $false
$wb = $Excel.Workbooks.Open($fileName)
$wb.Worksheets[1].SaveAs("c:\temp\" + $File.BaseName + ".csv", 6,$null,$null,$null,$null,$null,$null,$null,'True')
$Excel.Quit()

write-host -ForegroundColor Green "convertion done. saved as c:\temp\$($file.BaseName).csv"
write-host "press any key to finish."

$HOST.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown") | OUT-NULL
$HOST.UI.RawUI.Flushinputbuffer()

nic skomplikowanego. jeśli ma być auto trzeba pamiętać, że ścieżki muszą być zahardcodowane, a parametry wejścia najlepiej ograniczyć do nazwy pliq.

2. zrobić skrót na pulpicie, który przyjmie plik drag’n’drop. jeśli zrobimy skrót do ps1 – nie zadziała. skrót musi być do pliq exe. a więc proste:

  • utwórz nowy skrót
  • jako plik do uruchomienia:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noprofile -file C:\_scriptZ\convert-xlsx2csv.ps1

…no i w zasadzie tyle. teraz wystarczy upuścić plik Excel na skrócie i życie jest dłuższe o kilka ładnych kliqw (=

bezpośrednia edycja XLSX

a nie można by tak bezpośrednio na excelu pracować? ano możnaby. nawet na serwerze. jest taka fajna biblioteka, która pozwala zaimportować się bez instalacji samego excel. nawet kiedyś o tym pisałem. ale obsługa tego skryptem, jest mówiąc oględnie – mało przyjemna. praca na zwykłych obiektach to czysta przyjemność.

eN.

 

dsregcmd switches – undocumented

nieudokumentowane przełączniki dsregcmd.exe

nie wiem czemu to polecenie nie ma żadnej wbudowanej pomocy, nie ma też oficjalnej strony. a więc trzeba było trochę się grzebnąć w exe i sprawdzić. kilka rzeczy które udało mi się wyciągnąć:

lista przełączników dla deregcmd.exe :

/Debug
/Pause
/Leave
/Status
/Trigger
/CheckRecovery
/ForceRecovery
/RollbackRecovery

z tego co udało mi się ustalić to:

  • status: to jedyny, który pojawia się oficjalnie w wielu artyqłach. pokazuje status dla komputera i użytkownika – AD, AAD, WorplaceJoin
  • debug:  polecenie powinno działać w kontekście systemu. czyli np: ’psexec -s -i cmd.exe’ i z tąd odpalić dsregcmd /debug – dostaniemy informacje o precheck, statnie kluczy szyfrujących niezbędnych do operacji itd. może się przydać jeśli maszyna upiera się i nie chce się zarejestrować w AAD. można też debugować od strony samego AAD – ale pod warunkiem, że operacja została już zainicjowana. być może np. komputer nie ma połączenia z DC i w ogóle nie próbuje się podłączyć – wtedy tylko tak można spróbować sprawdzić czemu.
    co prawda niektóre artykuły wskazują polecenie dsregcmd /debug /join [przykładowy link do artu na dole] ale przełącznika join nie znalazłem w samym pliq exe. z moich testów wynika że 'dsregcmd /debug’ pozwala na użycie wraz z którymś ze wskazanych tu przełączników, i działa to dokładnie jak tryb verbose.
  • leave: oczywiście wywalenie z AAD
  • trigger: wymuszenie rozpoczęcia próby rejestracji
  • pause: przed wykonaniem operacji będzie czekał… na enter. chwila zawieszki, bo komunikat brzmi 'press any key’ ale dopiero enter pozwala kontynuować

do dokładnie robią flagi recovery… w sensie co jest odzyskiwane – nie jest jasne. po wykonaniu 'dsregcmd /debug /CheckRecovery’ output standardowo jest taki:

dsregcmd::wmain logging initialized.
DsrCmdRecovery::DetermineIfRecoveryIsNeeded Machine is joined to Azure AD and domain.
DsrCmdRecovery::DetermineIfRecoveryIsNeeded returned 0x00000001 (RECOVERY NOT NEEDED).

po wykonaniu 'dsregcmd /debug /ForceRecovery’ zostałem poproszony o zalogowanie się na swoje konto. na koniec informacja 'możesz teraz używać tego komputera’ – ale nie widzę żadnych dodatkowych informacji w AAD, ani jakiegoś przypisania do konta.

scenariusz

na koniec krótkie 'a po co mi to?’. aby w pełni wykorzystać możliwości zabezpieczania i sterowania stacjami z InTune, urządzenie musi być zarejestrowane w AAD. w przypadq maszyn domenowych mówi się o ’hybrid join’ bo są równocześnie dodane do AD i AAD. całą operacją steruje się prostym ustawieniem w GPO, więc teoretycznie pełny automat. dodam, że dla Windows 1o. dla Windows 7 jest dodatek ’workplace join’ ale ten ma normalną pomoc /? więc jest przyjaźniejszy w użyciu.

kiedy teoria nie działa w praktyce – wtedy warto przypomnieć sobie ten wpis.

refs

link do artów na temat procesu rejestracji urządzeń:

eN.

Group Based Licensing dla o365

GBL

możliwość zarządzania licencjami przez grupy AD to nieoceniona pomoc w każdym większym środowisq. co prawda spędziłem kilka ładnych godzin nad fajnym skryptem, którym można masowo zarządzać licencjami wraz z poszczególnymi planami serwisowymi, jednak możliwość ułatwienia administracji jest bezcenna. trzeba zatem było z łezką w oq wrzucić skrypt do projektów wymarłych i zająć się okiełznaniem grup.

ogólnie, GBL pozwala na przypisanie licencji (niemal) dowolnej grupie AAD, dzięki czemu zarządzanie licencjami sprowadza się do prostych operacji zmiany członkostwa. pomimo, że funkcjonalność jest jeszcze w public preview, uważam, że warto się mocno zainteresować, bo operacje licencyjne przeważnie są realizowane albo przez 1szą linię, gdzie korzystanie ze skryptów nie koniecznie jest mile widziane, albo przez automatyczne systemy zarządzania tożsamością, jako część procesu nowego użytkownika.

ponieważ jest to świetnie udokumentowane, nie będę się rozpisywał o podstawach, ale przedstawić ciekawe przypadki i problemy.

[info: art opisuje środowisko hybrydowe]

gdzie jest haczyk?

pierwszy i podstawowy haczyk, pojawia się już na poziomie projektowania grup. rzadko kiedy zdarza się, żeby wykorzystywany był pojedynczy typ licencji, czy nawet dwa-trzy. zazwyczaj jest wiele różnych wyjątków, wynikających z różnorodności zapotrzebowania – niektórzy będą mieli E3, inni E5, jeszcze inni będą potrzebować pojedynczych planów (np. PowerBI, AudioConferencing) jako uzupełnienie niższej licencji. są też dodatkowe produkty takie jak Visio czy Project, które też raczej wszystkim użytkownikom się nie qpuje.

okazuje się, że ilość wyjątków może być całkiem spora, warto zastanowić się więc nad modelem hybrydowym – np. używać grup do zaspokojenia przyjętych standardów, co zrealizuje 9o%, i to tych, przy których normalnie trzeba użyć jakiegoś skryptu. wyjątki natomiast obsłużyć ręcznie 'wykliqjąc’. jednolite rozwiązania są dużo łatwiejsze w zarządzaniu, i ogólnie jestem przeciwnikiem mieszania metod zarządzania tym samym fragmentem jednak w tym przypadq:

  • funkcja jest nadal w preview. public, bo public, i testowana jest już ok ok. 2 lat, jednak nie ma gwarancji co się zmieni w finalnej wersji. zakładam że nic, w porywach do niewiele, ale trzeba mieć z tyłu głowy ew. poprawki co całego projektu, lepiej więc go póki co nie komplikować
  • braqje na razie dobrych artyqłów z praktyki [co staram się załatać (: ], który pokazywały by realne bolączki i ryzyka.

mechanizm trzeba najpierw dobrze poznać i zrozumieć niuanse i konflikty, zanim wdroży się go globalnie. a więc pomimo, że docelowo najlepiej mieć czyste zarządzanie GBL, sugeruję zacząć od podejścia ewolucyjnego. dać sobie trochę czasu na nauczenie się zachowania mechanizmu i rozwiązywania problemów… o których może uda mi się kiedyś napisać.

double-trouble

z technicznego punktu widzenia, największym problemem są plany powiązane. niektóre plany są od siebie zależne i nie uda się przypisać jednego-bez-drugiego. przykłady:

  • plan 'Office Online’ wymaga planu 'SharePoint’
  • plan 'AudioConferencing’ wymaga planu 'Skype/Teams’

zależnie od implementacji, albo osoby nie będą miały oczekiwanej licencji, bo nie spełniają kryterium, albo w ogóle nie uda się utworzyć grupy licencyjnej. przykładowy scenariusz:

  • osoby posiadają licencje o365 E3 ale potrzebują tworzyć spotkania z opcją call-in. czyli trzeb im dodać plan 'Audio Conferencing’.

nie da się utworzyć grupy licencyjnej zawierającej wyłącznie ten plan, ponieważ nie ma gwarancji spełnienia warunq posiadania Skype/Teams. obejściem jest dodanie do grupy zarówno planu AC oraz Skype z licencji E3, trzeba się oczywiście upewnić, że nie więcej scenariuszy w firmie – np. trzeba będzie założyć grupę AC wraz z Skype E1 – co bardzo skompliqje zarządzanie.

trouble-double

…czyli to samo ale odwrotnie. usuwamy osoby z grupy licencyjnej, ba! usuwany całą grupę licencyjną. grupy w AD nie ma, wchodzimy do AAD… i grupa nadal jest, zawiera wszystkich członków, licencje nadal są przypisane, nie ma błędów synchronizacji… to czemu u licha grupa została??

otóż może tak się zdarzyć, że usuwamy grupę zawierająca licencję 'nadrzędną’ a gdzieś, wedle algorytmu, może zostać podrzędna. czyli np. usuwamy licencje zawierająca SharePoint, a są  grupie osoby które maja Office Online. AAD stwierdza, że to doprowadzi do konfliktu, więc bloqje całą operację.

jeśli usuwamy grupę licencyjna – zalecam zacząć od usunięcia wszystkich członków, synchronizacji, a potem dopiero usunięcie grupy.

konflikty licencyjne

przy złożonej strukturze grup mogą wystąpić konflikty licencji. taka sytuacja zdarza się w momencie, kiedy wedle grup użytkownik będzie miał przypisane plany z różnych grup. nie zapisałem niestety przykładowych przypadqw, ale miałem okazję oglądać sytuację, w której licencja nie została przypisana, ponieważ pomieszane były poziomy planów z różnych licencji – czyli jakiś plan z licencji E3 kolidować z innym planem, z E1.

podczas projektowania grup GBL lepiej przypisywać możliwie pełne licencje – zbytnie kombinowanie na poziomie planów szybko doprowadzi do scenariuszy konfliktowych.

podsumowanie

mechanizm GBL oceniam rewelacyjnie. AAD świetnie pokazuje komunikaty błędów, pomaga w debugowaniu i ogólnie całość jest bardzo fajnie przemyślana. nie jest jednak pozbawiony limitów, i nie zawsze będzie się nadawał. należy zapoznać się z niuansami działania, przemyśleć scenariusze użycia licencji w firmie i sprawdzić czy nie ma przypadqw na tyle skomplikowanych, że nie opłaca się go używać. stworzenie zbyt dużej ilości grup, dających możliwości granularnego zarządzania planami może albo posqtkować niezłym misz-maszem i wcale nie ułatwić życia, albo w specyficznych przypadkach być niemożliwe.

podsumowując 'KEEP IT SIMPLE’. znalezienie środka może być wyzwaniem jeśli scenariuszy licencyjnych jest wiele.

eN.

usuwane danych użytkownika z Office365

niby proste. ale jest 'ale’….

User

po usunięciu użytkownika – zostaje w śmietniq. to proste. czyli należy usunąć usera a potem go usunąć ze śmietnika

remove-MsolUser -UserPrincipalName user@w-files.pl

get-MsolUser -UserPrincipalName user@w-files.pl -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin

 

Exchange

teraz nie mogę znaleźć… ale jestem przekonany, że w artyqłach była informacja że po takim usunięciu wszystkie dane są również usuwane… ale tak nie jest! okazuje się, że skrzynka zostaje:

get-recipient user@w-files.pl -IncludeSoftDeletedRecipients

Name RecipientType
---- -------------
User, wufajls   UserMailbox

get-recipient user@w-files.pl -IncludeSoftDeletedRecipients | Remove-Mailbox -PermanentlyDelete

OneDrive

z OneDrive jest jeszcze dziwniej, bo po usunięciu użytkownika site nadal jest widoczny jako aktywny. jako dowód – po wykonaniu tego polecania, OD użytkownika nadal nie będzie na liście:

Get-SPODeletedSite -IncludeOnlyPersonalSite | FT url

natomiast wyświetlenie aktywnego site OD pokaże go:

Get-SPOSite -Identity https://w-files-my.sharepoint.com/personal/user_w-files_pl

Url Owner Storage Quota
--- ----- -------------
https://w-files-my.sharepoint.com/personal/user_wufajls_pl user@w-files.pl 1048576

opis algorytmu dla OD można zleźć w artykule na support.office.com. site jest widoczny i dostępny przez 7 dni po usunięciu użytkownika i dopiero potem trafia do śmietnika.

podsumowując

  • proste operacje 'pod spodem’ wcale niekoniecznie są takie proste.
  • każdy serwis żyje własnym życiem i ma własne zasady – office365 to nie jest pojedyncza usługa!
  • jeśli ktoś ma 'onpremową intuicję’ to należy się jej wyzbyć.
  • to wszystko to niby niuanse, ale bywają istotne – zwłaszcza jeśli trzeba odtworzyć konto w AAD oraz ze względu na aspekty bezpieczeństwa i dostępu do danych.

eN.

 

 

 

 

role AzureAD – jak zacząć pracę z graphAPI

Customized Administrator

czy zauważyliście, że zależnie od interfejsu, widać inne role w AAD? jeśli zajrzymy z Office Admin Center to:

kiedy tworzy się 'Customized Admin’ z portalu Admin, to już ilościowo widać, że jest coś więcej:

a tak na prawdę, jak nie trudno się domyślić, jest ich jeszcze więcej.  scenariusz 'po co?’ zostawię sobie na kiedy indziej a tymczasem – jak sprawdzić te role i jak do nich przydzielić? jakich braqje?

jak sprawdzić wszystkie role

najkrócej: za pomocą Microsoft Graph. zakładam, że używanie tego mechanizmu dla wielu osób nie jest oczywiste, dla tego krótka instrukcja. po wejściu stronę, należy się uwierzytelnić do swojego tenanta [po lewej stronie 'microsoft sign-in’]. w innym przypadq będziemy w testowym tenancie Microsoftu.

w oknie akcji widać trzy podstawowe elementy – okno zapytania, 'request body’ uzupełniające zapytanie oraz 'response body’ gdzie będą się pojawiać wyniki.

dla sportu można sobie kliknąć 'run query’ i zobaczyć wynik w 'response body’. szybko można się zorientować, że wszędzie widzimy legendarnego Dżejsona, a zapytania są w stanie spoczynq [REST]. jak nie rozumiesz – na razie nie szkodzi, ale warto uzupełnić sobie informacje o zapytania REST oraz format JSON. w odpowiedzi dowiemy się paru rzeczy o własnym koncie.

można się również szybko zorientować w dostępnych metodach rozwijając listę 'GET’ gdzie widać jeszcze 'PUT’, 'POST’, PATCH’ oraz 'DELETE’. widać również, że są dwie wersje Microsoft Graph – v1.0 oraz beta.

pierwsza niespodziewajka – czytając i przeglądając artykuły zaczniecie trafiać na wersje 1.5 czy 1.6… a to dla tego że oprócz Microsoft Graph jest jego poprzednia wersja – AzureAD graph. trzeba zatem uważać przy stosowaniu przykładów, do której są wersji.

dostępne role dla Customized Administrator – bo taki jest cel niniejszego zadania – widoczne są w części 'directoryRoles’. i tu widać pełną listę, m.in. niedostępnego z interfejsu 'CRM Service Administrator’, 'Power BI Service Administrator’ i kilka innych.

jak dodać rolę

pomimo, że w naszym świecie rolę przydziela się użytkownikowi, tutaj to roli przydziela się użytkownika. czyli operację trzeba wykonać dla pożądanej roli a nie dla użytkownika. to, co będzie nas interesować to 'ID’ roli. zanim coś przypiszemy najpierw sprawdźmy członków 'Global Admins’. tutaj nazywa się to 'Company Administrator’ … pewnie dla ułatwienia (; spisujemy ID i wykonujemy GET dla https://graph.microsoft.com/v1.0/directoryRoles/<ID Company Amdministrator/members -> Run Query. pojawią się wszyscy GA dla tenanta.

aby kogoś dodać, należy wysłać żądanie [POST] a w treści zamieścić opis obiektu zapisany jako JSON.

polecenie HTTP:

POST v1.0 https://graph.microsoft.com/v1.0/directoryRoles/<ID Company Amdministrator/members/ref$

oraz request body, gdzie zamieszczamy opis obiektu:

{
"@odata.id": "https://graph.microsoft.com/v1.0/users/<userID - może być UPN lub objectID>"
}

wykonujemy request i….

dostajemy błąd o braq uprawnień. pomimo, że jesteśmy adminami?

uprawnienia dla GraphExplorera

Graph Explorer działa jako proxy i standardowo ma tylko uprawnienia odczytu. należy aplikacji nadać uprawnienia, aby mogła wykonać operacje zapisu. zwróć uwagę, że tam, gdzie było 'Sign In’, teraz pod loginem jest 'modify permissions’ oraz 'sign out’. dla nadania roli wymagane są dwa uprawnienia:

  • Directory.AccessAsUser.All
  • Directory.ReadWrite.All

zostaniemy zapytani, czy nadać aplikacji odpowiednie uprawnienia i voila. wykonanie wcześniej opisanego query – doda userowi pożądaną rolę.

eN.

współdzielenie OneDrive – ciekawostki

OneDrive Sharing

na początek oczywiste oczywistości:

  • OneDrive to de facto SharePoint. główne ustawienia współdzielenia [Sharing] dziedziczy z globalnych ustawień SP
  • od jakiegoś czasu dostępny jest OneDrive Admin Center z poziomu Office365. z jego poziomu można pozornie ustawić zabezpieczenie współdzielenia na poziomie niższym, niż jest zdefiniowany w SharePoint. ale nie można [co zresztą jest opisane małym druczkiem na dole].

  • od niedawna rozbudowany został klient OneDrive – w końcu można nadawać uprawnienia 'bezpośrednio’ z Exploratora. co mnie pozytywnie zaskoczyło – okienko uprawnień jest renderowane przez OneDrive.exe a nie, tak jak się spodziewałem, iexplore.exe/edge .

Jak powstaje ACE dla osoby z zewnątrz

i tu się zaczyna robić ciekawie. standardowo, do czego przyzwyczaiły nas systemy operacyjne, flow jest taki:

  • użytkownik wybiera plik i nadaje uprawnienia
  • tworzony jest ACE – Access Control Entry – który staje się nieodłączną częścią pliq… w dużym uogólnieniu.
  • osoba próbuje się dostać
    • uwierzytelnia się
    • token uwierzytelniony porównywany jest z ACL [Access Control List] w poszukiwaniu ACE dla danego usera – rodzaj filtra
  • osoba dostaje dostęp lub nie.

wydaje się tak oczywiste… a jednak dla pliq współdzielonego z osobą z zewnątrz w OneDrive, jest inaczej. czy zastanawiałeś się po co jest poniższa opcja? skoro można uzyskać dostęp przez osobę inną niż zaproszona, to znaczy, że ACE nie może istnieć w momencie dostępu. zakładając, że wyłączone są linki anonimowe, w dużym uogólnieniu wygląda to tak:

  • użytkownik wybiera plik, uprawnienia edit/view i adres osoby z zewnątrz.
  • tworzony jest *link*, URL, zawierający token dostępu. ten link wysyłany jest mailem.
  • osoba, która otrzymała link otwiera go. zakładając, że wymuszone jest uwierzytelnienie, zostanie przekierowana na stronę logowania.
  • po pozytywnym uwierzytelnieniu, na podstawie linka generowane jest ACE, które dopiero teraz dopisywane jest do pliq
  • tworzone jest również konto [jeśli nie było wcześniej] „username_server.name#EXT#@company.onmicrosoft.com” w AAD

czemu tak i jakie to ma konsekwencje

opisywane zachowanie będzie zależne od kilq ustawień bezpieczeństwa na SP – czy włączone są linki anonimowe, oraz czy mogą być otwierane przez osoby inne, niż te, do których się je oryginalnie wysłało. współdzielenie linkiem jest znane od lat, i dość oczywiste, dla osób korzystających z usług chmurowych. po prostu w rozproszonym świecie chmury, gdzie nie ma centralnej bazy użytkowników, token jest przekazywany wraz z linkiem – w dużym skrócie posiadanie linka oznacza posiadanie dostępu. stąd powstały mechanizmy rozszerzające to rozwiązanie – np. o wymaganie uwierzytelnienia. czemu zatem link wysłany przez jedną osobę, standardowo może być otworzony przez inną? ta opcja została stworzona głównie z tego powodu, że ludzie korzystają z masy adresów, i mogą mieć konto MS Account założone z innym adresem niż my znamy – np. wysyłamy do kogoś na x@gmail.com a ktoś ma konto MS Account jako x@outlook.com. dzięki temu osoba nie jest zmuszona zakładać kolejnego konta, co było istotne zwłaszcza jakiś czas temu, kiedy nie istniał uproszony proces zakładania konta, i było to bardzo upierdliwe. ale ze względu na bezpieczeństwo, nie włączenie tej opcji, jest dość niepokojącym scenariuszem i sugerowałbym jednak, aby wymuszać weryfikację odbiorcy. w takim wypadq, nawet jeśli przekaże się linka innej osobie [lub zostanie wykradziony!], nie zostanie on obsłużony. można się przyczepić, że komunikat błędu pokazuje zdekodowany adres email osoby, która oryginalnie była w tokenie, ale nie jest to już tak wielki problem.  załóżmy, że opcja jest na 'default’, czyli może być otwarty przez inną osobę. co się stanie, jeśli roześlę link do stu osób? czy wszystkie będą miały dostęp? NIE. link zawiera 'token jednorazowego dostępu’. pierwsza osoba się dostanie i dla niej utworzony zostanie ACE, pozostałe osoby dostaną acc denied.

ciekawostki (bugs?)

nie może obyć się bez zagadek w-files. trafiłem na dwie. w porywach do trzech q:

  1. jeśli jakiś user ma wpisany alternate email z jakimś adresem zewnętrznym – np. x@gmail.com, i chcemy udostępnić plik tej osoby na tenże adres zewnętrzny… to się nie uda. AAD rozpoznaje użytkownika jako wewnętrznego i co prawda wysyła linka [zależnie od tego z jakiego interfejsu skorzystamy zachowanie może być różne], ale nie ma szansy zalogować się na kontem x@gmail.com .
  2. jak sądzicie, czy usunięcie konta #EXT# z AAD spowoduje, że osoba straci dostęp do pliq? scenariusz:
  • administrator doszedł do wniosq, że posprząta trochę, i *dla bezpieczeństwa* usunie konta #EXT# żeby zabrać dostępy.

no to się zdziwi, ponieważ usunięcie konta, nie powoduje usunięcia ACE – te systemy są rozdzielne, i nie ma 'centralnego repozytorium dostępów’. a ponieważ centrum uwierzytelnienia jest również rozłączne z naszym systemem, user zostanie poprawnie uwierzytelniony [przez Microsoft Account a nie przez nasz tenant AAD], ACE istnieje – ergo dostęp będzie. nie wierzycie – spróbujcie, podzielcie się wrażeniami. właśnie ta część pracy – odpowiedź na pytanie 'kto ma gdzie dostęp’ – jest nadal niełatwym zadaniem. 3. PS. czy zwróciliście uwagę, że w OneDrive for Business jest ’shared with me’ a w OneDrive personal jest ’Shared by me’? i żadne ze środowisk nie udostępnia mechanizmu dla pełnego rozeznania się co komu i dla nas….  

OneDrive for Business OneDrive personal

eN.

Teams i grupy o365

taka drobna ciekawostka… większość aplikacji o365 opiera się na ’Office 365 groups’. ciekawe jest to, że zależnie od aplikacji to nie zawsze jest dokładnie ta sama grupa, a raczej zawartość jest synchronizowana do kopii grupy dla aplikacji. podobnie jak grupa w AD onprem jest synchronizowana do grupy AAD w o365.

efekt jest dość zaskaqjący. jeśli manipuluje się przynależnością do Teamu w Teamsach, z poziomu aplikacji, jako właściciel danego Teamu/grupy, to zamiany są odzwierciedlane natychmiast. ale jeśli dokonuje się manipulacji na grupie od strony office 365 [np. dodanie/usunięcie członka], jako administrator, to zmiany w Teams zostaną zsynchronizowane… w ciągu 24h [SIC!]. jest to trochę dziwne. np. w tym samym czasie SharePoint widział zmianę od razu.

dwa wnioski:

  • lepiej unikać zarządzania administracyjnego – lepiej zostawić to właścicielom Teamów
  • trzeba pamiętać, że 'sowy nie są tym czym się wydają’

eN.

unikaty i duplikaty

Duplikaty

łatwo jest przefiltrować listę tak, aby mieć tylko unikalne elementy – jest zarówno commandlet 'get-unique’ oraz parametr ’-unique’ przy select-object, ale jak wyłuskać duplikaty?

sposobów jest oczywiście wiele a ten, który mi się podoba to:

cat "<file.name>"|group |? count -gt 1

lub w hiperpoprawnym zapisie:

get-content "<file.name>"|group-object|where-object {$_.count -gt 1}

plik:

PS C:\Temp> cat .\loremipsum.txt
Lorem ipsum dolor sit amet,
consectetur adipiscing elit.
non consectetur ex aliquam a. Vestibulum ante ipsum primis
Nulla at blandit nisi. Maecenas sodales tempor ligula.
Mauris ac pharetra eros. Nam pellentesque quam purus,
non consectetur ex aliquam a. Vestibulum ante ipsum primis
in faucibus orci luctus et ultrices
posuere cubilia Curae; Maecenas
consequat velit consequat
Mauris ac pharetra eros. Nam pellentesque quam purus,
vulputate fringilla. Donec
bibendum finibus ex vel congue.
bibendum finibus ex vel congue.

a teraz sprawdźmy duplikaty:

Count Name Group
----- ---- -----
 2 non consectetur ex ali... {non consectetur ex aliquam a. Vestibulum ante ipsum primis , non consectetur ex ali...
 2 Mauris ac pharetra ero... {Mauris ac pharetra eros. Nam pellentesque quam purus, , Mauris ac pharetra eros. Na...
 2 bibendum finibus ex ve... {bibendum finibus ex vel congue. , bibendum finibus ex vel congue. }

można jeszcze upiększyć output, pozbywając się śmieci:

cat .\sfbea.txt |group -NoElement|? count -gt 1

Unikaty

powracając jeszcze do unikatów… wydawałoby się, że skoro jest oddzielne polecenie – get-unique, to powinno mieć większe możliwości i być bardziej elastyczne niż jakiś tam parametr do innego polecenia.

o dziwo jest odwrotnie. osobiście traktuję get-unique jako ciekawostkę i nie miałem scenariusza, w którym bym go użył. a to dla tego iż [msdn]:

The Get-Unique cmdlet compares each item in a sorted list to the next item, eliminates duplicates, and returns only one instance of each item. The list must be sorted for the cmdlet to work properly.

Get-Unique is case-sensitive. As a result, strings that differ only in character casing are considered to be unique.

eN.

„nie można zainstalować drukarki – brak dostępu”

repairtiaaa… dawno nie było takiego wpisu q: czasem trafiają do mnie zadania czysto administracyjne. taki lajf. ostatnio trafił do mnie taki właśnie kejs jak w tytule – przy próbie dodania drukarki sieciowej na Windows 1o, wyskaqje takiż komunikat.. albo podobny (; minęło trochę czasu od kiedy zajmowałem się politykami GPO, ale finalnie i tak to nie one były przyczyną problemu. przeważnie chodzi o fakt, że użytkownik nie ma możliwości instalacji sterowników, i można to rozwiązać konfigurując dwa ustawienia w GPO: link tutaj

  • Computer Configuration\Policies\Administrative Templates\System\Driver Installation\Allow non-administrators to install drivers for these devices setup classes
    • Enabled
    • Device class GUID of printers: {4d36e979-e325-11ce-bfc1-08002be10318}
  • Computer Configuration/Policies/Administrative Templates/Printers/Point and Print Restrictions
    • Enabled
    • Security Prompts: When Installing Drivers for a new connection = Do not show warning or elevation prompt

ale… okazało się, że to nie pomogło. rozwiązaniem było ustawienie uprawnienia 'view server’ na poziomie Print Servera:

printerpermission01printerpermission02

eN.