Tuesday, 28 March 2017

My favourite features of ConfigMgr 1702

Configuration Manager Current Branch 1702 was released this week and is available as an in-console update for existing 1606 and 1610 sites. Read the official blog post here

As we've come to expect, 1702 offers a raft of new features for managing our estate of devices. There are some big hitters such as:
  • Support for express installation files for Windows 10 updates
  • Ability to add software update points to boundary groups to control which SUP clients can use
  • Being able to configure Office 365 installation settings from the Office 365 Client Management dashboard
Note that there are some deprecations also. Most notably, support has been dropped for the following:
  • SQL Server 2008 R2 for site database servers
  • Windows Server 2008 R2, for site system servers and most site system roles

Often though, my favourite features are less obvious. I've got two in this latest release:

1. I've always hated when customers ask me to create an OSD solution and give them the ability to deploy the OS using stand-alone media. I didn't like the idea of sending USB keys out in the field with no version control and no great way to withdraw them if they were superseded. Now we can set start and expiration dates on standalone media. Perfect, we can now timebomb the media so that it won't work after a pre-defined period.

I've configured the media so that it can't be used for a few days and will then expire in 2 months. I don't care if I never get it back now.

2. A new hardware inventory class (SMS_Firmware) and property (UEFI) have been added to determine if a computer is enabled to start in UEFI mode. This is a welcome addition so that we can report on the UEFI status of the estate. You're missing a trick if you're not using UEFI and enabling security features like Secure Boot. After all you already own it. That's like not locking the doors of your house or car because you couldn't be bothered.

I hope you're enjoying 1702. Until next time.....

Thursday, 2 March 2017

ConfigMgr OSD - use MDT without using MDT

The title may not make much sense but please read on about a recent customer requirement.

Customer requirement

In the task sequence, set the computer name to match the service tag


Easy - use the OSDComputerName variable with a value of %SerialNumber% (or was it that easy?)

Problem Statement

How does the %SerialNumber% value get populated in this case? This is straightforward if I'm using MDT integration as I can use the Gather step. However, the customer does not have MDT integrated and this would take a few weeks to organize with a strict change request procedure.
So what do I do?

Solution (revised)

Do I actually need MDT integrated or do I just need some MDT files?

I had a word with @ncbrady from @WindowsNoob and we came up with a plan. I installed MDT on a laptop and created a deployment share.

I figured that these files were all that I needed - only 45MB. I copied the files to my content source location and created an MDT Gather package (with no program).
Then I configured the TS as shown in the screenshots.

First I ran ZTIGather.wsf with this command

Cmd.exe /c cscript.exe .\Scripts\ZTIGather.wsf /debug:TRUE

This was to "discover" the service tag.

The next step was to set the hostname to match the serial number (service tag).

Unfortunately the task sequence failed:

"Gathering complete, but no INI file found” with an error code of 0x00001F40

On examining the smsts.log file the hostname was in fact set to the service tag, even though the task sequence failed. Happy days. I was just missing a customsettings.ini file. I manually created a default .ini file and copied it to the scripts folder.



That did it - SUCCESS.
Thanks for the assistance Niall.

Until next time.......

Edit #1:

Jörgen Nilsson has contacted me to say that only a few of the MDT files are actually required (less than 800KB). Here they are:

Thanks Jörgen.

Edit #2:

I've had some feedback about other ways to set the computer name to the service tag without using MDT. Thanks for that. However, the whole point of this post was to show how you can achieve MDT functionality without actually integrating MDT with ConfigMgr.

After all, the title is "Use MDT without using MDT".