Had a tag-team of problems with Office 365 Client updates and this one reared its ugly head just a I managed to successfully get the O365 updates syncing successfully.
Under Software Library|Office 365 Client Management|Office 365 Updates none of the client updates were checking in as ‘required’. Given that the O365 client on 5000-odd machines was at version 16.0.8201.2207 (v1705) this seemed odd to say the least. Everything was set correctly in SCCM for O365 Client Deployment so the summary screen should theoretically be showing that the whole estate needed at least every version beyond this.
After some considerable digging I discovered that for updates to work in SCCM, the CDNBaseUrl and the UpdateChannel settings in the registry MUST BE IDENTICAL. In my case, whoever had packaged the application had a bogus entry in the UpdateChannel setting that made no sense. I copied the CDNBaseURL setting (something along the lines of http://officecdn.microsoft.com/pr/492350f6-3a01-4f97-b9c0-c7c6ddf67d60) into the UpdateChannel setting, restarted the Microsoft Office Click-To-Run service and ran an update scan and update deployment policy refresh from the SCCM control panel applet. Immediately O365 client updates showed up as required. This can be checked under the following ConfigMgr report:
Compliance 8 – Computers in a specific compliance state for an update (secondary)
I then set up a GPO to push this URL out to the estate and watched the count increase.
I have recently been doing some work for a customer who has introduced OneDrive to their estate. For reasons known only to them, they have insisted that their users have their OneDrive storage restricted to only 1GB. Not much in today’s money.
The issue that I have been seeing (on more than one occasion) is that OneDrive would run out of space (denoted by a red cross over the blue cloud icon) yet if you were to look at what the folder contained, clearly there should be space left. On one occasion there should have been as much as 700MB left so I was left scratching my head as to why it was complaining it was full.
This is what has worked for me when I have come across the above scenario, and mainly involves removing the versioning feature, which by default will store 500 major versions.
Completely clear out the local OneDrive folder. Cut and paste the data into a local temp folder somewhere, eg C:\Temp\OneDrive
Right-click OneDrive icon and select View Online.
Select Recycle Bin from the menu on the left. Click Empty Recycle Bin. This can take a little while sometimes, be patient and ensure it’s properly emptied.
Once empty you should see a line at the bottom of the screen: Can’t find what you’re looking for? Check the Second-stage recycle bin. Click the Second stage recycle bin link.
Delete everything in the second-stage recycle bin.
Click the cog/gear icon in the top right of OneDrive. A setting menu should open. Select Site Settings.
Under Site Settings | Site Administration click Site libraries and lists.
Click Customise “Documents”
Click Versioning Settings.
Under Create a version each time you edit a file in this document library? select No versioning.
Select OK at the bottom of the screen.
Recommended: Remove OneDrive from the computer. Also ask user to save any profile related settings (favourites, desktop icons, etc) and remove user’s profile in System|Advanced Settings|User Profiles|Settings
Get the user to log back on and restore the user’s desktop and favourites.
Reinstall OneDrive. Once configured, copy user data back to the user’s local OneDrive directory and wait to sync.
The above steps were successful in releasing the ‘used’ space. Bare in mind, no version history will be kept in this scenario so please ensure that this is acceptable first. Without step 12, I did see the problem come back in one instance so if possible, I’d strongly recommend this step. You must bare in mind that when this procedure is carried out, it is like the user logging on for the first time and any customisations to their local profile WILL BE LOST.
All http://officecdn.microsoft.com is whitelisted and available, definitely no issue there.
All other updates seem to come down fine.
There are no ADR rules at all in place.
Running a full sync produces the error below:
My client downloads updates through a proxy server and naturally the correct details for the proxy were in place on the Site System Settings under Site System Roles. Also the checkbox for Use a proxy server when synchronizing software updates was checked under the Proxy And Account Settings tab under the Software Update Point Properties role.
Despite the fact that ADRs were NOT created or used in any way, it transpired that the checkbox Use a proxy server when downloading content by using automatic deployment rules also had to be checked. Once this was selected, O365 updates started syncing.
Headaches of an SCCM Admin. But no other symptoms yet.