Everything can be done automatically, as long as you configure it manually :-)
First off, this is mostly an inspirational post and the script used here is the latest release of my Windows 10 Toast Notification Script.
Secondly, from time to time, I still see people in various forums asking how they can send popup messages to the computers in their environment using SCCM (System Center Configuration Manager).
So I figured it would make a decent and quick blog post, describing how one can do just that using my Windows 10 Toast Notification script.
Debug/verbose logging! A topic which every ConfigMgr admin will have to get familiar with sooner or later. Lazy as one can be, I usually Google the requirements every time I need it, so I figured it was time to make something more permanent and more clever.
There are a billion blog posts on the topic already, but as far as my Google skills serves me, no one is using the run script feature and no one is providing complete scripts for the purpose. So this is me doing that. A complete solution for your copy/paste pleasure 🙂
Short and sweet. My Windows 10 Toast Notification Script have received a minor update. Now being at version 1.2. The changes mentioned in details below.
This is not exactly an A-Z guide on the topic, but rather a story of my experiences with upgrading Windows 10 over the Internet with In-Place Upgrade (IPU) Task Sequence using ConfigMgr and how it works in my environment.
I’m using a Cloud Management Gateway (CMG) with enhanced HTTP as well as initially being connected to the on-premises infrastructure with Always On VPN. The VPN in this scenario is a user-initiated tunnel and thus obviously disconnects once the upgrade restarts the computer. It’s not completely without challenges and I will try to cover those during this post.
Curious? Read on 🙂
Oh yeah, seeing I now allow IPU to happen over the Internet, I also created something in Powershell App Deployment Toolkit which extraordinarily warns the user if the upgrade is being initiated from outside the office network. A preview of that in the end of the post 🙂
When installing Office 365 ProPlus today, the recommended and default architecture is 64-bit. It has been so for some time, but it’s not until lately (at time of writing) that the Office Deployment Tool (in short ODT), is able to migrate from 32-bit to 64-bit in a single operation.
I have tested the migration, both using Microsoft Intune and System Center Configuration Manager and the outcome is what made this blog post.
Note: Migrating Office 365 ProPlus like this, from 32-bit to 64-bit in production, probably has more to it in terms of considering third party add-ins. You will have to test and make sure those add-ins are compatible with the relevant 64-bit Office application. I expect there will be some migration paths for those as well, where you will need to remove the 32-bit add-in prior to migrating Office 365 ProPlus to 64-bit.
Similar to when Windows 10 v1809 was released back in October 2018 and RSAT debuted as “Features on Demand”, the way of installing RSAT continues with the v1903 release.
Back then I did a Powershell script which is able to install and uninstall the RSAT features. I have now rewritten the script to also include Windows 10 v1903.
Find my 1809 post here: https://www.imab.dk/deploy-rsat-remote-server-administration-tools-for-windows-10-v1809-using-sccm-system-center-configuration-manager/
First off, bear with me here during the intro. I know introductions usually are boring, but I do have a few words to share with you first.
The following is by no means any substitution for any other Modern Driver Management solution out there. This is purely me exploring, learning and sharing that experience with anyone who’s interested. When I find something useful, I usually try to do my own thing for various reasons, but mainly to learn and also for being less dependent on others work and future maintenance plans.
Now, this post is primarily about a Powershell script and how that Powershell script is designed to run on a given device and export the device drivers into your ConfigMgr source file library or locally. In the process, the script is able to create a regular package in ConfigMgr containing those drivers. The post is also about how to use the regular packages for applying drivers, but the script is what took the most of my time 🙂
The idea here is, that you fire up a given device with a given version of Windows (preferably Windows 10) and install ALL the drivers (preferably the latest drivers) and verify that everything works in that combination of Windows, drivers and hardware model.
Note: Most vendors provide a tool which checks online for latest drivers and gives you option to install those. This is pretty handy when building new drivers for a given computer model.
Now knowing that everything works, this is the drivers you want to apply to future deployments of this computer model, so you run the script and everything is automatically exported and a package in ConfigMgr is created.
In lack of a better name, this is what I call ‘Almost Modern Driver Management‘. 😀
PS. If you’re looking for a truly nifty and ‘modern’ approach, I suggest you head over to SCConfigMgr.com and take a peek at their solutions for both BIOS and drivers.
Installing the OneDrive for Business client on a per machine basis is an often requested feature and for good reasons. OneDrive in it’s current state in the production ring, is installing into the users profile in %localappdata%, and for equally good reasons that is often not desired by enterprises.
Now, Microsoft has finally given us an option, allowing us to install OneDrive for the device into %programfiles(x86)%. The option is currently in preview and all the juicy details are found here: https://docs.microsoft.com/en-us/onedrive/per-machine-installation
PS. Credit where due: I was inspired by Per Larsen’s post on doing the same with Microsoft Intune and like many times before, this brought me to doing something on my own for the sharing and learning experience. Enjoy. 🙂
Since my previous WaaS posts, I have received a few inquiries about how to do drivers when precaching the content prior to running the actual In-Place upgrade. As of such, I figured it would make a great blog post covering the approach I’m currently using.
So this is me doing just that, as a small addition to what I have previously covered with my PreCache and In-Place Upgrade Task Sequences.
Note: I’m brewing on a complete WaaS section on here, sharing all and everything I do in details in regards to Windows Servicing. This will be available from this link once I get there: https://www.imab.dk/windows-as-a-service/
UPDATE: The script used here has been severely updated: https://www.imab.dk/windows-10-toast-notification-script/. The scenario described here is still relevant though, so I recommend that you still read through this 🙂
This will be a small but exciting contribution to my ‘Windows as a Service’ series!
The usual story here is, that everyone wants to add more user-friendliness to the whole experience around Windows Servicing.
End-users generally doesn’t care about new versions of Windows and they also, generally speaking, find interruptions in their work annoying, especially if those interruptions come unexpected.
So we come up with clever solutions to solve those problems and this will be an addition to that; remind the user with a big nice Windows toast notification when a Windows upgrade is pending. This is for the obvious reminder, but also to lure the end-user into a voluntary participation.
Find some of my previous WaaS posts here:
Part 1: https://www.imab.dk/windows-as-a-service-sharing-my-precache-and-in-place-upgrade-task-sequences-part-1/
Part 2: https://www.imab.dk/windows-as-a-service-sharing-my-precache-and-in-place-upgrade-task-sequences-part-2/
