10
Software Zuweisung per MSI 32 oder 64 bit
Hallo Freunde!
Habe eine Frage zur Softwareverteilung:
Wir nutzen in unserer Domäne Center Tools DriveLock, der Server auf S2008 R2, die Clients in einer Mischumgebung aus 32-Bit und 64-Bit XP und Windows 7 Rechnern.
Jetzt wollen wir den neuen Client per GPO verteilen. Ist auch nicht das Problem.
Wo ich etwas Bauchschmerzen habe und auch noch nix gefunden habe:
Die Unterscheidung, ob der Client 32 oder 64 Bitter ist. Es gibt 2 MSIs (32/64). Kann ich die gleichzeitig zuweisen und "merken" die Clients selbst, welcher der richtige ist, oder sollte ich
die Unterscheidung per Script vornehmen und die richtige MSI starten? Extra eine neue OU oder so fällt von vorn herein als Lösung aus.
Jemand einen Tip?
Gruß an Alle und Danke im Voraus!
Habe eine Frage zur Softwareverteilung:
Wir nutzen in unserer Domäne Center Tools DriveLock, der Server auf S2008 R2, die Clients in einer Mischumgebung aus 32-Bit und 64-Bit XP und Windows 7 Rechnern.
Jetzt wollen wir den neuen Client per GPO verteilen. Ist auch nicht das Problem.
Wo ich etwas Bauchschmerzen habe und auch noch nix gefunden habe:
Die Unterscheidung, ob der Client 32 oder 64 Bitter ist. Es gibt 2 MSIs (32/64). Kann ich die gleichzeitig zuweisen und "merken" die Clients selbst, welcher der richtige ist, oder sollte ich
die Unterscheidung per Script vornehmen und die richtige MSI starten? Extra eine neue OU oder so fällt von vorn herein als Lösung aus.
Jemand einen Tip?
Gruß an Alle und Danke im Voraus!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 145677
Url: https://administrator.de/contentid/145677
Ausgedruckt am: 05.11.2024 um 21:11 Uhr
10 Kommentare
Neuester Kommentar
Moin,
wäre doch nur eine subou in denen jeweils die 32 oder 64 drin sind.
Würde alles - u.a. den Wsus und den Überblick total vereinfachen.
Scripte um msis zu bauen halte ich dagegen für deutlich uneleganter und zukunftsunsicherer....
Gruß
Extra eine neue OU oder so fällt von vorn herein als Lösung aus.
Wenn man fragen darf warum?wäre doch nur eine subou in denen jeweils die 32 oder 64 drin sind.
Würde alles - u.a. den Wsus und den Überblick total vereinfachen.
Scripte um msis zu bauen halte ich dagegen für deutlich uneleganter und zukunftsunsicherer....
Gruß
Ich möchte fliegen - ein Flugzeug (gleich welche Bauweise) fällt aber aus. Nu gib mir mal ne Lösung...
Wie soll das bei dir gehen? Ne 32-Bit-SW läuft auf nem 64-Bit-OS auch. Also warum sollte sich das 64-Bit-OS weigern diese zu installieren? Du erzeugst mit dem Versuch höchstens nen schönes Chaos auf deinen Stationen...
Und ich würde generell die 64-Bit-Rechner in ne eigene OU packen... Denn da hast du ja öfters andere Software (eben 64-Bit-Versionen) - und das wird in Zukunft noch viel häufiger kommen...
Wie soll das bei dir gehen? Ne 32-Bit-SW läuft auf nem 64-Bit-OS auch. Also warum sollte sich das 64-Bit-OS weigern diese zu installieren? Du erzeugst mit dem Versuch höchstens nen schönes Chaos auf deinen Stationen...
Und ich würde generell die 64-Bit-Rechner in ne eigene OU packen... Denn da hast du ja öfters andere Software (eben 64-Bit-Versionen) - und das wird in Zukunft noch viel häufiger kommen...
Es ist kinderleicht. Bei 64-Bit-Paketen musst Du gar nichts machen. Bei 32-Bit-Paketen musst Du in den Eigenschaften des Pakets (nach Zuweisung) den Haken entfernen bei - Deployment - Advanced - "Make this 32-bit application available to Win64 machines".
Zitat von @DerWoWusste:
Es ist kinderleicht. Bei 64-Bit-Paketen musst Du gar nichts machen. Bei 32-Bit-Paketen musst Du in den Eigenschaften des Pakets
(nach Zuweisung) den Haken entfernen bei - Deployment - Advanced - "Make this 32-bit application available to Win64
machines".
Es ist kinderleicht. Bei 64-Bit-Paketen musst Du gar nichts machen. Bei 32-Bit-Paketen musst Du in den Eigenschaften des Pakets
(nach Zuweisung) den Haken entfernen bei - Deployment - Advanced - "Make this 32-bit application available to Win64
machines".
Salü,
naja...
angenommen ich hab eine 64 und eine 32 bit Version einer Software, dann bekommt der 32er die 32er und der 64 bekommt?
Von daher - wie bereits angedacht - einmal eine zusätzliche OU Struktur anlegen und das Ding ist nicht nur für diesen Fall gegessen.
Nix gegen deinen Tipp, aber Kinderleicht ist eben für ein Kind gedacht
Gruß
Der 64er bekommt die 64er. Ich verstehe den Einwand nicht. Du weist 2 Pakete zu und beim 32er gibst Du an, dass es nicht für 64-Bitter genutzt werden soll - machen wir seit Jahren so, OUs sind hierbei überflüssig.
Zitat von @DerWoWusste:
Der 64er bekommt die 64er. Ich verstehe den Einwand nicht. Du weist 2 Pakete zu und beim 32er gibst Du an, dass es nicht für
64-Bitter genutzt werden soll - machen wir seit Jahren so, OUs sind hierbei überflüssig.
Der 64er bekommt die 64er. Ich verstehe den Einwand nicht. Du weist 2 Pakete zu und beim 32er gibst Du an, dass es nicht für
64-Bitter genutzt werden soll - machen wir seit Jahren so, OUs sind hierbei überflüssig.
Yupp - aber nur wenn du / wer auch immer bei jedem 32er Päckchen genau das macht, was du da oben schreibst.
Und nachher kommt einer, macht mal eben kurz, hatte noch keinen Kaffe und dann....
Ous flüssig oder nicht, ich finde es einfach simpler, logischer und einfach um einen zusätzlichen Schritt an den man immer denken muß - weniger.
Anyway wir beide wissen ja eh, dass es viele wege nach rom gibt.
Gruß
Moin Leute!
Erstmal VIELEN DANK für den reichlichen feedback!
@timobeil
Neue OU war auch mein erster Gedanke, allerdings sind die Strukturen hier festgelegt und ich bin (noch) nicht in der Position, hier groß was zu ändern (Kundennetz, Probezeit etc.
Wegen Script, so schwer wärs nicht: per vbs rausfinden, ob Maschine 32 oder 64, dann einfach die richtige MSI per Kommandozeile. Aber mit der OU ist wirklich die eleganteste Lösung, denke ich.
Meine Unsicherheit rührt daher, daß wir hier im eigenen Netz zuerst versehentlich nur die 32Bit-MSI zugewiesen haben und zwei Win 7-Clients die auch geschluckt haben, dann aber eben gesponnen.
Ich denke, wir haben das Häkchen, wie von DerWoWusste gesagt, vergessen.
Nochmals vielen Dank Euch allen!
Erstmal VIELEN DANK für den reichlichen feedback!
@timobeil
Neue OU war auch mein erster Gedanke, allerdings sind die Strukturen hier festgelegt und ich bin (noch) nicht in der Position, hier groß was zu ändern (Kundennetz, Probezeit etc
.Wegen Script, so schwer wärs nicht: per vbs rausfinden, ob Maschine 32 oder 64, dann einfach die richtige MSI per Kommandozeile. Aber mit der OU ist wirklich die eleganteste Lösung, denke ich.
Meine Unsicherheit rührt daher, daß wir hier im eigenen Netz zuerst versehentlich nur die 32Bit-MSI zugewiesen haben und zwei Win 7-Clients die auch geschluckt haben, dann aber eben gesponnen.
Ich denke, wir haben das Häkchen, wie von DerWoWusste gesagt, vergessen.
Nochmals vielen Dank Euch allen!
Noch ein Nachtrag @maretz
Die 32 Bit Clients laufen NICHT korrekt auf 64er Maschinen, weil da von DriveLock Treiber installiert werden. Und 32Bit-Treiber auf 64Bit is eben nicht.
Nix für ungut und schonen Tag noch alle!
Die 32 Bit Clients laufen NICHT korrekt auf 64er Maschinen, weil da von DriveLock Treiber installiert werden. Und 32Bit-Treiber auf 64Bit is eben nicht.
Nix für ungut und schonen Tag noch alle!
Moin,
das Problem an der Sache: DAS weiss dein 32-Bit-Treiber nicht zwingend. D.h. du kannst normal (Treiber sind da noch ne Sondergeschichte) 32-Bit-SW auf nem 64-Bit-OS installieren. Nur: OB die dann läuft ist eben ne andere Frage...
Was wäre denn mit einer anderen Lösung? Ich denke mal das du die Struktur nicht ändern darfst/sollst weil die nicht wollen das du die Rechner von eine OU in die andere schiebst. Is ja auch ok -> was wäre denn wenn du eine OU "32bit" und eine "64bit" anlegst und dort nur eine GRUPPE reinpackst. In der einen Gruppe sind halt alle 32-Bit-Rechner drin, in der anderen sind die 64-Bit-Rechner. Schon hast du über die Vererbung das Problem leicht erledigt - jeder Rechner bekommt nur das was er bekommen soll. Und deine Vorgesetzten brauchen auch keine Sorge zu haben - da du die bestehenden Strukturen nicht änderst sondern dir nur eine OU hinzufügst. Es wird aber kein Rechner aus der Struktur verschoben oder geändert... (Du musst da dann lediglich aufpassen das du in DEINER OU nix explizit verbietest was woanders erlaubt wird -> denn dann ist es trotzdem verboten...)
das Problem an der Sache: DAS weiss dein 32-Bit-Treiber nicht zwingend. D.h. du kannst normal (Treiber sind da noch ne Sondergeschichte) 32-Bit-SW auf nem 64-Bit-OS installieren. Nur: OB die dann läuft ist eben ne andere Frage...
Was wäre denn mit einer anderen Lösung? Ich denke mal das du die Struktur nicht ändern darfst/sollst weil die nicht wollen das du die Rechner von eine OU in die andere schiebst. Is ja auch ok -> was wäre denn wenn du eine OU "32bit" und eine "64bit" anlegst und dort nur eine GRUPPE reinpackst. In der einen Gruppe sind halt alle 32-Bit-Rechner drin, in der anderen sind die 64-Bit-Rechner. Schon hast du über die Vererbung das Problem leicht erledigt - jeder Rechner bekommt nur das was er bekommen soll. Und deine Vorgesetzten brauchen auch keine Sorge zu haben - da du die bestehenden Strukturen nicht änderst sondern dir nur eine OU hinzufügst. Es wird aber kein Rechner aus der Struktur verschoben oder geändert... (Du musst da dann lediglich aufpassen das du in DEINER OU nix explizit verbietest was woanders erlaubt wird -> denn dann ist es trotzdem verboten...)
Moin Maretz.
Auf Gruppen wirken keine GPOs. Und 32-bit-Treiber lassen sich nicht auf 64ern installieren - ob der Treiber das weiß, spielt keine Rolle.
Auf Gruppen wirken keine GPOs. Und 32-bit-Treiber lassen sich nicht auf 64ern installieren - ob der Treiber das weiß, spielt keine Rolle.
