Windows 10 Lock Screen

So, you think you’re setting the lock screen, just to have OSD finish and be like “Why is the lock screen missing and showing a dark blueish color?” or “Argh, it’s the stinking Windows default lock screen, not the one I wanted”. Perhaps you have a lab, and don’t activate your PC’s, so you get the rotating Bing Picture of the day, which is actually pretty cool and all, unless you’re trying to test Lock Screens.  Thanks to Doug (managedoug.com) for bringing this to my attention and having me dig into it a bit more.

I’ve got Several Steps to control this during OSD which include Copying Files over the default lock screen images, and setting registry keys, basically depends on exactly what outcome you’re looking for.

Scenario 1, you want to set the Lock Screen and NEVER allow the user to change it.

Scenario 2, you’re cool with the user changing it, but want to set it to your own custom default.

To accomplish both, there are several things in common you need to do, so I’ll start with the steps you need to do for either situation, then break apart the single additional step that enables scenario 1.

Read more

WaaS–Post 1–PreCache Compat Scan TS

So this will be the first of several posts, well, it’s sorta the second, this heavily relies on the Script I posted for writing values to registry & WMI a few posts ago, however I’ve made several modifications to it since then, and have done A LOT of testing. Hence my last post about testing Low Disk Space machines.

WaaS Process, as Designed by Mike Terrill & Keith Garner quick overview:

  1. PreAssessment:  Set of Rules run against hardware inventory data to rule out machines that be known to fail the upgrade. Rules include:
    1. Hardware Checks
      1. Models
      2. Free Disk Space
      3. Memory
    2. Software Checks (Software we know that needs to be at specific versions to survive IPU, or not block it)
      1. 3rd Party Encryption Version level
      2. 3rd Party AV Version level
      3. Several other Apps
    3. General Checks
      1. Last HWInv Date
      2. Last MP Checkin
      3. OS / Build / OS Arch
      4. CCM Cache Size
  2. PreCache / Compat Scan (Task Sequence): After it passes all of the rules, the computer then added to a collection targeted with this TS.  The TS is setup as a Required Deployment, and set to Pre-Download Content, and Download all Content before starting the TS.  Then will dynamically download the driver packages, run the Check Readiness, and then Compat Scan.
  3. Schedule for Upgrade: After it has been cached, and passes the compat scan, the machines can be schedule (added to collection targed with the upgrade).

That’s a really quick overview of how we’ve setup WaaS, we went over this in great detail @ MMS, and I’d expect Mike Terrill to eventually blog that detail, I just don’t want to steal all of this thunder, but felt you needed a little overview to explain where this TS fits in.

Read more

Test Low Disk Space / Create Large Test File

So I stole this code from my friend Keith G, who provided it to assist with testing scenarios to see if our safe guards would work.
Basically, the 1 line command will check your drive, then create a dynamically sized file to leave “XX” GB remaining.  In my command, I leave only 15GB Free, which is low enough to trigger a failure on our in place upgrades.  Then I can test to make sure the the IPU TS fails the way I expect, running the proper remediation steps, and records the metrics for reporting.

Code: (run in elevated PowerShell Console)

get-volume c | % {$_.SizeRemaining - 15GB} |  % {Fsutil file createnew c:\TestFile.id $_}

So I made it into an App, I’ve added a few items into the app model to allow me to “install” it quickly on a machine to test failure scenarios.

App Code:

powershell.exe -command "get-volume c | % {$_.SizeRemaining - 15GB} |  % {Fsutil file createnew c:\TestFile.id $_}"

Read more

Collect OSD / IPU Info with Hardware Inventory

Update 2019.01.22 To include User Account that triggered the Upgrade & Unique Build Record Info. Blog Post for “Gather Account Name during IPU” HERE

Update 2018.08.01 To include Hard  Blocker from  Compat Scan, requires you to add a step into the TS to capture the Hard  Blocker to a  TS Variable,  Blog Post HERE

Update 2018.06.05 – I’ve posted the first WaaS Post, which incorporates this Script into a Compatibility Scan Task Sequence.  I’ve updated the script since this post, which is available to download, along with the Task Sequence Export in this POST HERE

Several years ago I started to use Jason Sandys’ OSDInfo Script.  I liked the idea of having a script run during OSD that would write information to WMI, which made it easy to inventory.  Now I do IPU (In Place Upgrade) so much more than OSD, and I wanted to do the same, gather important information from IPU and be able to use it for Reporting or creating collection queries.

I’ve taken Jason’s script and modified it… a lot.  All of his plumbing is still in place (functionality to add information to WMI & Registry), but I’ve added a lot of logic around using the script for different functions.

The script is now broken into 3 sections, OSD (Operating System Deployment), CS (Compatibility Scan), IPU (In Place Upgrade).  Using TS Variables, the script will run different sections of the script.  This allows me to use the same script in numerous scenarios.
First, I’ll show you results, and then go into details about how it’s done.  But I feel it’s easier to understand the script and process if you can see the end product.

Read more

Get Package CCMCache Location

Ever want to know where in the CCMCache the content was located for that package that was downloaded?  Ever think you found it, then figured out it wasn’t the most updated version of the content?  I quick wrote this script to help me find where in the cache the content is located, and spits back the most updated version of it.

Read more