I’ve created this spreadsheet and use it to track our progress week by week of our Windows 7 to Windows 10 migration project. Now that end of support for Windows 7 is under a year away I thought I’d share it for anyone who might find it useful.
On 11 January 2019 I had the privilege to speak at the Michigan System Center Users Group meeting on the topic of using Power BI to report your OSD build stats. This is a companion post to that presentation.
This is an update to my original post ( here ) on how to gather and present statistics on your build sequences. I’ve taken what I’ve learned since that original post and have expanded the process to handle not only an OSD “build” but also a WaaS CompatScan or In-Place Upgrade, or any other Task Sequence.
I’ve been looking for a simple way to identify and map out the nested task sequences. This is the first part of a project that I’m working on. The goal of the overall project is to duplicate an entire task sequence “suite” of the parent and all nested sequences, and then update all the nested references.
[6-Jul-2018: Updated Script to v 1.2 – New .NET 3.5.1 install command (per Mike Horton @mikeh36)]
After attending MMS one of the items that I put on my “Post-MMS To Do” list was to patch my OS Upgrade package source the proper way. I don’t want to do it manually, nobody does, so I set out to learn exactly how to do it right and script it.
That where Mike Terrill and Johan Arwidmark come in.
How to provide hard statistics on your build sequences.
A while back my boss gave me two goals for our OS deployments; 1) he set a target for 90% successful builds and 2) build times as close to 1 hour as possible. Okay, getting there is one thing, but how do I report on that?
Last week I wrote a post about setting up Windows PE Peer Caching. One of the limitations of that feature is that it only works within the Windows PE portion of a build task sequence. Once in the full OS or for deployments to established clients Peer Caching is unavailable.
Phil Wilcock, co-founder of 2Pint Software, commented and pointed out that you could use Peer Caching for getting the OS deployed and then use BranchCache within the full OS.
Now, I’ll be honest here. I understand the “textbook” when it comes to BranchCache but I had never actually set it up. It always seemed to fall under the, “One day I’m going to have to give that a try.” Well that day is today. This post will get BranchCache working with Configuration Manager. Once that is done my next step will be getting 2Pint’s BranchCache for OSD up and running.
“Unless you try to do something beyond what you have already mastered, you will never grow.”
-Ralph Waldo Emerson
What is Windows PE Peer Caching?
Windows PE Peer Caching was a feature added in Configuration Manager Technical Preview 2. During an OS deployment, it allows a machine being built to pull content from other systems on the local subnet (its peers) as opposed to going across a potentially slow WAN connection. It is quite simply a peer-to-peer network of content providers. This is similar functionality to 1E’s NomadBranch and 2Pint’s BranchCache for OSD Toolkit.
Configuration Manager 1511
After completing the first three parts of this series you would have a virtual lab with 4 separate network segments all connected to and routed through a Windows 2012 R2 server (RTR01) acting as the router. This server will also provide Internet access to any virtual machines that are connected to the 4 network segments. You also would have an Active Directory domain controller (DC01) that provides DHCP and DNS services to the lab.
In Part 4 we are going to build out a Configuration Manager 1511 infrastructure. This will include a Primary site server (CM16) and 2 Distribution Points (DP16a & DP16b).
|Part 1||Setting Up|
|Part 2||First VM – Windows Router|
|Part 3||Domain Controller|
|Part 4||Configuration Manager Infrastructure|
After completing parts 1 and 2 of this series you would have a virtual lab with 4 separate network segments all connected to and routed through a Windows 2012 R2 server (RTR01) acting as the router. This server will also provide Internet access to any virtual machines that are connected to the 4 network segments.
In Part 3 we are going to build a domain controller (DC01). This server will provide not only Active Directory Domain Services to the lab but also DHCP and DNS services as well.