[2000/2003] GPO en MSI verhuizen

[Profidiam]

Ik heb hier een beetje een vreemd vraagstuk ivm. de distributie/installatie van software dmv. gpo. Wij gebruiken deze techniek om al onze pc's te voorzien van de nodige software op computer basis en alle pakketten staan op een share op een bepaalde server (\\server1\software). Om bepaalde redenen moet deze server weg, dus die pakketten moeten daar ook weg.

Nu heb ik al gemerkt dat deze software share, ook al heb ik geen nieuwe clients in het netwerk gehangen, vrij vaak gebruikt wordt voor de reparatie van de software op de pc's. Logisch, daar is het voor gemaakt. Nu wil ik die pakketten gaan verhuizen, maar ik zie dat ik in de group policies dit pad naar de msi bestanden niet kan wijzigen.

Na heel wat gezoek blijkt dat ik dit inderdaad niet kan wijzigen. Nu dacht ik aan de volgende oplossing en vroeg mij af of jullie dit mogelijk achten, of misschien nog een andere oplossing zien.

1) server1 uit het domein halen/ buiten de kantooruren
2) op server2 exact dezelfde share aanmaken met de software in
3) in DNS voor server2 een CNAME maken met als naam server1

De clients denken nu dat ze met server1 praten, maar hebben eigenlijk server2 vast met dus alle software.

Nieuwe software wordt nu uitgerold op een DFS root, maar we hebben +- 40 pakketten die nog op de oude share staan.

[ Voor 0% gewijzigd door Profidiam op 24-11-2006 11:32 . Reden: Topicchange graag naar [2000/2003] GPO en MSI verhuizen ]

[sanfranjake]

Je moet dan misschien nog wel even een andere aanpassing doen: Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name

[djluc]

Je hebt de MSI's nog neem ik aan? Wat is dan het grote probleem om die 40 pakketten ook even op de DFS te zetten? Die 40 keer klikken ben je misschien even zoet mee maar het is wel een betere en meer toekomstgerichte oplossing.

[alt-92]

De info voor je packages staat normaliter in

code:

\\DomainController\SYSVOL\<domain>\Policies\{GUID}\Machine\Applications

in een ADE.cfg en een {GUID}.aas bestand.
De AAS is een binary formaat, maar de cfg kan je mogelijk wel editten.

Geen garanties dat er niks breekt hoor

[Profidiam]

sanfranjake schreef op zaterdag 25 november 2006 @ 09:43:
Je moet dan misschien nog wel even een andere aanpassing doen: Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name

Ok, dit kan ik doen en dan zou het kunnen werken ....

alt-92 schreef op zaterdag 25 november 2006 @ 12:56:
De info voor je packages staat normaliter in

code:

\\DomainController\SYSVOL\<domain>\Policies\{GUID}\Machine\Applications

in een ADE.cfg en een {GUID}.aas bestand.
De AAS is een binary formaat, maar de cfg kan je mogelijk wel editten.

Geen garanties dat er niks breekt hoor

Dit heb ik geprobeerd,maar zonder de (binaire) msi pakketten aan te passen lukt het volgens mij niet.

djluc schreef op zaterdag 25 november 2006 @ 11:46:
Je hebt de MSI's nog neem ik aan? Wat is dan het grote probleem om die 40 pakketten ook even op de DFS te zetten? Die 40 keer klikken ben je misschien even zoet mee maar het is wel een betere en meer toekomstgerichte oplossing.

Voor de nieuwe images zal dit inderdaad gebeuren, ook voor de oude images die op nieuwe pc's terechtkomen. Het probleem zit hem in de pc's die al msi pakketten ¨toegewezen hebben, je kan de installatie bron niet aanpassen en de msi's verwijderen en opnieuw toevoegen (met als pad de dfs) leidt tot herinstallatie en wachttijden met alle risico's van dien.

[djluc]

Dat klopt inderdaad, je zou dat dan 's nachts in moeten plannen o.i.d.