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 13, 2015 in Office 365
Tags: Office 365 ProPlus
In this article, I will try to cover how monthly updates for Office 365 ProPlus can be managed in your environment as a follow-up on my article on how to deploy Office 365 ProPlus with Configuration Manager 2012 R2.
First, I would like you to think as the monthly releases as builds, rather than updates. The builds are provided monthly, contains security, non-security changes and are cumulative. You are always at most one update away from the latest build.
Around 1 year ago, Office IT Pro Blog released the following two articles covering how to manage updates at that point; Managing Updates for Office 365 ProPlus – Part 1 and Managing Updates for Office 365 ProPlus – Part 2.
Since then there has been some updates that can ease this process, I will also cover how to implement a solution that covers roaming users. The articles above doesn’t take roaming users into consideration and you could end up with roaming users downloading big amounts of data over an slow/expensive WAN link.
So let’s set the scenario.
Read the rest of this entry »
One of my most popular blogposts of 2014 was Customize Office 365 ProPlus Installation, and I see that many search terms on how to deploy Office 365 ProPlus with Configuration Manager (SCCM) ends up on this posting. That is why I decided to write up a how-to guide on how to deploy Microsoft Office 365 ProPlus with Configuration Manager.
This Step-by-step guide describes how to prepare, add and deploy Microsoft Office 365 ProPlus using System Center 2012 R2 Configuration Manager (SCCM). I also share some tips on how to configure Microsoft Office 365 ProPlus for a seamless user experience.
Download the complete guide here in PDF format.