Here are two different series I wrote for deploying M365. The first is a more generic overview, then a second of applying it in an enterprise.

Microsoft 365 Deployment Series with MEMCM

• Intro & PreReqs
• Creating the Office Installer – Simple
• Creating the Office Installer – Advanced
• Deployment Methods
• Office Updates / ADR

Enterprise Deployment Lessons Learned

• Part 1 – Content
• Part 2 – Changing Channels
• Part 3 – Deployments
• Part 4 – Baseline – Toast Notifications

If you have any follow-up questions on those posts, let us know, and we’ll see if we can update/append additional information to help answer any questions.

About Recast Software

1 in 3 organizations using Microsoft Configuration Manager relies on Right Click Tools to surface vulnerabilities and remediate them quicker than ever.
Download Free Tools
Request Pricing

The post Microsoft 365 Deployment Series appeared first on Recast Software.

Part 4 – ConfigMgr Baseline

In this post, I’m going to cover how we are using a ConfigMgr Baseline to control the user experience. I’m not suggesting everyone do it this way. However, for us, we wanted to provide a good user experience, even to those on slow links, and make it look pretty while still looking legit and native.

The Microsoft 365 Baseline is how we control two things—the Microsoft 365 Application in the Software Center and the 365 Toast Notification. The Baseline consists of two Configuration Items: one running as a system to determine the state of the machine, and one that runs in the end user context to display a toast notification. The PreReq CI enables or disables the Toast Launch CI, so we really wanted to have the PreReq CI run and remediate before the Toast Launch CI . . . which we never were able to do. More on that later.

Scripts for ConfigMgr Baseline

• Pre-Req Discovery [The discovery script is also being used to make changes, which typically would be broken out into 2 scripts, this couple be a post of its own]
• Toast Launch Discovery [Checks Registry Key which tells the CI to launch the Toast (Run the Remediation Script) or go back to sleep]
• Toast Launch Remediation [This is the Actual Toast Content and probably needs a post of its own]

The Baseline in the Console:

Originally we had put these into one CI with two different settings, but we wanted to try to control the order of operation, which is just not possible. There is a UserVoice out there now to allow us to control it, but for now, we can’t. We wanted to have the Pre Req Discovery and Remediation both run before the Toast Notification Launch Discovery even ran, but we found out that Baselines run everything in serial.

IE, for all of the CIs in a baseline, it will go through each of the Discovery scripts in Pass 1, then come back around on Pass 2 and run any remediation scripts for CIs that have remediation that was flagged as Non-Compliant.

For this reason, we combined the Discovery and Remediation into one script and placed it into the Discovery section for the Pre-Reqs, to hopefully get to run and set items which the Toast Launch Discovery Script relies on. However, even this has proven only partially helpful.

Pre-Req CI‍

• Runs as System
• Checks:
  • Checks for the M365 Content in the CCMCache
  • Checks if M365 is already Installed
  • Checks if Microsoft 365 Semi-Annual Channel Deployment is targeted to machine and if so, is it visible in the Software Center
  • Checks if Microsoft 365 Semi-Annual Channel Deployment is targeted to machine and if so, checks if has Required Deadline

Based on the returned values, it performs different actions. Currently, we account for 15 different permutations of those values.

Let’s take a few Scenarios: [you’ll see a full list in the script of the 15 case statements]

1. M365 Content NOT Cached, M365 NOT Installed:  The Baseline will see the machine does NOT have the content, and that M365 is NOT already installed.  It will make sure that the application does not show up in Software Center until the content is available.
2. M365 Content Cached, M365 NOT Installed:  The Baseline will see the machine has the content, and that M365 is not already installed. It will make sure the Application (Microsoft 365 Semi-Annual Channel) is available in the software center (visible), remove the deadline and set a registry key to enable the toast notification.
3. M365 Content Cached, M365 is Installed:  The Baseline will see that M365 is already installed.  It will set a registry key to disable the toast notification.

While there are other options, those are the big ones.

Actions the CI will take:

• Toggle the Application Deployment Policy in WMI (“ROOTccmPolicy(USER GUIDActualConfig class name = “CCM_ApplicationCIAssignment”)
  • Toggles UserUIExperience from False to True (This will make it visible in the software center)
  • Deletes EnforcementDeadline property (This will change the application form required with a deadline to “available” in Software Center)
• Toggles custom registry key [HKLMSOFTWARESWDO365 – Property:Enable_0365_Toast – Value: True or False]

Client: You’ll see the Microsoft 365 Self-Service Notification Baseline.

Client Side Logging:

When Machine first gets policy but has not downloaded the content yet.

After the Content is downloaded, you’ll see a bit more action here: (Please note that our Discovery & Remediation are in the same script, and the script is in the “Discovery” Script in the CI. We are NOT using the Remediation Script in the CI.)

It then runs Remediation, to enable the app in the software center, remove the deadline, and set the registry key to enable the Toast.

Those are logs from the “PreReq” Configuration Item, which logs toc:windowstempo365_baseline.log

Launch Toast CI‍

• Runs under the User Context (So the Toast will display in their Context and be seen by the end-user)
• Checks Registry Value HKLMSoftwareSWDO365 – Enable_0365_Toast

Registry Value:

The Launch-Toast Log runs as the end user, so the logs go into the end user’s temp folder (c:users%username%appdatalocaltempo365_baseline.log)

The CI has two Scripts

• Discovery Script
  • If Registry Key = True… Report Non-Compliant to CM which will activate Remediation
  • If Registry Key = False… Report Compliant to CM and not run Remediation.
• Remediation Script

Let’s look at the logs which might help explain more.

Here you can see if the CI runs and the Registry Key is set to false, it does nothing and goes back to sleep. If the Registry key is set to True, it triggers the toast notification:

The Toast Image: (The Launch Toast Remediation Script)

So that explains how the toast works . . . Baseline works.

The scripts are all on GitHub and I’ve tried to add a lot of comments, but if you think they are deserving of blogs, let me know. -Gary

Lessons Learned from Microsoft 365 Deployment with ConfigMgr

After sharing my series on deploying Microsoft 365 with ConfigMgr, this follow up series details lessons learned by “someone” during a recent large-scale deployment.

1. Microsoft 365 Deployment with ConfigMgr – Lessons Learned 
2. Microsoft 365 Deployment with ConfigMgr- Lessons Learned – Changing Channels
3. Microsoft 365 Deployment with ConfigMgr- Lessons Learned – Deployments
4. Microsoft 365 Deployment with ConfigMgr – Lessons Learned – ConfigMgr Baseline – You are Here

The post Lessons Learned from Microsoft 365 Deployment with ConfigMgr: Part 4 – ConfigMgr Baseline appeared first on Recast Software.

Part 3: Self Service Deployments

Hey Team. In this post I’m going to cover how we’re doing our Self Service Deployments for the Microsoft 365 Apps. We’re controlling it via Active Directory Group Membership.

Our Deployment team can add users into these groups in AD that will then have access to the Apps.

Each User Collection has a direct rule of the AD Group.

The rest of the collections only have one deployment, the deployment for the corresponding application. I’ll be going over the Microsoft 365 Self-Service Notification Baseline in depth in the next post.

Microsoft 365 Content is a required deployment, ASAP, so that it gets the M365 Installer Content down to the machines as soon as it can. I go over that content a bit more in a previous post.

The Microsoft 365 Office – Semi-Annual Enterprise Channel is a required deployment set out for 10 years.

It is also hidden:

We don’t want to force the software down. Instead, we want it to be available for them to install themselves. However, we don’t want it to show up until the required content is completely downloaded, so we keep it hidden until it’s downloaded, then we have that Baseline come along and flip some properties in WMI to change it from Hidden and Required, to Show in Software Center and be Available. I’ll cover that more in the next post as well.

As a Bonus, here is the script I used to create the AD Groups and User Collections.

It looks through CM, finds all of the Applications that start with Microsoft 365 (excluding anything with Content in the name) then uses that name to base the AD Group and CM User Collections on.

Check it out on GitHub. I plan to add the lines that will automatically create the deployments as well. Note, I created it in about 10 minutes and used it once in my lab, so no real testing has been done… be warned.

Conclusion: Self Service Deployments in Microsoft 365

Thanks for checking out the post and after this series, if you have questions, please let me know and I’ll see where I can fill in any blanks. – Gary

Lessons Learned from Microsoft 365 Deployment with ConfigMgr

After sharing my series on deploying Microsoft 365 with ConfigMgr, this follow up series details lessons learned by “someone” during a recent large-scale deployment.

1. Microsoft 365 Deployment with ConfigMgr – Lessons Learned 
2. Microsoft 365 Deployment with ConfigMgr- Lessons Learned – Changing Channels
3. Microsoft 365 Deployment with ConfigMgr- Lessons Learned – Deployments – You are Here
4. Microsoft 365 Deployment with ConfigMgr – Lessons Learned – ConfigMgr Baseline

Right Click Tools Community is just a download away.

A free, limited, and powerful add-on, Right Click Tools Community offers a taste of the full suite of tools.

Download Heret

The post Lessons Learned from Microsoft 365 Deployment with ConfigMgr: Part 3 – Self Service Deployments appeared first on Recast Software.

Part 2: Changing Channels

Please note, that office channel names have changed since I wrote this. I’ll update this post, but I apologize in advance for anything I’ve missed. [MS Docs about Change]

The office has several Channels in which you receive feature updates at different rates. Check out a good Doc here [MS Docs]. I also highly recommend reading the [considerations section] on the [changing channel docs]. When I was researching how the Channels worked, the most useful post I found with information was on the MS Endpoint Mgr blog [Post].

Based on that, I wrote my own script used in a ConfigItem and deployed it as a baseline to set the Channel [GitHub]

We have set up 2 methods for channeling the Office Channel on devices. One that allows self-service via an application in the software center, and one that is forced via a baseline set on a collection.

Baseline (required) Model

Collections:

1. Microsoft 365 Set Channel – Semi-Annual Enterprise Channel
2. Microsoft 365 Set Channel – Semi-Annual Enterprise Channel (Preview)
3. Microsoft 365 Set Channel – Enterprise Monthly

Configuration Items:

CI’s are all identical except for a variable in the Scripts where it sets the Channel (SemiAnnual / SemiAnnualPreview / EnterpriseMonthly)

Baselines & Deployment Info:

Self-Service Application Model

When a user goes to install Monthly or Targeted, the installer script detects that Microsoft 365 is already installed, detects that you’re trying to install a different channel than the one currently installed, and flips the switch to change the channel to the new Channel.

When the user installs the Monthly Channel, the “Install” Process only takes seconds because all it is doing is changing a couple of registry keys and running the Click 2 Run engine telling it to change the channel.

This is the part of the script that runs in this scenario:

Registry Info

Before the switch, this is Semi-Annual Channel:

Then after the switch, the keys update to the Current Channel (Formerly Monthly)

After you flip the channel, during the next software update the machine will see it is on the new channel and pull down the patch.

Once the patch is downloaded, you’ll get the notification:

If you enable them in software center, you’ll also see it there:

Once the patch has been installed, when you launch the office product, you’ll see it has switched to running the new channel.

ConfigMgr Console

Confirming from the Console. Software Library Node -> Microsoft 365 Client Management. A nice Dashboard to monitor and assist with the management of Microsoft 365. You can see the different versions of Office installed, along with the different channels.

Just a quick plug: the Right Click tools make monitoring status easy too. If you’re trying to do this all remotely to assist a user, you can trigger it via Remote Software Center, then trigger the software update scans, then help poke the updates:

This is nice because I can see the updates have been made available to these machines and even installed. One of the machines is now pending a reboot before the machine changes from SAC to Targeted.

Sorry, since the channel change is so new, many of the tools haven’t yet been updated (ConfigMgr / Office Deployment Toolkit) to reflect the change, so I can’t get image captures at this point.

Thanks for taking a look. I hope this was helpful to you, as always!

Lessons Learned from Microsoft 365 Deployment with ConfigMgr

After sharing my series on deploying Microsoft 365 with ConfigMgr, this follow up series details lessons learned by “someone” during a recent large-scale deployment.

1. Microsoft 365 Deployment with ConfigMgr – Lessons Learned
2. Microsoft 365 Deployment with ConfigMgr- Lessons Learned – Changing Channels – You are Here
3. Microsoft 365 Deployment with ConfigMgr- Lessons Learned – Deployments
4. Microsoft 365 Deployment with ConfigMgr – Lessons Learned – ConfigMgr Baseline

Right Click Tools Community is just a download away.

A free, limited, and powerful add-on, Right Click Tools Community offers a taste of the full suite of tools.

Download Heret

The post Lessons Learned from Microsoft 365 Deployment with ConfigMgr: Part 2 – Changing Channels appeared first on Recast Software.

Part 1

Hey Team, thanks for reading through the Microsoft 365 Deployment Series. Hopefully at this point you’ve got a good grasp on the Office Setup Process, the Deployment Methods, and the user experience. I happen to know a guy who has set up Microsoft 365 Deployments in a rather large enterprise and was faced with a few “opportunities.”

Microsoft 365 Deployment Lessons and Opportunities:

• Upgrade Office from 2016 to Office 365 and only install Access if it was previously installed
• During Upgrade, Detect and Reinstall Visio Standard / Pro and Project Standard / Pro
• Most of the workforce is on VPN, so optimize deployments
• Share Content between all Installs (Each one of the various install types would actually use the same content id
• PreCache content, to allow Self-Service users to not have to wait when they click “Install” in the software center
• Provide Toast Notifications to Self-Service
• Always deploy office using the latest content

Reminder, the scripts I’m referencing are on GitHub.

From the previous Microsoft 365 Deployment series, you can see how we managed to accommodate the detection and reinstallation of different Office Components during the upgrade. But in case I glossed over it quickly, I’ll break it down now too. (o365_install.ps1)

From the image of a segment of the script, you can see that the script is using a simple WMI Lookup to see if Office is installed. You might need to modify this based on your own environment to make sure it detects the things you want.

Based on the information we collect, later on in the script, it enables additional sections in the XML to install Access, Visio, Project, etc. In this image below, you can see how those variables are being used to populate the XML.

Data Management

So now that we’ve got that figured out, how do we reduce the amount of data going over the wire?

Applications vs Packages have different pros and cons for content. Packages are easier to control and manipulate, with their package id that doesn’t change while also being able to run several programs on the same content. Whereas with an Application, every deployment type you add has a unique content ID, and it changes every time you update the content. So even if you point each Deployment Type to the same content on the Source Share, when you deploy the Application to a machine, it will have to download each application deployment type associated with the application before installing the appropriate deployment type. If you create several different deployment types for Office, guess what, you just downloaded 2.5 GB per deployment type.

Our Solution

How did we decide to go about this?

• We created a single App of Microsoft 365 for PreCache. Using the -PreCache parameter when the install script is called, it takes the downloaded office content and copies it to a local path.
  • Content for the PreCache App is the Full Office Suite Content.
  • The detection method for the PreCache is a PowerShell script. The script checks the CCMCache for the Payload, and it checks the o365_Cache folder for the setup.exe.
• Then we create an Install Application for Microsoft Office 365 Suite (Enterprise Monthly, SACE & SACEP), Access, Visio Standard, Visio Pro, Project Standard, Project Pro.
  • Content for the Apps all point to a single folder that contains 3 scripts.
  • Each of the Applications also has the PreCache App set as a dependency.

PreCache Content:

Office Install Apps Content:

App Deployment Type. Showing the Microsoft 365 App, the Deployment Type has the Microsoft 365 Content App as a Dependency. All of the other Apps are set up identically to the Microsoft 365 Main App, just by passing a different install parameter and adding a detection method for each of the different applications.

So that’s how we solved the content issue.

User Collections

We set up a user collection based on an AD Group of users called Microsoft 365 Deployment (slowly adding users throughout our roll-out period). We deployed the Content Application and set up a Hidden Required Deployment (ASAP Deadline) on the Microsoft 365 Deployment User Collection.

We created a REQUIRED & HIDDEN Microsoft 365 ProPlus – Semi-Annual Channel deployment to the same user collection. On that user collection, we deployed a Baseline with 2 CIs.  One CI that would monitor the Microsoft 365 Content Application, and once that content had been downloaded, would change the LOCAL policy on the Microsoft 365 ProPlus Deployment, flipping the WMI Properties from Hidden to Visible, so it would show up in the software center. We also enabled notifications. The 2nd CI contained a Toast Notification (based on [Trevor’s Blog]), alerting users that the Microsoft 365 application was available. It had 3 buttons, Snooze, Learn More (Opens Internal Website with more info), and Get Started, which launched the app in the software center. This will be blogged in greater depth at a future time.

My Recommendation

If that seems like a bit too much work, here is my recommendation: Setup an Available Deployment of the Microsoft 365 Application to the same user collection. Add users at the end of the day. Ideally, their primary device would start caching the content (Office Content Application with the Hidden Required Deployment), and finish downloading overnight.  Typically the content will download before a user would go to Software Center to run the available Office Install Application.

If a user did beat the pre-cache (Office Content Application Deployment), when the Office Install is triggered, because of the dependency, the App would download and copy the required files before allowing the Office Installer to try to install.

As for keeping content updated, we run a script [Github] on a monthly cadence that downloads the content and replaces the content. It’s very straightforward:

• Run the setup.exe with the config file to download the content
• Replace what is there
• Update the detection method with the new cab file name
• Bump the content

Then as the content is updated, it creates the new Content ID and the Required Deployment updates the policy. Next application evaluation, it fails detection because the cab file name changed, and it redownloads and runs the pre-cache script.

Conclusion

If you found this write-up explaining how one enterprise deployed Microsoft 365, check out my next lesson learned on Changing Channels.

Lessons Learned from Microsoft 365 Deployment with ConfigMgr

After sharing my series on deploying Microsoft 365 with ConfigMgr, this follow up series details lessons learned by “someone” during a recent large-scale deployment.

1. Microsoft 365 Deployment with ConfigMgr – Lessons Learned – You are Here
2. Microsoft 365 Deployment with ConfigMgr- Lessons Learned – Changing Channels
3. Microsoft 365 Deployment with ConfigMgr- Lessons Learned – Deployments
4. Microsoft 365 Deployment with ConfigMgr – Lessons Learned – ConfigMgr Baseline

Right Click Tools Community is just a download away.t

A free, limited, and powerful add-on, Right Click Tools Community offers a taste of the full suite of tools. ttt

Download Here

The post Lessons Learned from Microsoft 365 Deployment with ConfigMgr: Part 1 appeared first on Recast Software.

Post 6: Channel Info

Hey Team, Gary Blok here. I’m coming back after a few weeks and am now adding Channel Query Collections.

We had a request to take everyone on the current channel (formerly known as Monthly) and move them to Enterprise monthly. In a previous post, I talked about how to change the channel, but not how to find and target different channels if you’re looking to do it dynamically. Now if you’re looking for a report, this will get you a good start and has the same basic idea for creating a collection. Just remember this post is old and uses the old Channel Names. [System Center Dudes Blog Post]

Update: After I wrote this, I saw Martin Bengtsson (@mwbengtsson) wrote up a great post with a script to create these for you. Check it out!

Channel Info: [MS Docs}

• Friendly Name: XML Channel Code = Registry Key
• Current Preview Channel: CurrentPreview = “http://officecdn.microsoft.com/pr/64256afe-f5d9-4f86-8936-8840a6a4f5be”
• Current Channel: Current = “http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60”
• Monthly Enterprise Channel: MonthlyEnterprise = “http://officecdn.microsoft.com/pr/55336b82-a18d-4dd6-b5f6-9e5095c314a6”
• Semi Annual Enterprise Channel Preview: SemiAnnualPreview = “http://officecdn.microsoft.com/pr/b8f9b850-328d-4355-9145-c59439a0c4cf”
• Semi Annual Enterprise Channel: SemiAnnual = “http://officecdn.microsoft.com/pr/7ffbc6bf-bc32-4f92-8982-f9dd17fd3114”

Based on those Registry Keys for the CDN, we can create our collections. Now, remember, this assumes you’ve enabled the “Office 365 inventory” in your client settings, which I talked about in the first post.

Creating those Collections:

New Query Collection,

In the Console:

Now you have your collections, you can target them with a deployment to change channels.

Office 365 Deployment Series with ConfigMgr

1. Office 365 Deployment Series with ConfigMgr – Intro & PreReqs 
2. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Simple
3. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Advanced
4. Office 365 Deployment Series with ConfigMgr – Deployment Methods
5. Office 365 Deployment Series with ConfigMgr – Office Updates / ADR
6. Office 365 Deployment Series with ConfigMgr – Channel Info – You are Here

Next Series

Microsoft 365 Enterprise Deployment – Lessons Learned

• Part 1 – Content
• Part 2 – Changing Channels
• Part 3 – Deployments
• Part 4 – Baseline – Toast Notifications

Right Click Tools Community is just a download away.

A free, limited, and powerful add-on, Right Click Tools Community offers a taste of the full suite of tools.

Download Here

The post Office 365 Deployment Series with ConfigMgr: Post 6 – Channel Info appeared first on Recast Software.

Post 5 – Office Updates and Automatic Deployment Rules (ADR)

First, let me start by sharing another blog. This is the best blog post I’ve read to better understand the update behavior when deploying office updates using ConfigMgr. [Microsoft Blog]

And this is the second-best thing I’ve read which goes into great detail. [SystemCenterDudes Blog].

How to Create an ADR

In this post, I’m going to do a simple “How-to” on creating an ADR and deploying it to your devices. I’m not going to go into the depth that those other 2 posts do.. because I’m not a huge fan of reinventing the wheel.  I’ll have a little overlap, but will keep it simple.

Software Update Point Component Properties

Administration > Site Configuration > Sites. Home tab, in the Settings group, click Configure Site Components, and then click Software Update Point. [MS Docs]

Ok, now that we have that done, the office 365 updates will start becoming available. Lets create the ADR (you might need to wait a bit for everything to sync).

Automatic Deployment Rule (ADR)

Ok, no one wants to manage patches, and ADRs make it all happen magically. Office is simple with Office 365 – there are only a few patches that will be available to your machines, so let’s take a look. [MS Docs – ADR]

• Template: Office 365
• Collection: Recast Workstation. This collection contains ALL workstations.
• Typically most machines will have Office installed, so why create a query based collection to deploy to? There is no point. The updates will be available to all workstations and install on the ones that are applicable. No point in waiting cycles on collection evaluations. Unlike the old days, when Office and Windows had HUNDREDS of patches, there are only a few now, so it doesn’t hurt to make them all available and allow software evals to figure out what it needs. I go into more details about the Collections and deployments later.
• After you’ve created the ADR, you can add additional Deployments for your Test Collections. Set different Available & Required Times to meet your needs.
• Add to existing Software Update Group. I personally just like to keep my Software Update Groups clean. I have no requirements to create a new group each time.
• Enable the deployment after this rule is run. I personally am not worried about the updates going out on the schedule I’ve setup in the deployment. If you have additional “reviews” you require, you might not check that box.

I then like to limit the updates I deploy down to this mix. If you have other flavors, you’ll need to change to accommodate. You can see I only have 5 updates to deal with, and I don’t mind if they are made available to all workstations, as it doesn’t bloat the policy like hundreds of updates used to previously.

• Arch = x64 – I don’t deploy and 32bit office
• Date released = Last 3 months.  Covers my basis for SAC which doesn’t release very often
• Product = “Office 365 Client”
• Superseded = No
• Title = -Windows 7 & -Perpetual (This removes a few updates that don’t apply to my environment either)

Let’s take a look a the preview without those:

So while 24 still isn’t bad, by adding a couple more items to criteria to better match my environment, it really keeps things clean.

I pick the schedule to evaluate weekly on Wednesday night. Works good for me. I don’t want to tie office updates to OS updates. They are different products and I want them to patch at different times. I’d rather get office updates out to my users quicker, make them available, and let the users pick when to install via the ribbon in the app.

This is actually the default for the provided Office 365 template and it works great for me. Once again, this first deployment you might be setting up for your Test Collection, perhaps you want to set your deadline in 1 day to make sure your test groups is patched ASAP and can alert you of any issues before the other deployments you setup go out to the general public. I’ll go into this more a bit lower in the post.

I’ve chosen to hide the updates in software center. Users can still update via the ribbon in the Office Application, which I feel provides a better experience.

I’m setting this to “No deployment package” and allowing the machines to pull from the MS cloud. Make sure you’ve configured delivery optimization if you do this. Here at Recast Software, all of our users are working from home anyway, so it makes sense. In organizations where you need to control your source and data transmissions, you’ll probably have it set to a deployment package.

These are the defaults, then next, next, finish.

Deployment Details

For our environment, I’ve setup 3 Deployments on the ADR:

• 365 Patching Test Group 1 (Internal IT Test Group)
  • Available ASAP, Deadline ASAP | Show in Software Center
• 365 Patching Test Group 2 (Line of Business Test Group)
  • Available ASAP, Deadline +4 days | Hide in Software Center
• All Workstations (Everything, Generally available)
  • Available +2 days, Deadline + 14 days | Hide in Software Center

The idea here is that the initial test group would already be upgraded before it’s made available for users. Users will slowly Opt-In over the next couple weeks before their deadline. So even if an issue isn’t caught before it’s made generally available, damage should be relatively light.

Software Update Group

Here in the software update group created when the ADR Ran, you can see the 5 updates, so the preview function didn’t lie. Machines are getting patched!

Office 365 Client Management Dashboard

You can see the client versions. Let’s see if we can map the data and make better sense of it.

Ok, now you can see how we’re doing. We mapped that data from the Dashboard to the Update Group.

Lets figure out which machine needs that patch… by clicking on the “Red” slice, which is for the machine with older build, it shows me the computer.

Then using Remote Software Center, I can see if the patch is available on that machine:

Let’s trigger an inventory on that and see if CM updates the status.

So we’ve confirmed it patched (thanks to our ADR). Now we just need the data to sync with the serve and update the dashboard . . . and within a couple minutes:

Conclusion

Alright, now we can see that all our systems are patched. We have 3 different build versions, which correspond to the different channels, and all are running the latest version! Yippy, we’re patched and secure. It’s time for the weekend.

Office 365 Deployment Series with ConfigMgr

1. Office 365 Deployment Series with ConfigMgr – Intro & PreReqs 
2. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Simple
3. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Advanced
4. Office 365 Deployment Series with ConfigMgr – Deployment Methods 
5. Office 365 Deployment Series with ConfigMgr – Office Updates / ADR – You are Here
6. Office 365 Deployment Series with ConfigMgr – Channel Info

Next Series

Microsoft 365 Enterprise Deployment – Lessons Learned

• Part 1 – Content
• Part 2 – Changing Channels
• Part 3 – Deployments
• Part 4 – Baseline – Toast Notifications

The post Office 365 Deployment Series with ConfigMgr: Post 5 – Office Updates and Automatic Deployment Rules (ADR) appeared first on Recast Software.

Post 4: Deployment Methods

Thanks for making it this far in our Deployment and Maintenance of Office 365 using Microsoft’s Endpoint Manager, Configuration Manager (SCCM) series.

Now that we have our Office application setup, it’s time to get it deployed and look into how we can change the channel [Channel on Docs]. Based on how you deploy it and a setting in the XML file, you’ll see different behavior.

In the XML, the property setting “FORCEAPPSHUTDOWN” will control the behavior during the upgrade. [MS Docs]

XML Settings and Deployment

Let’s talk over a few scenarios and show how this works out:

• FORCEAPPSSHUTDOWN = TRUE
  • Required Deployment – Reach Deadline
  • Required Deployment – User Initiates Install Before Deadline
  • Available Deployment – User Initiates
• FORCEAPPSSHUTDOWN = FALSE
  • Required Deployment – Reach Deadline
  • Required Deployment – User Initiates Install Before Deadline
  • Available Deployment – User Initiates

So believe it or not, only number one provides a different end user experience. all the rest will prompt the user to close the applications, even if it reached the deadline. Let’s walk through a couple.

Assumptions, you’re using the App Model, and you’ve setup the deployment to show in software center. If so, this will be the behavior experienced:

1. User Deployment runs at deadline, closes all office apps automatically (no warning) and upgrades / installs Office 365
2. & 3. have the same behavior. The application installer launches prompts to close any open office apps. 4,5,6 all share this same behavior too.

So basically, the ONLY time it actually force closes the apps is when it reaches the deadline and triggers automatically. Any other time it will prompt the end user to close the app and if the user clicks cancel, it throws and error. Remember, when it force closes the app, there is potential for lost work. I’ve confirmed this in my testing — the unsaved documents are gone, not recoverable.

User Clicks Cancel

Now let’s see what happens if a user clicks cancel. When you click cancel, you get a generic error — the same error you’d get for some other situations. Now I’m unsure if the exit code is the same, but the message is.

‍

If you find other exit codes, you can update the script to note different codes and provide better feedback in the logs.

Now that we’ve gotten Office 365 installed, let’s say you want to take a group of users and change them from the “broad” channel to a faster release channel, like “Targeted” or “Monthly.”

Changing the Office Channel post deployment. [MS Docs] You can check in office which channel it is by going to the Account Node in one of the office Apps.

• Changing a Registry Key: [HKLMSOFTWAREMicrosoftOfficeClickToRunConfigurationCDNBaseUrl]
• Using a CI / Baseline [Blog Post – secureinfra.blog] – Note this is good info, but the Channels and Regkeys will be different. I’ll have an upcoming post with updated materials and scripts in GitHub.
• Group Policy [MS Docs]
• Running the Setup Engine with an XML Config File [MS Docs]

I’m not going to go over the methods here in this post, but check out the next post where I go into details about how I’ve set it up.

Office 365 Deployment Series with ConfigMgr

1. Office 365 Deployment Series with ConfigMgr – Intro & PreReqs 
2. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Simple
3. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Advanced
4. Office 365 Deployment Series with ConfigMgr – Deployment Methods – You are Here
5. Office 365 Deployment Series with ConfigMgr – Office Updates / ADR
6. Office 365 Deployment Series with ConfigMgr – Channel Info

Next Series

Microsoft 365 Enterprise Deployment – Lessons Learned

• Part 1 – Content
• Part 2 – Changing Channels
• Part 3 – Deployments
• Part 4 – Baseline – Toast Notifications

The post Office 365 Deployment Series with ConfigMgr: Post 4 – Deployment Methods appeared first on Recast Software.

Post 3: Creating the Office Installer (advanced)

In the previous post on Deployment and Maintenance of Office 365 using Microsoft’s Endpoint Manager, Configuration Manager (SCCM), I walked you through the generic process to create an Office Installer Application using Configuration Manager.  We also touched on the crazy amount of variations you might have to support.

In this post, we’re going to go over the magic of PowerShell and creating an XML file on the fly.

Basically, when you break down the XML [MS Docs], you get different elements that control the way Office is installed. If you understand these elements, you can treat them like “LEGO” bricks. As long as you know what you want to install, what you want to exclude, and how you want to control your installation process, you can build the XML during the deployment.

XML File

Let’s first look at an XML file and go over the sections:

I’m going to let that sink in a bit. The XML file can be a bit overwhelming at first, but as you break down each section, you can see how it can be quite simple, and how you can then modify each section to fit your individual needs.

I referenced that Doc [MS Docs] constantly as I was building our deployments and I’d recommend you become familiar to know the options best for your organization’s deployment.

Use PowerShell to Create and Modify XML Configuration File

So, now that you understand the XML file, and the options you have, we can use PowerShell to create / modify or own XML Configuration File. I’m no developer, unlike my co-workers like Bryan, Mark & Chris, but I’ve managed to become very proficient at googling things and reading documentation. I first found this [MS Dev Blog], which proved my idea plausible, then I found an article [PowerShell Magazine] that explained how to modify XML, and it was enough to get me to my final solution.

My goal was to use one single installer script to install Office 365 in several different scenarios. While I’d still have to make several applications, the content would be identical and the install script would be the same, but just passed different parameters in the “Install Program”. We planned to use our installer to also reinstall Access, Visio or Project if they were previously installed, so we added detection into the script to check for currently installed Office Apps before removing them and installing the Office 365 versions. We also decided to have office install from a cache location that we created instead of the CCMCache. This idea was borrowed from Mike, read more info about it here.

Creating an XML file that is generic enough to start with, getting the basics that would be in your normal install of office, that you can then easily modify to accommodate all of your variations.

Lets dig into the PowerShell / XML : Script on GitHub – o365_install.ps1

NOTE: Since the time I took all of these screen captures, the script has already been updated to accommodate both Project & Visio Standard and Pro versions. Anytime you see Visio or Project in the screen captures, imaging “ProjectPro” or “VisioPro” or “ProjectStd” or “VisioStd”. This was done to accommodate those who needed to install either Pro or Standard.
Also, this script assumes you have the content in the same folder as the script. Later in this series I’ll be covering “Lessons Learned” where we actually broke out the content into it’s own Application and I’ll go deeper into the why and how it works. But for now, we’re going to keep it more simple.

The script starts with collecting information passed in through parameters, this allows us to use the same script / content for installing office in several flavors. Office w/  Access, w/ Visio, w/ Project, or any combo.

We then collect information based on previously installed versions of Office programs to know what to put back on in the case of an upgrade scenario. We also detect if Office 365 is already installed, in the case where you had Office 365, but now are adding Visio or Project, it would check the current Office Channel you are on, then install the additional apps using the same Channel.

This first part is the generic XML that will be the base for all configuration XML files we use to deploy all variations of Office. You can see it has all the basic build blocks for the install. You’ll see many of the same building blocks from the config xml above that was created for us in the previous post.

Customize the Office Install

Then to customize the install, we inject additional XML content into that. Here is the code we use to change the Channel (Broad / Targeted / Monthly) but changing the $Channel variable via a parameter.  It then gets injected into the XML.

Here is how we add Visio / Project into the XML. These will be added into the XML based on a parameter fed into the script from the install command in the CM Application, or if the application was detected previously installed.

For Access, I have it add the “ExcludeApp” element into the OfficeProPlusRetail Prod XML, it will show up right under the other ExcludeApp IDs in that section. For Visio and Project I add another Project Element along with the required information.

Once we’ve created all of the XML settings, we can then build the full XML file:

Now that we’ve saved the XML File to our Install Cache, we call a “prep script” which helps clean up previous installs, then trigger the Office Setup (line 248 below). We capture the exit code and pass it back to CM.  Also depending on the situation, we pass back different exit codes, like if the process had to uninstall Office 2016, we pass back a return code of 3010 instead of 0 to tell CM to reboot.

The entire upgrade is also logged using the Write-CMTraceLog function.

Set Up

Ok, so let’s set this up in CM. Basically add the scripts to the Content and replace the Install line:

From the log, you can see the Channel was set properly by the passed in parameter, as well as the Access software was added to the ExcludeApp element.

Each App is using the same Content Source. The Applications are just slightly different Install Command and Detection Method.

Adding Access

Let’s take a look at Access. Say someone wants to add Access to their base Office Install.

Same goes for Project & Visio, a quick modification to the Install Line, and you’re set.

As I’ve shown, using a PowerShell script and building the XML file on the fly allows you to use one source folder and one install script to account for all variations of the installer. This makes maintaining it much easier as you only have one source to keep updated and ensures you’re using the same content for each deployment for better peer to peer / branch cache efficiencies.

Next Up

In the next post, we’ll cover some different deployment methods and how to change the Office Channel.

Office 365 Deployment Series with ConfigMgr

1. Office 365 Deployment Series with ConfigMgr – Intro & PreReqs 
2. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Simple 
3. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Advanced – You are Here
4. Office 365 Deployment Series with ConfigMgr – Deployment Methods
5. Office 365 Deployment Series with ConfigMgr – Office Updates / ADR
6. Office 365 Deployment Series with ConfigMgr – Channel Info

Microsoft 365 Enterprise Deployment – Lessons Learned

• Part 1 – Content
• Part 2 – Changing Channels
• Part 3 – Deployments
• Part 4 – Baseline – Toast Notifications

The post Office 365 Deployment with ConfigMgr: Post 3 – Creating the Office Installer (advanced) appeared first on Recast Software.

Post 2: Creating the Office Installer (simple)

In this Deployment and Maintenance of Office 365 using Microsoft’s Endpoint Manager, Configuration Manager (SCCM) post, we’re going to get familiar with the Office 365 App Creation process that comes built into Configuration Manager. While Configuration Manager isn’t required to create and deploy Office 365, they have done a very nice job of making it simple. If you have the desire to do it standalone or are unfortunate and don’t have access to ConfigMgr, the process is still pretty simple to come by the installer package.

Configuration.XML File

Before I go much further, I’m going to explain the Configuration.XML file [MS Docs]. This file (which can be named anything) is the “database” that the setup engine uses to know how to configure office. Instead of having a hundred different command line switches, there is one XML to rule them all. You’ll specify the channel of the Office 365, the apps you want to exclude, the apps you want to include, if you want 32bit or 64bit, if you want to magically remove previous MSI installed office versions, among so many other options, like language packs, and licensing models. Everything else in the install process is identical. There is NOTHING unique about your office install compared to mine, the only thing that sets us apart is this XML file, and in many cases, it will probably be the same for many organizations. Now that I’ve covered that, let’s get into the installer.

Office Icons I use in Software Center:

• Office
• Access
• Project
• Visio

I grab the versions just under the 500 x 500 pixel version.

Office Detection Methods:

• Semi-Annual Enterprise Channel: HKLM | Key: SoftwareMicrosoftOfficeClickToRunConfiguration | Value: CDNBaseUrl | Data Type: String | Eq: http://officecdn.microsoft.com/pr/7ffbc6bf-bc32-4f92-8982-f9dd17fd3114
• Semi-Annual Enterprise Channel (Preview): Registry: HKLM | Key: SoftwareMicrosoftOfficeClickToRunConfiguration | Value: CDNBaseUrl | Data Type: String | Eq: http://officecdn.microsoft.com/pr/b8f9b850-328d-4355-9145-c59439a0c4cf
• Monthly Enterprise Channel: Registry: HKLM | Key: SoftwareMicrosoftOfficeClickToRunConfiguration | Value: CDNBaseUrl | Data Type: String | Eq: http://officecdn.microsoft.com/pr/55336b82-a18d-4dd6-b5f6-9e5095c314a6

Also for easy reference, Detection Methods for the “Addons.”
Each one has 2 detections. One is always this: Detection: Registry: HKLM | Key: SoftwareMicrosoftOfficeClickToRunConfiguration | Value: CDNBaseUrl | Must Exist

• Access: File= %ProgramFiles%Microsoft OfficerootOffice16  | File = MSACCESS.EXE
• Project Pro: Registry: HKLM | Key: SOFTWAREMicrosoftWindowsCurrentVersionUninstallProjectPro2019Volume – en-us | Value: DisplayName | Must Exist
• Project Std: Registry: HKLM | Key: SOFTWAREMicrosoftWindowsCurrentVersionUninstallProjectStd2019Volume – en-us | Value: DisplayName | Must Exist
• Visio Pro: Registry: HKLM | Key: SOFTWAREMicrosoftWindowsCurrentVersionUninstallVisioPro2019Volume – en-us | Value: DisplayName | Must Exist
• Visio Std: Registry: HKLM | Key: SOFTWAREMicrosoftWindowsCurrentVersionUninstallVisioStd2019Volume – en-us | Value: DisplayName | Must Exist

‍Non-ConfigMgr App Creation Process:

• Download the Office Deployment Tool & Extract (This will provide the setup.exe & a few XML samples)
• Go to https://config.office.com/ and create your XML file to fit your needs and download it.
• To download the Content for Deployment, launch your elevated command prompt, run setup with download argument
• setup.exe/download\servershareMyconfigfile.xml
• That will download the installer files to a sub-folder from where you ran setup.
• To install, switch /download to /Configure and it installs.
• now that you made it through that high level overview, check out the [MS Docs] for some good info

Configuration Manager Style: [MS Docs]

Creating the Application

I’m going to walk through the Screen Captures of the process. While I don’t capture every image, you’ll get the overall idea of it. We’re going to start by launching the Office 365 Installer from the Office 365 Client Management Node.

The Application Info

Next Up

So now you’re like, that’s great, super easy . . . but now I have to create like 20 different XML files to get all of the different variations of the Office Install I want.

• Office with Access
• Office without Access
• Office with Visio Standard
• Office with Visio Pro
• Office with Project standard
• Office with Project Pro
• Office with Access & Visio Standard
• Office with Access, Visio Standard and Project Pro
• Office with Visio Pro & Project Standard
• ….. etc,etc, etc…
• OH… and I want those available in 3 of the 4 different Channels, so times it by 3.

This seems like a ton of work, along with a ton of different Applications, all for different variations of Office.

Stick around to see how we can take the installer to the next level by making the XML completely dynamic. We can simplify this greatly with the help of PowerShell and a little bit of thinking outside docs.

Office 365 Deployment Series with ConfigMgr

1. Office 365 Deployment Series with ConfigMgr – Intro & PreReqs 
2. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Simple – You are Here
3. Office 365 Deployment Series with ConfigMgr – Creating the Office Installer – Advanced
4. Office 365 Deployment Series with ConfigMgr – Deployment Methods
5. Office 365 Deployment Series with ConfigMgr – Office Updates / ADR
6. Office 365 Deployment Series with ConfigMgr – Channel Info

Microsoft 365 Enterprise Deployment – Lessons Learned

• Part 1 – Content
• Part 2 – Changing Channels
• Part 3 – Deployments
• Part 4 – Baseline – Toast Notifications

The post Office 365 Deployment Series with ConfigMgr: Post 2 – Creating the Office Installer (simple) appeared first on Recast Software.