Gather Lenovo Warranty Information with PowerShell

It’s been way to long since I’ve posted anything on this blog, so I figured it was time to do something about that.

I’ve previously shared some scripts on this blog on how to gather warranty information for Lenovo systems. Since both of those script where based on parsing through the web page displaying Lenovo’s warranty information for a system, they stopped working every time Lenovo changed the layout of the page.

So before giving another shot at this I spent some time searching for a better solution in the community. I found this post Get Lenovo Warranty Information with PowerShell by Nickolaj Andersen over at SCConfigMgr, but this solution was also parsing through the web page of Lenovo’s warranty information and I didn’t want to go down that road again. After some more research I stumbled over this posting over at the Lenovo forum.

So I decided to give it a shot and came up with the script below;

Advertisements

Windows 10 1607 – Taskbar and Start Customization Deep Dive

With the announcement of taskbar configuration in Windows 10 1607, I was eager to start exploring this option.

There is already released a couple of blogposts on this subject from highly skilled persons.

• Customize Pinned Items on Taskbar in Windows 10 1607 during OSD with ConfigMgr
• Pin apps to the Taskbar in Windows 10 1607 with Group Policy

So I started out with high hopes, but sorry to say the way things are working now, this is not usable for me and the scenarios I’ve been working with.

OSD Pre-Flight Checks

As a consultant, I have done numerous installations of Configuration Manager and one of the things that usually generate problems is when tasks are delegated from the Configuration Manager team over to other parts of the organization or third party. This solution will catch some of the most common issues that occur when handing over OSD to another team.

You as a deployment expert and the person who set up and have full control over your Configuration Manager environment will catch most of these issues without this tool. However, if a person on first line support is given the task to deploy new computers to end users he or she has no clue on what’s set up in the background and this tends to generate issues. An example being, deploying a computer model that has no driver packages assigned.

So I wanted to create a simple tool that check for the most common issues at the very beginning of the task sequence, no one wants to wait for several minutes just to find out that there is no driver package for this model. There are some solutions for this already out there but they are usually part of a UDI/Front-End solution or steps in the Task Sequence that give hard failure and fails the task sequence without any options to correct the problem. Therefore, I ended up with these criteria’s,

• Must be dynamic, only appear if something will/could prevent the task sequence from completing successfully else continue as normal
• Errors or warnings must appear at the very beginning of the task sequence, and it must be possible to correct these without the need for re-starting the task sequence
• Provide information about the computer in case of an error or warning

What I ended up with looks like this in action:

Display Correct Computer Name During OSD

Last year I blogged about how to show DP in use during OSD you can find that posting here.

I’ve gotten some questions on how to display the correct computer name in the background with bginfo instead of the MININT-XXXXXXX name.

I’ve created a script with the following lines;

'//---------------------------------------------------------
'// Purpose: Used to display correct computer name during OSD
'// Version: 1.0 - April 17, 2015 - Odd-Magne Kristoffersen
'//
'// This script is provided "AS IS" with no warranties
'//
'//---------------------------------------------------------
Set env = CreateObject("Microsoft.SMS.TSEnvironment")
Echo env("OSDCOMPUTERNAME")

and saved it as SetComputerName.vbs in the Tools\x86 folder of my MDT Toolkit Package.

I then modified STEP_01.BGI and STEP_02.BGI files provided in the MDT Toolkit Package to utilize this VBScript and display the information, below you see what changes you need to make to each of the provided BGInfo files. Alternatively, you can download a copy of them already modified here and replace the ones already existing in you Tools\x86 folder of your MDT Toolkit Package.
When done update the MDT Toolkit Package and start a new deployment and you’ll be able to see the correct computer name during deployment as shown below.

Fixing sysprep in MDT 2013 Update 1 for Windows 10 Build 10041

Microsoft released a preview of MDT 2013 Update 1 to support Windows 10 and it’s working fine with build 9926.

Build 10041 was released to the fast ring as an update last week and as previously stated by Microsoft no updated ISO will appear before it’s released to the slow ring.

Johan Arwidmark posted an article on how to create your own ISO from Build 9860 update and this still works for Build 10041 as I tweeted last week.. (Also and updated article is posted here)

I created the ISO, imported Windows 10 Build 10041 into MDT and was ready to do and build and capture with MDT.

Everything looked fine until it came to the Sysprep step, where it failed with the following error Messages;

By looking at the LTISysprep.wsf, we can see that script check for If oEnvironment.Item(“OSCurrentBuild”) >= “6000” two places (under these two sections “Prepare for running Sysprep” and “Run the appropriate Sysprep based on the OS Version”) and this worked for previous build as it was 9926, but now it’s 10041 and it doesn’t hit this rule, so sysprep will fail.

So I edited LTISysprep.wsf and added or oEnvironment.Item(“OSCurrentBuild”) >= “10041” to the two places as shown below

Now the build and capture task sequence completed with no issues.