sccm

KB: PXE boots using the wrong wim file.

loadwim

If you happen to change the source name of a boot wim the pxe point may boot using the old file. To fix rename

<Drive Letter>RemoteInstallSMSImages<WIMPkgID>oldbootname.wim to oldbootname.wim.old

Next PXE boot it will then use the new boot.wim file.

 

Versioning and naming your base SOE .wim during OSD

If you replace the base wim (via build and capture) frequently it can be good to set versions and date the wim file that you import. It makes it easy to revert back if a change didn't go so well. Below are the steps in my build and capture to do versioning and work around a bug with naming your captured image.

1. At the top of my task sequence I set a task sequence variable SOEBaseVersion, each time I do a build and capture this is incremented.

Set SOEBaseVersion

2. After 'Setup Windows and Configuration Manager'  I have a 'Run Command Line' step with the following command so that we can utilize that value on deployed machines if ever needed:

cmd.exe /c reg add HKLMSoftwareSOE /v SOEBaseVersion /d "%SOEBaseVersion%"

Set SOE Reg

 

3. Next I run a vbscript to set the task sequence variable TSDate to the date in the format YYYYMMDD

Set env = CreateObject("Microsoft.SMS.TSEnvironment")
env("TSDate") = DatePart("yyyy",Date) & Right("0" & DatePart("m",Date), 2) & Right("0" & DatePart("d",Date), 2)

Screenshot 2014-10-22 16.21.49

 

4. In the 'Capture the Reference Machine' step I can then use the TSDate Variable to create a unique file name for the capture and also use the version field. There is a bug with the SCCM console as it doesn't use the Description field when importing, the next 2 steps resolve that.

Capture

 

5. Connect to OS Capture share.

Connect to share

6. Copy imagex to a package, then use it to run the following command line

imagex.exe /info R:\WIN81_x64_Base-%TSDate%.wim 1 "Windows 8.1 Enterprise" "WIN81 x64 - %TSDate%"

Set Image Description

 

7.  You can now import into SCCM with all the fields filled in correctly

Add Operating System Wizard

 

 

 

Adding custom programs to the Set Default Programs UI

Capture

Hi, today I wanted the CMTrace tool to be recognised in the Set Default Programs control panel applet. There is a bit of information on the net but it's confusing.

In the registry you can set the program, launch arguments, file types and icon. This can be used for any app by modifying the reg file.

 

Download reg file

 

Once added you may like to use DISM.exe to extract your chosen defaults and import during your task sequence.

Modular Task Sequence groups - Just an idea

bricks

Maik Koster has created a really good tool that monitors/ keeps backup of task sequence changes

http://myitforum.com/cs2/blogs/maikkoster/archive/2011/05/12/versioning-monitoring-sccm-task-sequences.aspx

expanding from this it may be possible to mark groups of your task sequences as modules. So say when a task sequence changes the script would then record the xml changes of that module group and replace in all task sequences where it is used. It would be perfect for the apply driver steps.

I haven't really worked it all out as I don't have many task sequences for it to be super useful and it would be a bit to hacky. I hope Microsoft can implement modules and version control in the next release of ConfigMgr.

 

 

Add a Right Click Copy Folder or File path menu option in Windows Explorer

SCCM ConfigMgr doesn't like quotes around paths when adding packages or Wims, etc so the secret shh shift + right click copy as path isn't that handy.

Here's a reg file to add a special right click option for ConfigMgr

Download

SCCM USB Boot disk creator

USB

I made a little program that sets up usb drives to be bootable into OSD winpe. I made it because we are getting devices without dvd drives that can't pxe boot and our techs don't have access to create bootable usb's from the console as they need the dp cert and password.

You generate a boot iso from the console, then copy the cd contents to the source folder where the program resides.

Program and my bad source code (if anyone wants to improve it) https://send.estate/s?e=8d189f24f1c9ada[1]

Pre-Reqs:
Dot Net 3.5
A bootable iso generated from the SCCM Console

Instructions:
Copy all files from the bootable iso to the source folder that resides with the exe.
Distribute as you wish.

BDEDrive size

BDEdrive

 

It helps to set a bit more space for this partition if you add more components to the boot wim, I chose to use 1GB. SCCM uses the drive with the most space that isn't encrypted to copy the boot wim down. We had issues in operating system deployment if the boot wim needed to be downloaded, the task sequence would fail as there wasn't enough space to store the boot wim.

Set Computer Model OEM Information during task sequence.

Make your SOE a little bit fancy

 

Model

 

To set the Computer Model information during OSD you just need to add a run command line step

Powershell.exe -ExecutionPolicy Bypass -Command $model = Get-WmiObject win32_computersystem model;Set-ItemProperty -Path HKLM:SoftwareMicrosoftWindowsCurrentVersionOEMInformation -Name Model -Value $model.model

 

 

Other Settings you can put in HKLMSoftwareMicrosoftWindowsCurrentVersionOEMInformation

Logo - Pathtologo.bmp
Manufacturer
SupportPhone
SupportURL

How I automate patching desktops

update automation

It takes a long time to setup but worth it, computers should
not get policies they don’t need, at some point things will start stuffing up. I
have split desktops into 3 categories that suit our environment. Pilot get updates straight away and will reboot at night. Prod and PUC get updates 7 days later and have different reboot requirements.

Group

Deadline

User notifications

Deadline behaviour outside maintenance window

Device restart behaviour

Pilot

Asap

All

SW Updates Install

Yes

Prod

7 days

None

SW Updates Install

Suppressed

PUC (Public Use computers such as Labs)

7 days

None

SW Updates Install

Yes

I then split these groups into collections based on OS or
Office version requirements, so we have Office 2007, Office 2010, Office 2013,
Windows XP, Windows 7 x86, Windows 7 x64, Windows 8 x64.

A Pilot, PUC and PROD collection should be made so you can
limit the collections with it. These collections will vary in your environment.

Based on that you should have 21 collections - see ‘rules
and queries’ at the end for the messy queries

SUM-WORKSTATIONS-PROD–Office 2007

SUM-WORKSTATIONS-PROD–Office 2010

SUM-WORKSTATIONS-PROD–Office 2013

SUM-WORKSTATIONS-PROD–Windows XP

SUM-WORKSTATIONS-PROD–Windows 7 x86

SUM-WORKSTATIONS-PROD–Windows 7 x64

SUM-WORKSTATIONS-PROD–Windows 8 x64

SUM-WORKSTATIONS-PILOT–Office 2007

SUM-WORKSTATIONS- PILOT–Office 2010

SUM-WORKSTATIONS- PILOT–Office 2013

SUM-WORKSTATIONS- PILOT–Windows XP

SUM-WORKSTATIONS- PILOT–Windows 7 x86

SUM-WORKSTATIONS- PILOT–Windows 7 x64

SUM-WORKSTATIONS- PILOT–Windows 8 x64

SUM-WORKSTATIONS-PUC–Office 2007

SUM-WORKSTATIONS- PUC–Office 2010

SUM-WORKSTATIONS- PUC–Office 2013

SUM-WORKSTATIONS- PUC–Windows XP

SUM-WORKSTATIONS- PUC –Windows 7 x86

SUM-WORKSTATIONS- PUC–Windows 7 x64

SUM-WORKSTATIONS- PUC–Windows 8 x64

Update: 

Limit your pilot collections to a group of user's primary computers using this collection query

 

[code language="sql"]
Select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client FROM SMS_R_System JOIN SMS_UserMachineRelationship ON SMS_R_System.Name=SMS_UserMachineRelationship.ResourceName JOIN SMS_R_User ON SMS_UserMachineRelationship.UniqueUserName=SMS_R_User.UniqueUserName WHERE SMS_UserMachineRelationship.Types=1 AND SMS_R_User.UserGroupName="DOMAIN\SCCM Software Updates Pilot User Group"
[/code]

 

Thanks Powersheller

Next you create a Software Update Group (the current
baseline of approved updates) for each Office/OS Version and a deployments for
each based on the rules from the first table.

Then you create Automatic Deployment rules for each
collection based (to run on Patch Tuesday/Wednesday Australia time) on the
rules from above and what type updates you want released in the last 3 weeks.  They should be set to create a new software update group each time. See ‘rules and queries’ for what I have used.

You can also create an EndPoint Protection definitions ADR, however that should be set to use the existing software update group as the updates always superseed each time.

Rules and Queries:

Query Name

Query

Office 2007

See attachment

Office 2010

See attachment

Office 2013

See attachment

Windows XP

See attachment

Windows 7 x86

See attachment

Windows 7 x64

See attachment

Windows 8 x64

See attachment

Attachment - Download

Rule Name

Rules

Office 2007

Date Released or revised: Last 3 weeks

Product: “Office 2007”

Title: 32-Bit

Update Classification: “Critical Updates” OR “Security Updates” OR
“Updates” OR “Definition Updates”

Office 2010

Date Released or revised: Last 3 weeks

Product: “Office 2010”

Title: 32-Bit

Update Classification: “Critical Updates” OR “Security Updates” OR
“Updates” OR “Definition Updates”

Office 2013

Date Released or revised: Last 3 weeks

Product: “Office 2013”

Title: 32-Bit

Update Classification: “Critical Updates” OR “Security Updates” OR
“Updates” OR “Definition Updates”

Windows 7 x86

Date Released or revised: Last 3 weeks

Product: “Windows 7”

Title: -x64

Update Classification: “Critical Updates” OR “Security Updates” OR
“Updates”

Windows 7 x64

Date Released or revised: Last 3 weeks

Product: “Windows 7”

Title: x64

Update Classification: “Critical Updates” OR “Security Updates” OR
“Updates”

Windows 8 x64

Date Released or revised: Last 3 weeks

Product: “Windows 8” OR “Windows 8.1”

Title: x64

Update Classification: “Critical Updates” OR “Security Updates” OR
“Updates”