As System Center Configuration Manager (SCCM) matures into an “as a Service” model, the ability to rapidly upgrade an infrastructure has come a long way. It used to be complex and time consuming to upgrade SCCM as you would have to download all the prerequisite media test everything in your lab and then schedule the downtime in your production environment. With the advent of SCCM Current Branch (CB) the ability to upgrade directly from the console has made this much less complex and in theory less error prone. This doesn’t mean you shouldn’t take precautions and test before rolling to production. Here’s some advice on how to manage the risk associated with the upgrade:
- Backup your environment and test the restore in case you need to rollback. You do this regularly anyways right? There are several supported backup options for you select from based on your particular requirements. Here is some backup and recovery guidance just in case
- Check your site and component status to make sure you don’t have any unresolved issues that might impact the upgrade. Check them again post upgrade.
- Perform the prerequisite check
- Test everything in your lab, sandbox, or test environment before upgrading in production. You don’t have a test environment. Well you do you just like to call it “production”. You can setup a really simple and inexpensive virtual lab in Azure that you can spin down when not in use.
- Use Pre-pilot collections to test client agents. This is a great way to minimize the impact of client agent defects.
- Check that all of your site systems have been upgraded
- Test basic functionality such as HW and SW inventory and Software Updates. This puts the basic components such as MPs, DPs, SUPs and client agents through a smoke test.
- Test task sequences especially if there was an ADK upgrade involved
- Check if there is a newer version of MDT available / required in order to work with particular ADK you are using and to support any required servicing branches
- Test the console update and any extensions such as Report Builder
- Test any pre-release features that you were previously using. Are they now released? Do you need to reenable the functionality as pre-release?
- Is this version available as a baseline build? Do you want to keep an ISO handy?
- Check for any post upgrade hotfixes.
As organizations move to modern management to be more agile in the way they manage multiple types of devices and cloud based services, the legacy management models associated with traditional PC management can lead to multiple consoles for managing different types of devices and services. At Microsoft Ignite this year, a hybrid approach called “Co-management” was announced. to bring organizations closer to modern management while still maintaining traditional management methods. In the past it has been difficult to use more than one management platform for the same device. Windows 10 1709 opens the doo this co-management by allowing devices to be managed simultaneously with SCCM 1710 and with Intune. What are the benefits of co-management? Here’s a few that come to mind.
- Manage devices where they live. Use SCCM to manage devices that are primarily on premise and use Intune to manage the same device when it is roaming.
- Transition workloads to Intune as you are ready
- Add modern management functionality to traditionally managed devices. Consider device compliance policies, resource access policies, Conditional access, selective wipe, factory reset etc.
- Single pane of glass for consolidated views of all devices such as mobile phones, tablets, Macs, PCs.
- Transition Windows 10 devices to Intune while managing legacy (Windows 7) devices with SCCM until they are upgraded or lifecycled.
- Self-provisioning of devices by end users
- Simplified BYOD scenarios
- Enhanced mobile workforce management
So, is this the best of both worlds? Nto really. Microsoft views this as a transitional step on the journey to modern management. Nonetheless I’m excited about the new opportunities for organizations to deliver a better user experience.
I still use a Surface Pro 3 and many of my customers use SCCM to manage Surface devices. In fact, The Surface Pro is the tablet of choice in the Canadian federal government. So how is this related to SCCM 1706? While there are many new features in SCCM 1706 that you can read about here, there is a pre-release feature that is particularly interesting to anyone that has to manage Surface devices. The feature provides the ability to manage MS Surface driver updates with SCCM.
- All software update points must run Windows Server 2016.
- This is a pre-release feature that you must turn on for it to be available. For more information, see Use pre-release features from updates.
To manage Surface driver updates
- Enable Synchronization for Microsoft Surface drivers. Use the procedure in Configure classification and products and select the Include Microsoft Surface drivers and firmware updates checkbox on the Classifications tab to enable Surface drivers.
- Synchronize the Microsoft Surface drivers.
- Deploy synchronized Microsoft Surface drivers
WinPE Peer Cache is a new feature of SCCM CB 1610. It functions in a similar manner to BranchCache however, it is only available for content access from the Windows Preinstallation Environment (WinPE). WinPE Peer cache is configured and managed as part of the SCCM CB client management settings.
A task sequence configured to use Windows PE Peer Cache can get the following content objects from a local peer while running in Windows PE:
- Operating system image
- Driver package
- Packages and Programs (When the client continues to run the task sequence in the full operating system, the client gets this content from a peer cache source if the task sequence was originally configured for peer cache when running in Windows PE.)
- Additional boot images
It is important to understand that WinPE Peer Cache is targeted at OSD scenarios and does not replace Distribution Points and BranchCache as locations for other types of content. For example, the following content objects never transfer using peer cache. Instead, they transfer from a distribution point or by Windows BranchCache if you have configured Windows BranchCache in your environment:
- Software updates
WinPE Peer Cache only supports OSD scenarios that include a WinPE boot such as PXE boot or Boot Media.
WinPE Peer Cache is very new and is evolving very rapidly. To avoid possible issues with the model, Microsoft is adding features to create higher deployment success rates. Beginning with SCCM CB 1702, a peer cache source computer will reject a request for content when the peer cache source computer meets any of the following conditions:
- Is in low battery mode.
- CPU load exceeds 80% at the time the content is requested.
- Disk I/O has an AvgDiskQueueLength that exceeds 10.
- There are no more available connections to the computer.
At the Microsoft Education Event this past week, there were many announcements that we covered in the Universal Windows Podcast Episode 66. While most of the show was dedicated to the Education sector and Windows 10s, there were two announcements that I was particularly excited intrigued about. Specifically the new Surface laptop and Windows Autopilot.
When I try the Surface Laptop later this month I will check out the lapability but from the specs, there are definitely a couple of missing features that would fit my use cases. I’d really like to see a full USB-C port and built in LTE. From a USB-C perspective, I have run into issues with USB resources with my Surface Pro 3 and I think USB-C is the future. As the Surface Laptop is a premium device, for me to justify the price tag, I’d like to feel like the device has a long useful life ahead whether I keep it myself, hand it down to a family member or sell it. USB-C gives it a longer useful life in my opinion.
As far as LTE, I firmly believe the future is BYON (Bring Your Own Network). We won’t need to be hunting for free WiFi at Starbucks or airports and other locations with unknown risks and tethering while useful can be inconvenient and drain your mobile’s battery. There rumours that an LTE version might be out in the fall.
The most exciting reveal for me was Windows Autopilot. It appears to be a simple to use, Windows 10 mass deployment tool built for the classroom scenario. As I do a lot of work with SCCM, the de facto Enterprise class Operating System deployment tool, I am curious to see how this stacks up. I will do a side-by-side comparison once more details of Autopilot are available. Stay tuned.
This week Microsoft announced that Windows 10, Office 365 and System Center Configuration Manager would align their release schedules. They are looking at a spring and fall release most likely in March and September. This is great news for businesses that have being struggling to adapt to the new Windows-as-a-Service model align with Office-as-a-Service. There are definitely inter-dependencies between Windows and Office as well as SCCM the tool commonly used to deploy, update and manage both Windows and Office.
From an IT Management perspective, organizations have been trying to accelerate the engineering efforts previously put into Windows and Office deployments and operationalize the process but the various product release schedules with low predictability have made it difficult. This should help by providing regular milestones and predictability. Good Job Microsoft.
Here is a link to the release from Microsoft
As organizations upgrade to Windows 10 there are many opportunities for security and performance improvements. Many of these enhancements rely of functionality that is only available with UEFI firmware as it is required for secure boot which is often a prerequisite for enhanced security features such as Device Guard and Credential Guard. Since Windows 7 did/does not support UEFI, most organizations will need to convert device firmware to UEFI as part of the Windows 10 upgrade. As upgrading to Windows 10 can be a long process, organizations have looked to tools like SCCM and MDT to automate and accelerate the process. Often time performing zero touch installations of hours or through self-service. Converting Bios to UEFI as part of the process ahs been problematic as each device may have different methods for converting and it typically requires visiting the device since the change happens in the before the operating system loads.
Microsoft has just made this problem a little easier to manage. SCCM 1702 introduces the ability to include UEFI conversion as part of a Task Sequence if the device supports it. I’m looking forward to accelerating many Windows 10 migrations with this functionality.