(gears whirring)
- Coming up on the last part in our series,
we're gonna take a look at everything that you need to know
for managing Office using
System Center Configuration Manager.
Now, I'm gonna walk you through all the steps to keep your
managed Office apps up-to-date
and when to install Office on top
of an existing Office install
and how you can troubleshoot day-to-day issues.
Now, the move to click-to-run packaging
across the board for Office client apps
on Windows means that you'll want to be familiar
with post-deployment servicing,
how to lay out new capabilities
and also resolving issues.
I'll start with post-deployment servicing.
Remember back in planning,
we explained the servicing channels:
monthly, semi-annual,
as well as semi-annual and monthly targeted channels.
Now the monthly channels is gonna include
new features, bug fixes and security fixes.
Importantly, the semi-annual channel options
still continue to receive regular security and bug fixes
in between semi-annual releases.
Again, monthly channel is recommended
for general purpose PC's.
Now, in day-to-day operations, any of these updates
may be targeted to your manage PC's,
and if you don't have a history with click-to-run software
updates, the way that updates are packaged and delivered
is fundamentally different than before.
Now these are full installation packages
and the update process calculates the difference
between what's on the PC and the update
to choose the files that get applied.
So, there are no more .msp files.
And updates can be applied to existing installs
whether they've been recently updated
or very out of date.
Also, there's no need to reboot Windows as part
of the Office update process.
In general, software updates resemble in place upgrades
for already installed versions of Office.
Now, what it's gonna do is, it's gonna look at a list
of components that are offered in the package,
and see what's already there and still usable.
Then it's going to determine the components
that are out-of-date on a local machine,
and bring the out-of-date replacement
plus all the net new components
from the update package down.
And like the initial install,
you can point the Office update engine to files
that are served on-premises, on a local hard drive,
or the internet, but internet connectivity
is not always required.
Now, once the update engine compares what's already
installed with what's needed in the update source,
it's gonna download those update files
and it's also gonna save them temporarily
into a place called
"Program Files > Microsoft Office > Updates > Download".
Once the download's complete,
the process then moves those files to
"Program Files > Microsoft Office > Updates > Apply".
and at that point, closing and re-opening the Office
client apps are gonna trigger a straight file swap
for the new files and then your Office is up to date.
Now, if a user doesn't naturally close and re-open
their Office apps, or restart their PC as part
of their normal work flow, Office by default
is gonna start to begin to notify the user
via built-in Window system tray notifications,
after four days has passed.
After six days, a message will appear in the Office apps
themselves, informing the user that an update
is ready to apply.
Of course, there are group policies available
to admins to modify notification behavior and update timing.
Now when ready, users simply need to save their work,
close and reopen their Office apps, and the update process
itself just takes a couple of seconds, and again
it won't require Windows to reboot.
Now, let's look at the scheduled tasks
that are run in Office.
There are a few processes, such as
Office See to our Client.xe,
O license heartbeat.xe, and a few other Office processes
run on a regular schedules by default.
Now these are doing things like looking for updates
based on your channel and configuration,
checking licensing status of the install and rearming
as needed, and running background tasks to update Office.
So the update detection by default now runs at login,
weekly at 3:00 am, and also at computer idle times.
Now, if your using SCCM, the update engine
works in the same way and recommend that you continue
to use automatic updates from the Office CDN
for the majority of your PCs.
Now, what this will do is save you time discovering,
downloading and also pushing update packages to your
distribution points and collections.
Now, that said, you can still manually discover
and approve updates to your click-to-run packages
and Office apps, using the normal update process in SCCM.
By default, Office install packages created in SCCM
are gonna enable a property called Office Management Com,
to use your SCCM distribution points as deployment
and update source locations.
Now, these can be overwritten post-installation
using group policy to change the update location,
to use the Office public CDN as the update source.
Now, I mentioned that updates behave similar
to in-place upgrade.
Since the update engine is pointing to a full set
of installation source files, for certain post-deployment
scenarios, you can take the concept one step further,
and install Office on top of an existing install
with the same version of Office
or what we call second install.
Now, a second install of Office can be used to make
an addition to the existing Office install,
or to change what's there.
You might use it for things like adding Visio or Project,
or any other previously excluded out.
Or you can add a language pack.
Now, like the update process, the second install process
in this case looks at what's already on the PC,
compares it with the package and the properties
you want to install, then basically
applies what's different.
So, now we've described your servicing and post-deployment
configuration options, let's move on to trouble shooting
and issues management.
To troubleshoot updates or installs, Office logs
follow the following naming convention:
Machine name, Year, Month, Day and Time.
Now, logs themselves can help you troubleshoot
deployment issues and are stored in
"AppData > Local > Temp", or "Win > Dir > Temp".
And you'll wanna inspect the files also with Office,
C2R, or Click-to-Run and their names.
Now you can use the Microsoft Office
Support and Recovery Assistant Tool to help troubleshoot
common issues as well.
You can also make sure Office scheduled tasks are present
in Task Scheduler and haven't been disabled.
And also check that the device can access
your defined update path.
For example, you can try pinging things like
OfficeCDN.Microsoft.com and see if that resolves.
You can also try pinging your SCCM distribution point
or other custom defined location.
Now, you're gonna wanna check Program Files,
"Microsoft Office > Updates > Download" and also
the Apply folders for the presence of update packages
to make sure they're flowing in.
Check the registry for the last trigger source
to make sure it's set properly.
Usually, that's gonna be set to Scheduled Task,
and that's found in
HKLM\Software\Microsoft\Office\Click to Run\Scenario\Update.
Or, you can check HKLM\Software\Microsoft\Office\
Click to Run\Configuration for a version to report
and make sure that the version's correct.
Now you can try deleting the updates folder
in Program Files\Microsoft Office, to see
if triggering the update itself will actually hydrate
those update files again.
Now, in some cases activation services will not
rearm Office licensing.
In these cases, the best things to do are
check network connections and make sure they resolve
to your licensing services, ensure that the user
is provisioned in Azure Active Directory,
and correctly enter their credentials.
You're gonna also wanna ensure that user's licensed
for corresponding Office subscription versions,
and if your using KMS, make sure that PC can
hit the KMS service and that matching KMS keys
have been installed on the KMS server.
Now, you're also gonna wanna check if a product key
is configured on the device.
Now, this applies to all activation types,
and to do that, you run OSPP.vbs
to check the licensing status.
The command that you use is C script,
C:\Program Files\Microsoft Office\Office16\OSPP.vbs
using the D status switch.
Now, in some cases, you'll need to use Olicensecleanup.vbs
to remove activation and then sign in again to reactivate.
Now, certain Office issues might result in recently applied
Windows updates or other apps installed on the device.
Now, a common questions and common cases that we hear
about that are things like default file associations
are lost, this is common for example, when a .pdf moves
from Word to the Edge browser, or Adobe Acrobat Reader,
or Pin Task Bar and Start Manual Icons for Office apps
getting unpinned after an update.
Now, we've covered Windows 10 Start
and Task Bar customization using PowerShell
and policy is part of the Desktop Deployment Essentials
series at aka.ms\ddev4.
Now, finally, to fix issues before uninstalling
and reinstalling Office to a known working version,
you can take steps on a local PC to attempt manual repairs.
Now, this is where things like Quick Repair
and Online Repair can help.
Now, you'll access these options in Windows settings
via apps and features, your Office install
and then the modify button.
Now, Quick Repair can run in standard user context,
without a local admin privilege,
and without internet connectivity from locally
stored source to perform simple tasks.
Things like, taking back default file associations or DFA's.
You can also do an Online Repair which needs to be run
with local admin privilege and internet connectivity.
But, essentially, that's gonna reinstall
the affected version of Office according
to previously configured installation
parameters and properties.
All right, so now you should be able to manage
and keep your Office installs up to date
in your desired configuration
and also troubleshoot common issues
with a few common fixes.
And if you wanna see more in this series,
go to aka.ms/officeitseries.
Thanks for watching.
(digital music)