anyweb

I'd recommend you use smoothwall for that

Hi @Teffan Hawk thanks for the thanks, are you absolutely sure your content is on the CMG, in the above snippet it's the 12'th source version of the content that's missing cheers niall

Introduction Understanding when Windows Autopilot is complete is an interesting topic. It would be great if there was a reg-key or file that was set when Windows Autopilot completed successfully, but there isn't, at least not now. Or if there is, I haven't seen any official documentation stating it. In the meantime let's use some other method of determining whether it's complete or not. To do that we'll rely on the creation date of the Microsoft Intune Device Management Extension folder as that gets created on the device if a PowerShell script or a Win32 app is targeted to the user or device, and I'm fairly confident that we all have at least one Win32 app or a PowerShell script deployed to our Autopilot devices during the Enrollment Status Page (ESP) phase of Autopilot. You can see how the enrollment date is calculated from the script here. Note: The script will only run based on the hours since enrollment detected and the detected logged on user. The script will not run if it detects that the current logged on user is defaultuser0. That user is used by Windows during the Enrollment Status Page (ESP) Device Setup phase. As the script runs again during the Account Setup phase of the ESP (the last phase), this time it will be running as a user that is not defaultuser0 and in fact is the actual user that will use the computer. Therefore it will create a scheduled task to run XX minutes after the date/time that it detects, and that usually is 15 minutes or so after the user enters their credentials. It's not perfect, but it's better than nothing. Please adjust it to suit your individual requirements. If you know a better way to do this, then let us know. Now that we have an idea of when Autopilot finished, we can deploy a PowerShell script to our Autopilot users to present a welcome page to the end user. At least that's the idea, and speaking of ideas, this great idea came from a friend of mine on Twitter, I just expanded upon it and fine tuned it for my needs, so please show your thanks to Chris Roberts for the great idea, and do him a favor and follow him on Twitter. The scheduled task will only show the web browser once (1 minute after login), during the time frame we've decided (first 48 hours after enrollment). This gives your users a nice warm fuzzy feeling that everything is completed, and let's them know that they can now use their computer. In order to achieve this we'll do the following. Create a static website in Azure Upload some files to the website Add a PowerShell script in Intune Note: This guide assumes you've already created an app for Microsoft Edge Chromium and deployed it to your Autopilot users. Step 1. Create Storage Account In Azure Active Directory create a storage account. To do that click on Create a Resource in https://portal.azure.com. In the page that appears, search for Storage Account. Select it and click on Create. You can attach it to an existing Resource Group or as in my case (to keep things clean) create a new Resource Group. Next, fill in a Storage account name and select the region and performance. And click on Review + create and after being presented with the summary, click Create. In the Storage Account, select Static Website from the options in the left pane. Set it to Enabled and provide the following file names Welcome.html and 404.html. Click Save when done. Next, click on $web, you will be presented with a simple interface for uploading files to your new static website. Step 2. Download files Download the Welcome page html files and the LaunchEdgeWelcomePage.ps1 PowerShell script here. Note: To download the files hosted on windows-noob.com, make sure you are logged on to the site first. Download the Welcome page files hereWelcomePage.zip Download the LaunchEdgeWelcomePage.ps1 hereLaunchEdgeWelcomePage.zip Download Microsoft Azure Storage Explorer Step3. Upload files After installing the Microsoft Azure Storage Explorer, browse to the $web folder of your storage account in the Blob Containers The easiest way to get the files and folders to the $web folder is to drag and drop from Windows File Explorer. Step 4. Change Access Level In the $Web container click refresh, you should see your files/folders. Click on Change access level to change the access level to these files. Set it to the access level you require, for example Blob access. To restrict access to this website and to block public see the following post. Step 5. Add the static website URL to the script In the $web container, click on properties. The static website URL is displayed, copy the url. Note: the returned URL is case sensitive. Edit the LaunchEdgeWelcomePage.ps1 PowerShell script and paste in your static website URL. Notice how I didn't copy over the /$web part of the url, it's added later. Save the changes. Step 6. Upload the PowerShell script to Intune In Endpoint Manager, select Devices, Windows Devices and choose PowerShell scripts. Add the edited LaunchEdgeWelcomePage.ps1 script. Don't forget to assign the Powershell script to your Windows Autopilot users. Step 7. Review the end result During Autopilot, you've probably enabled the ESP (Enrollment Status Page), if not it's a good idea to do so as it gives your users an indication that something is happening. After Windows Autopilot enrollment is complete, it should logon to the desktop, and Edge should launch with the welcome page. After the user selects the Sync option they'll see this (you can auto configure sync options). The user can click on any of the icons in the webpage to bring them to the online versions of those applications. In addition, an icon on the desktop links back to the welcome page. Step 8. Troubleshooting If it didn't go as planned, check for the presence of the scheduled task. Try running it manually, also look for the log file in C:\Windows\temp\LaunchEdgeWelcomePage.log The script creates a scheduled task to launch the welcome page one time (for each user that logs on to the computer within the allotted time frame of 48 hours) after Autopilot is complete. in In the example below I ran the script on my daily laptop and it wouldn't add the scheduled task as enrollment was many months ago. If you want to test it anyway, then temporarily remove the # on line 87 and try again. Make sure to add the # back before uploading the script to Intune. Note: If Edge Chromium doesn't install during the ESP for whatever reason, and yes, sadly it happens then this welcome page won't launch either. If that happens to you try plan b, which is to launch another browser (I picked Internet Explorer). Below is the section containing the workaround which is NOT in the main script, so it's here just in-case you want to use it. Replace the $action line with this # special workaround for cases where MS Edge Chromium failed to install during ESP LogWrite "checking if Edge Chromium is actually installed right now...." $EdgeChromiumPath = "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" if (!(Test-Path $EdgeChromiumPath)) { LogWrite "'$EdgeChromiumPath' is NOT present, will use plan b..." $action = New-ScheduledTaskAction -Execute '"C:\Program Files (x86)\Internet Explorer\iexplore.exe"' -Argument $websiteURL } else {LogWrite "$EdgeChromiumPath is present, good !" $action = New-ScheduledTaskAction -Execute $EdgeChromiumPath -Argument $websiteURL } # end workaround That's it ! Have fun and please let me know how you get on with this, if you modify the script or webpage then please show us your changes/ideas ! Useful links Favicon Generator Edge Chromium sync - https://docs.microsoft.com/en-us/deployedge/microsoft-edge-enterprise-sync Microsoft Azure Storage Explorer Intune device management extension Azure static website Azure Blob pricing cheers niall

can you do a remote session with me so i can take a look ? teamviewer or microsoft quick assist

here's the video ! https://www.niallbrady.com/2020/12/10/video-deploy-an-os-via-cmg-using-bootable-media/

'Tis the season to be caring – caring for your loved ones, for each other, and yes, even your data and mailboxes. The arrival of the Holiday Season is a great time to recognize all the challenges we’ve survived this year, to be thankful for all we have and to share. If you use Microsoft 365/Office 365, Hyper-V or VMware, celebrate with Altaro. All you have to do is sign up for a 30-day free trial of either Altaro VM Backup or Altaro Office 365 Backup – it's your choice! How does it work? · Trial Altaro V­M Backup or Altaro Office 365 Backup · Get a guaranteed $10 Amazon voucher & a chance to win one of the Grand Prizes · Altaro will make a $10 donation to One Laptop per Child for every valid entry What are you waiting for? Sign up now!

Introduction Microsoft released update 2010 on December 1st and one of the many new features was the ability to deploy an OS over CMG using bootable media. I tested out this ability when it first arrived in aTechnical Preview release back in Technical Preview version 2009, you can read about that here to see how it worked then, there are some changes to the overall process since then. This blog post assumes you've already setup a CMG as documented here. So let's try out the feature. Update: 2020/12/19 Please review the following hotfix for anyone who installed ConfigMgr update 2010 using the fast ring. Below is related to OSD via CMG. Step 1. Create a task sequence In the following step I'll create a simple task sequence, nothing special other than the following settings: On the Install Windows step, select Enable the account and specify the local administrator password and enter a local administrator password. Next, change the Configure Network settings step to Join a workgroup instead of joining a domain. Select applications... Close the wizard when done. After the task sequence is created, edit the Enable BitLocker step and disable it or set it to Continue on Error. This is because the step will fail as it won't have access to AD to escrow the recovery key. Step 2. Distribute content to the CMG Select the task sequence created in step 1, right click and choose Distribute Content. On the Content Destination screen, make sure to select your Cloud Management Gateway (CMG). Step 3. Verify the following settings In the Administration pane of ConfigMgr, select Client Settings, then select Default Client Settings (or create a new one) and right click and bring up the properties of the client settings, select the Cloud Services section. Verify that the following settings are configured to Yes. Allow access to cloud distribution point Enable clients to use a cloud management gateway as shown here. Step 4. Create a device collection In the next step, create a Device collection and limit it to something appropriate like CMG Clients. You can populate this collection with known computers that you intend to target with this task sequence, for example by importing the mac address and associating it with a computer name. Note: This is my lab so I'm using All Systems, don't do that in production though ! Step 5. Deploy the task sequence Right click the newly created task sequence and choose Deploy. Deploy it to the collection you just created. Make sure to configure the following settings when deploying the task sequence. Deployment settings page: Make available to an option that includes media, for example Only media and PXE. User experience page: Allow task sequence to run for client on the internet Distribution points page, deployment options: Download content locally when needed by the running task sequence. I deployed the task sequence to both known (OSD via CMG boot media collection) and unknown computers. Step 6. PKI certificate modifications Note: As per the documentation, if you use a PKI-based certificate for the boot media, configure it for SHA256 like so... And with the Microsoft Enhanced RSA and AES provider. In case that's not clear, you'll need to modify your certificate template used for boot images to include the Microsoft Enhanced RSA and AES Cryptographic Provider instead of the default Microsoft RSA SChannel Cryptographic Provider. I created a new template on my IssuingCA matching that requirement. Note: Under the Request Handling tab make sure that Allow private key to be exported is checked. After creating the new Certificate Template on the Issuing CA, you'll need to request it on the ConfigMgr site hosting your distribution point. Right click the newly imported certificate and choose All Tasks, then select Export. In the welcome to certificate export wizard click Next and choose to export the private key. Save it on your desktop with a memorable name like CMG Cert.pfx. Step 7. Create bootable media Now that you've done everything above, it's time to create your bootable media, that media can be a USB boot key or a standalone ISO. In the ConfigMgr console, in Software Library, Operating Systems, Task Sequences, choose Create Task Sequence Media from the options available in the Create section of the ribbon. Choose Bootable media from the options. On the Media Management page of the wizard, select the option for Site-based media. Choose USB or ISO As we limited the device collection to All Unknown Computers, make sure to select that option from those available, and specify your OSD certificate+password. Also, as is this bootable media, set a strong password. Make sure to point to the newly created CMG Cert.pfx file created earlier if your site mode is HTTPS Only (PKI). On the Boot Image page, select the Cloud management gateway for the management point settings. continue through the wizard until complete. Step 7. Boot a computer using boot media After completing all the steps above and verifying that your task sequence content is on the CMG, it's time to boot a target computer (with a LAN internet connection) from the media (ISO or USB). This computer does not need a connection back to the Active Directory domain controller or the on premise ConfigMgr infrastructure. But it does need full access to your CMG. As I'm using a virtual machine, here are the configured settings I'm using to boot from the ISO file. The computer should boot very quickly from the media and wait at the password screen, enter your strong PXE password configured earlier. Select the task sequence and off it goes. In this step, you can see it's downloading the content from the CMG when it's done, login as Administrator, and your computer is managed via Endpoint Manager, there's the client, and it's getting policy so you can deploy apps, and do all sorts of things to this newly deployed computer. You will of course note that this is not domain joined and that is because it does not have any contact with the on premise infrastructure throughout the entire process. You can use the ConfigMgr client to provide apps to domain join or install whatever you want after the user has logged on. After the task sequence runs, the client uses token-based authentication. What an incredible feature ! Troubleshooting If and when problems occur look at the smsts.log file on the client (in x:\windows\temp\smsts.log) and the CMGService.log on the CMG, that log file and related logs can be found be clicking here. I've observed problems such as "failed to retrieve reg token from media token 0x87d00215 ", that should be resolved with this hotfix. If you see "WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED" check the Verify Client Certificate Revocation check box on the settings tab of your CMG properties. Recommended reading How to estimate the cost of OSD via the CMG The right way to find logs from your CMG Deploy an OS over CMG using bootable media Update 2010 for Microsoft Endpoint Configuration Manager Current Branch Plan cloud management gateway Creating boot media How can I configure MEM in HTTPS mode - part 1 How can I configure MEM in HTTPS mode - part 2

well when using that parameter it should uninstall the portal (first time you run it) on the second attempt, you should get a message stating there's nothing to uninstall (or similar), what are you seeing when you try to run it ?

yes see

interesting, can you go into more detail of how you are doing this, we might go this route (maybe), but for now are forcing the version via the suite method.

ok first things first, the SMSTSPostAction variable is for use in operating system deployment task sequences to do an action after the task sequence has completed, are you planning on installing SEP as part of a task sequence ? if so use an Install Application step instead of Install Package if that's easier, or even run PowerShell script... but first, if you really want to install the app just using a powershell script then test the script on a virtual machine standalone, outside of a task sequence

I'd suggest you test Powershell Application Deployment Toolkit, it's what most Enterprises use to install apps in ConfigMgr today

Yup, i've just tested the update function within Smoothwall, it works and the updates are right up to this year, if you get any complaint from the Smoothwall about not being able to update then reboot the Smoothwall and try again

interesting, it also seems that Microsoft is recommending the Monthly Enterprise Channel for office (while at the same time recommending Current Channel, see above...), which of course solves the problem but lacks features, another approach is to pay HP more money to ship devices without Office in the Corporate Image, that works too

Introduction This blog post is long over due and I've been asked to do it many times, today, I finally got around to writing it. Sorry for the delay. Using Hyper-v labs to test all the new Endpoint Manager releases that Microsoft produces means you probably want to have multiple labs on the go at any time, one for Current Branch, one for Technical Preview, and another for testing out PKI or some other functionality. Having internet access in those labs is also usually a requirement, and keeping them separate from each other is also important. Using a Smoothwall to control internet into (and out of) each hyper v lab gives you control over when that lab gets access to the internet or not. I've used a Linux based firewall solution called Smoothwall, and it works great, so much so that I have one Smoothwall virtual machine for each lab. The Smoothwall allows me to configure individual ports to virtual machines within each lab and lots more functionality. Some Linux experience helps, but it's really easy to use. I've been asked several times over the years how I setup my Smoothwall and never got around to creating a guide for it, so here goes. Are there other ways of doing this, of course, but this is the way I do it. Step 1. Get the ISO Download the Smoothwall Express-3.1-x86_64.iso from here. https://sourceforge.net/projects/smoothwall/files/SmoothWall/3.1/Express-3.1-x86_64.iso/download Step 2. Create network switches In hyper-v manager, create 2 network switches, one Private Network Switch for your lab (we'll name it #11 in this example) and one switch connected to a physical network card (either WI-Fi based or Ethernet) to share the internet into the lab, we'll call that ICS for Internet Connection Sharing. Below is the LAB network switch, it's private so computers within this individual lab can talk to each other but cannot talk to other labs on my host. Below is the ICS switch, note that I do not allow the management operating system to share this network adapter. That can cause all sorts of problems in the host operating system, so don't select it. Also, this is a WI-Fi nic but it could be an Ethernet adapter, as long as it has internet in, it's good to go. Step 3. Create a new virtual machine In this step I'll use a PowerShell script to create a new virtual machine to host Smoothwall, the important thing to remember is that the virtual machine must be Legacy (type 1) and the network card must also be a Legacy Network Adapter. Here's an example for my lab #11. Note: You only need 256 MB of ram for this virtual machine so either change the script or modify the virtual machine settings later. Step 4. Add additional Legacy Network Adapter In the virtual machine just created, add a new Legacy network adapter and point it to the ICS virtual switch. Note: You CAN use regular network adapters in the Smoothwall (100/100mbit) however every time you reboot/restart the smoothwall you have to enter the root password and confirm the network cards to continue. So if you don't want that behavior, choose the legacy network adapters (10/10 mbit). Step 5. Install Smoothwall Attach the ISO to the CD rom drive in the Smoothwall virtual machine, change the boot order to CD and boot. Choose to install Smoothwall Express. click Ok to the welcome and click OK to the file system preparation. Click OK to erase. and it's done. When prompted to restore the configuration choose No. Select your keyboard layout, Select timezone Give it a hostname half open is fine... for Network Configuration Type choose GREEN + RED as shown below Use TAB to move to Done, think of the two colours as follows: GREEN: Lan RED: Internet then click OK to no green interface assigned, and next, select Assign network cards by clicking on Card Assignments Click ok when prompted to set them you'll be shown the 2 nics identified by MAC address in the following screens, so you can see which nic is assigned to which colour. after that you'll be informed that all cards are successfully allocated, move to Address settings... As Green is the lab IP of our smoothwall, I normally follow the ip address settings within each lab as follows 192.168.X.1 where X is the number of my lab, so this is lab #11 therefore I always use the following for each lab, the only thing that changes is the number replacing X DC01=DNS/DHCP/Domain Controller = 192.168.11.1 CM01 = Endpoint Manager = 192.168.11.2 Smoothwall = Linux firewall = 192.168.11.199 click ok and here I configure the IP address to match the ip address range shown above for my #11 lab. click ok, select the RED interface I normally use DHCP on RED and get a separate IP from my home network click ok, then Done when complete. and tab again to Done (or configure DNS if needed) Click Finished for Web Proxy Next set the Admin password set the root password click ok when done ! Step 6. verify after the reboot, login as root, it is case sensitive so at the prompt below type root and enter the password when prompted. after logging in, type the following to list the ip addresses assigned to your smoothwall. ifconfig you will see output something like so...it probably scrolled off screen, that's ok. In the example above: eth1 is the smoothwall RED interface and has my local network ip (from my Wi-Fi router), eth0 is the smoothwall GREEN interface and has the ip address I manually assigned it namely 192.168.11.199 You can issue the following commands: ifconfig eth0 ifconfig eth1 to list each nic individually. Next, try pinging some address: control +c to cancel, it works ! On a Windows virtual machine in the lab you are providing internet access (and routing) to, your network settings should be configured like so...pointing your Gateway to the smoothwall and DNS to the Domain Controller, this can be configured via DHCP server settings on the DC. a quick ping to verify internet works Step 7. Optionally configure port forwarding On a Windows machine, open a web browser and browse to the ip address of your Smoothwall and include port 441 like so https://192.168.11.199:441 you'll probably get a warning, it's safe to ignore Click Advanced to continue...for username and password use the Admin user you created for web configuration In this example I'm forwarding port 80 from my external internet connection to my internal lab, specifically the web server in lab #11. Step 8. Configure things in AD On your domain controller, configure the DHCP scope options to point 003 Router to the internal ip address (in this case 192.168.11.199) your new smoothwall so that all computers that get an ip, know how to use the smoothwall. Point your forwarder in DNS on the DC to the smoothwall local ip address finally, restart DNS and DHCP services. I hope you found this useful ! If you'd prefer to watch a video of this then see here cheers niall

we've seen the issue is back today, so we've switched to the following version, it works.

Introduction I'm writing this post to catalog problems I recently faced while doing Windows Autopilot installations, we use a very slim enrollment Status Page (ESP) configuration with only one app marked as required (Microsoft Edge Chromium). The remaining applications are a mix of Win32 apps and the all important Microsoft Office 365 suite. This suite was configured with the following apps. Excel, OneDrive Desktop, OneNote, Outlook, PowerPoint, Teams, Word This worked well since about mid-February 2020. However, starting week 46, I started noticing the following error on newly delivered HP computers with Windows 10 version 1909 (and some office components preinstalled) after clicking the Microsoft Outlook icon soon after Windows Autopilot had completed. It looks ominous. Clicking OK and trying again, the problem looked even worse, you'd see something like this, outlook prompting you to choose a Profile. followed by a Script error, stating Class not registered on Line 278. Choose Yes or No had pretty much the same effect, Outlook was well and truly broken. If you clicked on the Account Information in Outlook you'd see something like this. A Metered connection warning followed by a Upgrade in Progress warning. The first is definitely a red-herring as the Network card was not in a state that was metered. When checking the version of office installed on affected machines I could see it was as shown below, Office version 2011. The interesting thing to note is that Computers that had a clean image of Windows 10 version 1909 with no Office installed previously did not exhibit this problem, it only affected factory image(s) of HP computers with Windows 10 version 1909 factory image and those images come with a version of Microsoft Office installed (in the Nordics), namely Microsoft Office 365 ProPlus version 1908 (Build 11929.20394). Troubleshooting Based on the above I knew that clean installs of Windows 10 1909 did not have the issue (even though they subsequently got the Office 2011 version installed before the user logged on). I initially suspected that security software or a device configuration profile were to blame, and went through the time consuming task of excluding a computer from each profile, and then resetting it to verify the behavior. Excluding a device from an assignment takes precedence over including a device so it was a good way of testing Windows Autopilot without certain settings or configurations, to rule them out. Below you can see I've excluded a group (containing my test device) from a Device Configuration profile, to verify if that was the issue. trying this didn't help, but it at least ruled out the following from being part of the problem. Device Configuration Profiles Win32 based Security based apps (such as Azure Information protection, Crowdstrike, Symantec DLP) Armed with that knowledge I recreated the Office Suite settings in my own test tenant, and ran a Windows Autopilot build, to my surprise the HP failed starting outlook the exact same way as in Production, so that completely ruled out everything other than the version of Office installed on the HP. Next I turned to logging options within Office/Outlook to see if that would help, but in reality it just generated .ETL files that I'm still analyzing in order to root-cause this issue. The breakthrough came when looking at the settings of the Office suite in Endpoint Manager. The version of Office that gets installed is based on your settings in the Office Suite, and we had been using these settings without problem since February 2020. The really important bit was the update channel, shown below. The update channel we were using was Current Channel (Preview). You can get details of the update channels here. According to Microsoft: ... three primary update channels: Current Channel Monthly Enterprise Channel Semi-Annual Enterprise Channel We recommend Current Channel, because it provides your users with the newest Office features as soon as they are ready. But what is the difference between Current Channel and Current Channel (Preview). According to Microsoft: To become familiar with the new features coming in the next feature release of Current Channel, we recommend that you use Current Channel (Preview). There isn’t a set release schedule for Current Channel (Preview). In general, a new version of Current Channel (Preview) with new features is released at least a week or more before that new version is released to Current Channel. There might be several releases of Current Channel (Preview), with non-security updates, before that version is released to Current Channel. You should deploy Current Channel (Preview) to a small, representative sample of users in your organization. This can help you identify any possible issues for your organization before those new features are released more broadly to your users that have Current Channel. We also encourage you to use Current Channel (Preview) so that you can identify any possible issues that you want us to fix before that version is released to Current Channel. This can help reduce the number of non-security updates that are needed for Current Channel. And this pretty much matched what we were doing, so now that we had this knowledge, but still had no root-cause for the Outlook (and Word/Excel issues). The Resolution I decided to change the Update Channel from Current Channel (Preview) to Current Channel. This decision was based on the fact that the Preview channel may contain changes that are incompatible with our image in some way, which is odd because we are using the factory installed HP image. Once I made the change, and re-tested Windows Autopilot the difference was clear. Now Outlook worked as expected without issue (and Word/Excel issues disappeared also), however the version of Office installed was Version 2010 instead of Version 2011 that we got in the Current Channel (Preview). This didn't matter too much but of course it meant that some cool new cloud friendly features in Version 2011 were now no longer available on newly installed Windows Autopilot machines. The versioning used by Microsoft for Office is somewhat confusing, in the Office Account screen you'll see the version info, here you can see it's listed as Current Channel, Version 2010 (the version without the problem). So version 2010 relates to year 20, month 10, or the October release of Office 365. That would of course mean that version 2011 is the November release. Note: we've noticed that HP's corporate ready image includes an office version that is released before the OS version was released, so for example if you get Windows 10 version 1909, then you'll get the Office version released approximately one month before that (Office version 1908). Likewise if you got Windows 10 version 2004, you should get Office version 2003. Summary Sometimes living on the edge means you will fall over. I know that changing from Current Channel (Preview) to Current Channel might only delay the problem until the Current Channel update channel migrates to the new version of office next month, so we may actually encounter this problem again, and soon. So to conclude, if any of you have come across this exact issue (I have searched and found similar problems with "Library not registered", but the advice within them didn't apply here), then please get in touch with me. In the meantime I will look through the gathered ETL traces to see if they provide any clue as to why Office was so broken on these new devices in order to root-cause the problem. Links used in this blog post Github script, Metered - https://gist.github.com/nijave/d657fb4cdb518286942f6c2dd933b472 Update Channels - https://docs.microsoft.com/en-us/deployoffice/overview-update-channels Office Versions - https://docs.microsoft.com/en-us/officeupdates/current-channel

get-windowsupdatelog on the machine in question will allow you to see where the updates is being downloaded from

hi Scott and welcome the first thing i'd suggest you do is grab the smsts*.log files on one of the affected computers and zip them up and upload here so we can take a look, that will hopefully reveal what went wrong any additional info you can add, such as hardware that was affected and whether or not there's any changes to BIOS/UEFI setup in the task sequence ?

yup that should improve things try it however are you sure your computers are only getting updates from ConfigMgr and not somewhere else ?

have you configured anything in Client Settings for notifications ?

are you referring to the TPM hash ? if so read here TPM password hash Previous MBAM clients don't upload the TPM password hash to Configuration Manager. The client only uploads the TPM password hash once. If you need to migrate this information to the Configuration Manager recovery service, clear the TPM on the device. After it restarts, it will upload the new TPM password hash to the recovery service. Uploading of the TPM password hash mainly pertains to versions of Windows prior to Windows 10. Windows 10 by default does not save the TPM password hash so therefore does not normally upload the TPM password hash. For more information, see About the TPM owner password.

while it's not a report, have you looked at the Cloud Management overview in the ConfigMgr console ? for more details about monitoring the clients to your CMG and and traffic involved see https://docs.microsoft.com/en-us/mem/configmgr/core/clients/manage/cmg/monitor-clients-cloud-management-gateway to figure out how much it costs see

thanks for the update !

ah ok, well it's out of support and you'll need to ugprade it to a supported build before you decide to do anything with it, that would be your first task, to setup a plan for the upgrade, it's easy, and you'll gain access to lots of new features by doing so (as well as remain supported) cheers niall