Poehli

Ich verstehe die Argumentation das das authorisierende Betriebsystem upgradeberechtigt ist, aber wenn ich mich recht erinnere sind für W7 Volumenlizenzen auch Betriebssysteme authorisierend die NICHT upgradeberechtigt auf W10 wären. Daran würde ich es also nicht festmachen. Ich sehe es eher so: MS hat erklärt welche PRODUKTE upgradefähig sind. Und zwar, indem sie erklären welches NICHT upgradegähig ist: W Enterprise Damit ist ein W 7 Prof Upgradeberechtigt. Ob es nun ein FPP, OEM, SB, oder irgendeine Art von Volumenlizenz ist - wurscht. Die Berechtigung orientiert sich am Produkt und nicht am Lizenzmodell. Was ja irgendwie auch Sinn macht. Würden sie wollen das Volumenlizenzen nicht upgradefähig sind müßten sie bei der obligatorischen online - Authentifizierung das nur entsprechend verweigern.

Und es handelt sich um Volumenlizenzen ?

Ich kann da ein bischen was aufklären. Ich habe bereits mehrfach W7 Clients auf W10 Version Juli 2015 geupgradet. Wenn nach dem Upgrade das Windows plötzlich nicht mehr aktiviert war, hat das nach meiner Erfahrung folgende Gründe: 1.) Upgrade falsch durchgeführt, zB nicht als Upgrade aus Windows heraus sondern durch booten eines Installationsmediums. 2.) falsches Upgrade, zB Prof statt Home, oder aber auch eine W10 Prof DE bei einem W 7 Ultimate eingesetzt, denn dieses benötigt ein W 10 Prof EN 3.) Und das ist im Business Umfeld sicher ein häufiger Grund : Das Upgrade wurde durchgeführt während der Client in einer Domäne war. In dem Fall muss man ihn aus der Domäne nehmen, dann erfolgt automatisch die Aktivierung, und dann wieder rein! Ich hab das bisher x mal gemacht, und es hat immer so funktioniert. 4.) Es gibt Komplikationen mit einem Productkey der im BIOS hinterlegt ist, und der zusätzlich noch ein anderes System ausweist wie gerade installiert ist. Punkt 3.) funktioniert sowohl mit OEM Lizenzen wie auch mit Volumenlizenzen bei Windows Professional! Leider wusste das nicht einmal der Supportmitarbeiter des VolumenLizenzcenter bei MS, noch der Helpdesk-Mitarbeiter bei dem er das Problem nochmal nachfragte. Das sagt ja dann wohl alles. Aber Vorsicht! Meine Erfahrungen der letzten Tage zeigen das Windows 10 Prof 1511, zumindest in der ersten Version, bevor sie es zurückgezogen und nochmal überarbeitet haben, sich ums verrecken nicht aktivieren läßt. Mir ist nur nicht klar warum. Womöglich liegt es daran das ich alle Punkte zur Datenübertragung abgelehnt hatte ( das sind mehr Punkte als bisher in der Auswahl) Womöglich haben sie es auch einfach nur verpfuscht. Und womöglich funktioniert es jetzt mit der "neuen" Version von W 10 1511, aber das kann ich erst morgen testen. Jedenfalls musste ich ein Rollback zu W7 machen und dann ein neues Upgrade zum ursprünglichen Juli - W10, dann aktivierte es sich wie gewohnt. Ich kann außerdem bestätigen das das einspielen des Hotfix für den WSUS zwar die korrekte Anzeige von W10 Clients ermöglicht und wie oben beschrieben eine neue Produktkategorie beinhaltet, aber ein W10 1511 Upgrade erscheint nicht. Ich vermute das kommt erst wenn aus dem Hotfix ein Update für den WSUS geworden ist!

Ich muss mich korrigieren. basierend auf diesen Infos http://www.software-express.de/hersteller/microsoft/microsoft-windows-10/ http://answers.microsoft.com/en-us/windows/forum/windows_10-win_upgrade/domain-joined-windows-781-pro-upgrades-to-windows/af5d843c-f39c-4196-9ec9-33ea917cea21?page=1 können Clients die einen Volumenlizenzvertrag haben UND in einer Domäne sind nur dadurch geupdatet werden indem man sie aus der Domäne nimmt, und das Update mit ( logischerweise) lokalen Adminrechten anstößt. Dann wird W10 aktiviert, und anschließend können sie wieder in die Domäne. Was das Lizenzupgrade mit einer Domäne zu tun hat entzieht sich meines Verständnis. Ich probiere das mal..... ...es ist auch ausreichend wenn man sie nach dem W10 Update einmalig aus der Domäne nimmt, lokal anmeldet, die Aktivierung abwartet, und wieder in die Domäne setzt. Das Update selbst kann ruhig als noch als Domänenmitglied passieren.

Wie bereits oben angesprochen kommt es auf eure Ausgangssituation an. Es sind alles Professional oder höher Lizenzen UND es sind OEM / Einzelplatzlizenzen ? Dann die XP rauswerfen und den Rest per kostenfreien Upgrade auf Windows 10 hieven. Es sind alte Volumenlizenzen, vermutlich ohne oder mit abgelaufenen SA ? Dann bleibt nur der Kauf von W10 Prof Volumenlizenzen, bei euch, wenn ihr die Anforderungen erfüllt, vermutlich der Form " Open Licence Academic " .

Nein. Die wurden per MAK aktiviert, hier läuft kein KMS. Und um die Verwirrung perfekt zu machen: Ich habe den VLSC Support angerufen. Der sagte " Das weiß ich nicht, ich frag den Helpdesk" , (!!!) und erklärte dann: "Alle Volumenlizenzprodukte sind vom kostenlosen Upgrade ausgenommen, es sei denn es besteht aktive SA. " Das hab ich bisher immer anders gelesen. Da lauteten die Veröffentlichungen: alles geht, außer Windows Enterprise. Ein weiteres W10 Upgrade wurde nicht von W7 Prof Volumenlizenz gemacht, sondern von einer WinPro 8.1 SNGL Upgrd OLP NL Acdmc, die ebenfalls im Volumencenter gelistet ist, und da wiederrum ist das Windows 10 dann korrekt aktiviert. Ein W10 Productkey wird aber dafür dann auch nicht angezeigt. Man kann also nicht pauschal sagen das alles im VLSC nicht updatebar ist. Man kann SingleLizenzen im VLSC haben, und die funktionieren. Mein Computerhaus kam noch mit der Überlegung die Rechner aus der Domäne zu nehmen und dann zu upgraden. Das würde zwar zu meinen Erfahrungen mit der Windows 7 Ultimate passen, aber andererseits dem Fass den Boden auschlagen wenn das geht.

Hallo, wir haben hier eine heterogene Lizenzlandschaft. Ich habe in der Vergangenheit einige Clients von W 8 Prof und 7 Prof auf Windows 10 Prof upgedatet. Da wir hinter einem WSUS sitzen, der die Update Werbung nicht durchläßt, mache ich das über freigegebene ISOs im Netzwerk. Zunächst habe ich einige OEM Lizenzen geupdatet, kein Problem. Dann gab es Schwieirigkeiten mit einem W 7 Ultimate was ein externer Gerätehersteller zulieferte. Nach dem (extra englischen) Updaten auf Windows 10 Pro war es plötzlich nicht mehr aktiviert. Alles versucht, immer wieder das gleiche. Ich mußte es aus der Domäne nehmen, und das Update online saugen lassen, dann gings. Parallel habe ich angefangen Clients mit W7 Prof. Volumenlizenz zu updaten. Alles gut, funktionierte. Jetzt stelle ich fest, das die Clients plötzlich kein aktiviertes Windows 10 haben. Selbstverständlich habe ich das Update passend durchgeführt, also aus dem laufenden Betrieb das Setup aufgerufen, Beibehaltung aller Daten usw. , 32bit /64 passt natürlich auch usw. Das ganze betrifft verschiedene Lizenzverträge. Die Systeme beschweren sich aber bisher auch nicht. So von wegen " Aktivierung erforderlich, Aktivierungszeitraum läuft ab, usw. Nichts. Habe die Befürchtung es läuft mit 90 Tage Testzeit. Dummerweise ist das bei einigen länger als 1 Monat her, dh der Rollback auf W7 ist nicht mehr möglich. Kann mir irgendjemand sagen wo das Problem liegen könnte. W 7 Prof ist doch ganz klar updateberechtigt. Und alle Mitteilungen von MS sagen doch nur das Enterprise nicht geupdatet werden kann. Wir haben auch keinen laufenden SA. Ich bin gerade etwas angespannt deswegen, Im Katastrophenfall muss ich frische W10 Lizenzen für die Systeme kaufen, arg. Hat da jemand Erfahrung ?

vielen Dank für den Link, sowas habe ich gesucht. Allerdings muss ich sagen das es mehrere Optionen gibt die in den neuen Template so nicht mehr vorhanden sind, zum Beispiel im Bereich Cloud und Store. Bei der OpenDrive Cloud Configuration habe ich beobachtet das die Abschalt-Optionen von W8.1 bei mir bei W10 nicht gegriffen habe, die W10 Templates funktionieren, allerdings gibts nur noch eine Option wo vorher 3 waren.

Ok, also etwas detailierter: .admx Dateien die ich in W10 vorfinde und in WS2012 nicht kopier ich einfach rüber, klar. Wie gehe ich bei den Dateien vor die auf beiden Versionen vorhanden sind, aber unterschiedlich groß sind, also verschiedene Optionen beinhalten. Ich hatte versucht einfach eine umzubenennen, aber da meckert die Verwaltung natürlich weil Zieladressen dann doppelt vorkommen. Muss ich ernsthaft alle Templates öffnen und die Einträge manuell zusammenkopieren und in die bestehende .admx ergänzen? Da gibts nichts offizielles was die bestehenden .admx "upgraded" ? Ich scheu nicht die Arbeit das zu Fuß zu erledigen, hätte nur gedacht jemand hat das seit Jahren bestehende Problem bei neuen OS Versionen mal programmiertechnisch angegangen :-)

Hallo, ich habe ein paar Verständnisprobleme mit der Integration neuer GPOs. Ich betreibe ein WS2012 R2, die Clients sind bisher XP-W8.1. Gestern habe ich mal den ersten W10 Client in die Domäne geholt, und einen Sack an Sachen gefunden die per GPO gesperrt werden sollten. Natürlich kennt der WS2012 R2 die neuen GPOs nicht. Ich habe gelesen RSAT für W10 ist draußen,aber das hilft mir nicht da ich hier normalerweise an einem W7 sitze. Soweit ich das verstehe kann man die .admx am Server auch einfach hinzufügen, und mir wäre das am liebsten, einfach alle neuen GPOs hinzufügen zu den bestehenden. Ist auf Grund vergangener Erfahrungen damit zu rechen das Microsoft eine Art GPO Update für den WS2012 ausrollt, oder ist klar das man sich selber kümmern muss? Das Verfahren besteht im Prinzip einfach darin die .admx / adml von einem W10 Client nach Server/Windows/ PolicyDefinitions zu kopieren, korrekt ? Ok. Jetzt mein Problem. Woran erkenne ich welche Dateien aktualisert wurden und neue Einträge enthalten ? Ich meine wenn es neue .admx sind die unter Ws2012 nicht exsistieren ist es ja klar, aber sonst? Oder kopiert man einfach alles, den kompletten Ordner? Bekomme ich dann eventuell Einträge doppelt ? Kann es passieren das ich alte GPO Optionen verliere ( für die letzte Handvoll XP Rechner die noch rumtüdeln?), wenn ich eine gleichnamige .admx von W10 über die Datei von WS2012 bügel ? Neben der Sache das es auf dem W10 Client neue admx gibt die WS2012 nicht kennt, gibt es ja auch gleiche Dateien wo man schon an der Größe sieht das sich der Inhalt geändert hat. Welches Vorgehen wird da empfohlen? Beide behalten, die neuere, Dateien öffnen undzusammenbasteln ? Ich konnte bisher nicht herausfinden wie man da korrekt vorgeht, ich kenne nur das Herangehen wenn man völlig neue GPOs einbindet, für Adobe, oder Office zum Beispiel. Grüße Pö

Ich bin halt noch in der Testphase. Beides ausgeführt habe ich erst mal deswegen: Remove-AppxPackage will remove an app for the user currently logged on. It will not remove the app from C:\Program Files\WindowsApps. Remove-AppxProvisionedPackage will remove an app from the machine (but will not remove the icons from any created user profiles). Allerdings ist meine derzeitige Meinung das es erst mal die bessere Idee ist die Pakete NICHT aus dem Installationspfad zu löschen, sondern sie nur mit remove-appxpackage in einem Anmeldescript zu entziehen wenn eine Anmeldung an eine Domäne mit entspechend greifenden GPOs erfolgt. Das kastriert das System nicht so falls zB das Notebook mal außerhalb ist. Gut, also: remove-appxpackage -package Microsoft.BingFoodAndDrink_3.0.4.212_x64__8wekyb3d8bbwe ...das ausführen der nach lokal hinkopierten Datei funktioniert, wenn ich die Datei in der Form .\RemoveApps.ps1 aufrufe. Der Fehler über GPP ist aber immer noch : Fehler: Ereignis 1130 Anmeldescript war nicht erfolgreich. Ich weise das Script als PowerShell- Script als Anmeldescript in der Benutzerkonfiguration an. Ohne Parameter - benötige ich welche ?? Des weiteren habe ich die GPP bereits dahingehend angepasst das die standardmäßig 5min zeitverzögerte Ausführung von Loginscripten abgeschaltet wird. *EDIT* Ok, und würde man nicht diese dämlichen Anfängerfehler machen und den Pfad richtig im UNC Stil angeben statt lokal auf dem Server würde es auch funktionieren :-) *gelöst*

"Powershell führt nur Scripts aus, die sich in der Umgebungsvariablen PATH befinden. Im aktuellen Verzeichnis befindliche Scripts fallen nicht darunter und müssen gegebenenfalls in der Form .\script.ps1 aufgerufen werden." http://www.windowspro.de/andreas-kroschel/powershell-scripts-ausfuehren Als ich lokal das Script ausgeführt habe mußte ich das auch benutzen. Jetzt vermute ich mal das ich das in der GPO auch irgendwie angeben muss, und nicht nur den Link zu dem File.

Hm. Also Remove-AppxPackage - package xxxxxxx funktioniert bei lokaler Dateiausführung, nur Remove-AppxProvisionedPackage -package xxxx -online will nicht recht. Da kommt immer das es die Datei nicht findet. Aber eins nach dem anderen. Lokal kommen auch Fehlermeldungen beim wiederholten Ausführen. Aber das ist ja nicht unbedingt verwunderlich, wenn das Paket einmal entfernt wurde ist ja klar das es beim nächsten Aufruf nicht mehr vorhanden ist und Powershell meckert. Ah, PS Scripte hab ich bisher nicht im Einsatz ....PS Skripte zulassen per GPO..... "lokale und Remote signiert passt nicht weil nicht signiert"...also "Alle" zulassen.... gleich mal probieren... Ich lese hier gerade den Hinweis die Scripte müssen sich in irgendeiner Umgebungsvariable befinden damit sie ausgeführt werden ? Ich hab es auf dem Server in einem separaten Ordner. Wie gebe ich das dann i nden GPOs an ?

Hallo. so, neuer Server neues Glück... Ich habe hier die ersten W8 Clients reinbekommen und will die Modern-Apps bändigen. Um sie von den Clients zu bekommen habe ich mir diverse Powershell Beispiele angesehen. hier http://superuser.com/questions/533170/how-to-fully-uninstall-a-windows-store-app und hier https://4sysops.com/archives/uninstall-windows-8-apps-with-powershell-and-group-policy/#uninstall-windows-8-apps-with-powershell ok. Noch nie Powershell benutzt. Gut Schritt eins, Befehl auf Client an der Konsole getestet. Funktioniert. Am Server Powershell ISE geöffnet, und mal versucht: remove-AppxProvisionedPackage -package Microsoft.BingMaps_2.1.3230.2048_x86__8wekyb3d8bbwe -online Dateiname:RemoveApps.ps1 GPO erstellt "App Einschränkungen", und das ganze als Benutzer Logg-On Script hinterlegt, auf dem Tab Powershell-Skripts ok. Am Client GP neu ziehen lassen, neu angemeltet.... Ereignisanzeige: Fehler: Ereignis 1130 Anmeldescript war nicht erfolgreich. Tja. Und nun? Erst mal für mein Verständnis: Mit der Richtlinie ist alles in Ordnung, oder? Sie wird quasi korrekt angewand? Der Fehler besagt nicht das er die Datei nicht ausführen kann oder so? Er bezieht sich auf den Inhalt der nicht stimmt? Oder wie oder was? Danke, Pöhli

Ich könnte im oberen Eintrag ComputerSystem durch OperatingSystem ersetzen und hoffen, aber ich würds auch gerne bischen verstehen :-). EDIT: Im Link von dir sind auch Vorschläge mit WHERE NOT wie ich das habe, ich verstehe im Moment nicht was besser bzw der Unterschied ist zu "Like", muss noch bissl nachlesen. Und nein, wenn ich sage es gibt Probleme unter XP meine ich damit 32bit. 64bit ist nicht vorhanden. Das der Eintrag mit Ziel %ProgramFiles%/ und der Zielgruppenadressierung "select * from Win32_OperatingSystem where not OSArchitecture="64-Bit" für W7 32bit und XP 32bit von mir vorgesehen wurde kommt daher das %ProgramFiles% ja entsprechend den korrekten absoluten Pfad setzt, je nach 32bit Windows Version, aber halt nicht unter 64bit Versionen. EDIT II : Ich habs, laut dem Link gibt es "OSArchitekture" erst ab Vista!, weshalb es unter XP nicht funktioniert. Also brauch ich eine andere Abfrage für die x86 Systeme die über alle Versionen hinweg korrekt ist.... Edit III : ...und die ist wie vorgeschlagen select * from Win32_ComputerSystem WHERE SystemType LIKE "%86%" Danke

Hallo, (WS2003 SP1 x64, RSAT W7) ich hab nicht wirklich so den Durchblick bei WMI und habe letztens das erste mal eine Zielgruppenadressierung in der GPO verwendet. Ziel ist das Kopieren von zwei Konfigurationsdateien eines 32bit Programms in den Programmordner. Ich habe den Kopiervorgang zwei mal angelegt: einmal mit Ziel %ProgramFiles(x86)%/ und der Zielgruppenadressierung "select * from Win32_OperatingSystem where OSArchitecture="64-Bit" und einmal mit Ziel %ProgramFiles%/ und der Zielgruppenadressierung "select * from Win32_OperatingSystem where not OSArchitecture="64-Bit" Letzteres, so meine Annahme, sollte auch unter XP an die richtige Stelle kopieren. GPO und Kopiervergänge werden unter W7 32 und 64bit korrekt ausgeführt, allerdings klemmt es unter XP. Ich bekomme die Fehlermeldung Das Computer "XYZ"-Einstellungselement im Gruppenrichtlinienobjekt "XYZ {5013D997-0A40-4E71-AF34-41B72BD9E9B7}" wurde nicht übernommen, da bei einem Element der Zielgruppenadressierung ein Fehler mit Fehlercode "0x80041017 <unknown-message-text>" Dieser Fehler wurde unterdrückt. aufgetreten ist. Soweit ich gelesen habe ist da irgendwo ein Synthax Fehler, aber ich schau wohl an der falschen Stelle. Wie muss das richtig gemacht werden? Danke Poehli

Ich habe jetzt den korrekten Workaround gefunden für diese Ordnerfalschbenamung: Man erstelle eine Gruppenrichtlinie, welche sich auf diejenigen Benutzer auswirkt, welche diese umgeleiteten Pfade bewirtschaften sollen. In dieser Gruppenrichtlinie muss die folgende Einstellung auf "DEAKTIVIERT" gesetzt werden (standardmässig ist diese "aktiviert"): - Benutzereinstellungen / Richtlinien / Administrative Vorlagen / System / Ordnerumleitung / Bei der Umleitung von Startmenü und eigene Dateien lokalisierte Unterordnernamen verwenden Diese Einstellung wirkt sich auch auf z.B. die Umleitung des Desktops aus - also nicht nur auf das Startmenü und die eigenen Dateien! gefunden bei: Pflaum Bei mir funktioniert es jetzt. Das ist übrigens der gleiche Ort wo man bei heterogenen Rechnerumgebungen auch die Offlineverfügbarkeit deaktivieren sollte!

@sweigl: ich hatte dazu gerade einen Thread begonnen bevor klar war das das hier in die gleiche Richtung läuft... dabei sind Dinge die auch hier beschrieben sind, auf dem Server betrachtet stimmen plötzlich Ordnernamen nicht mehr usw... byPö

Hallo, ich habe hier einen WS2003 R2, den ich per RSAT von W7 aus die GPPs verklickere. Die Clients sind WXPSP3 und W7SP1 x32 und x64. So. Ich habe in der GPP benutzerspezifisch die Ordnerumleitung für "Dokumente" eingerichtet und die Offlinesynchronisation abgeschaltet. Die Ordnerumleitung ist wie folgt: [Reiter ZIEL] Ziel: "Standard-leitet alle Ordner auf den gleichen Pfad um" Zielordner: an folgenden Pfad umkeiten: Verzeichnis: \\Servername\Daten\%username%\Dokumente (Dabei handelt es sich um das Serververzeichnis des Benutzers, Laufwerk X: ) [Reiter Einstellungen] [ ] [ ] [ ] ( ) (x) Ordner nach Entfernen....zurück ...umleiten Schließe ich die GPP und rufe sie erneut auf, werden mir nicht die korrekten Eintragungen angezeigt !! Statt dessen steht dort: [Reiter ZIEL] Ziel: "Standard-leitet alle Ordner auf den gleichen Pfad um" Zielordner: Einen Ordner für jeden Benutzer im Stammpfad erstellen: Verzeichnis: \\Servername\USERS Das gibt Horror wenn man nicht "Abrechen" drückt. Wie kann das sein? Prüfen wir die Richtlinie... Die GPO ist im Moment nur für einen frisch geschaffenen Testuser freigegeben damit kein Unheil entsteht. Wenn sich der Testuser auf einem W7 anmeldet und Bibliothek "Dokumente" öffnet wird in den Orten angegeben das nach \\Servername\Daten\%username%\Dokumente gespeichert wird KORREKT Wir legen dort einen Ordner Test mit der Datei test1.txt an. In der Bibliothek Dokumente und wenn der User über die Laufwerksverknüpfung X: auf seinen Serverordner zugreift ist alles korrekt, am richtigen Platz und hat den richtigen Namen. Jetzt ein Blick als Admin auf den Server. Der Ordner \\SERVERNAME\Data\testu (Testuser, Laufwerk X:) ist scheinbar weg! Dafür habe ich einen neuen Ordner "Administrator" mit anderem Icon. Bei näherer Betrachtung stellt sich heraus das das die Umleitung ist. Darin ist ein weiterer Ordner "Administrator". Bei näherer Betrachtung stellt sich heraus das das der Ordner "Test" ist, in welchem die Datei test1.txt ist. Was sind denn das für Umbenennungen? Da verliert der Admin doch sämtlichen Überblick und Kontrolle über die Struktur. Wieso werden mir Ordner plötzlich mit dem falschen Namen angezeigt? Hab ich ein Verständnisproblem oder sind die Einstellungen falsch? Danke Pö

Ja, genau, man muss die Ordnerumleitung auf die Bibliotheken machen. Und zwar für jede Bibliothek einzeln. Dann sollte man gut überlegen was man da einstellt und vor allem den Reiter "Einstellungen" konfugurieren!. Unbedingt mit einem Testclient ausprobieren! Die Konfigurationen bleiben teilweise auch nach Änderung auf dem Server erhalten. Ich beobachte hier einen ganzen Sack voll Merkwürdigkeiten die ich mir nicht erklären kann bei dem Thema...

Hallo, bei mir macht 7-ZIP etwas Ärger wenn ich es per LUP verteilen will. Der in der FAQ bei 7-ZIP beschriebenen Schalter /q INSTALLDIR="C:\Program Files\7-Zip" führt bei der Installation zu Error 80070667, was laut Google in der Verteilung wohl bedeutet: ERROR_INVALID_COMMAND_LINE Ich habe es mit %ProramFiles% probiert, die Anführungszeichen weggelassen und was weiß ich noch alles, hat aber auch nicht geholfen. Alle anderen Softwareverteilungen funktionieren, und bei 7-ZIP betrifft es nur die .msi Varianten, die Verteilung als .exe mit entsprechenden Rules funktioniert, aber msi wäre wenn schon verfügbar halt besser. Sofern jemand 7-ZIP als msi per LUP verteilt bitte ich mal darum den genauen ComandLine Eintrag im LUP nachzusehen. Danke byPö

Wenn du nicht über WSUS und LUP gehen möchtest kann ich dir das Verfahren per Script empfehlen, funktioniert auch sehr gut. Über die Ausbildung des Vergleichsparameter instversion == newversion regelst du in welchem Fall installiert wird. Wenn Clients ohne FF auch nichts bekommen sollen müßten die anderen entweder in eine Gruppe ( wie dort beschrieben), oder die Abfrage im Script muss erweitert werden ob der FF Pfad in der Registry exsistiert. Ich hatte das Verfahren eine Weile im Einsatz da es der einzige Weg ist .exe Dateien per GPO zu verteilen, UND man bekommt sogar noch eine LOG Datei. Zwischenzeitlich bin ich zu LUP gewechselt. Sollte man aber bissl Zeit mitbringen für die Umstellung. Und die alten GPO Freigaben erst mal lassen weil die teilweise bei Updates für die Deinstallation gebraucht werden. NACHTRAG: Ach ja, es gibt noch einen guten Grund FF per Script zu verteilen - die Konfigurationsdateien für den FF die man als Admin mitverteilen kann. Das geht nämlich über LUP nicht so ohne weiteres, es sei denn man verwendet statt des originalen FF die immer etwas hinterherhinkende Third Party .msi Variante von Frontmotion in individueller Modifizierung. Als weitere Alternative bliebe dir selber eine richtige msi von FF zu erstellen: so gehts.

Hallo, es ist natürlich richtig das die Installation nicht mit Benutzerrechten erfolgt sondern mit Systemrechten, das hab ich falsch formuliert. Aber ich denke es ist klar was gemeint ist: Ein Benutzer kann eine Softwareinstallation durchführen die im Normalfall einen Administratoreingriff erfordern würde. Es geht mir bei der Anwendung nur darum das es Software ist deren Verwendung nicht vorauszusehen ist. Zum Beispiel Paint.Net. Kann sein der User braucht das mal, kann sein er verwendet es nie. Dito 7Zip, Notepad usw. Das würde ich dann gerne optional bereitstellen. Ähnliches gilt zB für Software wo nur eine begrenzte Lizenzzahl zur Verfügung steht. mit LUP sehe ich da wer es wo im Einsatz hat. Punkt drei - ich wollte einfach ausprobieren und wissen wie das läuft, nennen wir es Weiterbildung :-) Leider ging das nur so 2 h, dieses Sichtbarmachen im WSUS und das versuchte anschließende Rückgängigmachen hat mir wohl die WSUS Datenbank angeknackst. Ich glaub ich muss mich mal in speziellere Foren verkrümeln, wenn man mich da versteht... Danke!

Hallo, ja, die Software wird bereitgestellt, ich konnte nur nichts sehen da die GPO unter XP die Installationsoption rausgenommen hat :-) Das Problem das der LUP die Software über "Software" bereitstellt, welche Adminrechte für die Installation erfordert bringt mich zu meinem ursprünglichen Anliegen zurück - Wenn ich ein Update zur optionalen Installation freigebe würde ich es auch unter "optionale Updates" erwarten, wo es mit Userrechten ausgeführt werden kann, und nicht im Softwareordner. Hm. Ich bin in der Richtung einen Schritt weiter gekommen und habe das Problem gelöst wiees aussieht: Denn unter W7 kann man Windows Update > Einstellungen ändern > Empfohlene Updates auf die gleiche Weise wie wichtige Updates bereitstellen .....abwählen, das geht auch per GPO. Im LUP müssen die Updates natürlich auf "optionale Installation" gestellt werden. Sie werden am Client optional bereitgestellt und können auf Wunsch mit Benutzerrechten wie ein Update installiert werden. Leider hab ich zwischenzeitlich ein wesentlich kritischeres Problem: Ich habe die Softwareupdates im WSUS sichtbar gemacht, also dem Produktkatalog hinzugefügt. Mit diesem Vorgehen. Hat alles funktioniert. Fein, dachte ich, jetzt bist du fast fertig. Das Dumme ist nur das jetzt plötzlich alle Updates unter LUP weg sind. Unsichtbar geworden. LUP hat sie zwar noch in der Überwachung über "All Computers", aber unter "Updates" ist alles leer. ARG! Damit komm ich auch nicht mehr an die Regeln ran, kann sie weder löschen noch sonstwas. Die Updates exsistieren noch, denn ich sehe sie im rechten LUP Bereich und sie sind im WSUS Produkt Update Katalog vorhanden. Ich habe sie jetzt im LUP neu angelegt, die neuen sind auch sichtbar, aber jetzt hab ich im WSUS Produktkatalog und im LUP jede Menge Updates doppelt. Da sie aber nicht links im Baum der LUP-Updateliste stehen kann ich sie weder löschen noch abwählen noch sonst irgendwas. Wenn ich "Katalog exportieren" wähle werden mir auch alle Updates angezeigt, inklusive der "unsichtbar verschwundenen". Wie komme ich jetzt aus dem Problem wieder raus? Finde ich die angelegten Updates in einer Datei / Datenbank? Wo? Hilft mir ein Datenbankeintrag mit umgekehrten Parametern: true / false? Da würde ich doch lieber auf die Sichtbarkeit im WSUS verzichten als dieses Chaos jetzt.

Hallo, die über WSUS verteilte Software soll im Softwareverzeichnis angeboten werden?? Das war so abwegig, das hab ich nicht geglaubt :-) Ich dachte das ist nur der Fall wenn Software über AD bereitgestellt wird, nicht über WSUS. Aber du hast recht, laut dem Beispielcode soll das angeblich im Softwareverzeichnis auftauchen. Allerdings nicht bis sondern AB Vista. Ich bin mir immer noch nicht sicher ob wir von den gleichen Optionen reden, aber ich verwende immer für alle : "3 - Autom. Downloaden, aber vor Installation benachrichtigen" TEST: 7ZIP , im LUP zugelassen als "Optional Install" Client: XP SP3 mit Benutzerrechten: Das Update steht am LUP auf Genehmigung: "Install" Status:"Not installed" Am Client taucht es im Softwareordner nicht auf, wo auch. Also mit XP wird das wohl gar nichts:( Client: W7 SP1 32Bit mit Benutzerrechten: Das Update erscheint als "wichtiges Update", und würde, wenn man es nicht explizit abwählt, sofort installiert. Die Updatebeschreibung am Client weist es allerdings korrekt als Empfohlenes Update aus, aber was nützt das schon in dem Fall. Zusätzlich - Im Softwareordner taucht es zu meiner Freude auch auf - im Abschnitt "Programm vom Netzwerk beziehen" erscheint es nach einem kleinen Moment. Aber was hilft das wenn es bereits im Rahmen der Updatefunktion installiert wird.:confused: Also wenn noch jemand eine Idee hat...... Wenn ich die Softwareupdates im WSUS sehen würde, was ich bisher noch nicht hinbekommen habe weil ich mich noch nicht an die Datenbank trau um den Sichtbarkeits - Eintrag zu ändern, würde ich diese Updates ja mal im WSUS abwählen. Vieleicht wäre das ja die Lösung. Sie werden publiziert, freigegeben, aber nicht verteilt.... Hat die Geschichte eigentlich schon mal jemand vor mir probiert :-)? Ich fände das ganz praktisch, so für Sachen wie 7zip oder paint.net.