Updating Office 365 ProPlus. A custom alternative (Using Powershell App Deployment Toolkit and SCCM)

Introduction

First off, this is probably not for everyone. ConfigMgr and WSUS can deploy updates to the O365 ProPlus client just fine and most needs are probably satisfied this way. However, if you are interested in more visibility before, during and after deploying O365 updates to your users – read on!

After updating ConfigMgr to 1706 (from 1610 and 1702) something changed in the behavior of installing O365 ProPlus updates. Previously, in 1610 and 1702, the behavior was actually quite transparent for the end user: A restart flag is set and the update is installed after the computer restarts. This actually meant that you could deploy any update to o365 ProPlus and not worry about notifying your users about anything but the coming restart (which is somewhat similar to the behavior of standard software updates for Windows)

Coming ConfigMgr 1706, this changed dramatically to in-app notifications as well as forced shutdown of apps (and potential loss of unsaved work) if the right circumstances was in place. Also, when the apps are shut down, nothing is being displayed to notify the user about the progress, so most users will re-open the Office apps right away creating even more problems.

The Microsoft Docs article for the change in behavior is outlined right here: https://docs.microsoft.com/en-us/sccm/sum/deploy-use/manage-office-365-proplus-updates#restart-behavior-and-client-notifications-for-office-365-updates

I urge anyone managing O365 updates with ConfigMgr to give it a read and take notes of all the possible outcomes when deploying O365 updates this way. To quote the important ones (note all the maybe’s, which makes the experience really inconsistent):

  • A pop-up notification might not display until the user clicks the icon in the notification area. In addition, if the notification area has minimal space, the notification icon might not be visible unless the user opens or expands the notification area
  • If the deadline is in the past or configured to start as soon as possible, running Office apps might be forced to close without notifications (they do – yay)
  • The in-app notification bar does not display on an Office app that is running before the update is downloaded. After the update is downloaded, the in-app notification displays only for newly opened apps (the yellow in-app bar is inconsistent. Sometimes it shows, sometimes it doesn’t. Reopening apps or not)

So, enough with the ranting. Above is the facts about the poor user experience when running ConfigMgr 1706. Below will be how I used something totally different to create visibility for our users.

Powershell App Deployment Toolkit!

We all know the infamous Powershell App Deployment Toolkit: http://psappdeploytoolkit.com/. (And if you don’t, that’s another day and another blog post 🙂

Below is exactly how (and along the lines, why) I chose to leverage the use of the Powershell Deployment Toolkit and the ODT to deploy O365 updates in my organization.

Configuration

Create the Office Deployment Tool .xml file (Update.xml)

The ODT relies on a .xml file. That is whether you want to update or downgrade your Office 365 ProPlus installation. In this scenario I want to update, and for this I can specify exactly what build I want to update to. If you don’t specify a version, you will be updated to the latest build in your channel. A lot of the content in the .xml is optional, and something you also can manage through ConfigMgr or GPOs.

This is exactly the .xml file I’m using to update my Monthly Channel (previously called Current Channel) clients to the latest build. I manage the channel through GPOs, which is why you don’t see the channel being set in my .xml.

Create the folder structure

This is optional and just an illustration of how I do it. I have a complete folder structure in my source file library equal to something similar to this:

8431.2107 and 8730.2127 are build numbers and is respectively version 1708 and 1711. Complete list of all the builds numbers and release dates for Monthly and Semi-Annual channel, look here!

Inside each build number, I have the Powershell Deployment Toolkit:

Inside the Files folder, I put my newly created Update.xml along side the Setup.exe from the ODT and a Update.bat file (which is what we will have the PS Deployment Toolkit running) containing following:

@echo off
“%~dp0setup.exe” /configure “%~dp0Update.xml”

I’m using a batch file to wrap the installation into, for the diversity and simplicity. If needed I can quickly edit the batch file, update DPs and move on (opposed to edit the PowerShell script)

Roll-back and downgrade

If needed, you can have the ODT (Setup.exe) to downgrade the version of Office 365 ProPlus as well. This is also done configuring the proper settings in an .xml file.

Below is my .xml file used to downgrade Office 365 ProPlus. Notice ForceDowngrade=”True” which is required if you are moving backwards (a SaaS like this, is meant to move forward 🙂 Again, take a look at this page for knowledge about the different versions/builds for your channel: here!

This I wrap into a Downgrade.bat as well inside the Files folder of the Powershell Deployment Toolkit. (In a separate folder. For a separate package in ConfigMgr.)

@echo off
“%~dp0setup.exe” /configure “%~dp0Downgrade.xml”

The above configurations is made to actually download the differences in bits directly from the Office CDN. This is also something to consider if using this method. However, you can specify SourcePath=”” to let the installation grab the bits from a local source if desired. Microsoft has specified the download sizes in this post here!

Deployment

With all of above in place, you will be ready for deployment with ConfigMgr. Note that I assume that you know your way around the Powershell Deployment Toolkit.

To target the update of Office to the proper computers, I use collections. ConfigMgr is able to inventory a lot of useful information regarding the Office 365 ProPlus client which includes the current version, channel etc:

This query example will give you all computers that: Has Office 365 ProPlus installed, runs on Current Channel set through GPO and is NOT already on the latest 1711 build. (This should probably be altered to fit your needs and environment, depending on various factors)

With this in place, you will have isolated the computers in need of being a target for your Office 365 ProPlus update.

Finally

Now there’s only a few steps left, but I assume you already know how to:

  • Customize your Powershell Deployment Toolkit to your needs
    • Close the Office apps, and keep them closed (prevent users from starting any, until the installation is done)
    • Keep the user notified during the entire process through custom dialogs
    • Show a friendly restart dialog, prompting the user to restart within allotted time
  • Create a package in ConfigMgr, distribute to your favorite DPs
  • Test the deployment
  • Deploy to your users
  • Be happy about the process being a lot smoother in regards to user friendliness.

GIF of everything in action: Installation running, user trying to open Word and the dialogs that follow.

Detect vulnerability in TPM (ADV170012) using ConfigMgr Compliance Settings

Introduction

Coming Patch Tuesday this month, Microsoft revealed a whooping vulnerability in some infineon TPM chips; ADV170012

In the above article, Microsoft gives us some insight on the vulnerability itself, as well as how to detect and counter the vulnerability.

As how to detect the vulnerability, they released a patch which writes an entry to the event log and highlights the vulnerability in TPM.msc.

They also released a Powershell script, which they in turn – unfortunately – don’t go into much details about. They tells us to use PSremoting to query multiple computers and nothing else.

So, how about using ConfigMgr to detect whether our computers are vulnerable or not? Compliance Settings to the rescue!

I rewrote their script to instead return $true or $false, and make it usable to detect compliance or non-compliance.

So, following is my edition of the script, and how to setup the CI in ConfigMgr

Configuration

  • Create a new CI. Give it a name and enable it to run on all Windows Desktops and Servers (Custom)

  • At the Specify settings for this OS page, click New

  • In the Create Setting page, select Script and Boolean. Insert my script from above in Edit Script

  • In the Create Rule page, select the newly created CI

  • Add the completed Configuration Item to a Configuration Baseline and deploy to selected collections

Summary

  • Taking a closer look directly on the client on the Configurations tab of the ConfigMgr client, you will either notice a compliant or non-compliant state

  • For a better summary of compliance, I personally like to create collections. Go to the deployment of the Configuration Baseline, and right click. Below is your options to create additional collections

  • The net result is a set of collections which memberships clearly tells the compliance state of the TPM vulnerability

Download my CI and baseline here: https://www.imab.dk/mab/CB_TPMVulnerability_Status.zip

Enjoy 😎

 

Switch Office 365 ProPlus update channel using the Software Center in SCCM (System Center Configuration Manager)

Introduction

Following is a post on how I let (some) of our users decide whether they want to roll on the Current Channel (now called Monthly) or the Deferral Channel (Now called Semi-Annual and Broad) for Office 365 ProPlus.

According to numerous blogs on the www, there are several ways of doing this; modifying registry, GPO, reinstalling Office or to rerun setup.exe from the Office Deployment Tool (ODT).

I’ve chosen to go with the last option, and modify the channel through setup.exe coming from ODT. (I spent some time on GPO and modifying the registry without the expected results. However using setup.exe gives you visibility and a method that yields the results right away)

Configuration

  • Go ahead and download Microsoft Deployment Tool (ODT) if you haven’t already. Link: Download Office 2016 Deployment Tool
  • Create two new .xml files containing following content (one for each channel switch)

Semi-Annual channel (also called Deferred or broad):

Monthly channel (also called current):

  • Put the .xml files in folder next to setup.exe from the Microsoft Deployment Tool (ODT)
  • Create two .bat files containing following content (one for each channel switch)
    • I’m deleting the current regkeys responsible for setting the channel prior to making the actual switch. This is due to some weirdness I’ve been seeing where the values are not properly updated.

SetDeferred.bat:

SetMonthly.bat:

  • Put the two .bat files into the same folder and copy the content to your content library used in ConfigMgr (Whereever that may be. This is pretty standard, so I’m not going into details here)
  • Create two new Applications in ConfigMgr with a Deployment Type set to Script Installer. Below the snippets from the Create New Application process.

  • Set the previously created .bat files as the installation program (SetDeferred.bat)

  • Detection rules for the applications will be the corresponding registry keys. The value of the below registry key is changing upon switching channels.

Monthly Channel: http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60

Deferred Channel: http://officecdn.microsoft.com/pr/7ffbc6bf-bc32-4f92-8982-f9dd17fd3114

  • Distribute the content of the newly created applications to your preferred distribution points (groups), and deploy the applications.

Summary

Running the applications will result in either an upgrade or downgrade of Office 365 ProPlus.  This should be followed by a series of windows which will take you through the process for the new channel that you have switched to.

This is something I have deployed internally in the IT department, enabling them to easily switch between the channels.

Enjoy! 😎

References:
https://support.microsoft.com/en-us/help/3185078/how-to-switch-from-deferred-channel-to-current-channel-for-the-office
https://blogs.technet.microsoft.com/odsupport/2017/05/10/how-to-switch-channels-for-office-2016-proplus/

Converting from BIOS to UEFI with Powershell (During OSD using SCCM on Lenovo laptops)

Following my previous post, this is an quick example on how to use my Powershell script to convert from BIOS to UEFI in a bare metal scenario. (Again, only Lenovo laptops is working with this script)

Most of the magic lies within the Task Sequence itself, so I will break it down in pieces:

  • Create a group in your Task Sequence called “Prepare Computer (BIOS)” with the condition _SMSTSBootUEFI not equals true (This will make sure the content of the group only runs if UEFI is not enabled already)

  • Next step, format the disk with following settings (Step: Format and Partition Disk (BIOS))
    • Disk type: Standard (MBR)
    • Partition type: Primary
    • 100% remaining disk
    • File system: NTFS

  • Next step, create a new group called Config Lenovo BIOS with following condition: SELECT * FROM Win32_BIOS WHERE Manufacturer = “Lenovo” (This will make sure the step only runs on a Lenovo computer)

  • Next step, run my Powershell script directly from a package like shown below. The parameter -EnableSecureBoot will also enforce UEFI to be enabled.

  • Next step, format the disk with following settings (Step: Format and Partition Disk (BIOS to UEFI))
    • Disk type: GPT
    • Partition type: Primary
    • Size: 600Mb
    • File System: FAT32
    • Variable: TSUEFIDrive
  • Add another partition:
    • Partition type: Primary
    • Size: 100% of remaining space
    • File system: NTFS
    • Variable: None

  • Next step, one final reboot to the boot image currently assigned to this task sequence. When the task sequence returns from the reboot, the Lenovo BIOS will be set to SecureBoot AND UEFI and Windows will continue installing.

Ultimately, you can have 2 steps to take care of when the computer is coming with either BIOS setting or UEFI, and act accordingly. Se below snippet for inspiration.

Enjoy! 🙂

 

Manage Lenovo BIOS with Powershell (During OSD with SCCM)

Update: Post and script moved to https://www.imab.dk/lenovo-bios-configurator/

I have no idea if this is something that has already been created out there, but I figured I’d do it anyway. Mostly because Powershell, I need the practice and I needed the ability to easily modify the BIOS in our Lenovo environment.

The script is inspired by the original VB script from Lenovo, which roughly does the same as my Powershell script. Lenovos script and documentation can be reached from this link (https://support.lenovo.com/dk/en/solutions/ht100612). However, it’s VB and it gives me shivers, so Powershell to the rescue.

The script is still work in progress, as it doesn’t hold all the abilities as the original Lenovo script, but I prioritized the ability to turn on/off following: Virtualization, SecureBoot, PrebootUSB-C/Thunderbolt and TPM.

You basically just run the script with parameters. Example: LenovoBIOSManagement.ps1 -EnableTPM -EnableSecureBoot -DisableVirtualization -Restart

An example from the use in my recent Windows 10 Task Sequence. The step is run prior to formatting the disk in WinPE. I have a condition on the step, to only run if a Lenovo laptop.

Enable Preboot Thunderbolt is separated as a single step, as it’s currently only the most recent Lenovo laptops which has this ability: T470s, X1 Yoga 2nd generation etc., and therefore has a condition to only run if such model is being deployed.

I’d appreciate any feedback. I’m by no means any Powershell champ, but I’m still learning – and willing to learn 🙂

Thanks!

Update: Post and script moved to https://www.imab.dk/lenovo-bios-configurator/

Configuration Manager collection based on Client Creation Date (Dates in WMI)

I just had a very specific scenario, requiring me to target all new mobile devices (post a specific date) with a different set of compliance settings, than the rest of the devices.

In that case you can separate newly created devices in their own collection, based off their creation date.

The time of when a device is created is stored in the database, and the data can be queried through WMI using WQL.

A date formatted in WMI is using following syntax: yyyymmddHHMMSS.xxxxxx±UUU and can look like this:

20170819071629.492270+120

So, if you want all devices created post July 1 2017, your query have to look like this:

The syntax for dates in WMI in details: https://technet.microsoft.com/en-us/library/ee198928.aspx?f=255&MSPPError=-2147217396

Powershell: Enable virtualization and Credential Guard in an instant (Lenovo laptops)

Windows 10 Credential Guard is currently another hot topic considering cyber security. Credential Guard is a new feature in Windows 10 (Enterprise and Education edition) that helps to protect your credentials on a machine from threats such as pass the hash.

To be able to enable Credential Guard in Windows, you need to have virtualization enabled on the CPU in the BIOS. Virtualization is rarely enabled by default, and as such you will need to enable it manually (F1, enter BIOS, modify the setting) or better yet, find a solution to do so remotely and automatically.

I have created following script in Powershell, that initially enables virtualization in the BIOS (Note: We only use Lenovo laptops, hence this is made for Lenovo laptops only) and then apply the registry-keys to enable Credential Guard. All steps are logged into c:\Windows\EnableCredentialGuard.log

The script can be targeted to the proper Windows 10 versions through SCCM collections (I this example I only target W10 1607 and 1703, as these Windows 10 versions no longer require the Isolated User Mode feature when enabling Credential Guard, as it’s now embedded into the Hypervisor)

When deploying powershell script from SCCM, remember to create the program with a command line like this: powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -File .\CredentialGuard\Enable-VirtualizationCredentialGuard.ps1

Snip of the logfile when everything succeeds:

WSUS maintenance for ConfigMgr

So it was my turn to face problems. I had neglected the obstacle for months excusing myself that everything was still working wonders, until today.

Following screenshot was the reality of my WSUS console when trying to run the server cleanup wizard:

wsuserror

Add so the struggle to solve the problem began and following is the facts and solution:

  • I’m using WSUS running on the internal database in Windows (WID), so I downloaded and installed SQL Server 2014 Management Studio on my server running WSUS
  • Connected to \\.\pipe\microsoft##WID\tsql\query in the Connect to Server window

studioconnecting

  • Ran the following two SQL scripts. My WSUS DB was so bloated that the reindex script from the scripting guys didn’t cut it. When that happens, the deal usually is that you have to delete updates manually directly in the DB.
    Fortunately for me, I found below script to my aid. The script runs the stored procedure EXEC spGetObsoleteUpdatesToCleanup and then deletes the updates. Beware, running these scripts may take several hours depending on the specs of the server and the amount of updates)
  1. DeleteObsoleteUpdates
  2. WSUSreindex

This is a snip of the two scripts showing directly in Management Studio, saved for later use as .sql.

studioscripts

Lesson learned:

Maintaining the SUSDB is important, and is not just something you setup and leave even though running it integrated with ConfigMgr.

**Will update this post on how I’m going to automate this in the future.

How to flash BIOS with SCCM during OSD (Lenovo ThinkPad laptop)

Note: June 3 2018: This post will be updated as soon as possible with some minor changes and reflect how I do this today 🙂

In this blog post I will go into details about how I flash the BIOS of our Lenovo ThinkPad series during OSD using ConfigMgr.

First off you obviously need to download the latest BIOS from the Lenovo support site: http://support.lenovo.com/dk/en/. In this example I’m flashing the BIOS of a ThinkPad T450s.

Go ahead and locate and download the BIOS Update Utility for Windows. The most recent version as of now for T450s is 1.21:

T450BIOS

When downloaded, extract the content to your source file library. In this case I have a folder structure equal to this: D:\Pkgsource\Applications\Lenovo\BIOS\T450S\1.21

The content of the 1.21 folder should be looking like this:

T450BIOS2

Next, mind the highlighted file: FlashBIOS.cmd. Create this file manually with following content (I exit the script with exitcode 0, as the BIOS update itself might return exitcodes seen as failures. Some might dislike this approach, but you can also translate the actual exitcode into zero using whatever method you prefer):

“%~dp0WINUPTP.exe” -s
exit 0

T450BIOS3

With this in place, go ahead and create a package in ConfigMgr with above content and distribute the package to your distribution points (I’m not going into details on this one, as this is pretty standard).

My packages in ConfigMgr looks like this (I have highlighted the package used in this example):

T450BIOS4

Next we will be using the package in our task sequence in a step of Run Command line. This is done somewhere after the step of Setup Windows and Configuration Manager like this (I put BIOS updates in the end of my task sequence as they require reboots):

T450BIOS5

As updating the BIOS to this specific version is a onetime operation, you would want to add following conditions to the Options tab:

T450BIOS6

This will make sure that the step is only run when a Lenovo Thinkpad T450 is being deployed AND when the BIOS is not already the most recent version (no need to run the step again, if the same laptop should be reinstalled in a near future)

You can run following powershell commands to display the computermodel and what BIOS version that currently is installed:

Get-WmiObject Win32_Computersystem

Get-WmiObject Win32_BIOS

T450BIOS7

Enjoy 🙂

Update 1602 for System Center Configuration Manager Current Branch

So, Update 1602 is out for SCCM Current Branch and I just updated my environment.

The new 1602 update is available from within the SCCM console, browsing: Administration > Cloud Services > Updates and Servicing. Right Click the update and select Install Update Pack.

1) Click next on the general page.

1

2) Select the desied features to be included.

2

3) Options for Client Update. I decided to test the new SCCM client on a selected test collection at first.

3

4) Finish the wizard and accept the license terms.

4

5) Go watch CMUpdate.log and wait for following line in the log: INFO: Successfully dropped update pack installed notification to HMan CFD box which translates into installation is complete.

6

Notes from the field:

  • I ran the pre-requisitecheck on the 1602 update before installing. Doing so required me to restart the SMS_EXECUTIVE service on the site server before the actual installation would continue. The status in the console was stuck on Installing, but nothing happened until the restart of the service. (CMupdate.log)
  • I decided to test the new client on a pre-production collection. Doing so actually did that the client binaries wasn’t updated (\\Siteserver\SMS_SITECODE\Client). To update the client binaries, you have to go back to the 1602 update in the console and accept the new client for production in Client Update Options. Yet again, I had to restart the SMS_EXECUTIVE service to see any action in CMupdate.log.

5