Wenn man mit Microsoft oder zumindest Microsoft Partnern im Zusammenhang mit Softwareverteilung streitet werden verschiedenste Gründe genannt die angeblich für SCCM sprechen. Ein solcher streitbarer Grund ist die angeblich bessere globale Verfügbarkeit.
Unbestritten ist Microsoft nicht nur größer, sondern auch umfassender und global besser aufgestellt als HeatSoftware. Das gilt sicherlich auch für das Partner-Ökosystem. Microsoft Partner gibt es in mehr Ländern als HeatSoftware Partner.
Allerdings ist nicht jeder Microsoft-Partner gleichzeitig ein SCCM Partner. Hingegenist ein sehr großer Teil der HeatSoftware Partner auch Softwareverteilungsspezialist. Das bedeutet, dass wenn man schaut wo HeatSoftware Partner hat, dann weiß man in etwa wo es DSM Berater gibt. Das gleich kann über SCCM Consultants nicht gesagt werden.
Unternehmen die im Sinne der Softwareverteilung global agieren können vermutlich in zwei Kategorien einteilt werden. Die, die alles zentral steuern und automatisieren und die, die dezentral agieren. Der Wunsch bzw. Bedarf an global verfügbaren Beratungshäusern dürften insbesondere in der zweiten Kategorie der Unternehmen vorhanden sein. Allerdings muss hier genauer hingeschaut werden. Welcher Bedarf liegt in diesen Fällen eigentlich vor? Geht es um einen Bedarf an Infrastrukturberatung oder geht es eher um Paketierungsunterstützung?
Egal ob zentral oder dezentral Paketiert wird – keins der mir bekannten Unternehmen zieht dezentrale Infrastruktur-Berater in Betracht. Die Infrastruktur wird – zumindest bei den mir bekannten Unternehmen – immer zentral geplant und gesteuert. Lediglich Paketierungsaufträge werden teilweise global eingekauft. In manchen Fällen passiert dies sogar in den Zentralen, dass die Paketierung per Outsourcing geregelt wird.
Diese Kriterien betrachtend muss man sagen, dass eine vermutlich bessere globale Verfügbarkeit von SCCM keinen Vorteil darstellt. Wie wir in einem der nächsten Blog-Artikel dieser Serie sehen werden hat SCCM erstaunlicherweise keinerlei Paketierungsfunktionalität in sich. Falls dies jemand noch nicht bekannt sein sollte: SCCM ist zwar ein Software-Verteilungswerkzeug, es hat aber erstaunlicher Weise keinerlei Paketierungsfunktionalität integriert! SCCM kann lediglich etwas externes anstoßen.
Benötigt man also externe Unterstützung , so benötigt man – wie oben bereits erläutert – lediglich jemand, der sich mit einem Paketierungswerkzeug auskennt.Da man mit SCCM gar nicht paketieren kann bringt ein SCCM „Spezialist“ in diesem Sinnegar nichts,
D.h. man benötigt eigentlich jemand, der sich mit MSI, Powershell, VBScript oder gar Batch-Scripten auskennt. Ein SCCM Kenner bringt keinen wesentlichen Vorteil. Dieser jemand, der für SCCM Pakete zuliefern kann muss diese Zulieferung in einer Form zur Verfügung stellen, die in jedem Fall auch von DSM ausgeführt werden kann.
Fazit
Es ist sicher richtig, dass man auf der Welt – und insbesondere global – mehr SCCM als HeatSoftware Berater finden wird. Benötigt wird aber Paketierungsknowhow. Da SCCM kein Paketierungswerkzeug ist werden somit nicht SCCM Berater sondern Paketierungsberater. Auf Grund der Funktionalität von DSM und SCCM kann man sagen, dass jedes Paket, welches mit SCCM ausgeführt werden kann auch mit DSM ausgeführt werden kann. Andersrum gilt das nicht!
Mit anderen Worten. Jeder, der für SCCM Pakete erstellen kann, kann diese auch für DSM zuliefern. Andererseits kann nicht jeder der DSM Pakete erstellen kann diese auch für SCCM erstellen.
Aus diesem Grund Werte ich die globale Verfügbarkeit von SCCM zu DSM Beratern mit einem Unentschieden.
Zwischenstand SCCM : DSM (2,5 – 0,5)
Im nächsten Blog werde ich das Thema Paketierung mit SCCM und DSM näher beleuchten
