Posts Tagged Task Sequence
In assisting a recent customer implement an upgrade from WinXP to Win7, they requested that the names be changed to fit a new standard as part of the in-place imaging process. In this particular case, all of the computers had a name that ended with a sequential number (1, 2, 3, …) plus an “A” tacked on at the end. They wanted the “A” removed and for the PC name just to end with the sequential number.
This was a pretty easy fix to accomplish through a VBScript which
- Retrieves the active OSDComputerName task sequence variable
- Detects if the last letter is an “A”
- Truncates the name to remove the “A”
- Re-sets OSDComputerName to the new value
'========================================================================== ' NAME: PCNameStandardization.vbs ' AUTHOR: Nick Moseley, <a href="http://t3chn1ck.wordpress.com">http://t3chn1ck.wordpress.com</a> ' COMMENT: This script will detect if the current computer name ends with ' the letter 'A' so that it can be removed. '========================================================================== Option Explicit Dim oTaskSequence, sComputerName, iNameLength Set oTaskSequence = CreateObject ("Microsoft.SMS.TSEnvironment") sComputerName = ucase(oTaskSequence("OSDComputerName")) iNameLength = Len(sComputerName) If right(sComputerName,1) = "A" Then oTaskSequence("OSDComputerName") = left(sComputerName, iNameLength-1) ' The echo statement is not displayed, but rather registered in SMSTS.log wscript.echo ">>>> Set OSDComputerName from " & sComputerName & " to " & oTaskSequence("OSDComputerName") End If
To add this into your task sequence:
- Put this script into a package for your general OSD Scripts
- Ensure you have the step to capture the computer name
- Immediately after the capture windows settings, run the PC Standardization Script
- On whatever step you have that prompts for the PC Name, add a condition to not execute if variable OSDComputerName does not exist. This is so that task sequence will not be held up on the other end waiting for someone to enter a PC name for one you’ve already set.
- Finally – ensure ConfigMgr environment is configured to automatically resolve conflicting records! See this as to why http://t3chn1ck.wordpress.com/2013/02/14/error-initializing-client-registration-0×80040222/
A common practice for OSD task sequences is set the advertisement to “run from server”. Recently there was a situation in which the advertisement needed to be set as “download content locally”. But there were scripts which needed to be executed BEFORE a disk partition existed, so the task sequence would fail with error code 0x800700a1 because there wasn’t a local disk in which to save the files.
There are a few ways to workaround this situation.
1. If possible, have the advertisement/deployment configured to run from server
2. Use DISM.exe to add the scripts into the boot image(s) (or use GImageX), then have a Run Command Line task to execute the scripts.
Note: the challenge with this method is it’s a bit tedious to maintain those scripts.
3. Use the “Connect To Network” task to map to a network drive, then have a Run Command Line task to execute the scripts.
Note: the challenge with this method is the possibility of scripts running across the WAN, which could be less than ideal if the scripts or installers are large or if the network files are not available.
One of the “gotchas” of BitLocker security is that by not having the hard drive first in the boot order within BIOS, can cause BitLocker security to become enacted and thus needing manual entry of the 48-character key upon the next system restart. This can be a frustration for users who have this happen to them, especially while travelling and unable to reach the help desk. So, during an OS deployment, make efforts to change the boot order in BIOS.
To do this with HP
- Obtain the BIOSConfigUtility in the Systems Software Manager
- Create a text file named “BootOrder.REPSET”. The text file contains the below content. Note that I found it is necessary to define two devices to modify the boot order.
English Boot Order Hard Drive(C:) Notebook Upgrade Bay
- Run command
To do this with Dell
- Obtain the Client Configuration Toolkit
- Run command
cctk.exe bootorder --sequence=hdd
If you find yourself in a position that you did not do this during the initial deployment of the OS, never fear, SCCM is here! Using task sequences, you can automate the process as to set the hard drive to be first in the boot order and re-seal the TPM by performing the following steps:
First, let me start by saying there is already a good blog post which outlines how to use HP’s BIOSConfigUtility in an MDT task sequence (which can be easily translated into an SCCM task sequence).
I recently implemented this tool for a client to enable the TPM feature in BIOS in preparation for BitLocker. The utility was being run from a task sequence with command line such as:
cmd.exe /c c:\temp\BIOSConfigUtility.exe /SetConfig:TPMEnable.REPSET /NewAdminPassword:"P@55word!"
In my testing, the BIOS password was being set properly, but the TPM enable would not get enabled. BIOSConfigUtility.exe would terminate with error code 10, which essentially meant it was trying to enable TPM but the provided password is incorrect. What I found to fix the problem was to instead specify the full path to TPMEnable.REPSET file. So instead, the switch would instead be:
If you have a custom HTA or dialog box as part of a task sequence, the dialog box could get in the way. And it’s quite annoying to manually drag it out-of-the-way every time. A workaround to this is to hide that task sequence dialog box altogether with the following VBScript. So run this bit of code before you launch the HTA
On Error Resume Next ' Hide the task sequence window Set ProgressUI = CreateObject("Microsoft.SMS.TsProgressUI") ProgressUI.CloseProgressDialog
A challenge with installing software updates during a task sequence is that it may occur where not all updates are applied on the first pass. The workaround is run software updates, run a VB Script or PowerShell script to force another scan, then run a software updates task again. Others have posted their scripts on this before, so it’s nothing new. However, I failed trying to quickly locate those scripts. So I’m just posting my own of what I use….
'========================================================================== ' AUTHOR: Nick Moseley , http://t3chn1ck.wordpress.com ' DATE : 7/30/2010 ' COMMENT: Initiates an SCCM client scan ' Script from http://msdn.microsoft.com/en-us/library/cc144313.aspx ' Updated 7/15/11 to include a sleep before exiting script '========================================================================== ' Set the required variables. actionNameToRun = "Updates Source Scan Cycle" ' Create a CPAppletMgr instance. Dim oCPAppletMgr Set oCPAppletMgr = CreateObject("CPApplet.CPAppletMgr") ' Get the available ClientActions object. Dim oClientActions Set oClientActions = oCPAppletMgr.GetClientActions() ' Loop through the available client actions. Run the matching client action when it is found. Dim oClientAction For Each oClientAction In oClientActions If oClientAction.Name = actionNameToRun Then oClientAction.PerformAction End If Next ' Wait for 3 minutes for scan completion before exiting script wscript.sleep(180000)
Ran into an interesting situation with an image build. I created a custom Office 2010 SP1 install using the OCT. During execution of my image build task sequence, Software Updates was not detecting any of the updates for Office. Further diagnosis revealed that the OCT-built install did not put its “hooks” into the Windows Update Agent, therefore neither the SUP or Microsoft Updates could detect for Office updates. (Side note: once the image was sysprepped, captured, and added into a deployment task sequence, the updates were suddenly available and installed.)
While the cause as to why an OCT-built Office 2010 SP1 install prohibits installation of updates has not been found yet, there is a workaround to run a script that forces Microsoft Update (e.g. WUA) to receive updates for “other products”. By executing the following VBScript after installing Office, SCCM Software Updates will then be able to install the updates during the image build task sequence. The original code is from a TechNet blog post, I just added some extra logging for troubleshooting. Also, if your TS advertisement is configured to “run from server”, then the script will cause the TS to fail. To get past this, simply copy the script locally first then execute it from that location.
Const ForAppending = 8 Set oFSO = CreateObject ("Scripting.FileSystemObject") Set oLogFile = oFSO.OpenTextFile ("C:\ConfigOfficeUpdates.txt", ForAppending, True) oLogFile.WriteLine "Starting execution of VBScript to configure Office to use Microsoft Updates" Set ServiceManager = CreateObject("Microsoft.Update.ServiceManager") ServiceManager.ClientApplicationID = "My App" ' add the Microsoft Update Service by GUID Set NewUpdateService = ServiceManager.AddService2("7971f918-a847-4430-9279-4a52d1efe18d",7,"") oLogFile.WriteLine "Script completed successfully" wscript.Quit(oLogFile.Close)
Cool way to automagically include support-related files in your boot images for troubleshooting during task sequences. I’m re-blogging it so I would always remember it ;-)
<< Edit: Prior to following instructions in this posting, please review http://support.microsoft.com/kb/974524 regarding Vista and Server 2008 >>
I frequently use task sequences to quickly and easily chain multiple, unrelated, software distributions together for deployment during our business scheduled maintenance window. One of the powerful things about using a task sequence is that a particular software install task can be limited to only run if certain criteria is met, such as only run the install of hotfix XYZ if Outlook 2010 is currently installed (otherwise skip). This can be done by using a WQL query that says “Select * from Win32_Product where Name = ‘Microsoft Office Professional Plus 2010′“.
In working on a new distribution of updates, I was met with a new situation for limiting software execution to only run if a particular software was NOT installed. Still using the same WQL query as an example above, it simply doesn’t suffice to replace the equals with “not equals” or “<>” because there will always be at least one installed software that is not Office 2010. Thus the logic fails and the task would execute…but we want it to NOT execute.
Instead, I used an If condition – that If none of the WQL query is true (e.g. installed) then DO execute. I tested this on a computer that already had the software (it skipped) and one that did not (it ran). So all is good! It was just a new thing I had not done in a task sequence before that I thought I’d share with everyone…..