Posted: August 18, 2016 in Windows 10
Tags: Windows 10
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.
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.
Read the rest of this entry »
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:
Read the rest of this entry »
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")
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.
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.
Posted: January 5, 2015 in Uncategorized
The WordPress.com stats helper monkeys prepared a 2014 annual report for this blog.
Here’s an excerpt:
The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 100,000 times in 2014. If it were an exhibit at the Louvre Museum, it would take about 4 days for that many people to see it.
Click here to see the complete report.