[GPO] Functie van bestand "admfiles.ini"

[Vliegvlug]

Daar ik momenteel de mogelijkheden aan het onderzoeken ben hoe de grootte van de policies in de SYSVOL te verkleinen liep ik tegen het bestand "admfiles.ini" aan.
Dit bestandje is te vinden in de 'adm' subfolder van de betreffende policy op de SYSVOL, de plek waar ook de adminstrative templates voor die policy worden opgeslagen.

Bij Microsoft is er bijna niets over de functie en werking van dit bestand te vinden afgezien van het onderstaande:

The list of selected .adm files is stored in the Sysvol GPO folder in the Admfiles.ini file. (bron)

Dit klinkt erg interessant omdat ik van plan ben de administrative templates (.adm bestand) van de SYSVOL te verwijderen en te consolideren op een beheerserver waarop voortaan de policies aangepast gaan worden.
Dat scheelt bijna 3GB op de SYSVOL. Het zijn nogal veel policies namelijk.

Nadeel van het bij elkaar opslaan van alle .adm bestanden is echter dat GPedit bij het bewerken van elke policy dan meteen alle templates inlaad en weergeeft waardoor de interface nogal onoverzichtelijk wordt. Wanneer het nog op de SYSVOL staat heb je dit probleem niet omdat per policy alleen de templates geladen worden die onder die policy aanwezig zijn.

Vandaar mijn interesse in de functie van admfiles.ini. Als ik dit kan gebruiken om ervoor te zorgen dat GPedit alleen de daarin vermelde templates laad kan ik voorkomen dat de GPedit interface onoverzichtelijk.

De structuur van admfiles.ini lijkt simpel genoeg, standaard staat er dit in.

code:

[FileList]
system.adm=1
inetres.adm=1
conf.adm=1
wmplayer.adm=1
wuau.adm=1

Dat zijn de standaard templates die bij het aanmaken van een GPO worden geladen.
Je zou dus denken dat hierin de bij de policy behorende templates worden bijgehouden.

Dat blijk echter niet het geval, wanneer een custom template wordt toegevoegd verschijnt deze niet in de lijst.

Ik heb de hele SYSVOL gescand op de inhoud van admfiles.ini en die ziet er altijd uit zoals hierboven terwijl er echt voldoende custom templates aanwezig zijn in het domein.

Kortom het lijkt er heel sterk op dat het bestand gewoonweg genegeert wordt.

De enige activiteit waarop ik het bestand heb kunnen betrappen is dat als je het handmatig verwijderd het automatisch terugkomt als je de policy met GPedit opent.
En dat wanneer je het bestand bewerkt en alle verwijzingen naar template bestanden verwijderd en alleen [Filelist] laat staan er automatisch twee template verwijzingen worden teruggezet na het openen van de policy in GPedit. Dan ziet het bestand er daarna zo uit:

code:

[FileList]
wmplayer.adm=1
wuau.adm=1

Verrassend dat de overige 3 standaard templates niet terugkomen.
Binnen GPedit zijn dan nog steeds wel alle templates geladen dus zelfs voor de default templates lijkt admfiles.ini genegeerd te worden.

Samengevat is mijn vraag dus of iemand weet of admfiles.ini überhaupt te gebruiken is om te bepalen welke administrative templates er binnen GPedit worden weergegeven.
En zo niet waar het dan wel voor dient.

[alt-92]

Vliegvlug schreef op donderdag 03 juli 2008 @ 15:09:
Dit klinkt erg interessant omdat ik van plan ben de administrative templates (.adm bestand) van de SYSVOL te verwijderen en te consolideren op een beheerserver waarop voortaan de policies aangepast gaan worden.
Dat scheelt bijna 3GB op de SYSVOL. Het zijn nogal veel policies namelijk.

Dan zou je alvast kunnen kijken naar de manier waarop Vista/2008 Admx templates op een Windows 2003 Domain Controller Server via een centrale repository gebruikt kunnen worden.

Bij je plan moet ik wel één kanttekening plaatsen, en die is dat je erg voorzichtig moet zijn omdat je met oudere clients (2000/XP/2003) te maken hebt die verschillend omgaan met een dergelijke wijziging.
(lees: bij ontbreken van de \SYSVOL gpo's wordt er uitgeweken naar de lokale GPO ADMs - en weg is je controle).

[Vliegvlug]

alt-92 schreef op donderdag 03 juli 2008 @ 16:03:
[...]

Dan zou je alvast kunnen kijken naar de manier waarop Vista/2008 Admx templates op een Windows 2003 Domain Controller Server via een centrale repository gebruikt kunnen worden.

Daar heb ik inderdaad ook al vluchtig naar gekeken maar dan moeten de beheerservers wel 2008 of vista gaan draaien en dat is nog even geen optie.
Daarnaast meen ik dat je daar tegen hetzelfde punt aanloopt dat alle template in de interface worden geladen, maar ik kan me vergissen want heb er maar kort naar gekeken.
En het probleem wat je hieronder schets doet zich dan ook voor, GPO aanpassen met oudere clients geeft dan hetzelfde probleem van uitwijken naar lokale adm's.

Bij je plan moet ik wel één kanttekening plaatsen, en die is dat je erg voorzichtig moet zijn omdat je met oudere clients (2000/XP/2003) te maken hebt die verschillend omgaan met een dergelijke wijziging.
(lees: bij ontbreken van de \SYSVOL gpo's wordt er uitgeweken naar de lokale GPO ADMs - en weg is je controle).

Dank voor de waarschuwing maar daar ben ik al helemaal van op de hoogte. De "Always use local ADM files for Group Policy editor" policy werkt inderdaad niet onder 2000 en XP.
Dit is echter al procedureel afgedekt doordat alleen GPO aanpassingen vanuit de beheerservers worden ondersteund.

Wat wel echt een probleem is bij het weghalen van de adm files van SYSVOL is dat Group Policy Management Console (GPMC) en GPedit helaas heel verschillend omgaan met de locatie van adm files. Hier kwam ik gisteren met testen achter.

Wanneer de policy is aangezet dat GPedit alleen nog lokaal kijkt kan je de adm bestanden in SYSVOL verwijderen en alle adm's lokaal op een beheerserver consolideren. Daar is ook een mooi Microsoft artikel over.

Dit levert echter verrassend genoeg een probleem op met de reporting van GPMC. Dit zou je niet verwachten aangezien deze standaard staat ingesteld op "The console searches the local Windows folder, then the GPO folder in de SYSVOL folder."
Voor de standaard adm files gaat dat helemaal goed maar custom templates weigert GPMC te gebruiken wanneer deze enkel lokaal staan. Dan worden de betreffende settings onder de "Extra Registry Settings" van het report geplaatst met de melding dat er geen bijbehorende adm kan worden gevonden.
Wanneer ik enkel de custom templates op de SYSVOL laat staan gaat het wel helemaal goed, de standaard adm's worden dan vanaf de lokale folder ingelezen en de customs van de SYSVOL en het report is dan helemaal in orde. (Ik had nog even het idee dat GPMC wel naar admfiles.ini kijkt omdat hier natuurlijk alleen de standaard templates in vermeld staan maar helaas zorgde het toevoegen van de custom template hierin er niet voor dat GPMC de template nu wel vanaf de lokale folder laadde)

Nadeel van het gedrag van GPMC is dat ik dan de custom templates zowel lokaal (voor GPedit) als in de SYSVOL (voor GPMC) moet hebben.
Dit is dat wel weer te fixen door in GPMC bij de reporting opties deze hard in te stellen om te zoeken in "C:\Windows\Inf" (ook al wordt daar bij de standaard reporting instelling al gezocht ) want dan gebruikt hij de lokale custom templates wel.
Deze instelling levert dan weer een nieuw uitdaging, hoe ga ik deze gebruikersinstelling voor iedere beheerder opleggen?

Daarnaast staat de vraag waar admfiles.ini voor dient en of deze misschien gebruikt kan worden voor weergave filtering van administrative templates in GPedit ook nog open.

offtopic:
(Hmm, naast de initiële vraag heb ik er nu juist nog een vraag bij, schiet lekker op .)