Windowsupdate – automatic update és reboot opciók menedzselése

A Microsoft Endpoint Managerrel (régi nevén Intune) szabályozhatjuk a windows frissítések telepítését.

Az update és reboot mindig is küzdés volt a felhasználók és adminok között: “munka közben indult újra a gépem”, “frissítéskor csak teker és nem tudok dolgozni”, csak hogy pár panaszt említsünk. Sok esetben ezt a problémát a rosszul beállított update policy okozza.

Nézzük, hogy a MEM-ben milyen lehetőségeink vannak. A cikkben most csak az update telepítés és reboot részre térek ki, a többi opcióra nem.

Ha megnyitjuk a Windows 10 update ring-et, a következő beállításokat látjuk az User Experince Settings / Automatic update behavior résznél:

Az egyes beállítások részletezése:

  • Notify download: letöltés és telepítés előtt figyelmezteti a felhasználót, akinek kézzel kell elvégeznie a műveleteket.
  • Auto install at maintenance time: a maintenance időben letölti és telepíti a frissítéseket, kivéve ha a felhasználó használja a gépet, vagy pl. nincs töltőre dugva. A maintenance időt az Active hours beállítással adhatjuk meg (pl. 8-17 óra között nincs automatikus letötlés és telepítés-restart). Az újraindításhoz kéri a felhasználó engedélyét, ha ez nem történik meg 7 napig, utána magától újraindul.
  • Auto install and restart at maintenance time: hasonló az előző beállításhoz, csak itt a telepítés után automatikus restart következik (ha az eszköz nincsen használva). Az Active Hours megadásával a reboot itt is kontrollálható. A nem menedzselt eszközökhöz ez az alapbeállítás: telepítés után auto restart, ha nem hasznáják a gépet.
  • Auto install and restart at scheduled time: definiálhatjuk a telepítés napját-idejét. A telepítést követően elindul egy 15 perces visszaszámláló, amit a felhasználó elhalaszthat. Alapértelmezetten hajnali 3-kor telepít.
  • Auto install and reboot without end-user control: a frissítések letöltése és telepítése automatikusan megtörténik. Amikor az eszköz nincs használatban, a reboot is követi. Ennél az opciónál a felhasználónak csak read-only joga van a beállítási ablakon.
  • Reset to default: visszaállítja alaphelyzetre az auto update beállításokat

A fenti beállításokból kiválasztható a szervezet igényeinek megfelelő update mechanizmus.

A következőkben tekintsük át, hogy milyen figyelmeztetési lehetőségek vannak, a felhasználók felé.

Telepítés után, ha újraindításra van szükség, egy felbukkanó pop-uppal jelzi a rendszer. Ez a figyelmezetés 25 mp után eltűnik, és csak a kis ikon marad az óra mellett:

Amennyiben azt szeretnénk, hogy ez a figyelmeztetés megmaradjon és a felhasználónak kelljen nyugtáznia, kapcsoljuk be a Require user approval to dismiss restart notification részt a policyben:

Szintén egy hasznos funkció, ha a felhasználó figyelmét felhívjuk a közelgő kötelező újraindításra. Evvel lehetőséget adunk, hogy reboot előtt elmentse a megnyitott munkáit. A következő figyelmeztetéseket tudjuk megjeleníteni:

Azaz hogy az újraindulás előtt 4 órával fedobjon egy figyelmeztető üzenetet a felhasználónak, 30 perccel előtte pedig már egy elnyomhatatlan figyelmeztetés jelenik meg, visszaszámolással. Természetesen ezeket az értékeket állíthatjuk.

A frissítések telepítését és a gépek kötelező újraindítását kezelhetjük a Deadline beállításokkal is. Ennek lényege, hogy meghatározzuk, mikor kerüljenek fel az update-ek és mikor történjen az újraindítás.

A deadline a frissítés megjelenésétől számítja a megadott napokat. A fenti példa alapján, ha 10-én jön ki a frissítés a Microsoft Update-re, akkor legkésőbb 3 nap múlva automatikusan telepíti és megpróbálja az újraindítást is, ha az eszköz nincsen használatban. Ha definiáljunk Grace Period értéket, akkor annak értékével halasztja. Ez különösen hasznos, ha a felhasználó pl. szabadságról tér vissza, és így kap időt, hogy a telepítés-újraindítás kontrolláltan, pl. másnap történjen.

A deadline beállításokkal egy sokkal szorosabb frissítési ütemet tudunk kialakítani, mint az első részben taglalt beállításokkal. Amennyiben ezt a módszert választjuk, ne felejtsük el a Quality update deferral period (days) és Feature update deferral period (days) értékeket 0-ra tenni, különben policy conflict keletkezhet.

A deadline esetében max 30 napot határozhatunk meg.

Ajánlott konfiguráció: itt tennék egy szubjektív ajánlást, hogyan érdemes beállítani a teljes policyt:

  • Quality update deferral period (days): 7 nap. Így egy hétig nem ajánlja fel a frissítés telepítését, az IT addig tudja tesztelni a patch-et
  • Automatic update behavior: Auto install at maintenance time. A nem aktív időben a frissítések települnek és megjelennek a reboot kérő üzenetek, 7 napig. 7 nap után kötelező lesz a reboot, amiről figyelmeztetéseket jelenít meg.
  • Active hours start: 8 AM
  • Active hours end: 4 PM
  • Restart checks: Allow. Ha alacsony az akku töltöttsége, vagy presenting módban van a gép, akkor nem indul újra.
  • Require user approval to dismiss restart notification: Enabled. A felhasználónak kézzel kell leokéznia a pop-upot, evvel is tudatosítva benne, hogy a gépe újraindításra vár.
  • Remind prior to requried auto-restart with dismissible reminder: 8 óra
  • Remind prior to requried auto-restart with permament reminder: 1 óra
  • Change notification update level: Use the default Windows Update notifications

Összefoglalva: az update ring beállításkészlettel megtalálhatjuk a középutat a frissítések telepítése és felhasználói élmény negatív befolyásolása között.

M365 Enterprise és SMB csomagok összehasonlító táblázatok

Sokszor nemcsak az ügyfelek, de a tanácsadók is elveszettek lehetnek, hogy melyik M365 csomagban milyen szolgáltatás szerepel, milyen limitációkkal stb.

Az alábbi két táblázat hasznos lehet, hogy eligazodjuk a “rengetegben”

M365 Enterprise csomagok összehasonlító táblázat (PDF)

M365 SMB csomagok összehasonlító táblázat (PDF)

Minimal vs Full Hybrid – melyiket válasszam?

Ügyfelekkel beszélgetve tapasztalom, hogy sok a homály az Exchange Hybrid kialakításással kapcsolatban. A legtöbb elakadás ennél a képernyőnél történik:

Azaz jön a jogos kérdés, hogy a mi különbség a kettő között, és melyiket válassza az adott szervezet?

Minimal vs Full Hybrid

A Minimal Hybrid használata esetén az alább funkciók nem lesznek elérhetőek:

  • Cross-premises Free / Busy információk (naptármegosztás funkció a földi és felhős postafiókos felhasználóknál)
  • TLS – titkosított mail flow a földi Exchange és az Exchange Online között
  • Cross-premises eDiscovery funkciók
  • Automatikus OWA és ActiveSync átirányítás az EXO-ba migrált usereknél
  • Skype for Business vagy Teams integráció a földi postafiókok esetén

Természetesen megmaradak az alábbi lehetőségek:

Online mailbox migráció (a felhasználó a mozgatás alatt is tud dolgozni a levelezésében); nincs szükség az Outlook-profil újrakonfigurálására; nincs szükség külön név/jelszó használatára (a céges account adatok szinkronizálódnak)

Mely szervezeteknek ajánlható a Minimal Hybrid kialakítás?

  • Kis -és közepes méretű cégeknek, akik szeretnének gyorsan az Exchange Online-ba migrálni, de mégis szeretnének kontrollt (szemben pl. a cutover migrációval)
  • Amely szervezeteknek nincs szükségük a fenti teljes funkcionalitásra és nem terveznek hosszú távon hybrid fenntartást.
  • Felvásárlás vagy egyesülés esetén, ha az igény a mailboxok gyors migrációja

Mely szervezeteknek javasolt a Full Hybrid kialakítás?

  • Nagy létszámú szervezeteknek, ahol hosszú távon is terveznek a földi Exchange megtartásával
  • Ahol szükség van a maximális kontrollra a migrációkat tekintve, emiatt szükséges az együttélés (co-existence) biztosítása
  • Ahol szükséges a Free / Busy információk megléte és eDiscovery funkció

Fontos tudni, hogy ha már beállítottuk a Full Hybridet, akkor az O365 Hybrid Configuration Wizard futtatásakor már nem választhatjuk a Minimal Hybridet (a fenti screenshoton is inaktív a lehetőség). Viszont amennyiben Minimalt állítottunk be, bármikor válthatunk a Full Hybridre.

Az alábbi táblázatban összeállíottam pár szempontot a döntéshez:

IgényVálasztás
Mailboxok gyors migrációjaMinimal Hybrid
Office 365 mailboxok kezelése és földi AD szinkronizálásaMinimal Hybrid
Global Address List fenntartása a földi és and Office 365 közöttMinimal Hybrid
Organization configuration beállítások szinkronizálása, pl. ActiveSync policykMinimal Hybrid
A mailboxok migrációjának előkészítése (pre-sync) és migráció befejezése alkalmas időbenMinimal Hybrid
Bejövő és kimenő levelezés a földi Exchange-en keresztül kell történjenFull Hybrid
Földi Exchange és Exchange Online közötti levélforgalom TLS-sel legyen titkosítottFull Hybrid
Megtartani a mailek eredeti fejlécét , ami szükséges a  mailtippek és out of office válaszokhozFull Hybrid
Free / Busy funckió használata (naptármegosztás földi és felhős postafiókok között)Full Hybrid
Földi és felhős postafiókok közötti Full Access / Send as jogosultságok megtartásaFull Hybrid
Integráció  Skype for Business / Teams és  Exchange 2016 mailboxok között vagy cross-premises eDiscovery használataFull Hybrid
Kontrollált mailbox migrációFull Hybrid

Összefoglalva:

Ha a cél a lassabb, de teljesen kontrollált migráció és fontos a teljes együttműködés megtartása a földi és felhős postafiókkal rendelkező felhasználók között, válasszuk a Full Hybridet.

Ha a gyors migráció a prioritás, beáldozva néhány funkciót, akkor érdemesebb a Minimal Hybrid opciót választani.

Seamless SSO – cseréljük a Kerberos kulcsot

Az Azure portálon, az AD Connect résznél szemünkbe tűnhet egy sárga háromszöges figyelmeztetés:

Pánikra nincs ok, a napi működésre nincs kihatással 🙂

De mit jelent mindez?

Áttekintés

A Seamless SSO-t beállíthatjuk, ha password hash sync vagy pass-through authentikációt határoztunk meg (a két hitelesítési mód összehasonlítása: Password hash sync vagy pass-through authentication – összehasonlítás | Zoltan Istvanffy’s IT Blog (istvanffyzoltan.com) )

A Seamless SSO segíti a felhasználói élményt, hogy domain-joined gépeken automatikusan bejelentkeznek az Azure AD-ba.

Amikor az AD Connect segítségével konfiguráljuk az SSO-t, a földi domainben létrejön egy AZUREADSSOACC computer objektum. Ez felelős érte, hogy megvalósuljon az SSO az Azure AD-val. A működésének rövid leírása:

  1. Felhasználó be szeretne jelentkezni egy felhős web app-ba.
  2. Az App átírányítja az Azure AD-hoz.
  3. Az adott App nem továbbít semmilyen domain vagy tenant információt, ezért meg kell adni a felhasználónak a felhasználó nevét.
  4. A webbrowser 401-es hibát ad, mert nincs érvényes kerberos ticket.
  5. A felhasználó böngészője kerberos jegyet igényel a “AZUREADSSOACC” objektumhoz. Igen és itt nyer értelmet ez az objektum, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget és ez az objektum képviseli az Azure AD-t.
  6. Kapunk egy kerberos ticketet a “AZUREADSSOACC” objektumhoz, ami titkosítva lesz a “számítógép” kulcsával.
  7. A felhasználó böngészője elküldi a titkosított kerberos ticketet.
  8. Azure visszafejti a titkosított kerberos ticketet, azzal a kulcssal, ami akkor jött létre, amikor bepipáltuk a “Enable single sign-on” lehetőséget.
  9. Amennyiben érvényes a jegy, akkor a böngésző visszakap egy tokent, amivel hozzáférhet az erőforráshoz.
  10. Ezáltal a felhasználó sikeresen bejelentkezett a wep app-ba, anélkül, hogy megadta volna a jelszavát.

(forrás: https://nlbit.blog/2020/08/07/seamless-sso-azureadssoacc/ )

Ez az objektumot érdemes egy külön OU-ba tenni és bekapcsolni rajta a “protect object from accidental deletion” opciót is.

A Kerberos-kulcs (decryption key) a lényeges, ezt érdemes legalább 30 napota cserélni. Ha nem tesszük, akkor kerül ki az Azure portálra a figyelmeztető ikon.

Hogyan cseréljük a Kerberos-kulcsot?

A művelethez szükségünk van Global Administrator és Domain Admin jogosultságra. Lépjünk be az AD Connect szerverre és admin powershellben navigáljunk el a “Microsoft Azure Active Directory Connect” mappába:

cd “C:\Program Files\Microsoft Azure Active Directory Connect\”

Importáljuk be az SSO modult:

Import-Module .\AzureADSSO.psd1

A következő paranccsal végrehajtjuk a hitelesítést az Azure AD felé:

New-AzureADSSOAuthenticationContext

Futtassuk le a kulcs-csere parancsot, és hitelesítsük magukat a földi AD felé:

Update-AzureADSSOForest

A hitelesítés után megtörténik a kulcs cseréje:

Rövid idő után frissül az Azure portálon is:

Összefoglalva: evvel az egyszerű művelettel érdemes legalább 30 naponta frissíteni a Kerberos-kulcsot. Az AZUREADSSOACC objektumra kevés figyelem jut, de érdemes jól “eltenni” egy külön OU-ba és bekapcsolni rajta a véletlen törlés elleni védelmet.

OneDrive- hozzáférés megtagadva

Egy gyors esetleírás.

Környzetet: a felhasználók használják az OneDrive-ot, és a Desktop/Documents/Pictures mappa is oda van irányítva (lásd cikk: OneDrive mint felhasználói backup | Zoltan Istvanffy’s IT Blog (istvanffyzoltan.com)

A gépek Microsoft Endpoint Management-tel (Intune) menedzseltek, Windows Information Protection policy beállítva.

Hibajelenség: nem lehet új file-t létrehozni az OneDrive folderekben, hozzáférés megtagadva hibaüzenettel.

Megoldás:

A WIP-policyben meghatározott Data Recover Agent tanúsítványa lejárt.

Cseréljük ki a DRA tanúsítványt, és újra működőképes lesz az OneDrive.