[INTUNE] Policies

[Echelon2011]

Ik ben InTune aan het bekijken maar wegens een zeer korte termijn (1.5 week) weet ik eigenlijk niet goed waar te beginnen. Misschien kan Tweakers mij wat in de juiste richting zetten.

De vraag is:
----------------
Bedrijf A levert hardware (Lenovo, HP, Dell...) aan klanten (Azure of hybride omgevingen) en zien een
mooie toegevoegde waarde om voor new users onboarding of naar beheer van de assets toe zaken te beheren via InTune.

Mijn specifieke vraag richt zich op policies en accounts
- Is er een specifieke rol/account/licentie die een werknemer in bedrijf A enkel de rechten geeft voor InTune?
Zodat deze persoon InTune kan beheren voor andere klanten?
- Is er een manier om GPOs 1 op 1 over te zetten naar InTune? Ik zie wel een powershell optie maar voor de rest is keuze aan policies redelijk beperkter dan GPO's.
- Zijn er commercieel best practices of bvb policies die bedrijf A kan voorstellen aan klanten om ze te overhalen. Klinkt vaag maar ik probeer met voor te bereiden om de meest common questions zoals koppelen van fileshares, koppelen van printers....
...

Relevante software en hardware die ik gebruik:
--------------------------------------------------------------
Ik heb een M365 DEV account opgezet met daarin enkele test accounts met alle nodige E5 licenties.
https://joymalya.com/learn-intune-get-m365-dev-tenant/

EDIT: Ik heb een VMware workstation met windows 10 ISO gejoined naar Azure AD en die is ondertussen zichtbaar.


Wat ik al gevonden of geprobeerd heb:
--------------------------------------------------
De komende dagen ga ik de MD101 learning path verder bekijken.
Dat is een hele brok gezien de resterende tijd. Daarom als iemand in dit gebied handige tips, tricks of artikels heeft verneem ik ze graag.
En ja ik heb het al aan ChatGPT gevraagd

[ Voor 4% gewijzigd door Echelon2011 op 22-02-2023 12:21 . Reden: vm host toegevoegd ]

[nextware]

Echelon2011 schreef op woensdag 22 februari 2023 @ 11:08:

Mijn specifieke vraag richt zich op policies en accounts
- Is er een specifieke rol/account/licentie die een werknemer in bedrijf A enkel de rechten geeft voor InTune?
Zodat deze persoon InTune kan beheren voor andere klanten?
- Is er een manier om GPOs 1 op 1 over te zetten naar InTune? Ik zie wel een powershell optie maar voor de rest is keuze aan policies redelijk beperkter dan GPO's.
- Zijn er commercieel best practices of bvb policies die bedrijf A kan voorstellen aan klanten om ze te overhalen. Klinkt vaag maar ik probeer met voor te bereiden om de meest common questions zoals koppelen van fileshares, koppelen van printers....
...

Vraag 1: Ja, Intune Administrator (via admin.microsoft.com)
Vraag 2: Ja, on-premise policies exporteren en deze in Intune importeren. Dit kun je doen via Microsoft Endpoint Manager admin center -> Devices -> Group Policy Analytics (Preview).
Deze analyseert je bestaande policies en geeft aan in hoeverre Intune (of Endpoint tegenwoordig) hiermee compatible is
Vraag 3: Dat ligt aan de wensen / eisen van de klant. Enkele mooie opties:
- AutoPilot (vereist ook een Azure licentie)
- Volledig beheer van je apparatuur in de cloud (geen hardware meer onsite)
- MDM voor mobiele toestellen zoals Android en Apple
- Etc..
- Etc..

[Echelon2011]

Ik loop wat voor op de feiten maar stel dat er klanten zijn met on-prem nog ADs met GPOs.
Die kan bedrijf A niet gaan uitlezen via Intune Endpoint Manager admin center.
Is het dan mogelijk die lokaal te exporteren en alsnog in Analytics nagekeken worden?
Om eerlijk te zijn... ik voel de microsoft bui al hangen

[nextware]

Echelon2011 schreef op woensdag 22 februari 2023 @ 12:02:
Ik loop wat voor op de feiten maar stel dat er klanten zijn met on-prem nog ADs met GPOs.
Die kan bedrijf A niet gaan uitlezen via Intune Endpoint Manager admin center.
Is het dan mogelijk die lokaal te exporteren en alsnog in Analytics nagekeken worden?
Om eerlijk te zijn... ik voel de microsoft bui al hangen

Je kunt op ieder willekeurig moment een export maken van je GPO's en die in Endpoint laten controleren. Maar mijn optie zou zijn om hier van te voren al mee te gaan beginnen voor je devices in Endpoint hangt.

[Echelon2011]

Dat is uiteindelijk ook de bedoeling.
Eigenlijk is heel het feitelijk opzetten en testen hier niet nodig met een endpoint maar als we er dan toch mee bezig zijn kan ik me moeilijk inhouden.

Maar dat zou dus eigenlijk de opzet uiteindelijk worden.
Een nazicht in de infra van de klant en een export van GPO's naar Intune om dan (hopelijk) te kunnen aantonen dat we de verkochte laptops ook via InTune aan alle GPOs kunnen onderwerpen.

Voor zover ik kan zien heb ik in de admin console 3 types van policies teruggevonden...
1. Compliance policies. Redelijk summier maar de requirement voor encryptie is al gelukt... nadat ik een TPM had toegevoegd in VMware

2. Security policies. Zaken als attack surface, firewall, etc...

3. Configuration profiles. Hier hoop ik dus ADMX files in te importeren nadat ik ze heb gechecked in GP Analytics(?)

En dan nog ergens Policy Sets maar daar kan ik voorlopig nog niets selecteren.

[ Voor 4% gewijzigd door Echelon2011 op 22-02-2023 12:36 ]

[nextware]

Echelon2011 schreef op woensdag 22 februari 2023 @ 12:33:


3. Configuration profiles. Hier hoop ik dus ADMX files in te importeren nadat ik ze heb gechecked in GP Analytics(?)

En dan nog ergens Policy Sets maar daar kan ik voorlopig nog niets selecteren.

In die analyzer voer je de export in van je on-premises GPO's in XML formaat
En vanuit daar kun je dan kijken welke policies compatible zijn met Endpoint en op die manier je ADMX aanpassen nadat je die hebt geïmporteerd.

[TheVMaster]

Echelon2011 schreef op woensdag 22 februari 2023 @ 12:02:
Ik loop wat voor op de feiten maar stel dat er klanten zijn met on-prem nog ADs met GPOs.
Die kan bedrijf A niet gaan uitlezen via Intune Endpoint Manager admin center.
Is het dan mogelijk die lokaal te exporteren en alsnog in Analytics nagekeken worden?
Om eerlijk te zijn... ik voel de microsoft bui al hangen

Ja hoor je kunt ze lokaal exporteren en dan in het Intune Admin Center inlezen (en ja, het heet weer Intune sinds een tijdje)

Wat voor Microsoft bui voel je al hangen?

[ Voor 4% gewijzigd door TheVMaster op 23-02-2023 11:07 ]

[Echelon2011]

En het is weer maandag vandaag
Aan de hand van wat info hier mij verdiept in InTune en de policies en we staan toch heel wat verder.
Ik schrijf ze hier maar neer. Wie weet is er iemand nog iets mee of halen we er nog incorrecte dingen uit

Intune Policies

• Conditional access policies
• App Protection Policies
• App Configuration Policies
• Device compliance policies

Configuration Profiles

dit is wat het dichtst aansluit op de vertrouwde GPO's voor Windows machines.
2 opties hier:

1. Templates
2. Settings Catalog

OMA URI Custom Templates

Bovenstaande is wat beperkt dus dit kan nog uitgebreid worden met een Custom Template.
Daar kunnen we via OMA URI nog iets verder gaan registersleutels om bepaalde instellingen te krijgen ism CSP.

Group Policy Analytics

Tot zover de kant van Intune.
Maar wat als er on-prem GPOs zijn?
Dan komen we bij de opmerking van @nextware

• Exporteren van de on-prem AD DS de GPOs naar ADMX
• importeren in de Group Policy Analytics tool
• Deze geeft dan een compliance overzicht van waaruit je verder kan

De Microsoft bui

@TheVMaster

Azure AD

Dat is niet echt 1 op 1 de online versie van AD DS
Je voelt aan alles dat dit niet hetzelfde doel heeft als een on-prem server.
Het gaat bij Azure om User authenticatie naar cloud stuff en beheren van applicaties en toegang.
Ideaal voor cloud native setups maar je ontbreekt gewoon de diepte van een AD DS omgeving met domains, forests en vooral OU's waardoor het toch wat ontbreekt aan fijnere en diepere beheren van policies.

ADMX en Intune is meh

Dat importeren is mooi maar ze spelen niet goed samen.
Kans dat je 100% compliant policies uit de Policy Analytics tool krijgt is klein en dan begint het gepuzzel en afwegen of die Intune nog wel opweegt tegen de policies die je opoffert.

OMA URI is nog meer meh

Lijkt allemaal heel leuk maar buiten het feit dat die dingen ontiegelijk tijdrovend en onoverzichtelijk zijn stel ik mij vragen op beheer naar lange termijn. Je krijg al snel een gigantische lijst van policies en als je eentje verwijderd... vraag ik me af of op de toestellen dan proper alles terug naar standaardwaarden wordt gezet. Lijkt me al snel een chaos te worden.

Conclusie

Je kan als service provider een toegevoegde waarde creëren naar klanten die hun huidige activiteiten willen verleggen of uitbreiden richting BYOD, Home Office users met eigen laptops, tablets... maar een flawless 1 op 1 migratie van lokale GPO's uit AD DS naar Microsoft Intune komt met wat kanttekeningen. Ik schat het meest voorkomende scenario in op een hybride situatie waarin een balans zal moeten gezocht worden tussen GPOs en Intune waarbij we moeten opletten dat er geen Policy Conflicts zijn door MDM policies de overhand te laten hebben op GPO's

GPO's are not dead (yet)

[TheVMaster]

Echelon2011 schreef op maandag 27 februari 2023 @ 11:47:
En het is weer maandag vandaag
Aan de hand van wat info hier mij verdiept in InTune en de policies en we staan toch heel wat verder.
Ik schrijf ze hier maar neer. Wie weet is er iemand nog iets mee of halen we er nog incorrecte dingen uit

Intune Policies

• Conditional access policies
• App Protection Policies
• App Configuration Policies
• Device compliance policies

Configuration Profiles

dit is wat het dichtst aansluit op de vertrouwde GPO's voor Windows machines.
2 opties hier:

1. Templates
2. Settings Catalog

OMA URI Custom Templates

Bovenstaande is wat beperkt dus dit kan nog uitgebreid worden met een Custom Template.
Daar kunnen we via OMA URI nog iets verder gaan registersleutels om bepaalde instellingen te krijgen ism CSP.

Group Policy Analytics

Tot zover de kant van Intune.
Maar wat als er on-prem GPOs zijn?
Dan komen we bij de opmerking van @nextware

• Exporteren van de on-prem AD DS de GPOs naar ADMX
• importeren in de Group Policy Analytics tool
• Deze geeft dan een compliance overzicht van waaruit je verder kan

De Microsoft bui

@TheVMaster

Azure AD

Dat is niet echt 1 op 1 de online versie van AD DS
Je voelt aan alles dat dit niet hetzelfde doel heeft als een on-prem server.
Het gaat bij Azure om User authenticatie naar cloud stuff en beheren van applicaties en toegang.
Ideaal voor cloud native setups maar je ontbreekt gewoon de diepte van een AD DS omgeving met domains, forests en vooral OU's waardoor het toch wat ontbreekt aan fijnere en diepere beheren van policies.

ADMX en Intune is meh

Dat importeren is mooi maar ze spelen niet goed samen.
Kans dat je 100% compliant policies uit de Policy Analytics tool krijgt is klein en dan begint het gepuzzel en afwegen of die Intune nog wel opweegt tegen de policies die je opoffert.

OMA URI is nog meer meh

Lijkt allemaal heel leuk maar buiten het feit dat die dingen ontiegelijk tijdrovend en onoverzichtelijk zijn stel ik mij vragen op beheer naar lange termijn. Je krijg al snel een gigantische lijst van policies en als je eentje verwijderd... vraag ik me af of op de toestellen dan proper alles terug naar standaardwaarden wordt gezet. Lijkt me al snel een chaos te worden.

Conclusie

Je kan als service provider een toegevoegde waarde creëren naar klanten die hun huidige activiteiten willen verleggen of uitbreiden richting BYOD, Home Office users met eigen laptops, tablets... maar een flawless 1 op 1 migratie van lokale GPO's uit AD DS naar Microsoft Intune komt met wat kanttekeningen. Ik schat het meest voorkomende scenario in op een hybride situatie waarin een balans zal moeten gezocht worden tussen GPOs en Intune waarbij we moeten opletten dat er geen Policy Conflicts zijn door MDM policies de overhand te laten hebben op GPO's

GPO's are not dead (yet)

Heb jij een auto-correct aanstaan, dat je elke keer IntTune typt?

Jij blijft trouwens met het ADDS en OU's wel beetje in de oude wereld hangen. Ik ken maar weinig (zelfs grote enterprises) die niet gewoon helemaal over gaan naar Intune voor het beheer (incl policies) voor hun werkplekken.

Het overstappen naar een moderne werkplek (met Autopilot en managed door Intune) ook een goed moment om eens kritisch naar je policies te kijken en niet alles zomaar 1 op 1 over te willen zetten. Ik moet de eerste (grote) klant nog tegenkomen die precies weet waar alle policies ook (alweer) voor gebruikt worden, dus het gros van de 'oude rommel' kan vaak worden afgevoerd bij een move naar Intune. Opgeruimd staat netjes.

[ Voor 5% gewijzigd door TheVMaster op 27-02-2023 13:06 ]

[HKLM_]

Wat is de reden om voor hybride te gaan? Dit is 9/10 gevallen helemaal niet nodig.

Wij hebben bijvoorbeeld nog een on-prem fileserver maar rollen wel alles AAD uit.

[TheVMaster]

HKLM_ schreef op maandag 27 februari 2023 @ 13:06:
Wat is de reden om voor hybride te gaan? Dit is 9/10 gevallen helemaal niet nodig.

Wij hebben bijvoorbeeld nog een on-prem fileserver maar rollen wel alles AAD uit.

Inderdaad. Ik moet eerlijk zeggen dat alle projecten waar ik het laatste jaar bij betrokken ben gaan met hun nieuwe werkplek naar AAD only. Hybrid zie ik bijna niet meer. Daarnaast zie ik ook steeds vaker beweging om weg te gaan van ADFS (voor zover klanten dat nog gebruiken) ,dat is overigens ook wat je Microsoft ziet roepen.

[Lelletje]

Wij hebben inderdaad on-prem werkplekken, die we nu aan het omzetten zijn naar werkplekken via Intune.

Daarbij hebben we de hele situatie opnieuw in kaart gebracht, waar moet het aan voldoen etc. Daarbij kijken we dan niet naar de oude situatie, maar bouwen we het gewoon van scratch op.

Dan ga je de testfase in en ga je de bevindingen onderzoeken en verbeteren/oplossen.

Hiermee is het ook veel makkelijker om afscheid te nemen van de oude omgeving.

[Acradavos]

HKLM_ schreef op maandag 27 februari 2023 @ 13:06:
Wat is de reden om voor hybride te gaan? Dit is 9/10 gevallen helemaal niet nodig.

Wij hebben bijvoorbeeld nog een on-prem fileserver maar rollen wel alles AAD uit.

Wellicht nog een oude legacy applicatie.

[HKLM_]

Lelletje schreef op maandag 27 februari 2023 @ 13:09:
Wij hebben inderdaad on-prem werkplekken, die we nu aan het omzetten zijn naar werkplekken via Intune.

Daarbij hebben we de hele situatie opnieuw in kaart gebracht, waar moet het aan voldoen etc. Daarbij kijken we dan niet naar de oude situatie, maar bouwen we het gewoon van scratch op.

Dan ga je de testfase in en ga je de bevindingen onderzoeken en verbeteren/oplossen.

Hiermee is het ook veel makkelijker om afscheid te nemen van de oude omgeving.

Die oude omgeving soms aardig in de weg zitten maar. Via intune is gewoon een hoop mogelijk. Ik “support” nog een CRM 4.0 met IE wensen… en zelfs dat gaat prima via Intune.

[HKLM_]

Acradavos schreef op maandag 27 februari 2023 @ 13:10:
[...]

Wellicht nog een oude legacy applicatie.

Als je synct accounts hebt via Azure AD connect of Cloud Sync gaat alle authenticatie gewoon mee

Zie mijn post over CRM, dat ding komt uit fucking 2007 (wil je het nog ouder?)

[ Voor 13% gewijzigd door HKLM_ op 27-02-2023 13:12 ]

[Acradavos]

HKLM_ schreef op maandag 27 februari 2023 @ 13:11:
[...]


Als je synct accounts hebt via Azure AD connect of Cloud Sync gaat alle authenticatie gewoon mee

Zie mijn post over CRM, dat ding komt uit fucking 2007 (wil je het nog ouder?)

Sorry, ik dacht dat het ging over de legacy applicaties, niet over authenticatie.

[Echelon2011]

@TheVMaster
Ik heb op dit moment enkel een Frans AZERTY keyboard layout ter beschikking.
En op 1 of andere bizarre reden heb ik daar steeds de neiging op om InTune te typen

Ik lees:
1. Alles wordt uitgerold in AAD. Je blijft hangen in het verleden
2. Misschien eens tijd om te kijken naar die GPOs

Dat klopt volledig.
En ik heb dat ook mee opgenomen in mijn aanpak.
Een soort van workflow dat we als opzet kunnen gebruiken als we de Intune vraag krijgen van klanten.
(en vooral gebaseerd op GPO in dit geval, dat was mijn deel van het verhaal)

Grosso Modo is het

Onderzoeken en in kaart brengen
- Wat is de wens van de klant?
- Wat is de huidige situatie?
- Indien AD DS > Welke GPO's zijn er op dit moment?
Ik vul dit aan met
- En welke zijn daarvan nog nodig?

Overzetten
Ik vul aan met:
- Kunnen we van 0 beginnen of moeten zaken echt overgezet worden
- Wat kunnen we afdekken met de Configuration Profiles (nieuwe settings catalog + templates)
- Wat kunnen we doen met de Custom Templates met OMA URI
- Wat kunnen uit de Group Policy Analytics leren?

Hopelijk brengt dat alles ons tot op het punt dat we inderdaad zaken vanuit Intune kunnen beheren.
Worst case scenario moet ik wel de optie openhouden dat er een hybride situatie ontstaat.
Maar dan nog kan het geen kwaad om Intune etc al binnen te brengen bij klanten?
Wat vandaag niet is kan maar al klaar staan voor de toekomst.

[ Voor 60% gewijzigd door Echelon2011 op 27-02-2023 15:47 ]

[TheVMaster]

Echelon2011 schreef op maandag 27 februari 2023 @ 14:39:
@TheVMaster
Ik heb op dit moment enkel een Frans AZERTY keyboard layout ter beschikking.
En op 1 of andere bizarre reden heb ik daar steeds de neiging op om InTune te typen

Vandaar

Ik lees:
1. Alles wordt uitgerold in AAD. Je blijft hangen in het verleden
2. Misschien eens tijd om te kijken naar die GPOs

Dat klopt volledig.
En ik heb dat ook mee opgenomen in mijn aanpak.
- Wat kunnen we wel/niet overzetten?
- Wat kan opgekuist worden?
Het doel is wel degelijk om die stap naar AAD zo compleet mogelijk te realiseren.
Maar zonder dat we iets over het hoofd zien.

Wat ik vaak aan klanten adviseer is om niet te kijken wat je in AD/GPO hebt zitten, maar wat zijn de requirements (vanuit security / organisatie) om zo met een echte schone lei te kunnen beginnen. Dat scheelt een boel uitzoekwerk. Het probleem met veel 'oude' policies is dat er vaak niemand meer is die weet waarom ze gezet zijn, maar niemand er ook afscheid van durft te nemen. Bij een migratie naar Intune heb je een uitgelezen moment om weer eens naar de requirements te kijken en helemaal opnieuw te beginnen.

Maar het verhaal startte als service provider die met klanten (KMOs van 10 tot 100 werkplekken) in contact kwam omwille dat daarvoor reeds hardware wordt voorzien (vandaar de ongekende wereld van Intune,... )
De situatie is niet interne infrastructuur of een eigen IT roadmap waar we in alle vrijheid over kunnen beslissen.

Juist bij die kleine omgevingen is het een no-brainer om volledig naar de cloud te gaan lijkt mij. Ik kom met name in omgevingen van 10.000 werkplekken en (veel) groter en zelfs daar is het een no-brainer om werkplekken (vaak) naar Intune te duwen en af te komen van ConfigMgr of andere 3rd party management oplossingen.

maar het hangt van toch wat factoren af.
Maar de grootste horde blijkt inderdaad mijn eigen angstvallig vasthouden aan die oude klassieke on-prem setup.
Mij leek binnen de beperkte kennis die ik de afgelopen week heb opgedaan nog niet het moment om 1 op 1 volledig te kunnen migreren naar Intune.
Maar naarmate ik me er verder in verdiep zal mijn mening nog wel draaien

Ach, ik doe bijna 10 jaar voornamelijk maar Intune (, Autopilot, etc). Dan kijk je er onderhand ook wat anders naar. Al snap ik best, dat als het allemaal nog redelijk nieuw voor je is, je er nog een beetje op een meer traditionele manier naar kijkt.

En een klein nazicht toont al aan dat er inderdaad opkuis mee nodig kan zijn:
...software\policies\microsoft\office\16.0\lync...
Die gaat niet meer van toepassing zijn denk ik

Nee, ik mag hopen dat Lync niet meer gebruikt wordt idd.

[Echelon2011]

@TheVMaster
je hebt zaken gequote uit een post die ik aangepast had. Sorry daarvoor maar daarom niet minder nuttig

[TheVMaster]

Echelon2011 schreef op maandag 27 februari 2023 @ 14:39:
[.......]

Grosso Modo is het

Onderzoeken en in kaart brengen
- Wat is de wens van de klant?
- Wat is de huidige situatie?
- Indien AD DS > Welke GPO's zijn er op dit moment?
Ik vul dit aan met
- En welke zijn daarvan nog nodig?

Overzetten
Ik vul aan met:
- Kunnen we van 0 beginnen of moeten zaken echt overgezet worden
- Wat kunnen we afdekken met de Configuration Profiles
- Wat kunnen we doen met de Custom Templates met OMA URI
- Wat kunnen uit de Group Policy Analytics leren?

Vergeet ook vooral (nieuwe) Settings Catalog niet (dat is wat anders dan de 'standaard Configuration Profiles Templates'), daar zul je de meeste nieuwe policies in terecht zien komen.

Hopelijk brengt dat alles ons tot op het punt dat we inderdaad zaken vanuit Intune kunnen beheren.
Worst case scenario moet ik wel de optie openhouden dat er een hybride situatie ontstaat.
Maar dan nog kan het geen kwaad om Intune etc al binnen te brengen bij klanten?
Wat vandaag niet is kan maar al klaar staan voor de toekomst.

Wat zou er voor kunnen zorgen dat je nog hybride zou moeten gaan dan? Als een klant nu al ConfigMgr heeft, dan zou je kunnen beginnen met het toevoegen van Co-Management en dan dus ook het 'aanzetten' van Intune. Kost je weinig inspanning (en moeite) maar je kunt dan langzaam workloads richting de cloud duwen en parallel daaraan zou je dan nieuwe clients al native aad kunnen enrollen (en testen) of alles nog steeds goed werkt. Ook vanuit een native AAD machine kun je Co-management toevoegen (zodat je ook nog zaken vanuit ConfigMgr kunt laten lopen, indien gewenst.

Echelon2011 schreef op maandag 27 februari 2023 @ 14:55:
@TheVMaster
je hebt zaken gequote uit een post die ik aangepast had. Sorry daarvoor maar daarom niet minder nuttig

Ik zag het

[Echelon2011]

[b]TheVMaster schreef op maandag 27 februari 2023 @ 15:24:

Als een klant nu al ConfigMgr heeft, dan zou je kunnen beginnen met het toevoegen van Co-Management en dan dus ook het 'aanzetten' van Intune. Kost je weinig inspanning (en moeite) maar je kunt dan langzaam workloads richting de cloud duwen en parallel daaraan zou je dan nieuwe clients al native aad kunnen enrollen (en testen) of alles nog steeds goed werkt. Ook vanuit een native AAD machine kun je Co-management toevoegen (zodat je ook nog zaken vanuit ConfigMgr kunt laten lopen, indien gewenst.

Ook dat ben ik aan het bekijken.
Ik was het onderwerp tegengekomen in de MD101 learning path.
Ik ga de komende dagen eens een lab setup opzetten in vm workstation zoals hier wat wordt beschreven.
Benieuwd of ik vanuit een VMware workstation met Azure AD Connect can syncen naar die DEV tenant die ik heb opgezet.

[akimosan]

Bij elke migratie moet je opnieuw beoordelen wat je wel overzet en wat niet.

1 op 1 alles overzetten is ook meenemen van vaak een hoop ellende en flink knutsel en plakwerk om alles aan elkaar te houden, dat is wat ik vaak zie met "policies" bij MKB.
Elke denkbare instelling in een policy, "omdat het kan" en niet omdat het "beleid" is.

Lean & Mean scheelt je flink in het overzicht en fris en fruitig starten kan leiden tot veel opluchting bij beheerders en eindgebruikers.
Als je dan toch een DEV tenant aan het opzetten bent, waarom dan AD connect?

Regel 1: bij weinig GPO's en instellingen:
Vergeet zoveel mogelijk het oude, begin opnieuw en zet datgene aan met configuration profiles wat je nodig hebt
Vergeet de security baseline niet! Daar staan al heel veel instellingen in voorgeconfigureerd die mgelijk overlappen (of conflicteren) met bestaande policies
Regel 2: Bij veel GPO's en instellingen (meestal de "puinhoop"):
Wees kritisch en haal de bezem erdoor. Breng terug naar de basis, wat is er nu echt nodig?
Goede kans dat je hierna weer met regel 1 kunt beginnen

[Echelon2011]

akimosan schreef op maandag 27 februari 2023 @ 21:26:

Als je dan toch een DEV tenant aan het opzetten bent, waarom dan AD connect?

Omdat ik het antwoord wil vinden op de vraag of ik vanuit een VM met trial versie van server 2019 een domain controller kan opzetten met AD DS en daar een sync kan doen naar een Microsoft 365 DEV tenant...
Net zoals ik mij afvroeg of je in die DEV tenant een account kan aanmaken en die volledig functioneel kan laten aanloggen op Teams. En jawel...

maar uw reactie past nog steeds in de workflow die ik voorlopig hier heb:
- Nagaan wat er is en vanuit onze kennis analyseren en adviseren of het echt nog nodig is
- Dat wat er overblijft aftoetsen aan Configuration Profiles, Custom Templates of ADMX import.

Het verhaal is en blijft wel dat de klant koning is. Hoe erg het ook moge zijn...
Ik ben er heel wat tegengekomen met dure mooie titels als Senior Infra Manager of IT Director... waar ik een paar keer met mijn ogen moet rollen als ze hun mond opendoen.

[ Voor 31% gewijzigd door Echelon2011 op 28-02-2023 08:32 ]

[Echelon2011]

ps nog een vraagje:
1 van de redenen waarom ik een Azure AD Connect zou gebruiken is om die accounts van AD DS naar de cloud te migreren.

Blijf je van daaruit AD beheren via on-prem?
Of is er een mogelijkheid om dan de banden te breken met die lokale domain controller en alles vanuit AAD te doen?

[akimosan]

Wanneer je Hybrid gaat werken, blijf je sommige dingen doen vanuit AD en sommige dingen vanuit AzureAD.

Het hangt ervan af of je ook gebruikmaakt van bijvoorbeeld Exchange Server of andere on-prem zaken die nog steeds AD moeten gebruiken.

AD en specifieke AD attributen blijf je eigenlijk beheren vanuit On-Prem
AAD vanuit Azure Portal (of andere tools/portals als Powershell / Microsoft Admin Center, etc)

AzureAD connect synced enkel die objecten en attributen die je specificeert in de connect config.

Dus om een voorbeeld te geven:

• Je synct Petra Puk , inlognaam [e-mail] naar AzureAD
• Je krijgt een verzoek om de achternaam van Petra te wijzigen naar Jansen en de wijziging ook door te voeren in de inlognaam

Je wijzigt de naam en inlognaam op normale wijze in je on-prem omgeving en de wijziging wordt gesynced naar AzureAD

Is er een mogelijkheid om later de banden te breken vanuit hybrid naar AzureAD?

Ja, als alle requirements voor je scenarios zijn voltooid zijn en het is tijd om de banden te verbreken, dan is er de optie om dat te doen. Het gaat te ver om hier antwoorden te geven op alle scenario's (Iets als Hybrid Exchange moet echt goed ontvlecht worden, maak je al gebruik van password hash sync, etc.) dus als het zover is zul je het plan moeten maken.
Voor user en group objects is het nog relatief simpel, voor AD joined machines is er niet echt een goede optie.
Eigenlijk betekent dat vrijwel altijd een reinstall en dan cloud only join, eventueel via Autopilot.
Daarom wordt het pad van Hybrid joined devices ook zo vaak vermeden omdat je er dan later geen rekening mee hoeft te houden.