Waarom worden niet werkende windowsdingen er er dan niet uitgehaald?

Omdat het heel vervelend is als jouw scripts en policy files ineens ongeldig zijn en foutmeldingen veroorzaken. En je dus moet gaan uitzoeken wat er aan de hand is. Het is beter dat Microsoft een optie zinloos maakt een adviseert deze te verwijderen.

Omdat ze dit enkel doen om beheerder te pesten naar hun idee van netwerk runnen waarbij M$ bepaalt wanneer iets moet gebeuren.

Voorbeeld
Allows the IT admin to restrict the updates that are installed on a device to only those on an update approval list. It enables IT to accept the End User License Agreement (EULA) associated with the approved update on behalf of the end user. EULAs are approved once an update is approved.

M$ hun response:
Deprecated already, replaced with Require Update Approval - which is now also being deprecated.


Tentijde van XP en W7 kon je als beheerder alles exact regelen zonder tramalant.
Gebruikers werden nooit lastig gevallen met update meldingen als je dat wou. Die kon je verbergen en vervolgens gepland en approved runnen rond tijden dat ze er geen last van hadden.. Nu kun je niet eens specificeren wanneer een failed update request een retry doet waardoor het altijd de gebruiker nu stoort,

Ik ken beheerders die op beveiliging policies na niet eens meer de moeite nemen om group policies aan te maken omdat M$ van de ene op de andere release zonder aankonding besluit iets ongedaan te maken. Maar ik ken ook beheerders die dit als oorlogs verklaring zien en heel W10 hebben gesloopt en alle policies er middels hacks in hebben gekregen en nooit meer Windows updater gebruiken maar alle kb's los installeren of runnen vanuit een non M$ deployment service.

Hoe dan ook als een bedrijf begint met vertellen dat ze geluisterd hebben naar de community feedback kun je 9 van 10 keer van uit gaan dat ze er niks gedaan mee hebben en hun eigen visie je de strot door duwen ook al levert het braakneigingen op bij de gebruikers.

Omdat een policy geen software is, maar een regel die je hebt afgesproken om uit te voeren als een situatie zich voordoet. Zoiets kun je op een bepaalde manier configureren, bijvoorbeeld nieuwe updates alleen maar automatisch downloaden en nog niet installeren, of wel installeren maar alleen op vooraf bepaalde machines.

Bang dat hetv dan helemaal niet meer werkt. Oude techniek: IF IT RUNS DON'T TOUCH IT

Spaghetticodebouwwerk. Een kenmerk van spaghetticode is dat alles maar dan ook echt alles op de meest ondoorzichtige wijzen aan elkaar hangt. Dan kan je er niet zomaar iets uithalen want dan maak je iets anders kapot en je weet meestal niet wat dat is en waar het is.

Deze policies zijn nutteloos voor Windows 10/11 maar nog wel nodig voor Windows XP/7/8. Als Microsoft ze via een update zou verwijderen valt het update proces van heel veel organisaties om.

Daarom is het ook zeer onverstandig om van Microsoft producten verschillende versies en ook talen te hebben draaien. Oftewel een monocultuur is het makkelijkst maar ook het gevaarlijkst.

Vendorlock-in zelfs binnen versie en taal? Dan is het nog veel erger dan ik al vreesde!

Jemig wat een reacties op dit forum...
Deze is dan nog het meest ontopic...

Policies zijn niet meer dan instellingen die uiteindelijk op een werkplek/server een registry plaatst, that's it...
Op dit moment heb je ADMX templates voor meerdere operating systemen, bv. apart voor Windows 10 en 11.
Wanneer je een ADMX in zou laden van Windows 11, daar policies mist voor Windows 7,8 of 10, dan valt er echt niets om.
Je ziet de policies alleen niet meer in Group Policy Management console, maar als je in het verleden iets hebt ingesteld worden deze alsnog gebruikt.

Als voorbeeld:
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/windows-10-or-windows-11-gpo-admx-which-one-to-use-for-your/ba-p/3063322

Het is maar een advies wat hier wordt neer gepost.

Dat men dat doet in windows11 - akkoord - maar als je midden in windows10 zo'n belangrijke details wijzigt - dan ben je echt niet goed bezig!

Wanneer je over aan het gaan bent van de ene naar de andere versie, zul je proberen om de verbeteringen uit het nieuwe systeem ook in het oude te krijgen. Verder is het logisch, omdat je dan de policies al goed kunt hebben, voor je naar die nieuwe omgeving gaat.

Ja het is heel erg. Ik heb eens door gebruik van een Engelse versie van een MS tool heel (in een NL omgeving) AD corrupt gemaakt

Dat is waar, maar ...

Veel configuratie ligt ook hard-coded in vast in de programmatuur, veelal als defaults - hoe beter de defaults zijn gekozen des te minder zal de gebruiker genoodzaakt zijn daar een andere waarde overheen in te stellen. Het vinden van goede defaults vergt veel inspanning, ook omdat als het heuristische waarden zijn wat vaak het geval is, redelijke defaults testen testen testen betekent. Daarbij, voor declaratieve systemen (non-procedureel) is configuratie de functionaliteit.
Kortom: de scheiding tussen code en configuratie is minder hard dan je zou denken.

Voor MS Windows kun je stellen dat er meer te configureren valt dan zinnig doenlijk is (i.p.v. dat de ontwikkelaar een verstandige waarde codeert) én dat veel wat je zou kunnen configureren hard gecodeerd blijkt. Ik heb het gevoel dat de meeste Linux distributies die complexe balans beter weten te vinden.

Als je ooit de MFC class library hebt gebruikt en bestudeerd - heel veel programmatuur W32 is daarop gebouwd - dan begrijp je waartoe dat leidt: niet onderhoudbare bagger. De maatschappij betaalt daar nog steeds een hoge prijs voor.

Een update voor een bepaalde versie van MS Windows raakt toch niet andere (major) versies ?
Aangenomen dat updates versie-specifiek zijn, zou wijziging van een (default) policy middels een update andere versies onverlet laten.

Klinkt redelijk, maar is toch niet zo simpel. In een release zijn verschillende (versies van) componenten in samenhang afgestemd en daarop getest (extreem voorbeeld: een nieuwe versie van een runtime lib met een andere ABI gaan gebruiken geeft grote problemen) en verandering van policies kunnen ook de samenhang raken.