9
SCCM Collections User-based und Device-based in Abhängigkeit stellen
Hallo liebe Community,
ich muss das Deployment von Office, AccessRuntime, Visio und Project am SCCM/MECM von Device-based auf User-based Collections umstellen und stehe dabei vor einem oder mehreren Problemen bei dem ich eure Hilfe brauche. 0 Plan wie man die Collections-Types miteinander in Abhängigkeit bringt.
Gleich vorweg:
Ich bekomme eine Anforderung und muss diese umsetzen. Egal wie blöd und unvorteilhaft diese Anforderung ist. Genauso kann ich nicht beeinflussen wie AD, Security oder andere Strukturen aufgebaut/umgesetzt sind.
Folgende Voraussetzungen müssen erfüllt sein:
Mein Problem:
MS hat anscheinend nicht vorgesehen, dass man User-based- und Device-based-Collections untereinander in Abhängigkeit stellt. Außerdem habe ich in einer Device-Collection in der Query keinen Zugriff aus "User Resources" und in User-Collections keinen Zugriff auf "System Resources". Kein Plan wie ich das umsetzen soll...
Hat irgend jemand eine Idee dazu? Ich raufe mir seit Tagen die Haare beim Suchen einer Lösung und komme aber weiter.
Vielen Dank für die Unterstützung!
Mayho
ich muss das Deployment von Office, AccessRuntime, Visio und Project am SCCM/MECM von Device-based auf User-based Collections umstellen und stehe dabei vor einem oder mehreren Problemen bei dem ich eure Hilfe brauche. 0 Plan wie man die Collections-Types miteinander in Abhängigkeit bringt.
Gleich vorweg:
Ich bekomme eine Anforderung und muss diese umsetzen. Egal wie blöd und unvorteilhaft diese Anforderung ist. Genauso kann ich nicht beeinflussen wie AD, Security oder andere Strukturen aufgebaut/umgesetzt sind.
Folgende Voraussetzungen müssen erfüllt sein:
- Collection-Membership-Rules basieren auf USER-Active Directory-Groups nicht auf MACHINE-AD-Groups
- die umgestellten Apps dürfen nicht auf Servern im Software-Center auftauchen. Dort melden sich aber die gleichen Benutzer (SamAccountName) an die sich auch auf einem Desktop-Client anmelden.
- Alle Geräte (Server und Desktop) sind Multi-User-Geräte
- Die Apps stehen in 32-Bit und 64-Bit zur Verfügung.
- * die 64-Bit-Variante von Office ist der Standard und wird als Device-Based-Collection verteilt.
- * 32-Bit wird bei Bedarf zugewiesen und ist User-based.
- * Wird die Office 32-Bit zugewiesen muss die Membership bei Office 64-Bit rausfallen (Exclution).
- * * Gleichzeitig müssen dann auch Visio und Project 64-Bit gegen die 32-Bit-Variante getauscht werden
Mein Problem:
MS hat anscheinend nicht vorgesehen, dass man User-based- und Device-based-Collections untereinander in Abhängigkeit stellt. Außerdem habe ich in einer Device-Collection in der Query keinen Zugriff aus "User Resources" und in User-Collections keinen Zugriff auf "System Resources". Kein Plan wie ich das umsetzen soll...
Hat irgend jemand eine Idee dazu? Ich raufe mir seit Tagen die Haare beim Suchen einer Lösung und komme aber weiter.
Vielen Dank für die Unterstützung!
Mayho
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: 5648699721
Url: https://administrator.de/contentid/5648699721
Ausgedruckt am: 23.11.2024 um 22:11 Uhr
9 Kommentare
Neuester Kommentar
Hi,
Office wird ja pro Device installiert, d.h. sobald sich ein 32-bit User an einem Device angemeldet hat, haben alle User 32bit an dem Device. Ist das gewünscht?
Die Server kannst du beim Deployment ausschließen.
Auch das 64bit Deployment kannst du so umstelle, dass es 32bit Office nicht überschreibst. (Zb detection auf die 32 oder 64bit exe)
32bit ersetzt aber ggf installierte 64bit Versionen. (Detection nur auf 32bit. Das Script muss ggf angepasst werden, aber das bietet office zb über die XML config an.)
Würde auch überdenken, wieso sich die "normalen" User auch an Servern anmelden. Sollten sie da nicht eigene Admin-User nutzen? Hatten mal so einen Helden und jetzt dürfen wir überall eine Software entfernen die (... auch von ihm...) per GPO verteilt wurde.
Sg Dirm
Office wird ja pro Device installiert, d.h. sobald sich ein 32-bit User an einem Device angemeldet hat, haben alle User 32bit an dem Device. Ist das gewünscht?
Die Server kannst du beim Deployment ausschließen.
Auch das 64bit Deployment kannst du so umstelle, dass es 32bit Office nicht überschreibst. (Zb detection auf die 32 oder 64bit exe)
32bit ersetzt aber ggf installierte 64bit Versionen. (Detection nur auf 32bit. Das Script muss ggf angepasst werden, aber das bietet office zb über die XML config an.)
Würde auch überdenken, wieso sich die "normalen" User auch an Servern anmelden. Sollten sie da nicht eigene Admin-User nutzen? Hatten mal so einen Helden und jetzt dürfen wir überall eine Software entfernen die (... auch von ihm...) per GPO verteilt wurde.
Sg Dirm
Zitat von @Dirmhirn:
Office wird ja pro Device installiert, d.h. sobald sich ein 32-bit User an einem Device angemeldet hat, haben alle User 32bit an dem Device. Ist das gewünscht?
Das habe ich auch gesagt. Zudem ist die 64-Bit-Variante im Image. Aber wer hört schon auf den Techniker...Office wird ja pro Device installiert, d.h. sobald sich ein 32-bit User an einem Device angemeldet hat, haben alle User 32bit an dem Device. Ist das gewünscht?
Die Server kannst du beim Deployment ausschließen.
Ach verdammt! Global Conditions und Requirements. Die habe ich schon seit Jahren nicht mehr verwendet. Total vergessen! <= *kopfTisch* Danke!Auch das 64bit Deployment kannst du so umstelle, dass es 32bit Office nicht überschreibst. (Zb detection auf die 32 oder 64bit exe)
32bit ersetzt aber ggf installierte 64bit Versionen. (Detection nur auf 32bit. Das Script muss ggf angepasst werden, aber das bietet office zb über die XML config an.)
Das ist alles kein Problem. Die Detection auf Bitness usw. funktioniert einwandfrei. Mein Haupt-Problem (Exclusion auf den OS-Type (Server oder Workstation) ) ist mit den Clobal-Conditions auch soweit gelöst. Außerdem ist Wahnsinn bei uns eh Programm. Alles ist nur "Available" 32bit ersetzt aber ggf installierte 64bit Versionen. (Detection nur auf 32bit. Das Script muss ggf angepasst werden, aber das bietet office zb über die XML config an.)
Würde auch überdenken, wieso sich die "normalen" User auch an Servern anmelden. Sollten sie da nicht eigene Admin-User nutzen? Hatten mal so einen Helden und jetzt dürfen wir überall eine Software entfernen die (... auch von ihm...) per GPO verteilt wurde.
Da habe ich leider keinen Einfluss mehr. Nicht meine Baustelle.Bleibt nur noch die Frage offen wie ich eine User-based Collection in einer Device-based Collection in Beziehung setzen kann.
Die 32-Bit (User-based) Collection soll in der 64-Bit (Device-based) Collection Excluded werden. Ich dachte ja zuerst an eine Query, aber nein...
Hast du da eventuell noch eine Idee dazu? Ich möchte es vermeiden ein Script als SCheduled-task laufen zu lassen das mit permanent die Ad-Groups abfragt und dann die Collections aktualisiert... *schüttelfrost*
Zitat von @mayho33:
Bleibt nur noch die Frage offen wie ich eine User-based Collection in einer Device-based Collection in Beziehung setzen kann.
Bleibt nur noch die Frage offen wie ich eine User-based Collection in einer Device-based Collection in Beziehung setzen kann.
Naja über die Detection. Auf Devices mit 32-bit, wird im Software Center 64bit & 32bit als installiert angezeigt. Nicht schön, aber wäre eine Lösung.
Andere Option weiß ich nicht, da wir keine Userbased Collections verwenden.
Zitat von @Dirmhirn:
Naja über die Detection. Auf Devices mit 32-bit, wird im Software Center 64bit & 32bit als installiert angezeigt. Nicht schön, aber wäre eine Lösung.
Zitat von @mayho33:
Bleibt nur noch die Frage offen wie ich eine User-based Collection in einer Device-based Collection in Beziehung setzen kann.
Bleibt nur noch die Frage offen wie ich eine User-based Collection in einer Device-based Collection in Beziehung setzen kann.
Naja über die Detection. Auf Devices mit 32-bit, wird im Software Center 64bit & 32bit als installiert angezeigt. Nicht schön, aber wäre eine Lösung.
Die Detection stellt ja nur fest ob die Installation OK ist. Ich muss die 32-Bit von der 64-Bit-Collection ausnehmen können, weil man sich wünscht, dass die Apps nicht doppelt im SW-Center aufliegen, diese aber via der anhängigen AD-Gruppen-Mitgliedschaft in welcher der User sich befindet, getriggert wird. Und nicht via Detection, also Rückwärts.
Wir hatten bisher auch keine User-Collections. Aber weil halt alles über Azure laufen muss... Azure-AD, 365 Tenent auf User, alles auf User.. und dann ist die Collection-Mechanik so bescheuert getrennt, dass nicht mal ne saubere SQL-Query möglich ist. Aber man muss ja jeden Mist mitmachen... Vor allem weil es sich um Installationen als SYSTEM handelt. Danke dafür Microsoft!!
So! Genug ausgekotzt über MS. Dann werde ich wohl doch AD-Exclusions basteln via Scheduled Task.
Falls du doch npch eine Idee dazu hast... oder jemand anderes. Bitte nur her damit!
Danke für die Hilfe bis dahin!
Kann man App requirements mit Registry Keys erstellen bzw global conditions?
Wir deployen (noch) alles als required auf DeviceGroups, da hab ich die ziemlich selten verwendet. (Und grad keinen Laptop bei der Hand.)
Azure blüht uns auch noch. Wobei Intune mit Co-management schon einige nette Features bringt.
Sg Dirm
Wir deployen (noch) alles als required auf DeviceGroups, da hab ich die ziemlich selten verwendet. (Und grad keinen Laptop bei der Hand.)
Azure blüht uns auch noch. Wobei Intune mit Co-management schon einige nette Features bringt.
Sg Dirm
Azure, Intune, usw. Alles keine Nachteile. Mich ärgert nur das halb ausgegorene Feature On Premise zu dem man dann gezwungen ist.
In einem Enterprise Managed Environment sollte so ziemlich alles reqired deployed werden was unternehmenskritisch ist. Nichts Schlechteres als unterschiedliche Versions- und damit auch Patchstände.
Mit User-Collections funktioniert ja noch nicht mal das Monitoring richtig. Es kann nicht User-based monitoren. Und wenn dann auch noch alles available ist...
Klar kannst du in Global Conditions auch Registry Keys abfragen. Ich mache es gerne via Powershell, weil sich damit so ziemlich jede Abfrage in ein simples True/False umwandeln lässt.
In einem Enterprise Managed Environment sollte so ziemlich alles reqired deployed werden was unternehmenskritisch ist. Nichts Schlechteres als unterschiedliche Versions- und damit auch Patchstände.
Mit User-Collections funktioniert ja noch nicht mal das Monitoring richtig. Es kann nicht User-based monitoren. Und wenn dann auch noch alles available ist...
Klar kannst du in Global Conditions auch Registry Keys abfragen. Ich mache es gerne via Powershell, weil sich damit so ziemlich jede Abfrage in ein simples True/False umwandeln lässt.
Ja wenn du da bei der 64 bit Version ein Requirement reinmachst, dass eben 32bit nicht installiert sein darf?
Dann sieht man 64bit nicht mehr im Software Center, sobald 32bit installiert ist. Davor 64bit als installiert und 32bit als available.
32-> 64bit geht dann halt nicht mehr...
Sg Dirm
Dann sieht man 64bit nicht mehr im Software Center, sobald 32bit installiert ist. Davor 64bit als installiert und 32bit als available.
32-> 64bit geht dann halt nicht mehr...
Sg Dirm
Ja eben! Die Anforderung ist aber leider, dass es schon so sein soll. Darum war die Frage ja wie man das mit 2 Collections von denen eine
Die 32-Bit-Col sollze in der 64-Bit-Col einfach auszunehmen sein. Geht aber nicht. Dann wäre es nämlich einfach: Nur einen User wieder aus der AD-Gruppe für 32-Bit zu nehmen, und schon ploppt er wieder in 64-Bit auf.
Da drehe ich mich leider im Kreis..
bg, Mayho
- Device-Collection ist / auf Alle / 64-Bit
- die andere User-Collection / AD-Gruppe / 32-Bit
Die 32-Bit-Col sollze in der 64-Bit-Col einfach auszunehmen sein. Geht aber nicht. Dann wäre es nämlich einfach: Nur einen User wieder aus der AD-Gruppe für 32-Bit zu nehmen, und schon ploppt er wieder in 64-Bit auf.
Da drehe ich mich leider im Kreis..
bg, Mayho
Sodala! Ich habe das Problem zwar nicht gelöst, aber umgangen. Und zwar so:
Wenn sich in der User-based-Collection für 32-Bit der Membercount ändert, wird ein PS-Script getriggert das sich aus der entsprechenden AD-Gruppe die User holt, via der User die Primary-Device vom SCCM und diese Devices werden dann in eine Hilfs-Collection eingetragen die in der 64-Bit-Device-Collection excluded ist.
Sowas umständliches musste ich echt noch nie machen! Danke MS für diesen ... Ich schreibe es lieber nicht.
Danke auch dir @Dirmhirn für die Unterstützung und den Hinweis auf Global Conditions.
Bg,
Mayho
Wenn sich in der User-based-Collection für 32-Bit der Membercount ändert, wird ein PS-Script getriggert das sich aus der entsprechenden AD-Gruppe die User holt, via der User die Primary-Device vom SCCM und diese Devices werden dann in eine Hilfs-Collection eingetragen die in der 64-Bit-Device-Collection excluded ist.
Sowas umständliches musste ich echt noch nie machen! Danke MS für diesen ... Ich schreibe es lieber nicht.
Danke auch dir @Dirmhirn für die Unterstützung und den Hinweis auf Global Conditions.
Bg,
Mayho
1
