Manage your Office 365 ProPlus deployment with cloud-based policies (preview)

Typically you manage your Microsoft Office installations by using group policies(-only) and options you have before you deploy the software to the computers within your organisation. However, now cloud-based policies for Office 365 ProPlus are in preview (Feb. 2019). These new option helps you to centrally mange Office 365 ProPlus deployments either for domain-joined or non-domain joined (but MDM managed) devices.

The cloud-based policies are for enforced user-based settings management and can complement group policies.

It only works for the Offce 365 ProPlus suite.

Further Ressources

Advertisements

System Center Configuration Manager 2016

SCCM 2016 Preview – Let the tests begin!

System Center Configuration Manager und Endpoint Protection 2016 sind als Preview für einen 60-Tage-Testzeitraum verfügbar.

https://www.microsoft.com/en-us/evalcenter/evaluate-system-center-configuration-manager-and-endpoint-protection-technical-preview

SCCM 2016 Releases?

Aufgrund des zeitlichen Versatzes für das Windows 10 Release (Q4/2015) und Windows Server Relase (KJ 2016?), wird es angeblich zwei SCCM 2016 Releases für Windows 10 und später eines für Windows Server geben. Ich vermute hier wird es eine Art Update (SP/CU) und kein “R2” für SCCM 2016 geben. (vgl. http://windowsitpro.com/configuration-manager/configmgr-2016-release-twicehttp://scug.be/sccm/category/system-center-2016/). Für SCCM 2012 / R2 sollen laut SCUG Blog Servicespacks erscheinen, um verschiedene Features/Supportability (Welche? -> vgl. SCUG Blog) zu integrieren oder zu aktualisieren.

SC 2012 Configuration Manager Servicing Extension Preview

System Center 2012 Configuration Manager Servicing Extension (~SCCM2012SC, (noch) keine offizielle Abkürzung) befindet sich aktuell noch in der Betaphase.

Servicing Extension ist eine Erweiterung der SCCM Konsole. Die Funktionen sind in einem neuen Knoten des Arbeitsbereichs Administration zu finden. Was kann ich dort finden?

  • Benachrichtigungen zu CM Updates sobald veröffentlicht
  • Informationen über die CUs die in den CM Sites installiert sind
  • Einfache und schnelle Erstellung von Queries basierend zum Prüfen der Client Versionen (2012, SP1, R2, CUx)
  • RSS Reader für den System Center Configuration Manager Team Blog und den Configuration Manager Support Team Blog

This slideshow requires JavaScript.

Eine praktische Erweiterung! Wenn ich nicht jeden Tag meine RSS-Feeds lesen kann oder einen übersehen habe, zeigt mir SCCM2012SC über einen längeren Zeitraum hinweg alle wichtigen Updates an.

SCCM Software Deployment Process

Der Ablauf für die Verteilung von Software mit dem System Center Configuration Manager (SCCM) sollte immer der gleiche sein. Ich habe mir mal die Zeit genommen, einen typischen Software Paketierungs- und Verteilungsprozess grob zu modellieren. Je nach Unternehmen, Paktierer und Umgebungsvariablen weicht der Software Deployment Process von dem hier exemplarisch gezeigt Prozess ab. Trotzdem sollte für eine gute End User Expierence auf die rudimentären Aspekte und Vorgehensweisen geachtet werden. Denn der User steht im Mittelpunkt und soll gefördert werden, so dass dieser seinen Aufgaben effizient erledigen kann.

TYPICAL SCCM SOFTWARE DEPLOYMENT PROCESS


TYPICAL SCCM SOFTWARE DEPLOYMENT PROCESS

Eine Ergänzung zu diesem Prozessbild:

  • Beim Troubleshooting oder beim Bedarf an Metriken zur Erfolgsmessung sind die Reporting Services für den Configuration Manager überaus hilfreich und nützlich. So kann einerseits alles wesentliche für Software Deployments aus den Reports abgelesen und darüber hinaus in praktischen Formaten (Excel, PDF, CSV, …) exportiert werden. Letzteres ist vielleicht nicht nur für einen SCCM Admin, sondern auch noch Vorgesetzte oder bestimmte andere Kollegen in einer IT-Abteilung nützlich. Z. B. für das Software Asset Management, …
  • Der Anteil der Kommunikation beim Paketieren oder Vorbereiten von Software für die Verteilung darf nicht unterschätzt werden. Wenn die Anforderungen für die Bereitstellung der Software geklärt werden (nicht im Prozess), kann sehr viel Kommunikation über verschiedene Ebenen (Software-Verantwortlicher, Vorgesetzte, Superuser, Hersteller) erfolgen. Technisch gesehen ist bis dahin fast nichts passiert, aber zeitlich gesehen, wurden Sofortnachrichten, Mails geschickt, Telefonate geführt und unter Umständen Meetings einberufen.

SCCM2012SP1 – Change Package Source Path

In manchen SCCM Migrationen kann es sowohl sinnvoll als auch erforderlich sein die Quellpfade von Paketen anzupassen. Bei einigen wenigen Paketen kann diese Aufgabe über die SCCM Konsole erledigt werden. Was ist aber wenn alle Quelldaten auf einen anderen Fileserver und dort auf ein neues Share umgezogen wurden? Wie macht man so etwas bei vielen hundert Paketen am besten?

Aufgrund der genialen PowerShell-Integration in SCCM 2012 SP1, nehmen wir doch diese! Gesagt, getan! Skript geschrieben! Da die Skript-Kommentare das Skript erklären, werde ich auf Redundanzen verzichten und an dieser Stelle nichts weiter erklären. 😉

##############################################
#Author: E. Kleefeldt
#Date: 27.05.2013
#Titel: MovePackageFileSourceLocation
#Description: Move Packages Source Location from $Src to $Dest
#Version History:
#27.05.2013 V 1.0 Created
##############################################
write-host "Script muss mit PowerShell x86 ausgefuehrt werden!" -foreground yellow
write-host "Die ExecutionPolicy muss auf unrestricted gesetzt sein." -foreground yellow
write-host "Im Vorfeld müssen die Pfade in den Variablen definiert werden." -foreground yellow
write-host "Die Ausführung wird jetzt beginnen." -foreground green
#Grundlegender Input
$sitecode='EKL:' #Don't forget the colon!
$cmmodule='C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin\ConfigurationManager.psd1'
#Import CM2012-Module
Import-Module $cmmodule
Set-Location $sitecode
#Quell/Zielpfad
$src='\\ws08fs01\packages$'
$des='\\ws12fs01\SourceFiles$'
write-host "Package Name holen." -foreground yellow
# AUSGABE PFAD NEU (Preview des Ergebnisses)
Get-CMPackage | ForEach-Object {write $_.PkgSourcePath.replace($src,$des)}
# ANPASSUNG DER PFADE
# Auskommentieren, wenn Preview erfolgreich
# Get-CMPackage | ForEach-Object {Set-CMPackage -Name $_.Name -path $_.PkgSourcePath.replace($src,$des)}
write-host "Package Location Change abgeschlossen." -foreground Yellow
write-host "Ergebnis prüfen." -foreground Yellow

Mit etwas Kreativität kann das Skript angepasst werden, damit die Quellpfade von Deployment Types ebenso angepassst werden.

Aktivieren von inkrementellen Updates

Einer des wohl schönsten Neuerungen von SCCM 2012 SP1 ist die PowerShell-Integration. Trotz allem fehlen an der ein oder anderen Stelle noch Optionen, um wirklich alles per ConfigMgr Cmdlets steuern zu können. So können inkrementelle Updates für Collections nicht per Set-CMDeviceCollection cmdlet einfach aktiviert werden.

SCCM 2012 SP1 Device Collection Wizard

SCCM 2012 SP1 Device Collection Wizard

Mit Hilfe von inkrementellen Updates wird immer nur das Delta erfasst und in die jeweilige Collection aufgenommenen. Angenommen wir haben seit ein paar Minuten neue Computerobjekte durch den Active Directory Group Discovery Prozess erfasst und damit in der Site Datenbank. So können wir durch setzen des Hakens periodisch die neuen Objekte in die Collection aufgenommen bekommen. Wenn wir den Haken nicht setzen, werden die Objekte erst bei einem geplanten vollständigen Update erfasst. Was heißt nun periodisch?

SCCM 2012 SP1 Incremental Update Period

SCCM 2012 SP1 Incremental Update Period

Periodisch heißt standardmäßig alle fünf Minuten.

Was ist aber nun, wenn wir mehrer hundert oder gar tausend Collections in unserer SCCM-Umgebung haben? Wie können wir diesen Haken dann bei allen Collections setzen bzw. sicherstellen, das der Haken für inkrementelle Updates bereits gesetzt wurde? Wir nehmen die PowerShell und arbeiten alle Collections mit einer ForEach-Object-Schleife ab. 10 Minuten anstatt 10 Tage exzessive Mausklickerei. 😉

Um den Haken für alle Device Collections zu setzen habe ich folgendes Script geschrieben:

##################################
#Enable Incremental Updates
#SCCM 2012 SP1 Collections
#V1.0 2013-05-08 Erik Kleefeldt
#PowerShell x86 verwenden!
#Set-ExecutionPolicy Unrestricted -Force needs to run first
##################################
#Basic Input
#Siteserver,Sitecode,Install Dir for the Admin UI (not CM12 install dir)
 $siteserver='WS12APP1'
 $sitecode='F01:' #Don't forget the colon!
 $cmmodule='C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin\ConfigurationManager.psd1'
#Import CM2012-Module
 Import-Module $cmmodule
 Set-Location $sitecode
#Acitvate each DeviceCollection for incremental Updates if it's not already active 
 Get-CMDeviceCollection | ForEach-Object {
 $temp=[String]::format("\\{0}\root\sms\site_{1}SMS_Collection.CollectionID='{2}'",$siteserver,$sitecode,$_.CollectionID)
 $a=[wmi] $temp 
 if ($a.IsBuiltIn -ne $true) {
 $a.RefreshType=6
 $a.put() > $null
 write-host "Update for" $a.Name "is now activated." -foregroundcolor green
 }
 }

write-host "Incremental Updates for all device collections is now enabled!" -foregroundcolor yellow
...

In diesem Script werden nur Device Collections modifiziert. Damit wir auch User Collections genauso anpassen können, muss lediglich das ConfigMgr Cmdlet “Get-CMDeviceCollection gegen Get-CMUserCollection ausgetauscht werden.

#Acitvate each UserCollection for incremental Updates if it's not already active 
 Get-CMUserCollection | ForEach-Object {
 $temp=[String]::format("\\{0}\root\sms\site_{1}SMS_Collection.CollectionID='{2}'",$siteserver,$sitecode,$_.CollectionID)
 $a=[wmi] $temp 
 if ($a.IsBuiltIn -ne $true) {
 $a.RefreshType=6
 $a.put() > $null
 write-host "Update for" $a.Name "is now activated." -foregroundcolor green
 }
 }

write-host "Incremental Updates for all user collections is now enabled!" -foregroundcolor yellow
C:

Das war’s auch schon!

SCCM 2012 SP1 Incremental Update activated

SCCM 2012 SP1 Incremental Update activated